1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Luc Calls For A Dead Linux Desktop If Keith Gets His Way

X.Org

Published on 17 September 2010 10:02 AM EDT
Written by Michael Larabel in X.Org
103 Comments

While X Server 1.10 is not being discussed at length until tomorrow (the final day of XDS Toulouse), besides today's notes, Luc Verhaegen who formerly was with Novell working on the RadeonHD driver and has also worked on the open-source VIA Unichrome driver and a few other X related projects, is preparing for another heated battle.

Back in February at FOSDEM in Brussels, Luc made a presentation on modularizing Mesa and DRI drivers, which ended up in a very heated discussion but ultimately his ideas fell on deaf ears. With X.Org Server 1.10, Keith Packard of Intel has expressed interest in merging the drivers back into the server, or in other words de-modularizing the X.Org Server after it was modularized a few years ago as being a feature.

Luc is very much in starch opposition to moving X.Org drivers back into the X Server to the point that he believes if the drivers are pulled back into the server that the Linux desktop will die. Those in favor of merging the drivers back into the xorg-server want this done so that they can more easily break the API/ABI and make such changes without worrying of backwards compatibility. Merging the drivers back in would also cause much more upstream testing of the xorg-server since most GPU developers will now be forced to rebuild the xorg-server quite often.

Those in opposition to pulling the drivers back in are upset as the X.Org Server can be a pain in the ass (and more time consuming) to build, will really not lead to major benefits, etc. It also means that a new X.Org Server needs to be released for providing a new driver, which may mean upgrading the xorg-server just to have new hardware support or to receive GPU bug-fixes. This could be problematic for not only end-users but also distribution vendors in how they push out stable updates.

Luc firmly believes that pulling the input and video drivers back into the xorg-server will put the system into a position where it will be far from bug-free and never in a constant "useful" state. Each time you want to upgrade one component, you'll need to upgrade the entire stack, which is likely to introduce other bugs. Mesa and libdrm are already tightly coupled together and major Linux kernel upgrades are already required for upping the DRM/KMS. "No normal person can then run a free software desktop system, and expect to use it, because an arbitrary mix of hardware cannot possibly work together acceptably, at least not for a measurable amount of time...Looking further, by shutting out our own users, we will take away the breeding ground that free software is based on."

Luc also praises the proprietary NVIDIA driver for its compatibility with a wide range of kernel and X.Org Servers and wants the free software graphics drivers to be more like this Santa Clara company's work. Many more thoughts are shared in Luc's blog post about killing the Linux desktop.

While most developers are not as polarized as this open-source enthusiast, there are other X.Org developers here who also are not in favor of their DDX drivers being pulled in for xorg-server 1.10. Tomorrow there should be much more information to report, but I'd likely suspect that X.Org input drivers will be merged back into X.Org Server 1.10 but not the xf86-video- drivers.
The proposed future direction for graphics drivers is to create graphics driver stacks. If not, we, the developers, might just as well stop working on free software graphics drivers altogether.

And while the current situation currently is bad, it is not impossible to fix. The problems are known and clear, a path to the solution should by now also be clear, but the willingness to put in the bit of extra thought is simply lacking.

So guys, if you really want to move into the wrong direction, please state the real reasons for doing so, state the consequences to your users; and know what the end result will be.

Latest Linux Hardware Reviews
  1. Overclocking The AMD AM1 Athlon & Sempron APUs
  2. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  3. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
  4. AMD Athlon 5350 APU On Linux
Latest Linux Articles
  1. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  2. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  3. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
  4. DDR3 Memory Scaling Performance With AMD's Athlon 5350
Latest Linux News
  1. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  2. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  3. Red Hat Releases Its RHEL 7 Release Candidate
  4. New Features Coming To Xubuntu 14.04 LTS
  5. NVIDIA Officially Releases CUDA 6
  6. Google Releases An AutoFDO Converter For Perf In LLVM
  7. Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation
  8. Star Citizen Will Be Coming To Linux
  9. Ubuntu 14.10 Convergence To Focus On Replacing Core Apps
  10. The Results Of Optimizing Radeon's VRAM Behavior
  11. Kernel Developers Discuss Improving Kernel Configurations
  12. Apple, LLVM Developers Figure Out Their 64-Bit ARM Approach
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. New tool for undervolt/overclock AMD K8L and K10 processors
  5. How to enable opengl 3.3 on r9 270?
  6. R290x sound problems
  7. radeon-profile: tool for changing profiles and monitoring some GPU parameters
  8. Torvalds Is Unconvinced By LTO'ing A Linux Kernel