Plenty of work ahead [LWN.net]

Plenty of work ahead

Posted Dec 2, 2007 17:32 UTC (Sun) by mmarq (guest, #2332)
In reply to: Plenty of work ahead by k8to
Parent article: The first ATI r5xx/6xx X11 driver release

"" The experience of this driver has actually driven me to use Windows again to get certain
work
done after around ten years of Linux as my sole working platform.

I suspect there is simply not enough manpower in the arena of the video drivers on Linux. ""

Nevertheless i still use Linux... try the proprietary offerings... I've being "crying to the
winds" in this forum for more than half a decade!!...

In my opinion its not manpower its the *will* and a workable method and organization(
concentrated efforts, because reverse engineering would be still in the menu ) to obviate the
lack of a long in time stable API or ABI of the driver model.

Worst that can happen its the various distros driving different implementations as a marketing
differentiation point!... akin to our favorite "Bill" selling *rope*, openly and without
shame, at the entrances of RH, Novell, Canonical... LF... headquarters ( rope for people to
hang themselfs )...

( for crying out loud why isn't DKMS official tree code ?... or am i being out for too long
?!)

If the *will* is there, than it only misses a good development method and organization for it
to take off good... because the hardware manufactores wont do it "really" for free for OSS( no
matter what they claim)... for them is just a matter of dumping development, maintenance and
support costs to the community.

If the *will* is there and the method and organization, then 'we' can talk about Linux desktop
really taking off and spreading like wild fire, otherwise, we better talk about santa claus!

(Log in to post comments)

Plenty of work ahead

Posted Dec 3, 2007 18:34 UTC (Mon) by elanthis (guest, #6227) [Link]

"for crying out loud why isn't DKMS official tree code"

Because upstream kernel developers think that out-of-tree kernel code is disgusting and awful
and evil, and DKMS is unnecessary for in-tree code.

They don't mind the idea that, in order to use new hardware or use a newer driver, you need to
upgrade your entire fucking kernel, along with without user-space libraries and daemons and
tools occassionally get broken by those updates (hal, udev, and anything that uses the fluid
sysfs paths).

Not sure it's really worth it to whine about the kernel like that, though.  It's the same deal
for a Linux distribution as a whole.  Want a newer version of FooApp?  Upgrade your whole
fucking OS to the next release, and then you also get all those undesired changes to your
desktop and other apps along with all the new bugs and breakage you didn't have to put up with
before.

Linux (both the kernel and the family of OSes) has always been based on one of two models: the
"compile shit directly from version control on a daily basis" model and the "you get a fixed
set of software snapshots in your OS appliance" model.  If you dislike both of those models,
use a different OS.

Plenty of work ahead

Posted Dec 3, 2007 20:39 UTC (Mon) by drag (subscriber, #31333) [Link]

Plus DKMS isn't a big deal when it comes to open source drivers. 

The only thing that matters in terms of kernel would be things like DRM or AGPGART stuff. DRI
and Xorg XAA/EXA drivers have no dependancy on the kernel beyond that. 

It's fairly trivial to manage multiple versions of the Intel driver or have compiled a Mesa
tree and DRI stuff outside your distribution-provided stuff.

It's even possible to switch between multiple versions of DRI drivers within the same X
session. It just requires LD_LIBRARY_PATH tricks to point applications at a different path. 

for example:
export LD_LIBRARY_PATH=/path/to/xc/xc/exports/lib:$LD_LIBRARY_PATH
export LIBGL_DRIVERS_DIR=/path/to/Mesa/lib

It's not that hard at all.

With the 2D drivers you just copy over the *_drv.so file, and keep backups of the originals so
you can go back if it breaks something. 

Occasionally you'll run into kernel-level dependancies for a new texture memory management
change or something like that. But for the most part they can be compiled into modules.