LWN: Comments on "Some notes on Linux and free drivers"

They do sell drivers.

stepz — Sat, 29 Apr 2006 22:05:50 +0000

Most people who don't give a damn about software freedom (ie. the overwhelming majority of NVidia's and ATI's customerbase) base their buying decisions mostly on performance. As drivers are a really big part of the graphics performance equation, one can say that people buy the drivers in the package - they are willing to pay more for a product with better drivers.

I'll bet that graphicscompanies commit a pretty massive amount of R&D resources in their driver technology. Even if they don't admit it, it is understandable that they would like to protect their investments.

Some of the commenters here seem to underestimate the complexity of todays graphics drivers. They are a LOT more complicated than any other driver in the kernel. Nevermind the DMA, power mode handling, dynamic memory controller parameter optimization, they even contain a fullblown optimizing VLIW compiler to JIT compile shaders.

Some notes on Linux and free drivers

zealot — Sat, 29 Apr 2006 02:35:54 +0000

Cool, this I will buy. I can stand slow open source drivers much better than I can stand binary only drivers. Because I can fix the first problem...

The open source drivers are not slow, the hardware is (with respect to 3D performance). At the moment you have to choose between fast hardware with binary-only drivers and slow hardware with open source drivers. That's the dilemma.

I like to play fancy-looking games on my computer from time to time, so I have no choice. If I had the choice between open- and closed-source drivers, I'd use the one that works better. If I used an open-source driver and found a bug, I'd try to fix it (with the help of kernel developers). It's as simple as that.

Call without hope

adobriyan — Sat, 29 Apr 2006 01:05:12 +0000

Nvidia, ATI people, if you're reading this, please make a decision to release documentation.

I'm not asking for driver, source code, skeleton driver, whatever. I don't care for Windows users, they will eat what they are given, anyway. I'm asking only for documentation, so other people can write driver in their copious free time for Linux and BSD.

There is a very simple reason for that: I trust Linux and BSD hackers much more than some NVidia or ATI coder to produce sane (both interface and implementation-wise), reviewed, secure driver.

Last time I checked NVidia driver was roughly 3 times bigger than the whole Linux kernel I'm using right now. With all its scheduling, memory management, networking, low-level filesystem, virtual filesystem, interaction with hardware (network, video, PCI, AGP, keyboard, mouse), DMA, power-management stuff. The list is infinite.

Are modern 3D graphics drivers are that complex. Are they more complex than the whole Linux operating system? I don't believe in it. It's just hard to believe.

Or be a man and release a driver. If hch and viro won't say

        Junk, learn C.

it would be a biggest compliment your company ever received.

The interface IS the source code

turpie — Fri, 28 Apr 2006 04:39:58 +0000

How often does that actually happen?
I would think that usually you would be able to install an older distribution and then upgrade the kernel to get support for peripherals.

Some notes on Linux and free drivers

jmansion — Thu, 27 Apr 2006 08:54:22 +0000

> But, it seems, they are not up to the task of writing a driver for a graphics adapter.

Perhaps not without access to documentation and examples that would be non-trivial for the hardware manufacturer to release.

> many, many Linux users have been very clear about their wishes for years

Huh. Are there many, many Linux users with desktops *at all*? More realistically a small number of vocal developers have been saying this. Lets not overestimate Linux' importance, its just an OS - and one that's hardly mainstream fro desktop use.

> There also is no defensible reason for keeping hardware programming information secret

How about 'publishing it externally will take effort and cost us money, and so will keeping it up to date, and we don't see a big enough return in terms of new sales volume'. Money talks and you know what walks.

You can see the pain Sun has to go through to open up all parts of Open Solaris: the hardware manufacturer may have to get permission from others to make a full release.

I can't see a *defensible* reason why Linux can't have stabilised kernel interfaces and accept third party binaries. 'Defensible' is very subjective - I don't particularly care if kernel developers are inconvenienced, for example, but I do care if I am.

It is not that simple

mikov — Tue, 25 Apr 2006 20:31:26 +0000

While I agree that the drivers should be open and everybody would benefit from that, I want to empahisze the point that writing a modern graphics driver is really extremely complicated, more so than commonly assumed. In my opinion it is much more complicated than any other driver in the kernel, by far. Besides the 3D math and the issue of performance, there are countless hardware bugs, workarounds, microcode programs, independant DMA channes, interrupts, etc.

There is another problem too. Hardware manufacturers cannot produce open documentation for their chips for the simple reasons that they don't have it themselves. It would require significant resources on their part to maintain accurate up-to-date public documentation of everything.

Why they won't put out free drivers.

landley — Tue, 25 Apr 2006 20:14:25 +0000

According to the people I knew in Austin who worked in graphics companies,
Every graphics company out there is infringing on a dozen patents from
every other graphics company. It's almost as hard to make a 3d card
without infringing on random patents as it is to write a "hello world"
program without doing so.

But if the card is a sealed black box, how can they prove infringement?

They're terrified that if they open source the driver, their competitors
will use it as evidence of patent infringement in the card, and they won't
be able to respond because the competitor's stuff is still a black box
within which they can't show the corresponding patent infringements.

The interface IS the source code

rickmoen — Tue, 25 Apr 2006 20:13:23 +0000

elantis wrote:

And, because no distro in its right mind supports wholesale kernel upgrades in a distribution release's lifetime....

This, of course, is a pile of foetid dingo's kidneys. You could have:

Installed using the standard Breezy image, provided at least your mass storage host adapter was supported, and then fetched a newer kernel to support the rest of your bleeding-edge hardware.
Used a third-party Debian-compatible image (e.g., a netinst) using a recent kernel, and then cut over using apt-get.
Used the Dapper pre-release installation image. (And why not, sir? It's quite good -- and probably a lot less buggy than the hardware in that "new box" you built.)
Temporarily put your hard drive into an older box, installed Breezy, fetched a newer kernel, moved your hard drive back.
Compiled the one or two drivers you needed, put them on a USB flash drive, and insmod-ed them into the Breezy installer when needed.

The reason nobody's going to hand you a guaranteed-stable binary driver interface, no matter how much you complain, are compelling and amply explained. If you insist on using obscure or bleeding-edge hardware, you have ways to deal with the problem you've imposed on yourself -- far more than you claimed were your "only options".

Alternatively, you're more than welcome to fork the kernel and maintain a "stable API", yourself. Please do: It'd be fun to watch.

Rick Moen
rick@linuxmafia.com

Some notes on Linux and free drivers

csamuel — Mon, 24 Apr 2006 12:03:45 +0000

It's not just video, I'm getting warnings from vendors about the new
Serial Attached SCSI (SAS) controllers that are emerging in new cluster
style boxes - comments like "the binary modules will only be available
for the kernels of Redhat and SuSE" fill me with dread. :-(

Some notes on Linux and free drivers

shapr — Mon, 24 Apr 2006 09:00:55 +0000

Cool, this I will buy.
I can stand slow open source drivers much better than I can stand binary only drivers.
Because I can fix the first problem...

The interface IS the source code

davecb — Sat, 22 Apr 2006 19:35:37 +0000

Just for everyone's information, the kernel interface
in non-Linux OSs aren't stable either. In Solaris, when
I was on the ABI team circa 2.6, we discussed a kernel
ABI and API, but drivers were acively evolving, so it
didn't happen.

The Solaris 10 driver interface is much more stable, but
it can still be changed if necessary.

--dave

The interface IS the source code

dododge — Fri, 21 Apr 2006 17:35:09 +0000

> Hm. What was preventing you from upgrading to newer kernel/modules
> in Breezy repositories?

He may have been talking about the installer kernel itself. For example
if the kernel that boots from the install CD doesn't have a recent enough
driver to be able to reliably access your SATA chipset, you're going to
have a hard time installing the base system onto a SATA drive in the first
place.

Planning ahead

man_ls — Fri, 21 Apr 2006 00:08:57 +0000

How long do you think it takes to bring a product to market? Or, once it is announced (if they don't want to lose the element of surprise), to distribute it in quantity? If it's something like six months, then the manufacturer should have time to submit their driver to lkml and have support in the kernel, in time for the next release of your favorite distro.

Even if the window is just one or two months, they would have time to submit their code to kernel developers and have it in the next kernel release, so that you could just download the kernel in source form and compile it yourself.

Hardware manufacturers have a responsibility to their users, so this process should not be too much of a burden. Certainly less than maintaining binary drivers themselves.

The interface IS the source code

oak — Thu, 20 Apr 2006 20:46:42 +0000

> However, the very most recent stable Ubuntu release *wouldn't install*
> because various bits of the hardware had no drivers in the ancient
> (by Linux standards) kernel in the Ubuntu Breezy install disc.

Hm. What was preventing you from upgrading to newer kernel/modules
in Breezy repositories?

> The same went for the most recent Fedora release at the time. In short,
> it was impossible for me to install any of the OSes I want onto this
> machine without downloading and installing a beta/pre-release version
> of an OS (Ubuntu Dapper, in my case).

Or updating just the kernel from Dapper?

(I just installed Breezy on P166 and updated just the X server to Dapper
because Breezy's ATI driver was segfaulting because it was probing for
my PCI gfx card from the ISA bus.)

Some notes on Linux and free drivers

yodermk — Thu, 20 Apr 2006 20:44:04 +0000

Nah, huge difference between closed source games and drivers. The kernel and its drivers need to be open source for numerous reasons, as pointed out in the articles. Games are purely user space, and if they are broken, the only consequence is that the game itself doesn't work. Closed source user space apps do not taint the kernel, nor render obsolete your hardware.

I'm willing to buy closed source software in some cases. I'm NOT willing to use closed source drivers.

Some notes on Linux and free drivers

bockman — Thu, 20 Apr 2006 20:20:14 +0000

The whole point of DRI/DRM is that the graphics driver runs in the X server, and the kernel just gives it an interface to the card

You're sure about that? Because my understanding is that, on the contrary, the kernel do talks with the graphic card and offers DRI/DRM as an higher-level interface that the X server can use to do its stuff. So the hardware-specific stuff goes in the kernel, not in the X drivers...

or not?

The Real Customers

ncm — Thu, 20 Apr 2006 20:10:53 +0000

Dell and HP simply don't care one way or the other, and why should they?

Some notes on Linux and free drivers

ehovland — Thu, 20 Apr 2006 18:12:06 +0000

I have bought nVidia chipset based graphics cards for the last 6 computers I have bought for my own use. And the last 10 computers I have had some influence with at work. Why? Because in general they have Just Worked.

But, my biggest gripe with both nVidia and ATI is that there is a portion of technology on their cards that I have a love hate relationship with - Motion Compensation support through XvMC. I use MythTV like I have no sense, with three MythTV boxen at home. And more to follow probably. It is like an addiction with this stuff. There isn't a room in the house I don't want to watch something on these days. My TV and netflix consumption has double since I got into MythTV. And for some darn reason every show I want to watch is on at the same darn time (must have 4 tuners). Now XvMC ought to make my watching more enjoyable and lower the per unit cost since I can offload this stuff to the already required graphics card. But the driver support goes back and forth every version with nVidia and ATI just plain doesn't support it.

In these niche markets, nVidia would save a whopping pile of money if they released the drivers. And since the IP that goes into them has been stale since about 2003, they are not loosing any market share. They might even get a leg up on XviD support in hardware. But alas, they continue to put out releases that either break or improve XvMC, causing me to laugh or cry.

Oh well.

The Real Customers

grahammm — Thu, 20 Apr 2006 17:22:10 +0000

How would Dell and HP lose out from free drivers? Surely the only people 'hurt' by free drivers would be those who sell non-free drivers separate from the graphics cards. ATI, Nvidia, Dell. HP etc are in the business of selling hardware. If anything the availability of free drivers would increase their bottom line not harm it.

The interface IS the source code

cventers — Thu, 20 Apr 2006 16:05:24 +0000

I invite advocates of the stable API theory to
read /usr/src/linux/Documentation/stable_api_nonsense.txt. I understand
that your scenario regarding distributions is a problem; the difference
is that it's actually not a kernel developer problem at all.

The problem kernel people have with a "stable API" isn't that they are
somehow lazy -- the problem is that a stable API flies in the face of the
agility of kernel development. This agility means that I can walk into
LKML, identify a bad design, propose a better design, and then in one
sweeping series of patches, replace the entire mechanism. It keeps the
kernel from getting cruft.

If you have a stable API, the time is soon going to come where it gets in
the way. Then you have a driver author hacking around the stable API,
because that's the way to talk to the kernel. And then you have the
subsystem maintainer hacking around the stable API, cause that's the way
to talk to the driver.

So you end up with crufty code talking to crufty code over a rickety old
bridge.

The correct answer is for the distributions to either accept the
responsibility of backporting important modules (because the reality is
often that while the api is not stable, it doesn't change *dramatically*
often enough that backporting would really be a huge effort), or,
alternatively, offer up-to-date kernel packages that users can accept
under a 'beta' headline in order to support their new hardware.

People say the bleeding edge kernels are buggy and unstable. Of course,
something that just hits the road is going to naturally have some
problems. But I've been on the bleeding edge for a long time, and rarely
has it led to any kind of problems whatsoever. In years of using Linux on
servers and desktops, I've never seen the kernel actually crash on me,
with the exception of one time when I had failing RAM. The reality is
that most desktop users that use bleeding edge hardware can probably get
by just fine on bleeding edge kernels, if only the distributions would
step up and accept responsibility of delivering them to their users in a
useable way.

Some notes on Linux and free drivers

yokem_55 — Thu, 20 Apr 2006 15:51:12 +0000

For me, if you are already using a proprietary piece of software such as a game, it isn't that far of a jump to be accepting of a proprietary graphics driver. This is precisely why the binary only drivers have managed to be accepted for so long: their users are already comfortable with using non-free games and thier related software, and if those games require a non-free driver, so what, you've already squandered your quibbles?

Now that XGL and company are gaining traction, the requirment for a good 3d graphics driver is expanding to those that aren't playing proprietary 3d games and only seek to use free software, and thus the level of protest is increasing.

Some notes on Linux and free drivers

tshow — Thu, 20 Apr 2006 15:35:28 +0000

Remember that what the PR office at a company tells you is often only tangentally related to reality.

There is one argument for keeping the drivers closed, and it's being used by the legal departments (ie: the people who really make the decisions) at most or perhaps all of the major graphics card manufacturers: patents. More specifically, all of the major graphics card providers are infringing each other's (and other people's) patents. They aren't totally sure which patents they are infringing on, but all the engineers I've worked with are certain that there are infringements in both their hardware and software, probably going back years and through billions of dollars worth of product.

Copyright infringement is also a problem; when you hire armies of developers and set them on writing something, some of them are going to copy things they find on the net without attribution.

Refusal to ship source is at least partly done as a head-in-the-sand defense against patent and copyright infringement lawsuits. That one of the (formerly) major graphics card producers up here in Canada got nailed for copyright infringement in their driver code hasn't helped, either. Rather than try to solve the problem, obscurity and denial are being used to hide it.

It's not the only problem, of course. There are misguided ideas about competition and reverse-engineering lead times, as well as downright stupid belief that if the public knows about hardware bugs it will result in face (or sales) loss. The IP law problem is a major issue, though.

In order to get chip specs and hardware level docs freely released again, we're going to have to do something about the mess of an intellectual property legal system we currently have. In the graphics industry in particular, IP law has been crippling everyone for years.

Some notes on Linux and free drivers

yodermk — Thu, 20 Apr 2006 15:32:29 +0000

To clarify for those of us who don't regularly follow graphics hardware, is this stuff significantly better than the Radeon 92xx? Is there a PCI express version or only available on Intel motherboards?

Will it run Novell and RH's new OpenGL X environments reasonably well?

(I plan to get a monster AMD64 system within the next year and REALLY hope there's a solution to this by then!)

Some notes on Linux and free drivers

lacostej — Thu, 20 Apr 2006 15:27:58 +0000

That's OK for me. I will then buy a laptop with an Intel graphic card AND let the manufacturers know the reason of my choice, not only the one I buy from, but the ones I don't buy from.

If 10000 persons do the same, I think that will send a clear message to the manufacturers.

Some notes on Linux and free drivers

tetromino — Thu, 20 Apr 2006 14:34:43 +0000

The ONLY modern graphics card with open-source, halfway-decently performing OpenGL drivers is Intel's GMA900 series (i915, i945, etc). And, quite frankly, Intel's graphics are dog-slow compared to any Nvidia or ATI card. If you go with open-source Intel, you will be able to play Quake III, but nothing more modern. Neverwinter Nights, for example, is barely playable on an i915 -- and it's quite an old game.

The interface IS the source code

tetromino — Thu, 20 Apr 2006 14:18:51 +0000

Overall, I agree with you, but just to nit-pick:

You say "no distro in its right mind supports wholesale kernel upgrades in a distribution release's lifetime"

Gentoo does. For instance, Gentoo 2005.1 was released in early August 2005. After it was found that it didn't install on some newer AMD64 systems, Gentoo updated the kernel and released 2005.1-r1 in mid-November.

The interface IS the source code

rknop — Thu, 20 Apr 2006 14:17:17 +0000

You are wrong -- it DOES solve the problem, at least some of the problems.

A year from now, when all (or most) of the distributions have done new releases, that hardware *will be* supported. Two years from now, it will be supported. But will it be supported if you have to rely on getting binary-only drivers from a vendor? Likely not; the kernel will have changed, and the old driver won't work.

It's ESSENTIAL to get your drivers into the mainline kernel if you few your hardware as anything other than a flash-in-the-pan, not to be used on Linux distributions that were released after six months after the release of the hardware device.

And a workaround to the problem you mention can go with in-kernel drivers. Redhat used to have their secondary archive of "addons". You can make packages for popular distros, or make source packages available, with added kernel drivers. After a few months, when a new distro release comes, everything will get simpler. This happened with the ipw2200 drivers (although we still need an annoying firmware blob... grrr).

Very few traditional vendors realize that the free software/open source development model is fundamentally *different*. A stable kernel API for low-level things like drivers really *is* less crucial, because the *right way* to do things is for everything in the kernel to be free, and thus integratable into the main kernel. They have all lived in the MIcrosoft world where they can list which versions are supported, and write drivers for those-- well, Linux just doesn't work that way, and the fact that proprietary vendors have always worked that way does NOT mean that it's the only way one can work. And, the Linux way really is better when it comes to older hardware-- the drivers generally do stay along and get updated for newer releases, whereas with vendor-supplied binary drivers, you have to count on enough backwards compatability, or the vendor releasing a new driver.

-Rob

The interface IS the source code

elanthis — Thu, 20 Apr 2006 13:46:57 +0000

This "get it into the mainline kernel" line is just as broken today as it ever was.

Here's an example:
I built a new box a month or two ago. I wanted to install Ubuntu. However, the very most recent stable Ubuntu release *wouldn't install* because various bits of the hardware had no drivers in the ancient (by Linux standards) kernel in the Ubuntu Breezy install disc. The same went for the most recent Fedora release at the time. In short, it was impossible for me to install any of the OSes I want onto this machine without downloading and installing a beta/pre-release version of an OS (Ubuntu Dapper, in my case).

Now, let us assume that the kernel had a stable driver ABI. Or, heck, we don't even need that; let's pretend it had a stable driver API. I could have downloaded the additional and updated drivers necesasry to install Linux on my new box, put them on a floppy, and told the installer to use those driver binaries or even to compile those drivers at install time. And voila, I could've installed just about any Linux onto this machine without resorting to installing buggy unstable pre-release software for hardware which was already close to 6 months old in shelf-time.

The "get it into the mainline kernel" line essentially means that in order to ever support new hardware, you have to upgrade your kernel. And, because no distro in its right mind supports wholesale kernel upgrades in a distribution release's lifetime (look at how much testing and effort has to go into getting a simple kernel patch package pushed out from a major distro vendor), that essentially means that you have to upgrade your entire operating system - every library, application, and so on - to a new version of the distribution release to get the newer kernel that supports your new graphics card or sound card or network card or whatever. And, if there hasn't been a new release of your distro with the new kernel yet... too bad. You are forced to not use some bit of new hardware, *even if a completely Free GPLd Linux driver has existed for several months for the hardware*.

Your only options become: (a) don't use new hardware, even if you have a genuine need for it; (b) install the kernel from sourcecode yourself, which requires a huge investment of time and energy, and requires knowledge most people don't have and shouldnt' realistically be forced to have, and which means you lose automatic kernel security updates from your OS vendor; or (c) install a beta version OS to get the new kernel.

Again, you don't even need a stable ABI or non-Free drivers; I just want to be able to take a Free GPLd driver that came out five months ago and install it on my OS which came out six months ago. I'm perfectly fan with completely banning non-GPL drivers. Wanting non-Free binary drivers is NOT the issue here!

"Get it in mainline" isn't an answer that actually helps users. The only people it helps are the developers, because it gives them an excuse to not need to put forth the effort for a stable API. It's the developers' project, and I in no way feel that I have a right to tell them how to do things unless I'm paying them to do it. But please stop blathering on with the nonsense that "getting drivers into mainline" actually solves the issues the *users* have with binary drivers. It doesn't.

Stuff to avoid

davidw — Thu, 20 Apr 2006 10:50:35 +0000

At the risk of being a bit repetitive for people who have seen it before, have a look at the Linux Incompatibility List:

http://www.leenooks.com

That's stuff that you shouldn't buy!

Remember, it's a wiki so that anyone can update it if they find hardware that doesn't work, or (hopefully), things that now have free drivers.

Intel graphics cards

shane — Thu, 20 Apr 2006 10:45:06 +0000

I asked for the Intel graphics chipset on my latest company laptop, because I knew Intel has been good about supporting open source (actually, I also asked for the Intel wireless card for the same reason). PCI reports it as:

Intel Corporation Mobile 915GM/GMS/910GML Express Graphics 
Controller (rev 03)

It works okay, although I'm using the VESA mode right now. It looks fantastic (better than Windows, and I don't know why that is), but doesn't support console blanking, so I'll be trying a more recent X.org release soon.

As far as performance... I don't know. 2D performance is fine, but when I boot into Windows to play Civilization IV, it's just too slow. But that's okay, because I shouldn't really be playing games on my company laptop anyway. ;)

Some notes on Linux and free drivers

lacostej — Thu, 20 Apr 2006 09:38:05 +0000

It's time to vote with our money.

I plan to replace my laptop within the next months. I want an open source driver for my card, and I am ready to pay more even if I don't get to play 3d games (which I never play anyway).

Are there any card with open source drivers?

What about Intel? Is their GMA 950 card coming with free drivers ? Is it good enough? I've yet to find a powerfull laptop with 2G memory and an at least 15" screen, a resolution > 1014x768 with such a card. Any advice?

And when I find my dream machine, I will call every single other vendor and tell them why I didn't pick theirs.

Some notes on Linux and free drivers

ken — Thu, 20 Apr 2006 09:33:59 +0000

Have LWN tried to get any more information out of Nvidia ??

Even if you get the same nonsense answer at least they are going to have to do some type of statement again and sooner or later at least they have to drop the customer don't want it line.

Derek Perez "Director of Public Relations" dperez@nvidia.com
Andrew Fear "open mouth whitout thinking department" afear@nvidia.com

Some notes on Linux and free drivers

pointwood — Thu, 20 Apr 2006 08:39:10 +0000

Considering how many NVIDIA and ATI cards that's in use and gets sold around the world, open source graphics drivers from them would certainly remove a large problem for especially desktop linux. I can only imagine x.org and the XGL project would love to see this happen.

The Real Customers

ncm — Thu, 20 Apr 2006 07:51:06 +0000

You're not a customer. You're a user -- at best, the customer's customer.

This is similar to TV, magazines, newspapers, and grocery stores. You're not a customer at all, there: you're the product. The advertiser is the customer. Your eyes are being delivered to the customer. Running a grocery store chain is a lot like real estate: Kellogg and Pepsi pay a high rent on the shelves you're most likely to see, and may even stock those shelves themselves.

What has this to do with graphics cards? Most of ATI's and Nvidia's money comes not from selling cards to people like you, but from getting their stuff integrated into complete systems. Their real customers are Dell & HP. When those guys ask for Free drivers, ATI & Nvidia will gladly hand them over. If they find that big customers (still not you; rather, GM or the DOD) are buying systems with i915 video instead of theirs because of the Free drivers, they might see the light, but they will probably only find that out because their own customers complain about lost sales. Dell & HP are more likely to offer GM and the DOD systems with i915 inside than complain to ATI or Nvidia.

Meanwhile, people at GM & the DOD who care about Free drivers find it nearly impossible to communicate that to anyone responsible for making buying decisions, or to anyone who ever talks to Dell or HP.

The problem is that the channel from people who care to people who decide leaks too much information. Very little gets all the way through. In some ways it's astonishing that modern markets function at all, with all the machinery that has been built up to filter out meaningful information.

Some notes on Linux and free drivers

vmlinuz — Thu, 20 Apr 2006 03:58:05 +0000

Surely the issue for a graphics driver isn't the ever-changing kernel interface, since, in general, the kernel doesn't manage graphics drivers? The whole point of DRI/DRM is that the graphics driver runs in the X server, and the kernel just gives it an interface to the card - and it doesn't seem like there's any problem with the kernel side of that interface being open. The modern x.org release process seems pretty stable and under control - it would seem like if a vendor *wanted* to fully participate in that process, as opposed to the occasional bug fixes for old cards which seem to be all they contribute now, it shouldn't be that hard for them to get decent drivers shipped, and 'supported' in the normal x.org way.

From my point of view, I don't feel the need for a lot of the funky features available on modern cards, which are often implemented partially or completely in the driver - all I want is fast, stable GLX, with a side helping of reliability and openness, with good xvideo support for afters...

Some notes on Linux and free drivers

kirkengaard — Thu, 20 Apr 2006 03:52:09 +0000

Les mots justes. There really isn't a better response to the article to be made; this is the argument. nVidia and ATi are not special WRT building complicated hardware, or having a wide range of device versions to support. Their work is in no way uniquely or insurmountably difficult.

The only excuse with any legitimate force is legal impediments provided by license incompatibilities WRT components of their drivers that they don't properly own. I've seen that one pushed about, but I haven't seen its teeth; what prevents them from releasing the bulk of the driver free and leaving us to work around the BLOBs? We have proven, excellent cleanroom reverse engineers in the community. The work can be done from specs; the work can even be done without specs, push to shove.

I have a sneaking suspicion that nVidia and ATi are not helping the problem with their driver offerings, in much the same way that bitkeeper's presence under not-totally-repulsive terms stalled its replacement. But nobody is really pushing in the same way, either. There is the expensive nature of gathering up enough varieties of either company's product to be considered; it's not like they will donate a set to be coded for, like has been done by other hardware companies. Though, if they did, it might be cheaper in the long run than doing their development in-house. If they're not worried about intellectual property, as they say...

The interface IS the source code

dwheeler — Thu, 20 Apr 2006 03:38:48 +0000

I just wanted to confirm your statement: "This discussion misses the point entirely. The way to get a driver to work across distributions is to get it into the mainline kernel." This has been repeatedly stated, in various ways, on the Linux kernel mailing list and elsewhere. Some people don't know this, so providing such information is useful... but way too many vendors cover their ears and sing instead of listening. Alan Cox made a posting several years ago making this clear, for example. There IS a standard method for creating drivers for Linux. That method is called source code, contributed as open source to the kernel project.

This approach has lots of benefits for users. I believe the #1 cause of Windows crashes has been driver problems... by having worldwide review, and enabling fixing of drivers, drivers end up being much higher quality. But most important to many is support -- for example, an open source software driver means that you can upgrade your kernel AND you get help from developers. Upgrading a kernel is eventually impossible with many closed source drivers, and few developers will help those with tainted kernels.

I'd love to see this problem fixed.

Some notes on Linux and free drivers

etwilson — Thu, 20 Apr 2006 03:35:04 +0000

I'm an nvidia customer, can I ask them for an open-source driver? 'Cause, to be frank, theirs really don't work very well. The nvidia supplied drivers for linux lock up for me pretty regularly.