Slashdot Mirror
Linux Kernel Devs Offer Free Driver Development
schwaang writes "Linux Kernel hacker Greg Kroah-Hartman, author of Linux Kernel in a Nutshell has posted an epic announcement on his blog. This could portend increased device compatibility for Linux users, higher-quality drivers, and fewer non-free binary blobs." From the announcement: "[T]he Linux kernel community is offering all companies free Linux driver development... All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program... in order to properly assure that all needed NDA requirements are fulfilled. Now your developers will have more time to work on drivers for all of the other operating systems out there, and you can add 'supported on Linux' to your product's marketing material."
A really quick scan of the price of windows driver development, demonstrates how much actual value this is for business. Now all you would need to do is pay someone to extend the drivers to other platforms! Eureka!
The dangers of knowledge trigger emotional distress in human beings.
Is this realistic though? Are companies actually going to take this offer up? If they do, the impact could be awesome (hardware compatibility that could rival Windows and/or Mac OSX)...
Nice one!
ilovegeorgebush
No, those drivers would most likely be written by the community anyways.
To me it seems more like an initiative to figure out which companies use "we don't have the staff/resources for an open driver" to keep their drivers proprietary.
perpetually dwelling in the -1 pits
This way they get drivers written for them for free, and don't need to provide any tech support for the device to those users who purchase it for linux.
I'd say that's pretty much the state of play for the majority of Linux drivers anyway. To be fair I have no way to back up that claim, but it feels that way to me.
My guess is most printer drivers are community developed. Also Modems, and Network adapters, Hard Disks and older video adapters, and Removable Mass Storage devices. The only big 'playas' doing anything in the LDD world are AMD, NVidia, HP and, I guess, Intel. Those contributions are nothing compared to their Windows effort.
This leaves scores of small manf. who hopefully will be interested enough in gaining that additional 5% market share to cooperate.
Where do I sign up as a developer?
I have never written drivers so I may be way out in left field here, but how close are we to being able to specify a standard driver model, with compatibility across operating systems? It seems to me that drivers are one of the biggest impediments to OS adoption. They are also a huge cost center for device manufacturers. Imagine if 99.9% of the driver code could be the same across platforms. Is this even remotely possible? Or perhaps the Linux Kernel driver developers could figure out a way to adapt Windows drivers to run, perhaps in an interpreted or emulated fashion, on Linux (ala Virtual PC). Just a thought.
The more you regulate a company, the worse its products become.
Other than the public announcement, how is this any different from the way things already work?
The community already writes free drivers for vendors who provide specs and (even better in some cases) loan some hardware.
There are already situations where Linux devs have been able to work out NDA-acceptable solutions.
Really, all the announcement is saying is, "Look, we do this. We've been doing this for years. Just letting you know how things work over here."
retrorocket.o not found, launch anyway?
i think it would be a really great thing if the linux community got together a site to petition hardware manufacturers to allow drivers to be developed for their products.
if i have a device that isn't supported by linux yet and i want the company that made it to let linux devs in on the hardware specs, my emails/calls won't mean SHIT to them. if there are several hundred signatures behind a petition for them to let people develop linux drivers for their product, on the other hand, maybe they'll take it more seriously.
I would disagree. Linux drivers are not made since they do not generate profit, largely due to the small user base verses the cost of developing the driver. If there is but a modest cost of a dev answering a few questions, it may be worth their while if it means shipping another 200 widgets.
If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be.-TJ
Ranked in order of preference:
a) no driver for your hardware
b) binary blob kernel patch created by hardware munfacturuers
c) binary blob in kernel tree created under NDA by the kernel team (who have private access to the source)
d) obfuscated code in the kernel tree (with original kept private to those kernel devs that have signed the NDA)
e) uncommented code in the kernel tree (with commented code kept private to those kernel devs that have signed the NDA)
f) fully open source driver
Personally I'll accept anything b or above - I'd prefer d or above, would settles for c but would really like f!!
I wonder where the compromises will be made? How far will kernel devs go? How far will companies go?
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
The arguments about out of the box driver support for linux happen all the time. The reality is that the issue is not out of the box support. I often have more functionality out of the box with a modern linux distro than windows on the same hardware but that only gets me so far. The biggest hurdle is supporting less common hardware. Adding driver support in the kernel is great, but there is no way they can keep pace with the release of new obscure hardware. We need a way to support less common hardware without constantly trying to bundle drivers into the kernel. Also the kernel developers are not always willing to merge 3rd party code into the kernel if it isn't to their standards or is perhaps not 100% complete. I completely understand this process, but it doesn't help people who have to search out these drivers and try to compile them from source.
The best example I have is my webcam. I know that when I purchased it it would have linux support because i did my research, but I still had to know how to do the research, how to track down the right driver and then how to build it from source. What we need is a driver manager that operates similarly to or in conjunction with our package managers. If during install or after a first boot I was told that a driver for my webcam was not installed as part of the distro it could then either download a driver package if one is available or it could at least suggest a link to download a driver not yet being packaged for my distro. Having to check my dmesg to see if my webcam shows up as a generic USB device or if a driver has been assigned to it is a terrible solution, we need a more friendly means of checking a supported devices database and better way to get access to the drivers that support our less common hardware. This is especially important for people who don't hand pick their hardware and are less familiar with exact model numbers or sometimes know even less.
This system that manages drivers might also do well to phone home to the distro maintainer when possible to catalog all of the hardware that is not being supported by a driver. That way we can at least get a better idea of where the biggest holes in device support are.
Fear trumps hope and ignorance trumps both
"Supporting" Linux under all circumstances, versions, and distros isn't really possible if "support" is meant to be a guarantee that the device will work. Chances are, the device will work if there's a free software driver for it and it's being used under reasonable circumstances (Ubuntu or Debian, not tinylittleunheardofdistro).
Really, we don't want "support". We just want a guarantee that they don't know of any reason why things shouldn't work. If Dell gives us a PC that will work with Linux, they shouldn't include any hardware that there isn't a driver for. If Logitech gives us a mouse that will work with Linux, they shouldn't not release the specifications.
I think there are cases where there may be a lot of extra functionality in some hardware (for testing or legal versions). Maybe it can operate in bands limited by the FCC, but should not for legal reasons. The detailed docs covered by NDA may detail this, and there is no reason to put all the details in the open source driver to get something working.
This way, you get your working open source driver, but you don't need all the details of the hardware (which may include a lot of IP for the hardware maker).
I have had trouble with a PVR-500 card in linux support. They changed hardware, but did not release full specs so the linux driver is lagging. People with access to the specs don't seem to care about making the driver work properly, so we are screwed. People with access to the specs are probably under NDA and can't release info.
Who is he speaking for? The whole Linux kernel community? I didn't think it worked that way. Even Linus is as much a cat herder as a boss, once you get beyond a few core people. The population of kernel developers who can be ordered (the difference between "might get a driver" and "will get a driver") to write drivers for obscure hardware they have no interest in must surely be fairly small. Who's actually in on this? Are there a few hundred kernel devs who've agreed to work on whatever they are assigned? I'm worried that this will backfire when they can't actually find anybody who wants to write the driver for a engraving machine that sells 400 units per year and has a particularly baroque interface. I don't expect there will be a problem for WiFi, TV or video cards, but there's a whole lot of hardware out there and not all of it is interesting.
Those are some pretty big promises he's making. I'm wondering what's there to back them up.
Chernobyl 'not a wildlife haven' - BBC News
The key driver (pardon the pun) will not be how many extra widgets they sell but the the strategic importance to most companies of reducing reliance upon Microsoft's hegemony. If you are a widget developer, you do not want to be in the position of most, dancing to the unrestricted tune of Microsoft. You need some collective force to help push back on Microsoft when necessary, or to demonstrate the worth of new ideas which Microsoft may not have picked up on. Having a competitor to Microsoft (even quite a small one) is a massively powerful force in this.
You'll need a big cluebat to get a lot of these companies to wise up. The real reason that they don't give out programming interface information is because they're listening to a lot of IP Lawyers that tell them they have to keep everything secret or it might affect future patentability of future devices (YES, I've seen that A LOT lately, doing Linux driver consulting for some of the crowd willing to do proprietary driver work...), etc.
It's a mixture of worries about revealing possible Patent infringements, trying to slavishly follow the lawyer's advice, and a confusion as to what business they are precisely in (Software versus hardware- a lot of companies, because of the advice of their IP lawyers are confused as to what they should be doing...).
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Some of it's Microsoft's doing, yes. But it's a lot more complicated than that.
"Show me the money"
"We have to protect our IP"
Those two statements I get told QUITE often in relation to my driver consulting work I currently do.
Both are varying degrees of wrong- and where the trick lies is in convincing the company in question that it's wrong to hold that position in the first place. Both are very difficult to shift because they're usually NOT fact based positions to begin with.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Exactly! I think Greg made a tongue-in-cheek post on his blog and the submitter and /. editor unwittingly took it at face value (no big surprise there). It will be wonderful/funny if some corporate shills also take the blog post at face value and actually start feeding the kernel developers the information they need.
To that, I would add that Epson is a particularly good choice. They've cooperated with the SANE project in providing hardware specs, sometimes even for hardware not yet released. They even make available a binary-only Linux driver and scanning utility through their Japanese division, though of course the open-source SANE support is preferable.
I have a Perfection Photo 2400, from a couple years back. It works flawlessly with xsane. (Do double check against the supported-hardware list, however, because some Epson models actually use third-party components for which no specs are available.)
iSKUNK!
As much as want you to be right, I have my doubts. Think about USB. Flash drives are supported on almost any 2.6 kernel, and have been for quite some time. Yet look at the packages. How many list Linux (2.6 kernel) as supported? Not many. It would cost the companies nothing to add that, but virtually all refuse to do so. Why? I have no idea. Same thing with external USB drives. I've only found one that doesn't work so far but I have yet to see any manufacturer list Linux on the box.
"Am I missing something, I don't see your point?"
Apparently not. What PP said was that there is the potential for profit there, but the hardware industry may be underestimating the buying power of the Linux desktop market.
For example, I, and many other Linux users buy my WiFi based on what works in Linux. I am not a Linux-only human; I have a Mac, a Windell at work, and a Ubuntu laptop.
But therein lay the point: The commercial OS developers already support your product; you wrote drivers for them. Now, at no extra cost, you can have the edge up on your competition for that 1.6% of the computer-using market that has Linux in one form or another. As of 2004, that's 1.6% of 61.8% of all people in the US, or about two-and-a-half million people. At median income of $30k, and assuming that 5% of their purchases are technology-oriented, that's a chunk of $3.75B you're fighting for.
Not a small number, and the slice of it you get could mean the difference between shelling out a new product in a month or shelling it out in a year. Meanwhile, if you can expand that slice at low (rather than building a monolithic driver, build drivers as modules that can be 'plugged in' to existing kernel scaffolding for Linux, Apple/Mach and NT) or no (having the Linux Devs build it) cost, there's no reason you shouldn't.
Of course, the bigger the company, the less this matters to them; large companies have the opportunity to 'rest on their laurels', as it were, when it comes to new accessibility.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
I've decided that HP pisses me off. They go out of their way to make sure you're not refilling ink carts (and in some cases toner) and frankly I don't think their printers are all that. Not to mention that they've all but done away with duplex modules, now you have to buy duplex printers. So if you bought a non-duplex printer and you need duplex, now you have to buy a whole fucking printer! I want a company that gives me choice, not a company that scares me into buying the full-featured product by not offering me a way to add the functionality later. And they're straight up lying if they claim that no one buys those things. Anecdotally, I've got a Laserjet 5550n behind me and to the left for which we would buy a duplex module if it were offered. Since it is not, I have to do it manually, and since I'm lazy, that makes me a sad panda. :(
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You actually managed to install it? I'm jealous. Those drivers won't even compile on my system.
That happened to me with my Radeon. At that point, the open source driver supported my card, and I didn't have to futz around with building kernel modules every time I tinkered with my kernel.
tasks(723) drafts(105) languages(484) examples(29106)