XLibre
Drop crusty old drivers for ancient display adapters #258
Replies: 32 comments 1 reply
-
|
How big of a problem and maintenance burden is to keep these drivers around? I wouldn't like to see stuff deleted just for the sake of it. People put work into these drivers, if they work and are not obstacle then why remove them, right? Also it's always good to get real data and feedback from developers, similar as metux did with proposal of removing HAL. |
Beta Was this translation helpful? Give feedback.
-
|
I was more considering a compromise where all of the practically unsupported drivers are shoved into 1 repo that's archived or all the seperate legacy drivers repos become archived with a notice if you want to continue development you can but it's probably not gonna be a good time considering X11Libre might add in new features that these cards probably can't handle |
Beta Was this translation helpful? Give feedback.
-
|
IMHO, the problem is different: who's been testing on those GPUs in the last 20 years? They work in the sense that they compile, but do they actually run? Does anyone actually now? |
Beta Was this translation helpful? Give feedback.
-
|
I don't see why xlibre needs to support hardware older than 20 years at all. The thing is that xlibre doesn't seem to have a clear objective. Does this project exist to maintain compatibility with old hardware and software that will never work on wayland? Or to prolong the life of xorg on modern systems and modern software? I don't think we can have both, and if the objective is the latter, it is pretty obvious that support for ancient hardware needs to be removed if it gets in the way of that.
I think that If you want to use ancient hardware you can use ancient software (xorg). |
Beta Was this translation helpful? Give feedback.
-
|
Is sympathize with this idea (to drop older drivers), but be specific. There are plenty of old servers (still running) that rely on ancient graphics. |
Beta Was this translation helpful? Give feedback.
-
I just asked if there's a valid technical reason for removing work of real people or if you want to remove it just for the sake of removing it, similarly how Linux kernel and other projects do it. Source code is just bunch of symbols in text file, it's not milk that gets spoiled after some time, age of code is completely meaningless. If asking for feedback from developers who might consider supporting XLibre before you mindlessly remove code is bad then so be it. Also, as @SuperDuperDeou said, it would be great to know whether these drivers even work. |
Beta Was this translation helpful? Give feedback.
-
Sure, but what exactly would be the point of running xlibre on old servers? Regular old xorg works just fine that purpose. Code doesn't actually rot like an organic material in the way that Wayland shills would have you believe. |
Beta Was this translation helpful? Give feedback.
-
|
The only people running this hardware in 2025 are hardcore retrogamers with their period accurate PCs running somewhere in the span of MSDOS and WinXP. I don't see a reason to spend a single second maintaining drivers that probably haven't been tested on real hardware in the last 20 years, for GPUs that can't even drive a 1080p screen. |
Beta Was this translation helpful? Give feedback.
-
There is a [Discussion] Project Direction: Maintenance, Breaking Evolution, or Both? · X11Libre · Discussion X11Libre/xserver#80 regarding the goals of the project. |
Beta Was this translation helpful? Give feedback.
-
Metux just claims that xlibre will never have to sacrifice backwards compatibility to modernize. |
Beta Was this translation helpful? Give feedback.
-
One thing is the protocol, another the drivers. |
Beta Was this translation helpful? Give feedback.
-
|
The problem with dropping older drivers is very complex. Let me explain this: Many modern server class motherboards use older VGA chipsets for display and rendering devices, mainly for 2D displays. I've seen EPYC and Xenon boards with S3/VIA Savage/Virge, 3Dfx Voodoo Banshee/3/4, Nvidia Riva/Vanta/TNT/TNT2, and other legacy chips. Why? Why not Aspeed and other modern SoC VGAs? Because many of them often have compatibility issues with drivers or simply lackl a userspace driver for X. Aspeed has no Linux X drivers except a very barebones kernel driver. Older stuff just works, even with a barebones 2D RAMDAC driver. Besides, many servers only use a 1280x768x24 display in the closet for emergency on site diagnosis. Does it need 3D support? No. That's why Mesa dropped many older chipsets from the code. It was just because these didn't support 3D well, most did, but many just didn't have the necessary EGL support. Do we need EGL support on an S3 Virge? No. Why not xf86-video-vesa? Because it's a fallback driver like xf86-video-fbdev. These are emergency fallback drivers. They're not supposed to be used for displays long term because they lack EDID reading and KVM support, which can still be problematic for a server display screen. Many servers use KVMs which might not work well with vesa and fbdev. The older drivers are still KVM compatible. |
Beta Was this translation helpful? Give feedback.
-
Isn't a 1280x768 truecolor double buffer already 5.625MiB? Those GPUs cap at 8. I don't see how it's storing any assets in VRAM with only 2.275MiB, especially when VMs get involved. Are they doing everything in software and using those GPUs just as display adapters? Then why do we even need GPU acceleration hardware for them? |
Beta Was this translation helpful? Give feedback.
-
Because as stated these are on server displays who's only job is to show controls and error messages. |
Beta Was this translation helpful? Give feedback.
-
|
Not all server units will use VMware for server distribution. Many use bare metal. |
Beta Was this translation helpful? Give feedback.
-
At least for the protocol. External drivers might be different in some cases - there are things on my 2do list that at least will break ABI and require some rework in the drivers. Only proprietary Nvidia can be a real blocker here - for the free drivers it's just a matter of some bit of extra work. |
Beta Was this translation helpful? Give feedback.
-
They're really putting those ancient chips on new boards ? Didn't expect that.
Can we fix up vesa/fbdev/kms for that ? |
Beta Was this translation helpful? Give feedback.
-
I do. But then, I am nobody's demographic. |
Beta Was this translation helpful? Give feedback.
-
|
As a sidenote: We compiled a list of X drivers without ebuilds in the Gentoo Portage overlay of XLibre and asked anyone to request packages in the corresponding |
Beta Was this translation helpful? Give feedback.
-
I don't know the exact boards off hand per model, due to the fact there's tons of them, but the manufacturers known for using legacy GPUs, yes. I have known many of these from years of experience... Tyan (they tend to use S3/VIA) VESA and FBDev would need all the GPU data sets for EDID and KVM support handling. I don't know exactly what rhey use other than the detected VESA/VGA specs obviously, or the RAMDAC framebuffer for basic rendering. I know that the kms/modesetting driver can't support these due to the lack of egl/opengles from Mesa, which it uses for 2D/3D rendering. I do know we completely don't have an xf86-video-aspeed driver, which is all modern Xeon and Epyc boards now use exclusively. |
Beta Was this translation helpful? Give feedback.
-
|
Enterprise class servers (Dell, HP) mostly use Matrox chipsets. Mga driver must not be dropped. |
Beta Was this translation helpful? Give feedback.
-
No. That would drive them to windows or other server os's. your asking them to devote cpu cycles to render a emergency console screen. |
Beta Was this translation helpful? Give feedback.
-
KVM switches and Server flat panels still operate off EDID readings which the older 2D chipsets still go off of. Unfortunately, newer panels don't always also go off of the same VESA 2.0 1280x768@60Hz timings especially KVM which requires EDID to be held in passthrough to the monitor. VESA and FBDEV don't read EDID information, whichbis why they're emergency fallback drivers. Vesa tries to read the VESA standard of the display if it can and render an image. If it can't the fbdev is loaded to try and read the RAMDAC directly for a minimum display based off the available VRAM. These drivers unfortunately can not load other information be be switchable via KVM. This is why drivers like ati, mach64, mga, tdfx, nv, s3, etc. are loaded and used. Because the KVM switch can switch and hotplug monitors via KVM. Unless you want to create a new vesa driver on par with modesetting that can act as a DDX multiple chipset driver, read RAMDAC, read VESA, read EDID, and then read the TMU registers to use proper kernel level hardware acceleration via DRI for 2D drawing, then we need the other drivers. |
Beta Was this translation helpful? Give feedback.
-
Out of curiosity: Are they running X11 emergency console screens on their servers? If so I am a little confused about the combination of X11 and emergency consoles. |
Beta Was this translation helpful? Give feedback.
-
|
Much of the usecase (in particular with older ATI/Nvidia) has to do with people running non-x86 Linux ports these days, such as ports for old PPC hardware (probably the highest profile one due to use in PPC Macs and Amiga descendants). In particular, this crowd still tends to use Mesa on older GPUs on big-endian platforms, which opened up a can of worms but also led to people making forum threads documenting it, and I remember the old Mint PPC site had people passing around how to use old Mesa versions to get 3d working. In particular, this is a problem with Macs as while the Power Mac desktops had swappable PCIe or AGP gpus, you're stuck with the original GPU on PowerBooks, iMacs, and Mac Minis. I also know for a fact that the IA64, SPARC, HPPA, and Alpha AXP Linux architectures all use ATI GPUs in some form, either the R100 or R300, even if it wasn't the sole GPU option. The T2 and Debian-Ports projects come to mind in this realm. On the other hand, there's also been some well-documented bitrot with some of the old drivers in which nobody cares enough to maintain them, unlike those examples. In particular some broke due to ramdac drivers being removed and similar, while also different groups are divided on this. Linux 6.3 removed some old drivers including r128, but Mesa devs didn't share the same view point of killing old drivers.
If anything, I think he's referring to using stuff like the Matrox G200 and Rage XL, which both lasted quite a long time in server hardware. Especially the G200, there are so many Dell/HP boards in particular using this core. This is because in particular, Matrox licenses out the IP core for that old GPU for embedded use.
If the drivers aren't broken, there's not really a reason to rip them out of X11, especially if it's hardware that someone somewhere who cares still has. There's still work on the r300 driver for Mesa for example being done because of it's use in the previously mentioned Macs as an example. |
Beta Was this translation helpful? Give feedback.
-
|
Related to #255 |
Beta Was this translation helpful? Give feedback.
-
|
For the record, - Mesa is planing to remove DRI2 "the-X11-protocol" in the near future. See Mesa MR 19942 for more context. So after this "cleanup" Mesa will be DRI3-only. Which somehow also means that Mesa will be in fact "Glamor-only". Well yes, there exist some talk about fixing EXA drivers to work also directly with DRI3 but most likely this is no longer really an option in mid 2025. 🤔 Ergo, - those old driver stuff has no longer any real use when Mesa finally switches to DRI3 / Glamor only support. And this will happen shortly I think. The last final hurdle is XServer MR 1636. That one backports all needed GLES2 Glamor fixes & enhancements to XServer 21.1 and means that even original Shader Model 2.0 hardware will be able to use Glamor. Older hardware has to use a Mesa version which still offers DRI2 support, - that is for sure current Mesa 25.1 or perhaps Mesa 25.2. And finally a few more personal thoughts about the future possible directions of X11Libre can be found in my comment here. /cc @metux Edit: XServer MR 1636 has now finally landed. I assume that Mesa MR 19942 will follow shortly which would mean that Mesa 25.1 will be the last version supporting DRI2. |
Beta Was this translation helpful? Give feedback.
-
|
A new short addition. DRI2 support was finally removed from Mesa with Mesa MR 35885, Mesa MR 19942 and some other following-up MRs. So as suspected, Mesa 25.1 ist the last version which supports DRI2. In regard to the affected hardware this has a relevance only for pre-GLES2 systems while all GLES2 (and higher) compliant stuff should work with Glamor and DRI3. XLibre should be already prepared for this change as it contains all needed Glamor enhancements and fixes which were recently backported even to the XServer 21.1 branch. |
Beta Was this translation helpful? Give feedback.
-
|
Related discussion: Is xfree86-video-nv driver really still needed ? · X11Libre · Discussion X11Libre/misc#256 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you all for your contributions! We currently restructured the "Ideas" discussions and accordingly this issue will be moved to the Good Ideas For Later category as this issue is a discussion of good ideas. |
Beta Was this translation helpful? Give feedback.
-
|
The discussion Remove some deprecated drivers and maybe adopt some new ones · X11Libre · Discussion #257 was very similar to this one and was therefore closed. Please continue discussing this topic here. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm gonna go a on limb and say we don't need a S3 ViRGE or a Rendition Verite driver anymore since in practice only 0.0000000000000000001 of X11 users probably use these
Beta Was this translation helpful? Give feedback.
All reactions