Thomas Zimmerman writes:
>
> I found this casting mess even more unreadable. I went back to v2, fixed
> the style issues and committed the patch as v4 (still under your name).
>
> https://cgit.freedesktop.org/drm/drm-tip/commit?id=1b617bc93178912fa36f87a957c15d1f1708c299
Will this patch make it
Thomas Zimmerman writes:
>
> Am 21.04.23 um 13:32 schrieb Linux regression tracking (Thorsten
> Leemhuis):
>>
>> Pierre, Tomas, Javier, et. al: how many "legacy BIOSes" do we suspect
>> are affected by this?
So far, two:
1) my Gateway laptop (Intel(R) Core(TM) Duo CPU,
Phoenix BIOS 83.08
I went back to nested max3() after all as Thomas asked. My first cut
had casts in the innermost max3() and the code looked truly awful. I
decided that two casts are tolerable. I added a comment to explain
the casts.
Against clamp_t(u8,lfb_depth,1,32): the clamp_t() macro does no
typechecking;
/dri-devel/20230419044834.10816-1...@panix.com/T/#u
Fixes: f35cd3fa7729 ("firmware/sysfb: Fix EFI/VESA format selection")
Signed-off-by: Pierre Asselin
---
drivers/firmware/sysfb_simplefb.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware
Thomas Zimmermann wrote:
> Am 19.04.23 um 06:48 schrieb Pierre Asselin:
>>
>> v2 fixes the warnings from a max3() macro with arguments of different
>> types; split the bits_per_pixel assignment to avoid uglyfing the code
>> with too many typecasts.
>
> What exac
Javier Martinez Canillas writes:
> Pierre Asselin writes:
>> Fixes: f35cd3fa7729 [firmware/sysfb: Fix EFI/VESA format selection]
>
> The convention is f35cd3fa7729 ("firmware/sysfb: Fix EFI/VESA format
> selection")
>> +bits_per_pixel= max(
/20230412150225.3757223-1-javi...@redhat.com
Fixes: f35cd3fa7729 [firmware/sysfb: Fix EFI/VESA format selection]
Signed-off-by: Pierre Asselin
---
drivers/firmware/sysfb_simplefb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/sysfb_simplefb.c
b/drivers/firmware
-by: Pierre Asselin
---
drivers/firmware/sysfb_simplefb.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/sysfb_simplefb.c
b/drivers/firmware/sysfb_simplefb.c
index 82c64cb9f531..05dc25a524c8 100644
--- a/drivers/firmware/sysfb_simplefb.c
+++ b/drivers
> diff --git a/drivers/firmware/sysfb_simplefb.c
> b/drivers/firmware/sysfb_simplefb.c
> index 82c64cb9f531..0ab8c542b1f5 100644
> --- a/drivers/firmware/sysfb_simplefb.c
> +++ b/drivers/firmware/sysfb_simplefb.c
> @@ -55,14 +55,10 @@ __init bool sysfb_parse_mode(const struct screen_info
> *si,
>
> p...@panix.com (Pierre Asselin) writes:
>
>> After careful reading of the comments in f35cd3fa7729, would this
>> be an appropriate fix ? Does it still address all the issues raised
>> by Thomas ?
>>
>> (not tested)
>>
>> diff --git a/drivers
> (not tested)
Tested. It fixes the regression on my laptop.
> diff --git a/drivers/firmware/sysfb_simplefb.c
> b/drivers/firmware/sysfb_simplefb.c
> index 82c64cb9f531..9f5299d54732 100644
> --- a/drivers/firmware/sysfb_simplefb.c
> +++ b/drivers/firmware/sysfb_simplefb.c
> @@ -56,10 +56,11 @@
After careful reading of the comments in f35cd3fa7729, would this
be an appropriate fix ? Does it still address all the issues raised
by Thomas ?
(not tested)
diff --git a/drivers/firmware/sysfb_simplefb.c
b/drivers/firmware/sysfb_simplefb.c
index 82c64cb9f531..9f5299d54732 100644
---
(Okay, can't back out *all* of the first patch, just the assignment
to mode->stride.)
Anyway, here you go:
grub: gfxpayload=keep
[0.00] Console: colour dummy device 128x48
[0.00] printk: console [tty0] enabled
[0.419983] fbcon: Taking over console
[0.516198] pci
> Javier Martinez Canillas writes:
>
> I still don't understand why this particular configuration didn't work...
>
> The framebuffer starts at 0xd800 and has a size of 0x24 bytes, so
Says who ? It's the same grub, same video mode as before the regression,
so the size is probably
> And can you share the "linelength=" print out from simplefb ?
Okay. Three cases, see below.
Your patch tries to fix the stride, but what if it's the _depth_
that's wrong ? Grub sets the mode, the pre-regression kernel picks this:
format=x8r8g8b8, mode=1024x768x32, linelength=4096
> Interesting. So you don't have the simplefb output that you had before ?
I do now, after a 'make clean' and "make bzImage'.
In between, I had tried CONFIG_SYSFB_SIMPLEFB=n . That "works", by
falling back to vesafb in every case. I restored the .config before
testing the patch, but there
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: f35cd3fa7729 ("firmware/sysfb: Fix EFI/VESA format selection")
> Reported-by: Pierre Asselin
> Signed-off-by:
> 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
Oh oh, I just reproduced the problem on a desktop tower, a Dell Precision
T3610, probably 2019 vintage. The only thing in common with the old
laptop, that I can think of, is that both use the legacy BIOS. The Dell
has EFI but the graphics card may not support that; there is no integrated
Thomas Zimmermann wrote:
> Select color format for EFI/VESA firmware scanout buffer from the
> number of bits per pixel and the position of the individual color
> components. Fixes the selected format for the buffer in several odd
> cases. For example, XRGB1555 has been reported as ARGB1555
20 matches
Mail list logo
