Slashdot Mirror
Qualcomm Calls To 'Kill All Proprietary Drivers For Good'
An anonymous reader writes "Next week at the sixth Linux Foundation Collaboration Summit, two Qualcomm Atheros engineers will be making a stand for killing all proprietary drivers for good — across all operating systems. The Qualcomm slides go over their early plans. Do they stand a chance?"
I know where I'm throwing my money the next time I need such hardware!
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Killing software patents.
This is the sort of thing Google should have pushed for with Android, but after a year of struggling with their OS I've come to realize Google doesn't care about the end user experience. By subsidizing and dumping Android they pushed webOS and MeeGo out of the market.
If Qualcomm starts with their cellphone baseband processors, I'll start listening.
Nobody is telling you what to do. Just like RFCs don't tell you what to do.
They tell you what you should do. This is an important distinction.
Of course, if you ignore those recommendations and do your own thing: you are on your own.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Yes. It's a kind of bread you can smoke.
An example that leaves a particular bad taste in my mouth...
I bought a set of LCD shutter-glasses years ago. I had an nVidia card that had driver support for them. I got these babies, got the special nVidia driver, and I was blown away.
But soon I needed to upgrade my gfx card, and found nVidia no longer supported shutter-glass stereo on any of their new shiny cards. Weird right? All you need is software trickery.... but wait, yes.... Suddenly 3D LCD panels come out and nVidia simultaneously releases drivers that support them. And next thing you know, they have their own shutter glasses that cost way, way more than the ones I'd bought years before.
And still, there's no support for my set. Support that already existed.
My opinion: This is why hardware companies care about drivers, it lets them wrangle money out of people who'd like support for their products.
> no, yes, maybe (tagging beta)
And nobody ever installs Windows, themselves, either, on a notebook.
Boy I hope that's sarcasm. Otherwise I fear I must question my own existence, as I've done just that many, many times.
Who in their right mind would leave the factory installation of windows on a notebook in the first place if they didn't have to? Why spend 2 hours cleaning all the adware bullshit off of it, searching the web to see what the hell half the start-up programs even are ("Gee, do I need kdjsdksjhdjsh.exe to run on startup? What about eroiuerrurrjkffl.exe???"), missing shit, and all of that, when you can spend 45 minutes doing a fresh install of Windows and then maybe another 45 minutes doing updates/driver installs and have a clean machine with all that bullshit removed from the get go?
Step one on any new notebook I buy is always a fresh install of windows. I don't play that "recovery disk" bullshit.
I know it used to be a lot more difficult in the past to find drivers and shit for notebooks, but it's really not that bad anymore. Certainly not in my own experiences.
The problem is a lot of hardware is heavily patented, and the patents cover the hardware-software combination.
A sound card would be the best example - you can have a basic sound card with open drivers (it's just a combination ADC and DAC on a board, after all). But then people want justification for their purchases, so you add in Dolby Headphone support to give you surround sound with headphones (patented, licensing fees to use). Or DTS/Dolby Digital encoders so people can get surround sound piped to their A/V receivers. Or HDMI audio injectors that support HDCP.
Ditto video cards - HDMI+HDCP is a spec that does not allow for open drivers. A lot of 3D technologies are patented, heavily.
Network cards - well the TCP offload egnines are considered "secret sauce" because a good TOE can ensure your host system can be full bandwidth and hardly take any CPU resources. And this can include onboard firmware for the onboard processors. LIkewise, WiFi is similar.
Nevermind software controlled parts of hardware that cannot be modified for compliance reasons.
Hell, half the hardware guys out there would kill if they can release the drivers as source and give it all away - less work for them to support (they can direct people to a community support page). Or just release the hardware and let the community write the damn driver for it.
Of course, there's also the irony in that Qualcomm supplies a lot of binary blobs for stuff using their processors... especially with Android.
It might just take nothing more then that first hole in the dyke.
They prefer to be called "lesbians" now, you insensitive clod!
Many years ago i was associated with Project UDI, the Uniform Driver Interface. The goal was to make a uniform ABI/API for device drivers. On Machines with the same hardware target (say, 32 bit x86) you would have binary compatibility. The same driver works on Solaris or Windows. For other platforms, they'd be at least source compatible. It worked in theory, and somewhat in practice - I think UnixWare shipped this as their native Device Driver Interface.
But you never heard of it. Part of it was the SCO/Caldera fiasco. 'Nuff said about that.
But part of it also was the fact that people had vested interests in this failing. Most famously, Stallman didn't like it. For now you could ship drivers without source for all i386 targets (not that having the normal Linux DDI prevented that before). But it was fun that I worked on something shipped in a commercial kernel, and also something that pissed off Stallman.
More importantly, the people who want this are necessarily in the weakest position. MS doesn't want this - everyone makes Windows drivers. They get nothing from it except lower exclusivity. (The fact that Gates and Stallman were on the same side of this should have given Stallman time to reflect). They'd never allow the UDI code to touch their kernel. One or two other big UNIX vendors feigned interest, but they had the same issue - they had exclusive (to UNIX) device drivers, and they'd lose exclusivity. Only Caldera used it. It was their project, and it helped their forked codebase - they had both UnixWare and OpenServer (very old) code bases they needed drivers for, and it made it an easier target for device makers.
None of the issues were tech issues, they all were people issues, which haven't gone away in the intervening years.