This whitepaper published at LinuxDevices describes an approach to solving the “device driver crisis” that plagues both the embedded and non-embedded computer system markets. SciTech, the developer of the “System Neutral Access Protocol” device driver architecture (“SNAP”), says the SNAP approach to device driver development is radically different from traditional methods, and can drastically reduce the complexity of OS- and processor architecture-related device driver support.
An Approach to Solving the “Device Driver Crisis”
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
As long as its closed source, we don’t want to hear about it.
It only takes a few minutes for the “Open is good, Closed is bad” crowd to get in. Seriously, I have a licenced SNAP copy, and it is good stuff. Maybe it is not (yet) very useful for every end user (till 3D accelleration is supporterd), but it is for large deployments it is. Not every company wants to fiddle with a XF86Config on a hetrogenous network. SNAP detects the card automatically and X can be used without any configuration.
Yes, it sounds stupid, but I believe that was mentioned in the PCI spec…but there’s an execption for PCI cards on X86!
Then the Add-in card could communitate to the mobo what it does in a machine-neutral method. Of course, if vendors would just “stick to the specs” for the standard of their devices we wouldn’t have such problems…would we?
Relying on one vendor for core drivers is a bad idea. What if they’re sold to another company, go out of bussiness? Remember, the goal of a commercial software company is to increase shareholder value, not to write good software. I think SCO proved this fact quite nicely.
Is this a cross platform driver system? If it is, this would be great since it would alow hardware companies to write a driver that would be supported by every OS! I would love to be able to run OSX with the abillity to use any hardware I wanted! It would create a great deal of choice. This could be as significant as JAVA! Am I wrong?
Speak for yourself. Not everyone has the same views, if their drivers are better, and they work, who cares if they’re closed source?
Not everyone uses linux, and the fact that you can use their drivers on MULTIPLE operating systems, _without_ a recompile is a HUGE plus.
I’m at the point where I weigh any closed option very carefully before I use it. I’m certainly not going to use this unless I have no other choice.
Any company would be glad to fiddle w/ a XF86Config-4 file if that will get them their desired results. They already bought that file. And once they get it perfect they can deploy it all over their network. Not to mention that your point is moot as any distro worth a grain of salt autodetects the monitor and video card anyways.
This is a very good idea, actually. I’ve always wondered why devices didn’t have drivers built-in as OS-independent firmware.
Seriously, I have a licenced SNAP copy, and it is good stuff. Maybe it is not (yet) very useful for every end user (till 3D accelleration is supporterd)
I fail to understand why everyone wants SNAP to handle the 3D side of things too. DRM already provides an abstraction layer for the underlying hardware upon which drivers can be implemented in a cross-platform manner. Unfortunately it seems the only drivers that have been implemented on top of DRM are X-specific DRI drivers.
Is it just me, or is every Linux user blind to benefits of anything past what affects Linux and Linux only.
Please, for the sake of all of us, take the blinkers off and realise ‘open source’ is not only Linux.
LGPLed tools to create free drivers that interface with a driver model that you must pay for.
I think we would get more mileage from taking the idea of an easy to use platform independent, OS independent driver interface and making it BSD (that way companies like MS might actually think about using it) and then we can get driver makers to actually make drivers for the system.
in the very least, we need a much more simplified interface for hardware venders to make good drivers, including GFX drivers.
People find that 3d in Linux is a problem, and they jump on anything that could be perceived as a possible solution.
I wouldn’t mind an opengl based xserver personally, but until that happens I really don’t mind setting up my mga drivers myself.
@RE: SNAP?
Linux is the open source operating system with the device driver problem.
What if they’re sold to another company, go out of bussiness?
Doing all we can to prevent that;) but as a way to ensure the survivability of SciTech SNAP we have released the SciTech SNAP SDK under a dual license which includes an LGPL option and will soon release the SciTech SNAP DDK under a similar dual license with a GPL option (instead of the LGPL). So feel free to get familiar with SciTech SNAP tools and write your own drivers. If you need assistance getting started feel free to ask.
Cheers,
Andrew
Cheers,
Andrew
Is this a cross platform driver system?
Yep! Enjoy
ignore the second “cheers Andrew”, I should scroll down before posting next time;)
Any company would be glad to fiddle w/ a XF86Config-4 file if that will get them their desired results.
I know of one company with 10’s of thousands of machines deployed and dozens of different graphics cards installed on their enterprise whom would not wish to fiddle with each and every machine to get it working properly. But if that’s your bag have at it.
This is nice. We need to get more hardware vendors interested in Linux. It is truly the only operating system that has the most potential in the desktop environment if hardware vendors will just give it a chance.
snore……..snore…….
To the person who has flamed the “free software zealots”:
The problem is not with the software quality itself. yes, most of us can realize that propietary software surely can show excellent quality. However, since we choose the “free software” concept, all we can say that is a fine piece of software, but, unfortunately, we will not use it since is propietary, Our respects to the people that developed it. Please, do not misunderstood our point.
It’s good to hear that SNAP has a “dual-licensing” mode. It’s really pleasant to hear for us “free software zealots”. Keep up the good work!
What advantages does SNAP have over ProjectUDI for the greater OS community? (www.projectUDI.org) As far I can see nothing, other than SNAP is owned by one company, rather than community based like ProjectUDI.
PS. ProjectUDI is also backed by some big players: Intel and HP just to name a few… Just check out the website for more details…
Not all hardware vendors work in an environment where they cannot share source code between OS’s. Consider the NVIDIA display drivers. If you believe their presentations, they share 95% of the code for their drivers between all chipsets and all OS’s across their entire line.
Having Open Source drivers is a good thing in many ways (no such thing as a Linux PowerPC NVIDIA driver, for example), but I think NVIDIA’s policy should be viewed as a shining example of how to do cross-platform closed-source drivers right.
What advantages does SNAP have over ProjectUDI for the greater OS community?
Support for over 200 video cards on x86, and over 100 on PPC? Can ProjectUDI claim the same?
Actualy there was a generation of devices which had OS-independent firmware in them. They are old Sun SBus devices which had OS-independent Forth drivers in them. There was, and still is, a Forth interpreter in OpenFirmware (OpenBoot, whatever) which was utilized to control them. In this day and age, you have to reflash your GeForce to get it to work on a Mac because of big/little endian issues.
Where can I get a bios flash to get a Geforce FX PCI card to work with a mac ?
Any system that allows hardware vendors to release binary drivers is a *bad* idea.
Binary drivers are *evil*, this should be obvious even for windows users, as a good % of BSOD are caused by crappy drivers.
For more info read this thread in LKML from last week:
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.2/index.html#032…
M$ already tried to have an “standard” driver interface across windoze versions, and it did _not_ work, I doubt it’s worth the trouble, with the necessary specs, porting a driver from one OS to anothers is really easy.
\k
Did you see who hostes it? It looks that they are not working on it anymore (or they should have changed the name of the hosting)
Wake me up when my ATI 9800 Pro card’s 3d is working with these drivers……
If you need the drivers so badly, why don’t you just purchase Xig Summit 3D graphics driver?
Shame the licences are *GPL. That effectively means the BSD systems will not want to use such a means for their drivers. A BSD/MIT style license would be great – else an independently developed BSD/MIT equivalent may be a better idea to really get other OS’s on board (this was one of the goals right?).
What advantages does SNAP have over ProjectUDI for the greater OS community? (www.projectUDI.org) As far I can see nothing, other than SNAP is owned by one company, rather than community based like ProjectUDI.
PS. ProjectUDI is also backed by some big players: Intel and HP just to name a few… Just check out the website for more details…
IIRC, wasn’t this meant to be included with Linux 2.6 and there was a big stink made by RMS about its inclusion claiming that some “big evil company”(tm) would be able to steal driver code.
Anyway, I hope that there is a move to eventually move all the drivers on Linux over to UDI so that there is no longer the “match the driver with the kernel revision” fun that occurs.
Their crappy drivers don’t support anything past 9200 you dufus.
“Linux is the open source operating system with the device driver problem.”
I read (don’t recall where) that the reason Linux has a device driver problem is that hw mfgs won’t supply their specs. Secondly it is simply a matter of resources, there aren’t enough Linux coders with the skill to write quality device drivers.
As for SNAP, I for one welcome any abstraction that helps simplify device driver writing and not bleed you dry. To compare, Java is a great language and lives up to its billing so hopefully this too can make its way into the mainstream.
Their crappy drivers don’t support anything past 9200 you dufus.
Nice to see that parents still discipline children in this day and age. Back in my day, I would have been given a beating for saying that.
Yes, I am incorrect about that, however, I have checked the ati website and here is a link to the ATI supplied driver for your ATI Radeon 9800:
http://www.ati.com/support/drivers/linux/radeon-linux.html?type=lin…
Even though this does sound like a great idea on paper, all too often the religious rhetoric takes priority over the realities of life. Just look at the rhetoric which RMS spewed in regards to the use of bitkeeper because it was closed source.
Sure, people can have their own opinions but at the end of the day they should be able to walk away and simply say, “hey, thats cool, lets just agree to disagree”.
btw; I am CooCooCaChoo however, I’ve had to change to ChocolateCheeseCake because some sad little man keeps spamming my old email address with “Windows update” rubbish.
Howdy
I was thinking something along the lines of this a while ago (but more like a device VM or something) but this is great!
I`m not sure about the license though, would the LGPL allow linking to BSDed code ?
Does anyone know if all the specs and interfaces for both parts are available (i`m to lazy to look this up myself :p) ?
What is needed IMO is something that works like SNAP but addresses sound cards. Very few cards have drivers for anything but Windows and Mac.
There is actually a very bad practical problem with closed source drivers if the driver (which is usually also the hardware) vendor is not willing to constantly update the drivers, regardless of user bug reports.
Right now I’m having this problem with the M-Audio Oxygen 8 USB-MIDI keyboard I bought yesterday. Because of a drivers issue, the keyboard is unable to send any MIDI data over USB in my WinXP installation. According to M-Audio website, the “latest” drivers (uploaded in 2003-03) should have fixed the issue, but it doesn’t seem to be the case on my machine. I’ll have to try installing Win2k today just to see if it works any better (as I haven’t found any complaints about Win2k compatibility). If that doesn’t work, the next stop is Linux and usb-midi drivers + http://usb-midi-fw.sourceforge.net/
Previously, I had a same kind of problem with horribly unstable 3Com Bluetooth PCMCIA drivers that they updated a little less than once a year. The funny thing is that in FreeBSD, with (3rd party) drivers that were labeled as a hack, the thing worked perfectly with zero issues.
Note that this post doesn’t have anything to do with SNAP drivers. I’m just telling about a general problem with many closed source drivers, that could be quite efficiently eliminated by opensourcing the drivers.
Since no-one has done it yet, I guess I should point out that there’s yet another OS-independent graphics driver infrastructure: KGI, http://www.kgi-project.org/
Right now I’m having this problem with the M-Audio Oxygen 8 USB-MIDI keyboard I bought yesterday. Because of a drivers issue, the keyboard is unable to send any MIDI data over USB in my WinXP installation. According to M-Audio website, the “latest” drivers (uploaded in 2003-03) should have fixed the issue, but it doesn’t seem to be the case on my machine. I’ll have to try installing Win2k today just to see if it works any better (as I haven’t found any complaints about Win2k compatibility).
That is quite surprising. Considering the premium one pays for the hardware, one would assume that they would spend more time testing their drivers and ironing as much of the bugs out as possible.
The only thing I could suggest is doing a complete clean install of Windows XP (delete partition and format) and install the newer drivers. What could be happening is a conflicts between the old and new driver setup.
The only thing I could suggest is doing a complete clean install of Windows XP (delete partition and format) and install the newer drivers.
Actually I already tried it (well, my XP installation was in need of a reinstall anyway, and this was a good reason to do it).
I for one am really excited about this technology. As AndrewB and the whitepaper stated, the SDK (OS-specific) will be LGPL; I believe this means you can develop your own for free as long as you distribute it free, with code. This means that all open-source OS’s could benefit, for free, and commercial ones in need of updating (e.g. OS/2 as already witnessed, perhaps in the future Amiga?) could license the technology and gain a huge base of driver support.
The DDK (device-specific), which I don’t believe is out yet, will be GPL, meaning anyone can develop fully open-source cross-platform device drivers using this system. The option for closed-source development is there, too, for people who want to develop commercial drivers–which is important because graphics card companies, for instance, probably won’t want to share their code. In fact, I believe it is actually a key step for widespread cross-platform device-driver adoption that this technology has a dual license. If it were only GPL, companies probably wouldn’t be as willing to develop the drivers, because the drivers would also have to be GPL.
Furthermore, I find it perfectly reasonable that corporations wishing to use the drivers pay a fee. It is, after all, largely targeted at companies with huge installed bases of computers, which theoretically have more than enough money. Considering how much work SciTech has put into this, it’s fair that they should get paid.
What I am a little confused about is whether the SciTech-developed device drivers are free for individual, non-commerical use. If yes, amazing! If not, that doesn’t necessarily mean that this is a bad technology. After all, GPL’ed drivers could theoretically be developed using the same platform.
As for the company-going-bankrupt scenario, maybe then everything would be open-sourced. A possibility.
Finally, if the fact that it’s proprietary is so irksome to the zealots, maybe it still wouldn’t be a bad idea to at least examine the technology. Perhaps a completely open-source alternative based on a similar concept would be feasible.
“Using the LGPL Tools, can I make software for internal use in my company/organization? — SciTech’s LGPL tools are not intended for such use; it is our policy that when you are using SciTech’s tools for free, you should in return contribute to the free software community. If you cannot do that, you should get a commercial license from SciTech.”
I think the (L)GPL allows the use an modification for internal use in a company/organization without releasing the source as long as this derived work is not distributed. Not allowing this would make the software non-free. So I think SciTech is wrong about this.
Also, I thought software that needs to be linked with LGPL licensed software in order to run is not required to be licensed under the LGPL also, as I think SciTech is suggesting…
I’ve been using the SNAP Linux driver with a Matrox G550 card for some time, like it, and paid for the registered version. What I want is a good 2D display; games, 3D, etc., don’t interest me. (Neither am I willing to sacrifice quality for adherence to the open source ideology.)
Would love to see SNAP available for FreeBSD, though! Anyone have it working there, or know if SciTech is considering it?
ATI’s drivers are even worse then the other ones ! Especially if you have a KT400 or KT600 board which requires you to recompile the Linux kernel with a patch ! Who the hell has time to recompile a Linux kernel when the W2K supports these boards with no issues ?
P.S. You are still a dufus.
I may not be understanding this correctly, but if one is trying to promote a cross-plateform standard why release the DDK as GPL? This effectivly limits it to GPL based operating systems and GPL based drivers. Which is fine for Linux, but no other operating systems.
What about the abstract driver API? Are the specs for it avaliable? Is it copyrighed, patented? I’m all for cross plateform drivers, but I’m not sure this fits the bill. Such an API would have to be implemented on all operating systems, closed or open, without license reprocussions. It also needs to allow both closed source and open source drivers to be written *without licensing costs*.
RE :This is amazing!
It is amazing. You are 100% correct. This is a HUGE monumental breakthrough that alot of people on this website still don’t get. This is revolutionary .
I have always wondered about having a java type interface to these drivers and Operating systems so you don’t need to code for each specific system. Write once and it works everywhere alot like a virtual machine. This is probably where they got their idea. Excellent.
Another idea for the future would be to allow anyone to generate their own drivers without actually writing code but just writing the ‘specs’ of a card into text file and allow some ‘compiler’ to generate the driver .
Hows that for another increase in productivity !
Lets support SCITECH and drop the animosity towards companies that want to make money.
We can coexist with them. They have found a solution that has evaded our Xfree86 friends.
thank you . Eric Martin
(Replies about licensing based on knowledge of the licenses involved; I don’t work for SciTech.)
Re: Yay… – I`m not sure about the license though, would the LGPL allow linking to BSDed code ?
Sure, with the same dynamic linking or relinking requirements as proprietary code.
Re: SciTech’s (L)GPL explanation – Not allowing this would make the software non-free. So I think SciTech is wrong about this.
Technically, the FAQ didn’t say that they don’t allow you to keep your internal modifications private, they just said that they didn’t intend it. Not quite the same thing.
Re: DDK is GPL and SDK is LGPL? – why release the DDK as GPL? This effectivly limits it to GPL based operating systems and GPL based drivers.
True for the drivers, perhaps false for the OSes. SNAP hardware drivers are plugins to the SNAP OS drivers – the hardware drivers are dynamically linked through a standard interface, and can be replaced at runtime with other drivers. This means that the hardware drivers could be effectively considered seperate entities. I’d like to hear from SNAP whether they consider the two parts of the driver to be seperate, which would mean that the GPL wouldn’t restrict the host OS.
Keep in mind that what constitutes the “program” has to change from situation to situation. If you go by the definitions in the GNU FAQs, the GPL could never be applied to entities on any OS where programs are started by means other than fork-and-exec (like Windows). Device drivers aren’t mentioned at all. Only SciTech would be able to tell you what they think constitutes the “program”: the hardware driver, the OS driver, or the OS itself.
I may not be understanding this correctly, but if one is trying to promote a cross-plateform standard why release the DDK as GPL? This effectivly limits it to GPL based operating systems and GPL based drivers. Which is fine for Linux, but no other operating systems.
Keep in mind that it’s a DUAL LICENSE that can be used for free or under license. So it’s not “limited to GPL-based OS’s and drivers”–you’d just have to license it otherwise. I’m assuming you realized this when you made your post, but I wanted to clarify. Also, correct me if I’m wrong, but I thought GPL’ed software could be used with software under similar open-source licenses–i.e., BSD.
Anyway, I believe what you’re getting at is: What if someone makes a GPL device driver. Can it be used with a non-free OS? If the SNAP driver that interfaces with the OS is LGPL, then I’d say it’s a possibility, although really I don’t know. If the SNAP driver is closed-source, then the answer seems to be a qualified no.
However, this issue probably won’t affect the majority of users. Just bear with this logic for a minute. Firstly, who are the users?
The SDK seems to target the following: Current commercial OS’s with limited HW support (would license), free OS’s with limited HW support (would use LGPL), and programmers that want to add HW support to their favorite old, unsupported commercial OS (would probably use LGPL but could license if they wanted to sell it).
The DDK seems to target the following: Hardware manufacturers that want to make closed-source device drivers (would license); third-party programmers that want to make closed-source, for-profit device drivers (would license), and programmers that want to make free, open-source device drivers (possibly for old, unsupported hardware) (would use GPL).
Assuming that the “No GPL device drivers on non-free OS’s” analysis is correct, the main group who would be unable to use GPL device drivers are those licensing the SDK for their commercial products (aka IBM for OS/2). They would probably have to pay SciTech for their pre-developed, commercial device drivers, which is fine for a commercial OS manufacturer with some capital (like IBM). There’s a chance they’d need to develop a few extra drivers on their own, also reasonable. In addition, any other closed-source drivers (such as those that could potentially be developed by HW manufacturers) would be available for use.
The only other users that would be unable to use GPL drivers are those using the “old, unsupported commercial OS”. But, there’s still the possibility that GPL device drivers could be used with an LGPL SNAP driver, regardless of OS (this is a question we need to ask SciTech, or a GPL expert). In any case, this represents a very small portion of the population.
Finally, for anyone using a free OS, they would have access both to commerical and GPL device drivers, whatever suited them best. The hope, of course, would be that in the future HW makers would create freely available, official, SNAP-compatible device drivers, which they’d be able to update on all platforms simultaneously. These would also never get outdated, as long as the single OS-dependent component stayed up-to-date.
In short, my guess is that the choice of GPL for the DDK is so that the licensees have to pay SciTech for drivers as opposed to getting GPL ones for free. If this is the case, I find it relatively fair, although they should have just said it and not been so sneaky and confusing. But most importantly, it doesn’t limit the free software community’s use of this technology. Please correct me if I’m wrong.
Easy porting of drivers between operating systems is of course important: Due to small market share of desktop Lnux and difficulty of making drivers, many manufacturers do not make drivers for Linux. Deficiency of drivers is one of the major reasons against using a Linux distribution as a home desktop.
More important, however, is the lack of standardization of hardware: Different devices that perform the same functions have different interfaces and hence need different drivers. In some cases, the specification of the interface is even subject to a nondisclosure agreement. Standardization of hardware interfaces would mean that almost all hardware will work with almost all computers, and that drivers need not be numerous but are likely to be of high quality and security.