On Sat, 2023-05-13 at 10:22 +0200, Cyril Brulebois wrote: [...] > Kernel-side > =========== > > The fb-modules udeb hasn't changed much since 4+ years, with some DRM > modules getting added alongside existing ones, leading to the following > contents in Bullseye (5.10.178-3): [...] > Those contents are defined via those files in linux.git: > > kibi@tokyo:~/debian-kernel/linux.git (sid=)$ cat > debian/installer/modules/amd64/fb-modules > #include <fb-modules> > > vesafb ? > vga16fb > > kibi@tokyo:~/debian-kernel/linux.git (sid=)$ cat > debian/installer/modules/fb-modules > # We don't include all DRM drivers here as on many platforms we can > # call system firmware to get hold of a simple framebuffer
To expand on this comment, in the case of UEFI boot the efifb driver should provide a simple framebuffer, and on BIOS vesafb should do it. Those are both built-in on x86, and efifb is also built-in on arm64 and armhf. [...] > X-side > ====== Both of the kernel drivers are old-style framebuffer drivers so in Xorg, the appropriate generic driver is "fbdev", not "modesetting". > Now, we know that the contents of xserver-xorg-core-udeb have changed a > little between Bullseye and Bookworm (#1035014), but that doesn't seem > to be a factor here. > > I've tested 3 netboot/gtk/mini.iso to assess the situation: > > - mini-20210731+deb11u8.iso from Bullseye 11.7 > - mini-20230427.iso from D-I Bookworm RC 2 > - mini-daily.iso from D-I daily builds (downloaded today) > > If people want to replicate those tests, they're available at: > https://people.debian.org/~kibi/bug-drm-vs-uefi/ > > Or: > > wget > https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/20210731+deb11u8/images/netboot/gtk/mini.iso > -O mini-20210731+deb11u8.iso > wget > https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/20230427/images/netboot/gtk/mini.iso > -O mini-20230427.iso > wget https://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/mini.iso > -O mini-daily.iso These all include fbdev_drv.so, and Xorg.log shows that the fbdev driver is being used. So I suppose there's a regression in either efifb or fbdev_drv. > 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 [...] > Questions > ========= > > - Is it really to be expected that X and standard drivers would regress > this way when moving from Bullseye to Bookworm? No. > - Or is it expected to require specific kernel modules while that wasn't > the case before? I've discovered this in VM environments, but maybe > similar things could be happening on bare metal as well, and maybe > some more modules should be considered for inclusion? No. > - Is it acceptable to just bundle bochs, cirrus, and vboxvideo for the > time being (i.e. RC 3, RC 4, 12.0.0), be it via the nasty approach > or via a proper linux fb-modules inclusion? > - Or does shipping those few modules risk breaking the kernel and/or X > on other platforms? (I'd definitely hope not!) I would not expect so. They get used on the installed system, so they probably work. [...] > Proposal plan for d-i (Bookworm RC 3, RC 4, and 12.0.0) > ===================== > > Unless I received strong negative feedback before Monday (May 15th), > I plan on including the nasty approach in RC 3, and to revert it > altogether in RC 4 if big bad regressions are reported: > > https://salsa.debian.org/installer-team/debian-installer/-/commit/9fceca63273d0b501ea64d7b719acafc93a5b7fa > > As a side note, keeping the bundling in src:debian-installer for the > next few weeks makes us autonomous: we can enable and disable those > extra modules without requiring a new linux upload… so it's nasty but I > actually thought about the few advantages we were getting out of this! > > We should also be OK legal-wise, given we already have linux in > Built-Using via its udebs, so copying things around from linux-image > wouldn't change anything there, would it? > > Of course in the long run, if having those modules is desired, it will > be better to have them merged in linux and to drop the nasty code, e.g. > in a point release. [...] Definitely. I will spend some time investigating this, but I doubt I'll come up with a better fix in time. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code.
signature.asc
Description: This is a digitally signed message part
