Fedora starts to simplify Linux graphics handling
- Reference: 1651055526
- News link: https://www.theregister.co.uk/2022/04/27/fedora_starts_to_simplify_linux/
- Source link:
The planned changes are coming in two stages. Initially, the imminent Fedora 36 release will [1]remove the old fbdev driver, leaving only DRM and KMS. Then in Fedora 37, which is due later this year, the plan is to remove the driver from the X.org server as well.
These steps are associated with the planned [2]transition to requiring UEFI firmware, with a later goal of removing legacy BIOS support altogether.
[3]
The tools are already in place: this is not adding any new or experimental technology, but rather removing some old tools and drivers that in modern PCs are no longer needed, and which make graphics handling more complicated.
[4]
[5]
The kernel's fbdev device has been [6]deprecated since 2015. It's a very old-fashioned mechanism for the kernel to display graphics on the system console, which was introduced in kernel 2.1.109 back in 1999.
A visible use was the Tux logo that some distros display with the kernel messages during startup. It did have other uses, though, such as the ability to display software-defined fonts on the console, handy for those who use characters, or entire alphabets, not covered by the PC's [7]character set . Last century, it was also used on some computers that don't have a native text mode, such as early Macintosh models.
Out of the frame
The functionality is not disappearing. What is [8]going is the software and drivers that enable the kernel to do this directly. They will be replaced by a new driver called [9]simpledrm , which emulates the old framebuffer. It sets up the display using KMS, which all distros have used for many years.
KMS stands for [10]Kernel Mode Setting . It's a mechanism for the Linux kernel to switch the display into a particular mode, very early in the boot process, so that the system startup looks smooth, without sudden jerky changes of graphics mode when the display server starts. KMS in turn uses [11]DRM to accomplish this. Not Digital Rights Management, in this context, but Direct Rendering Manager, which is how the kernel talks directly to GPUs.
[12]
For now, simpledrm will replace fbdev , but it's not yet possible to completely remove this, partly because fbcon , the [13]kernel console driver , requires it.
Once the old fbdev device is gone, the plan is that Fedora 37 will continue this process by [14]removing the X.org drivers for both fbdev and the generic [15]VESA driver. Eventually, X.org itself will be removed, as the various desktops that Fedora offers shift over to Wayland.
Most users shouldn't notice any difference. Virtually all distros, even text-only server distros, already use KMS to configure a console graphics mode, enabling people to use other alphabets and writing systems.
[16]Ubuntu 22.04 LTS arrives on everything from a 2GB Pi to AWS Graviton
[17]Next versions of both Fedora and Ubuntu head into beta
[18]GParted 1.4: New version of live partition-manipulation tool
[19]GNOME 42's inconsistent themes are causing drama
The only potential problem that the Reg FOSS desk can envision is with troubleshooting. If a Linux system won't boot properly, one of the first troubleshooting steps to try is to add nomodeset to the kernel parameters – for example, see this Dell [20]page . It stops the kernel from trying to set the graphics mode, and it's useful because that is a step which quite often goes wrong.
In theory, this should still work, as the simpledrm console driver handles three cases where KMS doesn't work: [21]efifb , a generic UEFI frame buffer, [22]simplefb for some Arm64 machines, and [23]vesafb , a generic method for Intel machines. ®
[24]
But as Yogi Berra said: "In theory, there's no difference between theory and practice. In practice, there is."
It is possibly relevant to note that on the day before Ubuntu 22.04 was released, the developers turned off some experimental features relating to Wayland support: [25]switching to X.org by default on machines with only an nVidia display, and [26]disabling 3D acceleration when running Ubuntu in a VM under Ubuntu. Some of this technology is not ready for prime-time just yet.
Of course the goals of Fedora and Ubuntu are very different: indeed, those of an Ubuntu LTS release, which will be supported until 2027, are diametrically opposed to Fedora, which doesn't have long-term support releases. These pro-active moves from Fedora should help to reveal issues in the Linux graphics stack. We can hope that by the time Ubuntu 24.04 appears, this stuff will be a lot more stable, including for RHEL 10.
Get our [27]Tech Resources
[1] https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
[2] https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YmlosZ@kXEgK8EefNICRdgAAAFQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YmlosZ@kXEgK8EefNICRdgAAAFQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YmlosZ@kXEgK8EefNICRdgAAAFQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://lkml.org/lkml/2015/9/24/253
[7] https://www.ascii-codes.com/
[8] https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
[9] https://lore.kernel.org/dri-devel/20210430105840.30515-1-tzimmermann@suse.de/
[10] https://www.kernel.org/doc/html/v4.15/gpu/drm-kms.html
[11] https://dri.freedesktop.org/wiki/DRM/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YmlosZ@kXEgK8EefNICRdgAAAFQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] https://www.kernel.org/doc/html/latest/fb/fbcon.html
[14] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2T63OVVZJEJL4CYGKQABM263ECMYXB5R/
[15] https://www.x.org/releases/current/doc/man/man4/vesa.4.xhtml
[16] https://www.theregister.com/2022/04/21/ubuntu_22_04/
[17] https://www.theregister.com/2022/03/31/fedora_and_ubuntu_36/
[18] https://www.theregister.com/2022/03/30/gparted_14/
[19] https://www.theregister.com/2022/03/28/gnome_42_inconsistent_themes/
[20] https://www.dell.com/support/kbdoc/en-uk/000123893/manual-nomodeset-kernel-boot-line-option-for-linux-booting?lwp=rt
[21] https://www.kernel.org/doc/html/latest/fb/efifb.html
[22] https://www.kernel.org/doc/Documentation/devicetree/bindings/display/simple-framebuffer.txt
[23] https://www.kernel.org/doc/html/latest/fb/vesafb.html
[24] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YmlosZ@kXEgK8EefNICRdgAAAFQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[25] https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1969566
[26] https://bugs.launchpad.net/ubuntu/+source/osinfo-db/+bug/1969524
[27] https://whitepapers.theregister.com/
Same here, bits of old kit repurposed to run Linux when original OS stopped being supported, keep them running until they peg out as
a) Useful to have a spare if main machine fails
b) Laptops, so occasionally get fired up to do a bit of work outside on a nice day instead of being stuck at a desktop.
I have machines that have marched forwards for decades. They don't do UEFI boot, and even if they did but they were in BIOS mode it's non-trivial to swap over.
So one day I'll update to Fedora N and it will break at reboot?!?
Yes, but not any time soon. The aim of their current changes is to forbid new installs that don't use UEFI:
Systems currently using Legacy BIOS for booting on x86_64 will continue to do so.
However, this modifies the baseline Fedora requirements and some hardware will no longer be supported for new installations.
If its a new install, the hardware most likely does support UEFI, even if it isn't currently turned on, so that's not so much of a problem is it?
"The aim of their current changes is to forbid new installs that don't use UEFI:"
But why, just to bring up graphical text faster? People sometimes argue security reasons but nothings more secure than encrypting the entire drive, which UEFI isn't a concern.
This was all linked in the article:
While this will eventually reduce workload for boot/installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro.
[...]
UEFI is required for many desirable features, including applying firmware updates (fwupd) and supporting SecureBoot. As a standalone change, it reduces support burden on everything involved in installing Fedora, since there becomes only one way to do it per platform. Finally, it simplifies our install/live media, since it too only has to boot one way per arch. Freedom Friends Features First - this is that last one.
Don't worry.
Just means some day Fedora will not work on old machines. But I'm pretty sure there will be other Linux distros that will. Probably even a Fedora fork or respin will, as some Fedora users will decide they will not give up BIOS and x.org, unless you pry it from their cold, dead hands (I myself might be in that group, x.org still has the advantage over Wayland that it works with all desktops envs, not only the most bloated ones).
The frame buffer device was depreciated? Obvs I don't use it anymore but I do shed a little tear to the time when it was the only way to get the Linux GUI to work with certain hardware.
If these people made cars ...
The kernel's fbdev device has been deprecated since 2015. It's a very old-fashioned mechanism for the kernel to display graphics on the system console
Wheels are a very old fashioned approach to transportation. If these guys were car-makers, they'd probably be planning to replace them with something else in the 2026 models. Maybe dozens of tiny feet. Or some sort of serpentine slithering device.
BTW, for those who, like me, have not the slightest idea what fbdev does, it appears to be a driver for the framebuffer. The framebuffer is an area of memory in the X86 architecture that contains a user accessible bitmap of the current video screen. DRM is a acronym for Direct Rendering Manager, not Digital Rights Management. And presumably what this change will do is gratuitously break the workflow of a few folks whose plain old software and perhaps custom hardware just works
References:
. Old proverb "If it ain't broke, don't fix it"
. A. C. Clarke: Superiority ("http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html")
Re: If these people made cars ...
What a crap analogy.
How's your modern car with its carburettor? Those points still playing up? How is your arm after the crank start kicked back? Still, pretty sure that cast iron sub frame is holding those hand beaten panels well, although they are getting a little rusty these days. Just don't go to fast, those drum brakes without a servo can take a bit of stamping on to get them to work.
Re: If these people made cars ...
More like it may be time to stop using solid wooden wheels and try something a little more modern like metal rims surrounded by pneumatic rubber tires attached to axles that are cushioned by shock absorbers. Should make for a smoother ride and make for some easier maintenance in areas, just saying.
Re: If these people made cars ... they would be electric
If I understand this correctly:
Before, if you were writing the driver for a new graphics card you had to implement fbdev, KMS and DRM. For a car, fbdev is the equivalent of adding an internal combustion engine, petrol tank and gearbox to an electric car. In future, you will only need to implement KMS and DRM. Any software that tries to read the fuel gauge will get the answer "full" from the kernel. Any software that tries to change gear with get the response "gear changed" from the kernel which will also modify the way the accelerator pedal position gets converted to required torque from the motors.
User space software will not notice but kernel drivers will be simpler.
I actively use nomodeset.
First case is a smaller 4k display. Without nomodeset the console text is tiny and unreadable without bring up a gui I do not often want.
Second case is that I have a situation where I need to ignore the intel igpu and jump into X with an nvidia card. I know there is another solution here, but it is a lot more work.
As for removing support for any computers without UEFI... are we really going to shut out machines that are perfectly functional but happen to not be newish hardware? This totally reminds me of Win11 requiring TPM and forcing older systems into ewaste prematurely.
Heck, if I'm building a qemu VM I don't waste time setting up uefi... it is an unnecessarily complex additional burden. I maybe understand the reasoning, but I disagree with this path.
Re: I actively use nomodeset.
> Heck, if I'm building a qemu VM I don't waste time setting up uefi... it is an unnecessarily complex additional burden. I maybe understand the reasoning, but I disagree with this path.
I think the likes of this Fedora policy change regarding UEFI will drive various Cloud Providers to support (or indeed by default use) UEFI for their instances. Some of the bigger Cloud Providers already support UEFI but many other providers do not yet.
Another "driver" for their enabling UEFI support is in order to support/rollout Arm instances as these also use/require UEFI.
Alpine Linux already switched from fbdev to DRM
The Alpine 3.15.0 release (in Nov 2021) [https://alpinelinux.org/posts/Alpine-3.15.0-released.html] made the switch from fbdev to DRM. There were a few minor hiccups at the time but in general it has worked fine.
Obviously if you have some obscure graphics card without a DRM driver you may have issues (I think one model of Aspeed card used for server IPMI boards only gained DRM support in a recent kernel).
"grub2 reduces surface area, syslinux goes away entirely"?
I converted all my home machines from Grub2 to extlinux precisely because Grub2 is large and complex and is designed to handle so many boot situations that I couldn't trust it to be secure. (Extlinux is the variant of syslinux that boots from ordinary hard drives with ordinary filesystems. The things that apply to the vast majority of Linux boxes.)
"requiring UEFI"
Yikes.
I have machines that have marched forwards for decades. They don't do UEFI boot, and even if they did but they were in BIOS mode it's non-trivial to swap over.
So one day I'll update to Fedora N and it will break at reboot ?!?