Problems in getting new drivers into Linux distributions
Oron Peled
oron at actcom.co.il
Wed Jan 5 00:35:34 IST 2011
On Tuesday, 4 בJanuary 2011 19:43:53 Omer Zak wrote:
> The article "The Challenge In Delivering Open-Source GPU
> Drivers" (http://www.phoronix.com/scan.php?page=news_item&px=ODk3MA)
> discusses the obstacles facing Intel and AMD in getting up to date Linux
> support for new graphic cards into Linux distributions.
1. The claim Phoronix present in the article that Linux release cycle
is too slow for graphics stack updates should be taken with
several grains of salt:
* Both Intel and AMD know how to work with FOSS *pre-release* so the
software support is in place before the silicon is shipped.
Two prime examples are the release of Intel/Itanium more than a
decade ago and the release of AMD/Opteron more than 5 years ago --
We talk about complete new (64bits) CPU architectures here and
in both cases Linux was ready when silicon was ready (unlike
Windows...)
* The release cycle of desktop Linux distro Ubuntu/Fedora/Debian-Testing
etc. is fast enough to enable many possible merge points.
Let's look at real data -- Examples from Fedora on my Laptop
(June-Dec 2010):
- Kernel (yes the box was upgraded in Nov-2010: fc13 -> fc14):
$ grep kernel-PAE-2 /var/log/yum.log-20110101 | grep Installed
Jun 02 00:21:12 Installed: kernel-PAE-2.6.33.5-112.fc13.i686
Jun 15 23:43:25 Installed: kernel-PAE-2.6.33.5-124.fc13.i686
Jul 10 23:53:31 Installed: kernel-PAE-2.6.33.6-147.fc13.i686
Aug 04 02:23:42 Installed: kernel-PAE-2.6.33.6-147.2.4.fc13.i686
Aug 24 12:21:18 Installed: kernel-PAE-2.6.33.8-149.fc13.i686
Sep 05 11:30:03 Installed: kernel-PAE-2.6.34.6-47.fc13.i686
Sep 10 19:53:34 Installed: kernel-PAE-2.6.34.6-54.fc13.i686
Sep 24 01:49:23 Installed: kernel-PAE-2.6.34.7-56.fc13.i686
Oct 23 23:16:50 Installed: kernel-PAE-2.6.34.7-61.fc13.i686
Dec 05 21:30:10 Installed: kernel-PAE-2.6.35.9-64.fc14.i686
Dec 23 11:30:32 Installed: kernel-PAE-2.6.35.10-72.fc14.i686
Dec 27 14:22:06 Installed: kernel-PAE-2.6.35.10-74.fc14.i686
- Xorg server:
$ grep xorg-x11-server-Xorg /var/log/yum.log-20110101
Jul 02 10:07:40 Updated: xorg-x11-server-Xorg-1.8.0-17.fc13.i686
Jul 10 23:57:40 Updated: xorg-x11-server-Xorg-1.8.2-1.fc13.i686
Jul 25 10:53:30 Updated: xorg-x11-server-Xorg-1.8.2-2.fc13.i686
Aug 08 08:55:39 Updated: xorg-x11-server-Xorg-1.8.2-3.fc13.i686
Sep 24 01:48:57 Updated: xorg-x11-server-Xorg-1.8.2-4.fc13.i686
Nov 26 13:02:29 Updated: xorg-x11-server-Xorg-1.9.1-3.fc14.i686
Dec 23 11:35:40 Updated: xorg-x11-server-Xorg-1.9.3-3.fc14.i686
- Xorg drivers (cut long lines):
$ grep xorg-x11-drv /var/log/yum.log-20110101 | cut -c1-60
May 28 10:46:43 Updated: 1:xorg-x11-drv-nouveau-0.0.16-6.201
May 29 23:00:40 Updated: xorg-x11-drv-wacom-0.10.6-2.fc13.i6
Jun 02 00:16:40 Updated: xorg-x11-drv-synaptics-1.2.2-6.fc13
Jun 11 16:50:44 Updated: xorg-x11-drv-wacom-0.10.6-3.fc13.i6
Jun 23 23:00:32 Updated: xorg-x11-drv-wacom-0.10.6-4.fc13.i6
Jul 02 10:08:13 Updated: 1:xorg-x11-drv-nouveau-0.0.16-7.201
Jul 02 10:08:15 Updated: xorg-x11-drv-intel-2.11.0-5.fc13.i6
Jul 02 10:08:16 Updated: xorg-x11-drv-elographics-1.2.4-1.fc
Jul 10 23:57:41 Updated: xorg-x11-drv-vmmouse-12.6.9-4.fc13.
Aug 21 06:04:10 Updated: xorg-x11-drv-wacom-0.10.8-2.fc13.i6
Sep 05 11:32:39 Updated: 1:xorg-x11-drv-nouveau-0.0.16-8.201
Nov 06 15:49:24 Installed: xorg-x11-drv-wacom-0.10.8-1.20100
Nov 19 03:10:10 Updated: xorg-x11-drv-wacom-0.10.8-2.fc14.i6
- KDE:
$ grep kdelibs-4 /var/log/yum.log-20110101
May 28 11:45:39 Installed: 6:kdelibs-4.4.3-2.fc13.i686
Jun 17 09:58:21 Updated: 6:kdelibs-4.4.4-1.fc13.i686
Jul 14 10:58:46 Updated: 6:kdelibs-4.4.5-1.fc13.i686
Nov 19 03:06:46 Updated: 6:kdelibs-4.5.3-1.fc14.i686
Nov 28 09:05:23 Updated: 6:kdelibs-4.5.3-3.fc14.i686
Dec 12 13:15:27 Updated: 6:kdelibs-4.5.4-2.fc14.i686
> Seems that there are all kinds of interlocking interdependencies - both
> kernel, X-Window and Mesa (OpenGL implementation) need to be updated to
> support such drivers.
2. It should be noted that this wave of updates is because the
Linux graphics stack had pretty out of date architecture not long
ago because graphic cards vendors did not want to play the FOSS
game. This changed in the latest 2-3 years:
* Intel which had FOSS drivers for a longer time, started doing more
serious graphics cores (e.g: shaders etc.) -- leading to major
changes.in the Linux graphics stack.
* Roughly at the same time, AMD bought ATI and made them work
together with FOSS developers -- leading to similar major changes.
So you get the picture -- about 2-3 years ago a technological shock
wave started in the Linux graphics stack. Trust me, as a user of a
bleading edge distro [Fedora] and a very demanding graphics
desktop [KDE-4] these changes was strongly felt by me -- Including
having to use GNOME for few months on my older laptop about two
years ago [circa Fedora-10].
However most of it is over and in the last year I see very good out
of the box support for various Intel chipsets -- so getting the same
experience for bleading edge chipsets is quickly approaching
(including AMD/ATI -- although I have less experience with them)
What we see is a temporal problem here and not something inherent to
Linux distros development cycle or FOSS.
> And this is a problem for distributions which
> periodically release a version (Arch and Gentoo are exceptions).
>
> I do not understand one thing.
> Debian has backports (http://backports.debian.org/). Through backports,
> it is possible to get the appropriate updated versions into a
> installation based upon a particular release.
>
> Don't other distributions have backports, too?
3. Backports are needed for distributions with long life cycle. These
distros can pull *some* modern packages from their fast-pacing
relatives:
* Debian-stable have backports from Debian-Testing.
,* RedHat/Centos have extra modern packages from Fedora (EPEL repository)
While they are different, there are some common attributes:
* In both cases, only *selected* packages are backported/added.
Normally, nobody tries to add packages that conflict with
existing packages and may make package maintenance a nightmare.
* In both cases, the packages are taken from a distribution that is
standing on its own and may be installed in the first place if so
desired.
This means that the probability that backports or EPEL would push
big architectural changes (as opposed to one driver update) into a
"stable" distro is very low, and for a good reason.
Also, this is why most people using Linux desktops, choose some
fast-pacing distribution.
Don't worry, be happy ;-)
--
Oron Peled Voice: +972-4-8228492
oron at actcom.co.il http://users.actcom.co.il/~oron
"The future is here, it's just not evenly distributed yet."
- William Gibson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110105/d416d8b7/attachment-0001.html>
More information about the Linux-il
mailing list