The Challenge In Delivering Open Source GPU Drivers

yuhong writes "After the recent Intel Sandy Bridge launch left Linux users having to build the latest source from Git repositories in order to have full support for the integrated graphics, Phoronix looked at the problems involved in delivering new graphics drivers for Linux."

Comments

Damn linux users!

[intellitech]

You've just gotta have your own cake and get to eat it too!

Re:Damn linux users!

[smallfries]

It's not so much about the eating of and having of cake. It's more about demanding that Intel ship you cake in time for there to be cake there when you are hungry (that you can both eat and have).

It's a bitchy whiney ridiculous complaint - and yet it is a good thing as it puts pressure on Intel and AMD to treat Linux support as something necessary for a launch. Hopefully it won't result in Intel pointing out that there is no cake...

Re:Damn linux users!

[LingNoi]

After RTFA it seems more that there are a ton of features missing rather then delayed. Here's an excerpt from the article..

They include Video Processing Accelerators - never coming to Linux, Color Processing Accelerators - never coming to Linux, Skin Tone Enhancements - never coming to Linux, Adaptive Contrast Enhancement - never coming to Linux, Total Color Control - never coming to Linux, Video Decode in hardware - Q1, Video Encode in hardware - Q1, 3D acceleration - Q1 sooner rather than later and a host of software to use it - never coming to Linux.

Re:Damn linux users!

[erroneus]

Ah. That's sarcasm isn't it? [/sheldon]

I also got out of the article that it casts the current order of things as the ideal order of things -- in this case that Linux users are second class or lower users where Windows is the only OS that is deserving of support by hardware makers. But that is simply not what current and forward looking hardware developers should be thinking.

As others have predicted, I tend to agree that desktop computing is simply not the future of computing. In fact, it's barely the current state of computing even now. Of course business systems still run on Windows XP and pretty much the same stuff we had 5, 10 even 15 years ago with only incremental improvements. But on the consumer end, we are seeing a rapid surge in internet enabled devices serving a variety of purposes including content delivery and more. It is this area that is paving the way for adoption of this change from generic purpose computing to application specific computing devices. (AKA embedded)

And what are these embedded devices running? Some are running Windows, some are running BSD variants and derivatives ; most are running Linux. Windows is barely suitable for its originally intended purposes and most definitely not suitable for the additional uses and purposes it is being crammed into today. BSD variants and derivatives are successful but requires a heavier investment by implementers to customize the OS and surrounding code to make it work for them. Linux enjoys a greater momentum of use and support with a great deal more active enthusiasm in its communities.

As embedded systems are increasing, the selection of components that go into these devices are being made. If these components are limited in their support by which OSes are supported, I believe we will see a great deal of omission of these components in embedded devices. This is a large reason why we see less nVidia hardware in embedded applications and more Intel in my opinion.

Of course at present generic desktop computing is king. This is changing. Soon only hackers/developers will have generic desktop computing devices and the world will be using embedded systems.

It's not "linux users" that need support. It's hardware component makers that need to wake up and see what is going on. Evidently, they don't see it or they would be responding to changes in the market. Has Microsoft kept them so blinded and enticed? Where embedded systems are concerned, the majority is Linux, not Microsoft.

Re:Damn linux users!

[jedidiah]

Sounds like a lot of features that are already in the Nvidia drivers that don't seem to be included on the list of problem children.

Why can they manage while no one else can?

Re:Damn linux users!

[Teun]

As if you have a choice when buying laptops.

Re:Damn linux users!

[ThePhilips]

Meanwhile, Intel is requiring at least FIVE different base operating system components to be changed for their drivers to be updated?

I have understood the case made by the RTFA differently. (Or was the RTFA simply dumping the raw facts? Never mind.)

Supplying a binary driver works at the moment, and that what nVidia and AMD/ATI do. But that's bad because not OSS-friendly.

Yet, if a company (Intel in the case) decides to go full open source, properly and timely submits all the changes to the corresponding OSS projects as our God Linus intended, delivery of technology to the end user becomes a nightmare because of (1) all the inter-dependencies which exist between the projects AND (2) lack of central coordination.

IMO the story here is not per se that Intel f****ed it up - but about the fact that the particular area of OSS ecosystem is f****ed up (and easily alienates both vendors and users).

Re:Damn linux users!

[erroneus]

That sounds like you have never developed a hardware product before. I have been involved in the production of a series of automated teller machines and I have to say that it was pieced together from a lot of parts and tied together through an application running on an operating system.

Unless the device has its own proprietary OS (which is RARELY the case) builders of such systems typically select hardware based on the software they are creating. In some cases, they base the software creation on the cost and availability of components. Those components are typically supported in the form of SDKs which are usually focused on one or a few operating system environments and certainly not all of them.

Manufacturers at all levels do not build and support every component of the end products they produce and sell. For the implementation of these products, they tend to rely on the information provided by the manufacturer of the component.

This is PRECISELY why the Nouveau project is inferior to the nVidia proprietary driver -- nVidia doesn't make the information needed for implementation available to anyone. Not even in Windows do they release the specs of the hardware -- they just offer an "OEM" driver with data on how to customize in some way.

Intel and Open Source

[Technician]

I would have expected Intel to have released drivers. They are involved heavily in Open Source. They have the Open Source Technology Center. Has anyone asked Intel about it?

http://www3.intel.com/cd/corporate/icsc/apac/eng/teams/331393.htm

Re:Intel and Open Source

[vidnet]

They did release drivers for the latest kernel, and they work great. However, you do need bleeding edge versions of the entire graphics stack to use them. This is a problem when combined with non-free ATI and Nvidia which always lags behind with no way for maintainers to get them up to speed.

In other words, a distro can include "old" kernels/drivers/X-servers with non-free ATI/Nvidia support XOR newer and less tested ones with the latest Intel support.

Either way, it's a reduced user experience and that's what TFA is on about.

Re:Intel and Open Source

[Anonymous Coward]

Seeing as GPU manufacturers mainly used to support Windows and Mac, probably due to contracts between them, to attract cross-over clients. There was no such incentive for *nix back then.

Well, it was less of that and more a matter of having a dis-incentive (if there is such a word). For a long time, most of the 90's, it was not easy to get drivers from the hardware vendors. It's only been in the past 10 years that we've seen a website with regular driver updates become standard- you used to have to hunt for a support number, usually not a toll free one, wait for an hour on hold only to be told it would cost you $20 for handling and take 3 to 6 weeks to ship you a disc. This meant having the drivers included with the standard Windows distribution was make-or-break for most peripheral hardware, especially GPU's and soundcards which rarely came pre-built back then.
So MS was able to drop some "subtle hints" to the hardware vendors that well, if they released drivers for other OS's then it might cause some "problems" getting their drivers approved in time for the OS install discs to print and ship. In other words, although they never got caught 'red-handed', there was a LOT of fear in the hardware industry of being shut out in the cold if they supported Linux or other OS's which MS didn't want to compete with. Combine that with the usual FUD we used to (and still do) hear about opensource letting go of 'industry secrets' etc. and you end up with a climate which actively discourages the hardware makers from releasing their own drivers for Linux, or even giving out enough source to build your own. Luckily we've seen this attitude shift quite a bit in the last 5 years or so, but we're not all the way there yet.

As for Mac, back then Apple had pretty much total control of their hardware and software, and they just plain old didn't want to let any of their competitors use it.

Re:Intel and Open Source

[Anonymous Coward]

Wait, am I getting this right? Intel wrote an _open source_ driver working with the latest and greatest in Linux GPU-support-land, it was availible on release day, and people are WHINING about this?! Back in the day you'd get a binary driver needing legacy components months after the hardware was released, if you got an official driver at all.

I guess Linux on the desktop has come a long way when people start bitching about new hardware not being supported out of the box in Ubuntu. Not long ago you'd follow guide after guide trying to get all the hardware in your 5 years old computer to work...

Re:Intel and Open Source

[jbernardo]

Intel has already messed up the drivers situation for one of its product families - GMA500 aka Poulsbo. They've released 3 driver families for it, PSB, IEGD and EMGD, progressively doing a worst job. PSB is stil working in Xorg 1.9 thanks to some users who have been patching and hacking the source parts, without any Intel support. It has some unfinished parts that would take a xorg developer a couple of days to fix, but Intel has refused to even listen to the users who have been patching it, never mind helping. It has a closed source 3D driver, but the kernel and 2D drivers are open source. IEGD seems abandoned and was mostly binary, compiled for a couple of distributions. EMGD is 99% binaries including libGL, libva, and others, as some luminary at Intel decided to release the closed binaries linked to specific versions. This last crap is the currently "supported" by Intel, the other two are obsolete. EMGD only supports a very old Fedora release, and a old MeeGo release, but was made to work with Ubuntu 10.10 by downgrading Xorg to 1.8.

After all this, did anyone still expect Intel to release decent drivers? I for sure didn't.

Re:Intel and Open Source

[stoborrobots]

Wait, am I getting this right? Intel wrote an _open source_ driver working with the latest and greatest in Linux GPU-support-land, it was availible on release day, and people are WHINING about this?!

You're getting it 90% right - the whining hasn't started yet, but these guys are explaining why it's about to start...

• It's not a single driver - Intel contributed patches to all the relevant projects for support for the new features; but they've only been included into the repositories so far, and are expected to be included in the upcoming releases over the next few weeks, and some features are not yet complete, or not even planned to be supported...
• The components involved which would need recompiling on to work include the kernel, the lowest-level support libraries like libdrm and libmesa, and X - the holy trinity of "if this fucks up I can't use my computer"...
• Since the patches haven't been backported, they likely won't make it into packages which can be installed on currently-available release, or even next-releases of the big distros, where the freeze window starts some 6 months ahead of release...
• From the article:

  Over the years the expectations of Linux users have gone from simply wanting Linux drivers for their hardware to wanting open-source Linux drivers (read: no binary blobs) to now wanting open-source drivers in the distribution of their choice at the time the hardware first ships...

So, yeah - there's code out there which should be usable to make the open-source drivers go, but most of the reviewers on the net won't be able to make the bits go, some of the bits won't be ready for a while, and in general, anyone who tries to make them go in order to review this will have something or other to complain about...

But you're spot on with this statement, which echos some of the sentiments from the article:

I guess Linux on the desktop has come a long way when people start bitching about new hardware not being supported out of the box in Ubuntu.

Re:Intel and Open Source

[camperdave]

The components involved which would need recompiling on to work include the kernel, the lowest-level support libraries like libdrm and libmesa, and X - the holy trinity of "if this fucks up I can't use my computer"...

You are aware that you can compile stuff on a different machine than you're going to install on. You are aware that you can dual boot a machine. You are aware that you can ssh or use serial ports to access a machine without using X or graphics drivers. You are aware that you can make backups of the current files and use a livecd to restore them. In short, you should never be in a "can't use my computer" scenario.

It's not easy

[ToasterMonkey]

Unlike the proprietary drivers from ATI/AMD and NVIDIA or any of the drivers on the Microsoft Windows side, it's not easy to provide updated drivers post-release in distributions like Ubuntu due to the inter-dependence on these different components and all of these components being critical to the Linux desktop's well being for all users.

That's a funny was of saying Linux doesn't have a stable ABI because its architects are crazy.

I honestly hope in five years you can all go back and laugh at articles like these, but more than likely you'll have slightly bigger version numbers and different silly names.

hurl
blech

Re:It's not easy

[hitmark]

How many gaping issues are left unresolved because microsoft is maintaining a stable ABI?

Re:It's not easy

[should_be_linear]

Stable ABI requires more resources for development (people, time, testing). Simple as that. Linux HQ decided that these resources are better spent somewhere else, like fixing security issues and overall improving. Bleeding edge graphic cards _are_ the problem for several months after introduction, but that sounds like acceptable trade off to me. Resources are always limited and trade off can only be moved elsewhere, but not eliminated.

Re:It's not easy

[pseudonomous]

I'll admit I don't know too much about this but freebsd has managed to provide a stable ABI, I think back to the 4.x releases via compatibility layers (which are not installed by default but are available). I've heard that solaris's abi is stable back to the first official release. Linux devs could provide a stable abi ... but they don't care. They build their kernels from git anyway.

Re:It's not easy

[JonJ]

http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt

Re:It's not easy

[Mad Merlin]

It's obvious that you don't understand the issue, kernel ABI is completely irrelevant here. Not only is the overwhelming majority of the software that requires updating here in userspace (Mesa, Xorg libraries and Intel DDX driver), you can already switch out the kernel version in use freely, without a stable ABI!

No, what the article is trying to say is that because not every driver completely reinvents the wheel like they do on Windows, there needs to be more coordination between the driver and the other libraries that it depends upon, instead of just being able to dump the latest development code as a new release and call it a day.

Re:It's not easy

[Kjella]

That's a funny was of saying Linux doesn't have a stable ABI because its architects are crazy.

This is about a bit more than the kernel ABI flamewar. The binary blobs don't just interact with the kernel but are pretty much all over the graphics stack. If you change the X server they stop working, while the open source drivers depend on a more recent X server. If you want to change this, you need to create a Linux equivalent of WDDM, the new graphics driver model that came with Vista and caused tons of grief even though both nVidia and ATI had tons of people working on it. It would take a huge effort specifying up an ABI through the entire stack that is ultimately very little relevant to the open source Intel, AMD and noveau projects.

Re:It's not easy

[Timmmm]

That is just silly.

Paraphrasing, they say that they can't have a stable ABI because of small differences in how C compilers compile things (alignment of structures, etc.). Has that problem *really* not been solved? Microsoft manage to do it!

They then say they can't have a stable API (DPI?) because it would mean they have to maintain old code (true, but surely not too much work), and people might accidentally use the old version. Seriously? I guess they haven't heard of documentation.

And finally they say the solution is to get your driver into the main kernel tree. Not only would this be a hell of a lot more work than just shoving it on a website (subscribe to mailing lists, learn to use git properly, submit code for review, revise code, etc. etc.) but I seriously doubt they will just accept anything. What if I make a device that only I have? Will they accept a driver that is only useful for me?

Re:It's not easy

[Anonymous Coward]

That would be zero. There may well be gaping issues with MS software, but maintaining a stable API is not even PART of the problem. API stability (and even ABI stability) is just standard, well-established practice. And yes, Linux suffers a LOT for not having it.

Re:It's not easy

[icebraining]

Not only would this be a hell of a lot more work than just shoving it on a website (subscribe to mailing lists, learn to use git properly, submit code for review, revise code, etc. etc.)

Yes, you actually have to work to make sure the drivers integrates properly instead of doing a code dump. How shocking!

What if I make a device that only I have? Will they accept a driver that is only useful for me?

Regardless of whether they accept it or not, that's not really a reason to choose a stable API vs including in the tree.
And if you're the only user, do you really need to keep an updated kernel? Can't you simply write it for the current kernel and not upgrade?

Re:It's not easy

[vadim_t]

It's not about the ABI.

What's happening is that the way graphics work in Linux is being completely overhauled. This isn't a "now the do_stuff() function takes an extra argument" kind of change, it's a complete redesign. A stable ABI would prevent the former, but redesigns like this one would still happen. You can't use the Windows 3.1 drivers on Win7 for instance.

This is more of an issue of bad timing, with hardware arriving before the software is ready. A bit like XP having a lot of trouble to install on systems with SATA drives (at least initially)

Re:It's not easy

[Anonymous Coward]

It's an entirely practical proposition: with having the source code we can fix bugs and can improve the code without having to wait for the 'ABI driver owner' to do something.

It's a tradeoff between long term independence and short term availability.

And if you look at how Linux stormed the supercomputer and smartphone space you'll have to admit its architectural flexibility works in a splendid way. Yes, the other side of the coin is that the established, Windows dominated, secrecy-obsessed PC hardware space will have it easier to exclude Linux from certain hardware components, by keeping specifications secret from OSS devs.

Tough luck for them, and as Samsung has shown it it's not impossible to build hardware from scratch and use the best kernel to dominate a new space.

Re:It's not easy

[Ash-Fox]

The point is, it's a fucking mess to install graphic driver. I mean, why in the last 10 years, hasn't Linux/Xorg been able to roll out a stable graphic API on which the graphic card manufacturer can build drivers.

Actually, they have, it's just that graphic card manufacturers want more than what the API provides.

By the way, it's not about open source vs closed source, it's about Intel drivers flawed development process and Nvidia's working one. Nothing stops Intel from doing the same that Nvidia does (bundle everything) and release it as open source.

nVidia bypasses a lot of opensource code to make their stuff 'just work', I wrote this small blog entry a few years ago that explained some of the things that nVidia's drivers do to resolve 3d acceleration issues and so on in the x.org architecture (some of the information is now outdated, but nVidia still bypasses various bits to make them 'just work'):

http://ash.weststar.name/babble/20081104161100/why-nvidia-rocks-where-x-org-does-not/

Re:It's not easy

[SiegeTank]

Exactly, this file from the kernel docs explains the practical reasoning of not having a stable ABI in detail - http://lxr.linux.no/#linux+v2.6.36/Documentation/stable_api_nonsense.txt

Not only is stability and being able to integrate the drivers better within the kernel a key part of having the source for the drivers. If some poor person gets stuck using a piece of once 'in' hardware that the manufacturer has long since abandoned supporting - the issues can still be fixed. Or will have been fixed before the hardware became obsolete.

It also allows people who can code to help stabilise the drivers. Which essentially means the user has a better impression of the hardware. So the manufacture can benefit significantly from the source for that driver being available.

The reasons are practical - not only for stability but for longevity of support well after the manufacturer has long stopped caring. Having a stable ABI did nothing for Windows XP when the driver ran riot and took down the entire system in an all too common video driver BSOD.

Re:It's not easy

[Ash-Fox]

That would be zero.

Err... Aren't you conveniently forgetting that just last year we had the issue of Microsoft's unpatched DLL load hijacking issue that could not resolved without changing stable APIs and recompiling software?

Re:It's not easy

[HonIsCool]

Reads a lot like one Linux Hater's Blog post :) Minus some foul language :)

Re:It's not easy

[Microlith]

ABI stability helps no one but those that develop and release closed source binaries. Holding the rest of the kernel back for the sake of a handful of modules made by people who won't play nice is stupid in the extreme.

Re:It's not easy

[MostAwesomeDude]

Ever read Raymond Chen's book? It's pretty terrific. There's an entire section dedicated to showing how Win32's stable API and ABI in kernel and user space has been a horrific nightmare and is a large waste of developer manpower.

Also, the *only* people affected by the lack of stable ABI are people that ship out-of-tree kernel drivers, all of whom have no excuse for not immediately pursuing upstream merges of one sort or another.

Also, some exported kernel APIs, like the syscall list and ioctl list, are sacred and are never altered. To take a topical example, all KMS graphics drivers respect and give sensible return values for legacy userspace X components calling pre-KMS settings.

And finally, to answer your strawman, *yes*, you can get a driver accepted if it has no users besides yourself. IBM's notorious for this; one of their upstream drivers has something like 2 users in the entire world. The drivers that tend to be controversial are things like reiserfs4 (layering issues, maintainer conflicts), aufs (layering issues, code quality issues), OSS4 (licensing issues, maintainers want to keep it out-of-tree!), etc. where there are clear and obvious reasons why the upstream merge hasn't happened.

Hell, for DRM, this was a problem too, since the DRM/libdrm tree was buildable for BSD as well. We made the decision a bit ago to merge into the Linux tree and make the out-of-tree repo for libdrm only, and all of a sudden, life gets *easier* because we no longer have to switch back and forth between Linux and BSD compat.

Re:It's not easy

[shutdown -p now]

No, it also helps those who develop and release open source kernel modules but don't have the time to maintain them for the foreseeable future just to make sure they keep compiling on every new minor kernel release.

And the "handful of modules" are, for the majority of Linux users, the only way to get stable 3D acceleration for their systems, which, I dare say, is a very important "handful". I'm not going to say who is stupid in the extreme here, but do keep your response in mind next time we're going to discuss gaming on Linux (or rather lack thereof).

Re:So get a killer app

[babai101]

I want to play warsow and xonotic, and watch 1080p movies without having to pay 7500 rupees for an OS I'll never use.

Seems worse in the mobile space.

[ChunderDownunder]

This thread discusses the availability of FOSS drivers for those snazzy ARM Cortex chips found commonly in touch-screen devices.
Even if you can 'root' your Android phone, getting a 3D accelerated x.org experience is unlikely. Even Nokia's forthcoming Meego device will be a binary blob affair, I suspect.

Re:Seems worse in the mobile space.

[lkcl]

It's not just ARM Cortex CPUs: it's the Telechips ARM11 (which is causing headaches for the sheer number of GPL violations Chinese products), but also there are MIPS SoC processors coming out as well - *all* of them use either proprietary NVIDIA, proprietary Vivante, proprietary MALI or proprietary PowerVR.

now, i've spoken to Richard Stallman about this and it may surprise you that he pointed out that these proprietary libraries are actually classed as "System Libraries" under the GPL. so, the proprietary libraries aren't the problem. and, neither are the GPL Linux Kernel drivers because these are typically "shared memory shims" which allow the proprietary userspace libraries to gain access to the memory-mapped 3D hardware's registers. ... the problem is the proprietary firmware blob that needs to be "uploaded" to the 3D engine in order for it to BECOME a 3D engine. that's "non-free" and it's a bitch.

the irony is that if these 3D companies opened up their engines, they would be able to benefit massively from the Free Software Community's work on Gallium3D and LLVMpipe.

so the first manufacturer that creates a SoC CPU which has truly "open" 3D graphics is onto a winner: much lower ongoing development costs because of Free Software Community support, for a start.

however, any company that has "true" OpenGL rather than "embedded" OpenGL has a bit of a problem: their engines typically consume an entire IC far bigger than these SoC! but not only that, they're targetted at CMOS which is very, very power-hungry (8 watts minimum is considered to be "low power"!). CMOS, even when the IC is doing nothing, still consumes power, and that's unacceptable in the SoC embedded space, where the entire CPU only requires 1 watt absolute max and that's in 45nm running at 1.2ghz! if you come down to say 400mhz you can get away with around 0.1 watts or less!

the game is changing, significantly, and the "traditional" CPU "leaders" have to realise this (they have to. it's the consumer who isn't aware!). so to illustrate: a MIPS processor, with only 74,000 gates, can easily be put into a quad-core arrangement and then be run at well over 2ghz in 28nm, without any massive design effort. that means you can get over 8ghz of processing power out of a few hundred thousand gates! (contrast that to a few tens of MILLIONs of gates, from an Intel or AMD CPU). and as MIPS RISC CPUs are a far, far simpler design, it costs far less. it's the same story with ARM (but less so - their architecture has got complicated, with the Cortex range as it's based on a Harvard Architecture, now).

so over the next year, you can expect to see 45nm and 28nm MIPS dual-core and quad-core CPUs coming out at under $USD 10, possibly even as little as $5. this makes me laugh when i see AMD being so happy that their latest lowest-cost offering is $75, it really does. and i find it absolutely stunning and bewildering that Intel comes up with prices of $300 for their top-end CPUs.

remember: the chinese government have been working on a *SIXTEEN* core 1ghz MIPS called the Loongsong 3 for a good couple of years, now. 1000 of those cores will result in them taking the number one spot in the Supercomputer race, and the machine will fit into a room, not a warehouse.

the world's changing very very fast.

TANSTAAFL

[bbbaldie]

I'm just glad drivers get written at all. In the last ten years, Linux has gone from daunting to a snap to install and maintain. If you can contribute, and you aren't doing so, you have no reason to bitch about the tardiness of drivers. Heck, you don't have a right to bitch anyway about something that's free.

Re:TANSTAAFL

[bbbaldie]

Sure. You've earned the right. :-)

Re:TANSTAAFL

[Rhywden]

Yeah, I'm thankful for those drivers as well - but they still have some massive problems. I recently tried to use a dual monitor setup on an older laptop with an ATI chip.

Absolute catastrophe. Either one or the other monitor wouldn't be set to the correct resolution, show only half of the picture - and when I finally managed to get it right through some obscure config magic, the setting would have been reset upon rebooting the laptop.
And 50% of the time, trying to change the config resulted in a hardlock.

Re:TANSTAAFL

[Ash-Fox]

How the fuck is anyone supposed to know about your branches if you don't mention them?

I mention them once, I mention any updates I do once. I don't go do the whole justification, arguments which people seem to want to do non-stop on mailing lists. You changed the name of an integer name in a piece of code to resolve some twisted compatibility issues and despite knowing this, people want you to write like nine replies justifying it when it has already been justified. When you don't waste the time by repeating what you said over and over in slightly different wording, your contributions end up ignored because you didn't happen to spend hours a day correcting people.

Don't be a total douchebag.

Honestly, I find the whole assault in justifying something repeatedly rather 'douchebaggy' more so than my comment at my displeasure of having to essentially 'fight' for my contributions repeatedly, when I already 'fought' for it.

Re:Linux drivers? Good luck

[Ash-Fox]

Intel are lucky to have managed to write a driver that works for the kernel "X" and the window manager "Y "

I have no idea what window manager dependency you're even referring to, I can't find any mention of anything to do with window managers on the article it self. A quick Google search isn't returning anything relevant. Could you provide related practical and technical information, please?

Exactly So, the real problem is

[IBitOBear]

_hardware_ manufactures who think they want to be in the _software_ maintenance market.

The difference between calling an API to render color fast, and knowing that cramming a 0x721 into a register at 0x3392 to render color fast isn't particularly a hemorrhaging of 'intellectual property'.

Granted, it does let us know where the API is "cheating".

So while the example of one byte in one register is reductio ad absurdem, and the process is more about laying out memory buffers and such, who cares. Sure the manufactures may be worried about nock-off hardware, but that hardware almost certainly be nock-off quality. Think of all the SoundBlaster knock offs that have ever been made. Compare that to Creative's bottom line. Those third party cards, which are _still_ on the market made SoundBlaster a universal name. Creative has been reclined upon those laurels for years now.

It is horrifically stupid on the part of the hardware manufacturers to be palying so close to the vest. They should _want_ everybody scrambling to be compatible with _their_ hardware interface, making them the leader that the market has to chase.

First big name out of the gate with a fully open graphics hardware platform would own the segment anew for years.

But "companies" have no smarts and that "isn't the way (that) business is done" so here we languish on in a half-realized market.

(As for the "getting drivers" thing I have spent hundreds of hours of my professional and personal career "getting drivers" for windows machines. Only the "you'll damn well eat what we serve you" hardware platforms like Apple can remove the quest for drivers. And woe betide you if you want to use old gear from those guys. So the whole plaintive "waah, I had to look for drivers" complaint rings a little false.)