Control: tag -1 patch On Sun, 2023-05-14 at 00:21 +0200, Ben Hutchings wrote: [...] > So I suppose there's a regression in either efifb or fbdev_drv.
I'm not spotting any functional changes in fbdev or the submodules it depends on between bullseye and bookworm. So this implicates either efifb or, as you mentioned, GRUB. > > Via QEMU, under BIOS and UEFI, results are: > > > > +-------------+-----------------+-----------------+-----------------+ > > | Graphics | Bullseye 11.7 | Bookworm RC 2 | Daily builds | > > +-------------+--------+--------+--------+--------+--------+--------+ > > | | BIOS | UEFI | BIOS | UEFI | BIOS | UEFI | > > +-------------+--------+--------+--------+--------+--------+--------+ > > | | OK | OK | OK | KO-G | OK | KO-G | > > | -vga std | OK | OK | OK | KO-G | OK | KO-G | > > | -vga cirrus | OK | OK | OK | KO-S | OK | KO-S | > > | -vga qxl | OK | OK | OK | OK | OK | OK | > > | -vga virtio | OK | OK | OK | OK | OK | OK | > > | -vga vmware | OK | OK | OK | OK | OK | OK | > > +-------------+--------+--------+--------+--------+--------+--------+ > > I started testing with QEMU and OVMF from unstable, and I'm instead > seeing Xorg failing to start in the same cases you see glitches. The > relevant error message seems to be this one: > http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c&line=504 [...] I tested with QEMU from bullseye and OVMF from unstable, and again I saw Xorg failing to start, rather than glitches. Weird. I also patched the kernel to report the internal screen_info structure and the fb_var_screeninfo structure passed in and out of FBIOPUT_VSCREENINFO. The key difference is: - With -vga qxl, screen_info says 32 bpp, X wants 32 bpp, the kernel agrees with that. - With -vga std or -vga cirrus screen_info says 24 bpp, X wants 32 bpp, and the kernel says 24 bpp. I think the problem is this GRUB has native drivers for Bochs and Cirrus that reprogram the framebuffer bit depth, and the kernel is then confused about what the bit depth is supposed to be. With QXL, GRUB doesn't have a native driver so it doesn't reconfigure the framebuffer. Unfortunately, with Secure Boot we have to use a monolithic GRUB build so I can't easily exclude video_bochs and video_cirrus to see if that improves matters. But what does works for me is: --- a/build/boot/x86/grub/grub-efi.cfg +++ b/build/boot/x86/grub/grub-efi.cfg @@ -5,7 +5,7 @@ else fi if loadfont $font ; then - set gfxmode=800x600 + set gfxmode=800x600x32 set gfxpayload=keep insmod efi_gop insmod efi_uga --- END --- A full patch is attached. This works for me with all the QEMU graphics devices. But I haven't tested on real hardware. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
From 49a5e562850e3ae4f64ed2d61bd582d8adedc393 Mon Sep 17 00:00:00 2001 From: Ben Hutchings <b...@debian.org> Date: Sun, 14 May 2023 19:17:45 +0200 Subject: [PATCH] Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019) --- build/boot/x86/grub/grub-efi.cfg | 2 +- debian/changelog | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/build/boot/x86/grub/grub-efi.cfg b/build/boot/x86/grub/grub-efi.cfg index 0a9a67d48..14708c7bc 100644 --- a/build/boot/x86/grub/grub-efi.cfg +++ b/build/boot/x86/grub/grub-efi.cfg @@ -5,7 +5,7 @@ else fi if loadfont $font ; then - set gfxmode=800x600 + set gfxmode=800x600x32 set gfxpayload=keep insmod efi_gop insmod efi_uga diff --git a/debian/changelog b/debian/changelog index 4624187fe..6be6864b5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,12 @@ debian-installer (20230428) UNRELEASED; urgency=medium + [ Cyril Brulebois ] * Bump Linux kernel ABI to 6.1.0-9. * Switch source format from 1.0 to 3.0 (native). + [ Ben Hutchings ] + * Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019) + -- Cyril Brulebois <k...@debian.org> Thu, 27 Apr 2023 22:52:15 +0200 debian-installer (20230427) unstable; urgency=medium
signature.asc
Description: This is a digitally signed message part
