dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	Pierre Asselin <pa@panix.com>
Cc: mairacanal@riseup.net, dri-devel@lists.freedesktop.org,
	jose.exposito89@gmail.com
Subject: Re: [PATCH v3 01/13] firmware/sysfb: Fix EFI/VESA format selection
Date: Mon, 17 Apr 2023 09:34:14 +0200	[thread overview]
Message-ID: <8124f39d-cd64-be21-2f3c-bad590a3ccf3@suse.de> (raw)
In-Reply-To: <87sfd5s5tu.fsf@minerva.mail-host-address-is-not-set>


[-- Attachment #1.1: Type: text/plain, Size: 4715 bytes --]

ping

Am 12.04.23 um 13:22 schrieb Javier Martinez Canillas:
> "Pierre Asselin" <pa@panix.com> writes:
> 
>>> Can you please share you grub config file? It seems that is set to
>>> GRUB_GFXMODE=1024x768x32 but the actual mode is set to 1024x768x24 ?
>>
>> Okay, but you'll be sorry...  The gfxmode is set to "keep" in all the
>> entries.  https://www.panix.com/~pa/linux-6.3-simplefb/grub.cfg .
>>
>> The "TEST" entry was used to bisect.  The "PRE-TEST" was to set things
>> up, to receive the bzImages compiled on a faster machine. Now I boot
>> the "Linux 6.3.0-rc5-x86".
>>
>>
>>> That is, it fails when the picked format is DRM_FORMAT_RGB8888 but
>>> works when is DRM_FORMAT_XRGB888. I can't spot any error in Thomas'
>>> patch so I wonder if the problem is with what grub is passing to the
>>> kernel.
>>>
>>> The mentioned vga=0x318 workaround that you mentioned makes the mode
>>> passed to match the selected DRM_FORMAT_RGB888 which I guess is why
>>> that worked for you.
>>
>> All right, I did a series of reboots, editing the grub command line
>> to change the "gfxpayload=" grub option or the "vga=" kernel option.
>> In each case I captured the output of
>>    "dmesg | egrep -i 'fbcon|console|fb0|frameb|simple|vga|vesa'
>>
>> https://www.panix.com/~pa/linux-6.3-simplefb/selected-modes
>>
>> (D'oh.  My script printed "vga=vga=" twice when that option was set.
>> Good enough as is.)
>>
>> Note the difference in linelength= between the bad and good r8g8b8.
>> Does it mean anything ?
>>   (bad)> format=r8g8b8, mode=1024x768x24, linelength=4096
>> (good)> format=r8g8b8, mode=1024x768x24, linelength=3072
>>
> 
> Ah! That's a good data point and I believe that found a possible issue in
> the sysfb format selection logic. Can you please try the following patch?
> 
>  From 55b5375c528b4128350dfa2126277049f8821349 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javierm@redhat.com>
> Date: Wed, 12 Apr 2023 13:20:48 +0200
> Subject: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is
>   calculated
> 
> The commit f35cd3fa7729 ("firmware/sysfb: Fix EFI/VESA format selection")
> fixed format selection by calculating the bits-per-pixel instead of just
> using the reported color depth.
> 
> But unfortunately this broke some modes because the stride is always set
> to the reported line length (in bytes), which could not match the actual
> stride if the calculated bits-per-pixel doesn't match the reported depth.
> 
> Fixes: commit f35cd3fa7729 ("firmware/sysfb: Fix EFI/VESA format selection")
> Reported-by: Pierre Asselin <pa@panix.com>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> ---
>   drivers/firmware/sysfb_simplefb.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/sysfb_simplefb.c b/drivers/firmware/sysfb_simplefb.c
> index 82c64cb9f531..5dc23e57089f 100644
> --- a/drivers/firmware/sysfb_simplefb.c
> +++ b/drivers/firmware/sysfb_simplefb.c
> @@ -28,7 +28,7 @@ __init bool sysfb_parse_mode(const struct screen_info *si,
>   			     struct simplefb_platform_data *mode)
>   {
>   	__u8 type;
> -	u32 bits_per_pixel;
> +	u32 bits_per_pixel, stride;
>   	unsigned int i;
>   
>   	type = si->orig_video_isVGA;
> @@ -54,14 +54,19 @@ __init bool sysfb_parse_mode(const struct screen_info *si,
>   	 * bits_per_pixel here and ignore lfb_depth. In the loop below,
>   	 * ignore simplefb formats with alpha bits, as EFI and VESA
>   	 * don't specify alpha channels.
> +	 *
> +	 * If a calculated bits_per_pixel is used instead of lfb_depth,
> +	 * then also ignore lfb_linelength and calculate the stride.
>   	 */
>   	if (si->lfb_depth > 8) {
>   		bits_per_pixel = max(max3(si->red_size + si->red_pos,
>   					  si->green_size + si->green_pos,
>   					  si->blue_size + si->blue_pos),
>   				     si->rsvd_size + si->rsvd_pos);
> +		stride = DIV_ROUND_UP(si->lfb_width * bits_per_pixel, 8);
>   	} else {
>   		bits_per_pixel = si->lfb_depth;
> +		stride = si->lfb_linelength;
>   	}
>   
>   	for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> @@ -80,7 +85,7 @@ __init bool sysfb_parse_mode(const struct screen_info *si,
>   			mode->format = f->name;
>   			mode->width = si->lfb_width;
>   			mode->height = si->lfb_height;
> -			mode->stride = si->lfb_linelength;
> +			mode->stride = stride;
>   			return true;
>   		}
>   	}
> 
> base-commit: fd35174e13f98f9232c4aa66689816731d34ca28

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2023-04-17  7:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-02 11:29 [PATCH v3 00/13] drm: Fix color-format selection in fbdev emulation Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 01/13] firmware/sysfb: Fix EFI/VESA format selection Thomas Zimmermann
2023-04-06 15:45   ` Pierre Asselin
2023-04-08 11:26     ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-04-16 12:06       ` Linux regression tracking #update (Thorsten Leemhuis)
2023-04-08 16:10     ` Pierre Asselin
2023-04-11 15:56       ` Javier Martinez Canillas
2023-04-11 19:39         ` Pierre Asselin
2023-04-12 11:22           ` Javier Martinez Canillas
2023-04-17  7:34             ` Thomas Zimmermann [this message]
2023-01-02 11:29 ` [PATCH v3 02/13] drm/format-helper: Comment on RGB888 byte order Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 03/13] drm/format-helper: Fix test-input format conversion Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 04/13] drm/format-helper: Store RGB565 in little-endian order Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 05/13] drm/format-helper: Type fixes in format-helper tests Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 06/13] drm/format-helper: Flip src/dst-format branches in blit helper Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 07/13] drm/format-helper: Add conversion from XRGB8888 to ARGB8888 Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 08/13] drm/format-helper: Add conversion from XRGB8888 to ARGB2101010 Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 09/13] drm/format-helper: Add conversion from XRGB8888 to 15-bit RGB555 formats Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 10/13] drm/fh-helper: Split fbdev single-probe helper Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 11/13] drm/fb-helper: Fix single-probe color-format selection Thomas Zimmermann
2023-01-03 21:18   ` Maíra Canal
2023-01-04  8:14     ` Thomas Zimmermann
2023-01-04 10:34       ` Maíra Canal
2023-05-12 13:20   ` Linus Walleij
2023-05-12 14:11     ` Thomas Zimmermann
2023-05-15  8:01       ` Linus Walleij
2023-05-15  8:17         ` Thomas Zimmermann
2023-05-15  8:59           ` Linus Walleij
2023-05-15  9:26             ` Thomas Zimmermann
2023-05-15  9:30               ` Linus Walleij
2023-05-15  8:16       ` Daniel Vetter
2023-05-15  8:42         ` Thomas Zimmermann
2023-05-14 12:10     ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-05-26 12:22       ` Linux regression tracking #update (Thorsten Leemhuis)
2023-01-02 11:29 ` [PATCH v3 12/13] drm/format-helper: Simplify drm_fb_build_fourcc_list() Thomas Zimmermann
2023-01-02 11:29 ` [PATCH v3 13/13] drm/format-helper: Remove unnecessary conversion helpers Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8124f39d-cd64-be21-2f3c-bad590a3ccf3@suse.de \
    --to=tzimmermann@suse.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=jose.exposito89@gmail.com \
    --cc=mairacanal@riseup.net \
    --cc=pa@panix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox