Changes/LegacyXorgDriverRemoval

Change dropped
Per 2023-09-21 FESCo meeting, this Change is dropped. It can be re-proposed if interest in it revives.

Summary

This change removes the xorg-x11-drv-vesa and xorg-x11-drv-fbdev driver packages, and associated support code from the xorg-x11-server-Xorg package.

Fedora's primary desktop environments are moving away from being X11 sessions, to being Wayland servers in their own right. This transition is incomplete, and the Xorg server is still potentially used in a variety of "fallback" situations. In particular the vesa and fbdev drivers can find themselves pressed into use when no better native driver is available. Both of these drivers are somewhat deprecated upstream, and the code to handle them is increasingly fragile as it gets exercised less and less.

Owner

• Name: Adam Jackson
• Email: ajax@redhat.com

Current status

• Targeted release:
• Last updated: 2023-09-21
• devel thread
• FESCo issue: #2782
• Tracker bug: #2078921
• Release notes tracker: #822

Detailed Description

Does this affect me?

Probably not! Let's find out. The below series of commands assumes you have enough privileges for them to work. For Silverblue machines, this means running them from the host and not inside a toolbox.

First, you need to be running Xorg for your display server. This is not the default for Gnome or (I believe) KDE under normal circumstances, but there are plenty of ways to get there and listing them exhaustively is exhausting, so if you're unsure you can print the process id of any running Xorg server by running:

$ pidof Xorg
289301

If that prints a number instead of nothing, my condolences! You're running Xorg, so you're not out of the woods yet. For this change to affect you, you need to be running one of the drivers in question, so let's get a list of the loaded drivers:

$ pmap $(pidof Xorg) | grep _drv
00007f312c016000     24K r---- libinput_drv.so
00007f312c01c000     44K r-x-- libinput_drv.so
00007f312c027000     12K r---- libinput_drv.so
00007f312c02a000      4K r---- libinput_drv.so
00007f312c02b000      4K rw--- libinput_drv.so
00007f3138940000     24K r---- modesetting_drv.so
00007f3138946000     64K r-x-- modesetting_drv.so
00007f3138956000     16K r---- modesetting_drv.so
00007f313895a000      4K ----- modesetting_drv.so
00007f313895b000      4K r---- modesetting_drv.so
00007f313895c000      4K rw--- modesetting_drv.so

If that command lists either fbdev_drv.so or vesa_drv.so in the last column of its output, then this affects you.

I'm using fbdev, why?

In Fedora 36, you really shouldn't be. If you are, please seek medical attention, by which I mean please email devel@ about it so we can figure out what nightmare you and your machine are experiencing.

Prior to Fedora 36 and the ReplaceFbdevDrivers change, by far the most likely reason is that you are using the efifb kernel driver. One way to verify this is to look at the kernel message log:

$ dmesg | grep -w fb0
[    0.712829] fb0: EFI VGA frame buffer device
[    1.831062] fb0: switching to amdgpu from EFI VGA
[    2.189153] fbcon: amdgpudrmfb (fb0) is primary device
[    2.189162] amdgpu 0000:01:00.0: [drm] fb0: amdgpudrmfb frame buffer device

If for you the above command doesn't mention switching from EFI VGA, then either no native kernel driver is available for your hardware yet, or you disabled it from the kernel command line. In either case it means that the efifb driver still owns the display, and its only interface to userspace is /dev/fb0, and for that you need fbdev_drv.so in Xorg.

Some other remote possibilities:

• You're on i686 (not x86_64) - because you built your own kernel using the i686 Kconfig from Fedora pkg git, I guess? - and you were using either an AMD Geode GX/LX or an Intel i810. The unlikely thing here is that you're using an i686 kernel at all, honestly. drm upstream would likely be happy to see these ported over if you're interested, but these systems are already not capable of running stock Fedora anymore. In any case, graphics support for this system would instead fall back to vesa, for which see below.
• You're running something even older than F35, which is as far back in the kernel change history as I've gone so far. You should test an upgrade to F35 first.

I'm running vesa, why?

In all of the below cases the assumption is that you've used BIOS to boot on an x86_64 machine. If UEFI is present then the vesa driver's internal consistency checks should have prevented it from running. Again, if you've somehow managed to run the vesa driver outside of these cases in Fedora 36, please let the devel list know.

By far the most likely possibility is:

• You disabled the KMS drivers from the kernel command line, probably by saying nomodeset.

You likely did this to work around a bug in your KMS driver at some point, and never switched back. You should probably fix that first. One thing to try is to remove that directive from the kernel command line and see if graphics still works. If it does, update your grub config to match, and you're done and this change no longer affects you.

Another possibility is that your machine supports booting via either BIOS or UEFI, and you've chosen BIOS. Again, it's likely you did that to work around a bug with either Linux's or your machine's UEFI support, and it might be worth trying to fix that first. This is a bit more inconvenient because there's no simple tools for upgrading such a machine in place, so you can either try to boot the Live image from UEFI first to see if it works, or just back up your /home and other precious data to external storage and reinstall. If you do switch to UEFI, then nomodeset will instead fall back to the simpledrm support for the UEFI framebuffer, and this change no longer affects you.

Less common, and hopefully temporary, would be:

• You have a physical video card where Linux has a KMS driver for that family of devices, but not that specific model yet, because it is newer than the kernel you're trying to run.

There's not much to be done about this until we invent time travel. However this path is covered by the simpledrm framebuffer support, so fallback graphics will still be available.

The remaining cases are varying degrees of "upstream doesn't have a driver for this hardware", all somewhat to extremely rare:

• You have a virtualized graphics device that Linux has no KMS driver for. We have native drivers for qemu's qxl, cirrus, and stdvga cards; virtualbox; vmware; hyper-v; and virtio-compatible hypervisors (which we believe includes parallels). If there are other hypervisors that we should try to support here, we'd love to know.
• You have a physical video card where Linux has no KMS driver, but fairly easily could, because (for example) there was a userspace-modesetting Xorg driver for it. The "high" end of this category includes things like the 3dfx Voodoo 5, S3 Savage, or Matrox G550. As a rough gauge of their popularity, Fedora hasn't included 3D support for them since Fedora 16. (The author admits that this class of device does include the kinds of cards that find themselves in parts bins and pressed into service when troubleshooting a normally-headless machine in person. But also notes that ATI and NVIDIA cards of that era are equally common if not more so, and still fully supported.)
• You have a physical video card that Linux doesn't have a driver for at all. Examples here include things like 3dlabs Wildcat, Matrox P and M series, or S3 Chrome series. These are pretty rare in the wild; in a sense, the fact that they don't have a driver is because they're rare in the wild.

In any of these cases, this change affects you. To keep graphics working you need to set vga= appropriately on the kernel command line. This will make the kernel set the appropriate video mode using the VESA BIOS interface, and use that as the system framebuffer. Later in boot, the same logic that handles UEFI framebuffer will notice the VESA framebuffer and connect it to simpledrm.

There are two issues with this. The first is that there's no obviously good thing to set vga= to, other than ask, but even that is really only appropriate once and we should remember what was selected. Still, that's probably the right thing to do for the installer boot config, and the installer should munge that setting when writing out grub.conf to the host.

The second issue is, like all other simpledrm drivers, the mode you get is the mode you get, you can only change it by rebooting. Xorg's vesa driver does let you change resolution dynamically, so in that sense this change is a regression. A regression that puts you on equal footing with every other platform framebuffer support path, but still.

Could we keep mode switching working with vesa somehow?

Probably! The uvesafb kernel driver connects the kernel's fbdev interface to a userspace daemon that acts as the vesa driver. The author suspects it would be straightforward to adapt that code to be a KMS driver instead. The bochs_drm driver is probably the one to steal from, since Bochs is already a VESA BIOS implementation for virtual machines like qemu, so the device API already matches that of uvesafb. This would presumably require packaging v86d as well.

Hooking this up would be a stretch goal for this feature, but if we get it working, that'd be fantastic. If we do get it working, I would expect it to also eliminate the need to mess with vga=, because the mode switch would be delayed to userspace code that already knows how to pick a reasonably good one.

What does this mean for the installer's "basic graphics" feature?

This should do vga=ask in addition to nomodeset, and the system grub config that we write should write out what was actually selected.

Feedback

Quite a bit on the devel list thread. I've tried to address the issues raised there in the detailed description above.

Benefit to Fedora

• Verified modern supported paths for cases currently handled by vesa/fbdev
• Simpler support/testing matrix for QE
• One less reason to need Xorg installed at all

Scope

• Proposal owners: ajax needs to audit hardware support matrix for cases that can hit these drivers, and the rest of the OS for places that can configure them.

• Other developers: Maintainers of other affected components may need to incorporate some changes, and may wish to look for additional support code that can be dropped.

• Release engineering: #Releng issue number This is mostly ensuring that the two driver packages are indeed dropped from the compose, etc.

• Policies and guidelines: N/A (not needed for this Change) Although this is a system-wide change I don't think there's any real policy impact.

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives: Yes, we'd be arguably the First to try this.

Upgrade/compatibility impact

For an upgraded system to notice this change, it would need to be already using one of these drivers. For cases where the driver is set explicitly in xorg.conf, there is no obviously correct remedy that we could do automatically, and the user will need to fix their X configuration manually.

(This is... not totally true. If we really did know that neither vesa or fbdev could exist, we could patch the X server to treat them as aliases for modesetting and figure out the appropriate device for them to run on. A modest amount of work for marginal benefit, but it might be a nice polish feature to at least point the user in the right direction.)

Systems using the kernel's vesa support will no longer be able to change resolution dynamically, and will get a framebuffer console instead of 80x25 text mode. Systems that don't set vga= will no longer have graphics support.

How To Test

This should fall out naturally from the normal release testing process, but we'll expand the details here as the various configurations are tested and fixed.

User Experience

This change should be largely invisible, but there will likely be observable changes (for instance, if you end up using a Wayland session, $WAYLAND_DISPLAY will likely no longer be empty). These will be documented here as we fix the individual cases.

Dependencies

The kernel may need changes to add more drivers for more situations.

The installer and other system-wide configuration tools should be audited to ensure they don't emit cases that can force vesa/fbdev.

The major desktop environments may need to be fixed to handle more cases, and may wish to drop code to support the old cases.

Contingency Plan

• Contingency mechanism: ajax reverts the changes.
• Contingency deadline: Beta freeze seems fine.
• Blocks release? No. Partial completion is possible.

Documentation

Just this page so far.

Release Notes

The installation guide should strongly recommend booting with UEFI, for this and other pre-existing reasons. The section with that recommendation should note the drawbacks of booting with BIOS, and this change would add whatever drawbacks remain to the remaining vesa support to that list.