From Fedora Project Wiki

< Changes

Revision as of 18:46, 20 April 2022 by Ajax (talk | contribs) (big ol' update)

Legacy Xorg Driver Removal

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

Current status

  • Targeted release: Fedora Linux 37
  • Last updated: 2022-04-20
  • devel thread
  • FESCo issue: #2782
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

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.
  • You're using the ssd1307 driver for the Solomon SSD1307 OLED controller, of the kind used in wristwatches. This was the only other fbdev driver enabled for any architecture in F35. If this is you, presumably you know what you're doing, and if future drm support for that device is important to you, upstream awaits your patches.
  • 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.

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. If there are other significant hypervisors that we should have support for, that should get fixed upstream regardless. Parallels maybe?
  • 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, but this path _is_ covered by the simpledrm framebuffer support on UEFI machines, so fallback graphics will still be available.
  • 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 get 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 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 means Fedora no longer has a video driver for your hardware. If your video output displays anything, it will probably be the VGA text console.

Is there anything else we could do to keep graphics on these devices?

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 driver to use the simpledrm interface instead. This would preserve graphics on the above cases where X's vesa driver is currently used, and would extend it to Wayland servers that only know about KMS and not fbdev.

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

Any of the above cases where vesa would no longer work, would no longer work. You would need to install in either text mode, vnc, or with a full kickstart.

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.)

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 "you don't have a fallback graphics driver, be prepared to drive a text console" to that list of drawbacks.


Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/LegacyXorgDriverRemoval&oldid=641046"