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. ASUS AM1I-A: A Mini-ITX Board For Socketed Kabini APUs
  2. Mini-Box M350: A Simple, Affordable Mini-ITX Case
  3. Overclocking The AMD AM1 Athlon & Sempron APUs
  4. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
Latest Linux Articles
  1. Ubuntu 12.04.4 vs. 13.10 vs. 14.04 LTS Desktop Benchmarks
  2. AMD OpenCL Performance With AM1 Kabini APUs
  3. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  4. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
Latest Linux News
  1. FreeBSD Advances For ARM, Bhyve, Clang
  2. Ubuntu 14.04 LTS "Trusty Tahr" Officially Released
  3. Ubuntu 12.04 LTS vs. 14.04 LTS Server Benchmarks
  4. QEMU 2.0 Released With ARM, x86 Enhancements
  5. Running The Unity 8 Preview Session On Ubuntu 14.04 LTS
  6. R600 Gallium3D Disables LLVM Back-End By Default
  7. Fedora 21 Gets GNOME 3.12, PHP 5.6, Mono 3.4
  8. Fedora Workstation Is Making Me Quite Excited
  9. Maynard: A Lightweight Wayland Desktop
  10. Chromium Browser Going Through Growing Pains In Ubuntu 14.04
  11. KDE 4.13 Is Being Released Today With New Features
  12. Trying Out Radeon R9 290 Graphics On Open-Source
Latest Forum Discussions
  1. Radeon 8000M problematic on Linux?
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  4. The GNOME Foundation Is Running Short On Money
  5. After Jack Keane, RuseSoft will briing Ankh 3 to Linux through Desura
  6. Suspected PHP Proxy Issue
  7. Change installation destination from home directory
  8. Bye bye BSD, Hello Linux: A Sys Admin's Story