The Linux Kernel Preparing To Drop Infrastructure For Old & Obsolete Graphics Drivers

[GreenReaper]

Obviously if you are using something like that you probably also use some distro that has 10 years support.

I run my HP Gen8 MicroServer on the edge! It's Debian, sure, but it gets lots of backports,.and occasional stuff from this guy called Sid when I want something fresher.

I had a fun time getting its KMS working at the resolution I wanted, but it worked out in the end. Was amusing to set different colour modes and watch it struggle to scroll in 32-bit and speed up in 8-bjt (I think it's faster now).

[Developer12]

You're right in principle, but maybe don't be so angry with people who don't 100% know the intricacies when you are arguably wrong about details yourself?

1) That's true for the modern way of doing things, but not universally or historically - you can get quite far with just memory mapped IO and IO ports, where the only OS involvement is access control to the relevant resources. As Mat2 says, that's traditionally how X drivers worked.
2) I don't agree. There are DRM drivers for a number of simple framebuffers (VESA, EFI, different virtualization passthroughs), and those are definitely kernel components - but at the same time the rendering is done in software; there's no hardware acceleration of the graphics primitives. Using llvmpipe into a xen passthrough or simpledrm-on-vesa framebuffer are both "software rendering" but they're not identical.

(And ofc I'm going to be wrong about something fundamental here myself, because that's just how this works)

A framebuffer (or even most of DRM and modesetting) has nothing to do with a GPU or the process of rendering. These are completely separate things. See "video outputs." I can have a framebuffer provided by a USB 2.0 monitor where there is absolutely no acceleration and where mesa is completely uninvolved. Just open the hardware device and start writing pixel bytes to it an they'll show up on the screen.