A Linux Driver Project status report
Hi all, It's been about a year since the linux driver project was started, so I figured that it was about time for a status report of how things are going, and how things are going to be changing a bit for the future. Thanks again for everyone that has participated so far, I, and all of the Linux users out there, really appreciate it. greg k-h ------------ Linux Driver Project Status Report as of April 2008 Executive Summary The Linux Driver Project (LDP) is alive and well, with over 300 developers wanting to participate, many drivers already written and accepted into the Linux kernel tree, and many more being currently developed. The main problem is a lack of projects. It turns out that there really isn't much hardware that Linux doesn't already support. Almost all new hardware produced is coming with a Linux driver already written by the company, or by the community with help from the company. There are two main classes of hardware, video input devices and wireless network cards, that is not well supported by Linux, but large efforts are already underway to resolve this issue, with the wireless driver issue pretty much taken care of already, however there are a few notable exceptions. Because of this, our main effort has turned into one of education. Educating vendors of how to become members of the Linux kernel community, proper coding standards and procedures, and how to get their code into the kernel tree. Much of our recent effort has been in code cleanup and shepherding into the kernel.org releases. In the future, we are open to any new devices that need drivers to be written for them, and our procedure for handling projects is going to be changing to reflect the lessons learned in the past year to make things easier for vendors to participate, and for the community to easily detect what is going on and be able to help out in easier ways. The Past Year The Beginning The Linux Driver Project (LDP) was born a little over a year ago with an announcement on the linux-kernel mailing list and a few blog postings. It sprang up out of the complaints from some users and companies that there was a real "Linux driver problem". The perception was that Linux did not have good driver support, and that closed source drivers were potentially taking over some device types. I figured that if we reduced the barrier for any company to have a Linux driver written for them to nothing except a few emails, a document or two, and hopefully a sample device, these problems would go away and we would be able to create a raft of opensource drivers for these problem devices that everyone seemed to be complaining about. So the LDP was born. It started out as a single place for hardware manufacturers to contact in order to get drivers written for their devices for free. We allowed the ability for companies to sign an NDA if needed to help get over the hurdle that some companies have in releasing their specifications. The NDA process was put into place through the Linux Foundation, and is a 3-way NDA with all of the proper legal documents needed. A funny thing happened though, what I figured would be a project flooded with requests for companies to get hardware working turned into anything but that. Two major things then happened, both of which I could have never expected: - The number of developers who said they would be willing to help out in creating these drivers was amazing. As of today, we have over 300 different people who have signed up to be a developer of a Linux driver, volunteering their talents and time to help Linux out. This large developer base is a shining example of how strong and large the Linux community is. - Very few companies signed up for drivers. It's this last point that made me worry. Yes, a number of companies did ask for drivers to be written, and we have done so, but not as many as I originally imagined. The drivers we were writing were in the narrow vertical markets, all interesting devices and companies, but nothing really "mainstream". So where was this mass of hardware that Linux wasn't supporting? The Linux Driver Myth Back in 2006 I gave a talk at the Ottawa Linux Symposium about a number of myths that are around the Linux kernel. One of them was device and driver support. I stated then, and still do that: Linux supports more different types of devices than any other operating system ever has in the history of computing. Later on, a representative from Microsoft validated this statement saying that their research agreed with it, so this is not an unproven statement. Yet still the "Linux has a driver problem" myth persisted. The OSDL and then later the Linux Foundation's Vendor Advisory board had "Linux drivers" as the second most pressing issue that they faced. Surely these large vendors, all of which shipped Linux on their hardware and dealt with user issues every day were on to something. So the LDP was created. And no companies showed up. So I spread the word some more. And still no major companies showed up. So what to do. I tried my best with a general announcement of, "Tell me all of the hardware that you know of that is not supported by Linux!" The response by users was overwhelming. My inbox was flooded with hundreds of messages, and the wiki page: http://www.linuxdriverproject.org/twiki/bin/view/Main/Dri... was created. This is the community's best list of devices that are not currently supported on Linux as of today. I then went and asked all of the individual companies that made up the Linux Foundation's Vendor Advisory board what they needed for Linux drivers. The conversation almost always went like this: ME "What hardware do you ship that is not currently supported by Linux?" VENDOR "It all is." ME "But wait, why are you claiming that 'Linux drivers' is your second most pressing issue today with Linux?" VENDOR "I don't know." After much cajoling and harassment on my part, I'm happy to say that the Linux Foundation's Vendor Advisory board's top 10 list of things that need to be worked on with Linux doesn't mention drivers at all. So let's put this myth to rest once and for all please. User Complaints But wait, what about all of those email responses that I received. It turns out that they can be categorized into four different groups: 1) Printer and Scanner support. 2) Older devices no longer manufactured that people really want to see working on their Linux machines someday. 3) Wireless device support 4) Video input device support. Category 1 is already being handled very well by the Linux Printing project and the SANE project. Printer and scanner drivers in Linux are userspace programs and libraries and have nothing to do with the kernel at all. If you have any issues with these types of devices, please go ask the developers of those projects about it. They are very knowledgeable, skilled, have vendor contacts, and can do a lot to help resolve your issues. This area is already aptly covered by these people. Category 2 is hard. It would be great for Linux to support all of these older devices, but without the specs for the device, or in many cases, a company that is still in business, Linux support is going to be very difficult to achieve. Reverse engineering is a great skill, one that I personally am no good at anymore. This type of effort is not something that the LDP was set up to address, and luckily, for almost all modern hardware devices, it is not necessary. So that leave wireless and video input devices. Luckily both classes of these devices have a very active and productive developer community surrounding them. The Linux-Wireless group of developers have done an amazing amount of work in the past year, adding a whole new wireless protocol stack to the Linux kernel, as well as numerous different hardware drivers, some initially created by vendors and others created by reverse engineering the hardware with no vendor help or approval. The latest kernel.org releases contain a raft of new hardware support for wireless drivers, and the number of active drivers in their queue to be added in the near future is quite large. There are still some wireless vendors that do not provide Linux support directly. Two of these, Atheros and Broadcom have drivers created by the community through reverse engineering efforts. These drivers usually lag the introduction of the hardware by a number of months due to the lack of vendor support. Both of these companies have internal versions of drivers for their new hardware, but efforts on getting them to release them so far has been resisted. Hopefully this will change in the future. As for video input devices, there is an active Linux developer community in this area, but they seem to be hampered by a different development model (Mecurial trees outside of the main kernel source), and a lack of full-time developers, not to mention a high degree of inter-personal conflicts that seem quite strange to outsiders. Support for a large majority of these devices is slowly trickling into the main kernel tree, the most important being the USB Video class driver, which will support almost all new USB video devices in the future, thereby removing the major problem most users will face when purchasing a new video device. The LDP group is also actively working on drivers for a number of different video devices today, with the code being available today for testing by users in the linux-next kernel releases. These drivers should go into a kernel.org release in the near future when development is complete. Education During the past year, I have had many different inquiries from different companies wishing to either have a driver written for their hardware, or to help get an existing driver into the Linux kernel source tree. Almost all of these contacts has resulted in a process of helping to educate the vendor as to how the kernel community works, if a driver is even needed for their hardware (in many cases it was not), and how to clean up their code for acceptance. Despite my personal feeling that Linux has a very well documented procedure of how kernel development works, along with free books explaining how to do kernel development, it seems we still have a lot of work to go. We need some way to help spread the message further to companies that are just starting out with Linux development. Maybe we need to sign up a marketing department from some major Linux vendor to help out with this kind of effort. In the past year I have given talks at many different companies all around the world on how the Linux kernel development process works, and I see this travel and speaking effort not ending any time soon. I have started to recruit more developers to help out with this education process, but can always use more help. If anyone wants to participate, and is comfortable in explaining our kernel development procedures, please let me know. It is this kind of education that has helped out the most so far. Lots of drivers have been cleaned up through the education process and eventually accepted into the kernel tree. This effort will continue on, and has already started to move a lot of out-of-tree drivers into the main kernel.org tree Method of Development When the LDP project was started, the structure of having a project manager for the individual project, and a number of developers working on each one was established. Over the past year, this has worked for some projects, while for others, it has failed badly. Some project teams have disappeared, including both project managers and developers. This is quite common for opensource projects, so we need a way to route around the problem of this, allowing everyone to participate in a more open model. To try to work toward this, I've started to keep all code related to the LDP project in a quilt patch series. It can be seen at: http://www.kernel.org/pub/linux/kernel/people/gregkh/greg... and is now automatically included in the linux-next daily kernel releases. This quilt series is contained within a git tree at that can be accessed at: http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git This tree provides a place where developers can provide changes, updates, and see where they can help out if they wish to do so in a much easier manner. It also provides a way for companies participating to observe the status of their code in a much more open manner. The Future So, what next? I have the following goals for the LDP in the next year: - Continue to write new drivers for any company that wishes to have them developed. These drivers are all to be released under the GPLv2 and included in the main Linux kernel source tree hosted at kernel.org. Future maintenance of these drivers will be done either by members of the original company, or by the community members, depending on the wishes of the company. - Continue to be a focal point for companies to learn about the Linux development process and become part of the kernel community if they wish to. I hope to enlist more people to help out with this process, but if not, my airline miles logged will continue to increase. - Work more in an open development manner, hosting all experimental and development code in a public git tree, getting daily testing in the linux-next tree on all architectures. Thanks I'd first like to thank my employer, Novell, for giving me the opportunity to work on this project full time. Their acceptance and support for the LDP is amazing and has been what has allowed it to survive and produce such great results already in a short amount of time. I'd also like to thank all of the developers who have offered to help out with this project. Your volunteering to participate is amazing and shows the strength of the Linux developer community. I'd also like to thank Tomasz Grzegurzko for maintaining and keeping the linuxdriverproject.org domain and server up and running so well, despite my best attempts to do stupid things with it at times. Also thanks to the OSU Open Source Labs for your domain and bandwidth support of the project. _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/...
(Log in to post comments)
How about easier installation?
Posted Apr 8, 2008 5:59 UTC (Tue) by phansi (guest, #51469) [Link]
Even though the drivers exist, installation of the drivers can a mess. Specially those where firmware has to be loaded at startup. I do understand that there is not much we can do about this, but I find it difficult to convince people to use Linux when they see me jumping through hoops to install -- specially wireless cards and printers. Every piece seems to require a separate setup and an hour or two of searching and making notes. Which is fine for me, but I find it difficult to convince unmotivated people that using Linux is a Good Thing.
How about easier installation?
Posted Apr 8, 2008 6:51 UTC (Tue) by gregkh (subscriber, #8) [Link]
There is a standard location for where driver firmware is to be placed, and it's up to your distro, and its package selection tools to place them in the correct place when your hardware is discovered. Some distros get this right very well, others do not. If yours does not, complain to the developers and help them fix the issue. Ranting on a random web site isn't going to help the matter any :)
How about easier installation?
Posted Apr 8, 2008 8:19 UTC (Tue) by shalem (subscriber, #4062) [Link]
I'm sorry Greg, but thats simply not true. When manufacturers don't give permission to distribute the firmware there is nothing distro's can do. This is esp. true with certain wireless cards, making some of all the hard (and good) wireless work being done still not result in a situation where things just work. It would be great if you + someone from RedHat (together representing the 2 biggest Linux firms) could try to negotiate redistribution rights for the firmware with these manufacturers.
How about easier installation?
Posted Apr 8, 2008 12:15 UTC (Tue) by drag (guest, #31333) [Link]
It's not to bad. For example on my distro broadcom cards typically will have a firmware extraction kit that will download the XP drivers and rip the firmware from them. Mostly automatically. Just because they can't distribute it doesn't mean that they can't make it easy. It would be easier to deal with binary firmware then, say, having a GUI button to download and compile proprietary ATI or Nvidia drivers. But ya it would be nice to have a standardized way to distribute stuff like that.
How about easier installation?
Posted Apr 8, 2008 15:51 UTC (Tue) by proski (subscriber, #104) [Link]
It works great if your connection is not wireless :-)
How about easier installation?
Posted Apr 9, 2008 7:29 UTC (Wed) by mjthayer (guest, #39183) [Link]
> But ya it would be nice to have a standardized way to distribute stuff like that. How about driver disks, which nearly all hardware companies provide anyway? Perhaps companies that can't be persuaded to help with Linux drivers could at least be persuaded to pack their firmware in a Linux-friendly way alongside the Windows drivers? Alternatively, said firmware extraction in Linux distributions could recognise the driver disks (and even prompt for them if necessary).
How about easier installation?
Posted Apr 9, 2008 8:25 UTC (Wed) by cathectic (subscriber, #40543) [Link]
Wouldn't help much - most of the drivers that need firmware that can't be distributed (i.e. the reverse engineered drivers, such as b43) rely on a particular version of firmware (otherwise, it leads to a support nightmare, since they can't support every firmware version going - they tried that with bcm43xx). So being able to extract from a random vendor disc of the week is not much use here (and firmware versions required also change as well - e.g. this has happened recently with b43). No, the only real solution is still for the offending vendors to at least allow their firmware to be redistributed, and then let the distributions handle which version of the firmware to ship with the kernel they provide.
A Linux Driver Project status report
Posted Apr 8, 2008 6:11 UTC (Tue) by djabsolut (guest, #12799) [Link]
Perhaps one of the reasons for the perceived lack of drivers for Linux is that to many people Linux == a Linux distribution.
Getting a driver into the kernel does not automatically make the hardware useful. No matter how much I alter my Fedora 8 setup, I still can't get the audio to work on my laptop. The kernel driver loads fine, but something in the elaborate wrapper mechanism for the driver (PulseAudio + etc) is screwing things up.
Additionally, Xorg requires it's own drivers, and there is no denying that there is a lack of drivers for Xorg, e.g. recent ATI and NVIDIA chipsets. (As a sidenote, it would be useful to move this stuff out of Xorg and into the kernel).
A Linux Driver Project status report
Posted Apr 8, 2008 6:53 UTC (Tue) by gregkh (subscriber, #8) [Link]
If you have audio problems with Fedora, file a bug and work with the developers to solve the issue for you. As for xorg, some drivers are already migrating into the kernel. There really isn't that many different vendors for video chips these days, so there is not a large variety of drivers needed anymore.
A Linux Driver Project status report
Posted Apr 8, 2008 13:40 UTC (Tue) by djabsolut (guest, #12799) [Link]
If you have audio problems with Fedora, file a bug and work with the developers to solve the issue for you.The audio issue was an example. The point is that simply having a driver does not automatically mean the hardware is actually useful for the user. 'amartoq' and 'osma' describe this problem better in comments below.
A Linux Driver Project status report
Posted Apr 8, 2008 8:29 UTC (Tue) by sylware (guest, #35259) [Link]
>Additionally, Xorg requires it's own drivers, and there is no denying that there is a lack of drivers for Xorg, e.g. recent ATI and NVIDIA chipsets. (As a sidenote, it would be useful to move this stuff out of Xorg and into the kernel). Working on it... working on it... (nouveau reverse engineering and full AMD/Intel specs). A brand new graphic stack won't happen in a day, it's rather a long process when you look at those chips complexity.
A Linux Driver Project status report
Posted Apr 8, 2008 19:58 UTC (Tue) by drosser (guest, #29597) [Link]
Now, I am not an Xorg developer and the only platform I use is Linux, but why would Xorg want to move their drivers into the Linux kernel? Wouldn't that break compatibility with the BSD's, Solaris, .etc?
A Linux Driver Project status report
Posted Apr 9, 2008 2:47 UTC (Wed) by djabsolut (guest, #12799) [Link]
Now, I am not an Xorg developer and the only platform I use is Linux, but why would Xorg want to move their drivers into the Linux kernel? Wouldn't that break compatibility with the BSD's, Solaris, .etc?
From a purely technical point of view, programs which are in "user space" should not be touching the hardware. That's the kernel's job, i.e. the kernel abstracts the hardware. Currently Xorg is half a user space program and half a graphics kernel. Having two kernels can and does lead to problems.
As for taking care of BSDs/Solaris -- yes that's an issue. However, it may be possible to write low-level drivers (licensed under a BSD license) that are then integrated with Linux/BSD/Solaris kernels using a kernel-specific wrapper. (A ruder alternative is to look at the ratio of Linux to BSD users and concentrate only on the biggest slice).
Popular third party drivers
Posted Apr 8, 2008 7:21 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
I am wondering about the prospect of cleaning up and merging widely used third party drivers such as http://mxhaard.free.fr/spca5xx.html as part of the Linux Drivers project. I dropped a mail to Greg KH a while back and didn't get a response on that. This is pretty important to Fedora atleast since we don't have additional kernel module packages anymore. https://www.redhat.com/archives/fedora-devel-announce/200...
Popular third party drivers
Posted Apr 8, 2008 7:31 UTC (Tue) by gregkh (subscriber, #8) [Link]
I'm sorry if I missed your email, I searched my archives and could not find it anywhere :( Anyway, yes, we are working to bring drivers that are out of the tree into the main kernel tree. Look at the large patches that are currently in our quilt/git tree. It contains a number of drivers just like this. Please feel free to send me a pointer to the latest version of the driver that you wish to see in the tree in email, as long as the original developer of the driver does not object to it being added (we try to not go against the wishes of the authors.)
Popular third party drivers
Posted Apr 8, 2008 22:45 UTC (Tue) by davidw (guest, #947) [Link]
Speaking of which, I thought I'd sent you something about collaborating/integrating/seeing what's possible with the Linux Incompatibility List (at leenooks.com ), which I run, but can't seem to find that email, so maybe I never asked. The scope is quite similar, although I'm liable to include things that are very difficult for ordinary people to actually use, or things that have a driver that's not there 100%. I don't run the site for profit (the adsense covers hosting costs), and to tell the truth wouldn't mind unloading it to the right person.
SPCA
Posted Apr 8, 2008 9:44 UTC (Tue) by eru (subscriber, #2753) [Link]
Half a year ago the SPCA driver came up on KernelTrap, when I asked about it in the comments of a story on out-of-tree modules. See the comments in the story at http://kerneltrap.org/Linux/Out_of_Tree_Modules. It seems the problem here is a style issue, or one of architecture (to put it more grandly), and thus more intractable than one involving merely missing specs. :-( <- the face of a sad webcam owner.
Popular third party drivers
Posted Apr 8, 2008 12:14 UTC (Tue) by jengelh (subscriber, #33263) [Link]
>This is pretty important to Fedora atleast since we don't have additional kernel module packages anymore. Sweet, that gives distros with kmods an edge :-)
Popular third party drivers
Posted Apr 8, 2008 12:57 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Technically, the patches can be just be in a single kernel package instead of kmod's but the whole point of that exercise it to support upstream better. While distros can ignore the upstream aspect of it, that is generally a short term win. Getting these drivers upstream benefits everybody. Distros shouldn't try to get an edge on such matters IMO.
Popular third party drivers
Posted Apr 8, 2008 13:19 UTC (Tue) by jengelh (subscriber, #33263) [Link]
Putting all modules as a patch into the main kernel.src.rpm is just going to be a hassle if that is even legally possible. kmods seemed to have been welcomed by hardware vendors, as they could ship a simple one-command installable package (e.g. ati/nvidia rpms for suse, justrpm -Uhv
); I am sure people were happy to have such a package; now with kmods going away they are back to square¹ with the ugly .sh installers.
Popular third party drivers
Posted Apr 8, 2008 13:21 UTC (Tue) by jengelh (subscriber, #33263) [Link]
Oh right, here's a good example the ivtv package from SUSE. Has no .src.rpm, so I guess there is even more surrounding legalese than with the NVIDIA license if there is not even a .src.rpm. Now, how would you get ivtv into the single kernel package...
Popular third party drivers
Posted Apr 8, 2008 15:41 UTC (Tue) by Thalience (subscriber, #4217) [Link]
FYI, the ivtv kernel driver was merged in 2.6.22. Not sure what might be in the SUSE ivtv package. Perhaps the firmware (would explain the lack of a .src.rpm)?
Popular third party drivers
Posted Apr 9, 2008 1:28 UTC (Wed) by drag (guest, #31333) [Link]
Yes. I would think it was firmware. I have one of those cards and they do require separate firmware, but the driver is now in-kernel.
Popular third party drivers
Posted Apr 8, 2008 16:39 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Read the link before jumping to conclusions. Kmod's are only going away in the official repository which was only including free and open source code anyway and hence for proprietary drivers the Fedora change makes no difference. Third party repositories like Livna continue to provide such drivers as kmod or dkms packages and there is no need for shell script installers.
False positives
Posted Apr 8, 2008 7:24 UTC (Tue) by oglueck (guest, #51471) [Link]
I think some of the devices listed in the Wiki pages are actually supported. But the users just couldn't figure out how or are using an old kernel. The listing is a bit unstructured. It would be nice to have some structured information on each of the devices. Like PCI ID, USB IDs, kernel version tested etc.
False positives
Posted Apr 8, 2008 7:27 UTC (Tue) by gregkh (subscriber, #8) [Link]
It's a wiki, if you feel you can structure the information better, please do so :) Also, if there is information on there that is obsoleted by newer drivers in newer kernel versions, please feel free to remove it.
False positives
Posted Apr 8, 2008 16:26 UTC (Tue) by iabervon (subscriber, #722) [Link]
Not that I know how to structure it, but there's value in having a list of kernel versions that added support for devices, because otherwise people will find that there is a version of the kernel that doesn't support their device, and no entry for it on the page, and add it. Maybe if the wiki supports source text that doesn't get rendered, the source text should have all of the devices that have ever been listed, with ones that are now supported hidden with a label saying what happened to them.
Hardware needs more than a driver for proper support
Posted Apr 8, 2008 10:33 UTC (Tue) by amartoq (guest, #1712) [Link]
I think the real issue here is hardware that just works. And the main missing part, that it must work *well*. My ATI Radeon Mobility X600 has been a PITA for the past 3 years... Yeah, I've got everything working but compiz never didn't work until now and suspend/hibernate never worked. I felt dissapointed because it worked, but my system didn't perform as well as I expected. I've got a logitech notebook webcam that performs pretty well in windows but not in linux. The reason? The light conditions are not handled by the linux driver. So, in a simple application like gnome Cheese, I don't see anything or got everything too bright. Yes, it works, but it doesn't work *as well* as expected again. And it performed poorly because my xorg.conf didn't include XV overlay as default. I had to figure that out, after reading some docs... For a hardware to work, there is a need for a driver. That's being covered in kernel or userspace; and I'm thankfully that I don't need to worry about installing drivers, just plug it in and it's automatically recognized. That's amazing! The issue is that it doesn't work always well. Many times the windows "driver" installer puts a lot of extra software that its needed and it's missing in linux. Or the linux port is far away of being comparable to the windows port, or it's too complicated to get the "useful" features. The hardware needs more than a driver for proper support.
Hardware needs more than a driver for proper support
Posted Apr 8, 2008 12:17 UTC (Tue) by osma (subscriber, #6912) [Link]
Seconded. Having a basic working driver is a good first step, but often users expect more from their hardware. If we only look at driver status as a binary distinction between driver exists vs. driver missing, then from a user's point of view every device works in principle but not well in practice. This is still a huge step forward from the situation some years ago when a lot of hardware actually didn't work at all with Linux. If the situation with most classes of hardware is as good as Greg makes it sound, then we need to raise the bar higher and not just talk about missing drivers. As a personal story, I have a Dell X300 laptop with a memory card reader that barely works with the out-of-tree sdricoh_cs driver. IO is much slower than in Windows because the driver only does polling, no interrupts or DMA. I can't use the reader in practice to transfer pictures from my camera, it would take forever. I don't expect the situation to improve since no specs are available and the hardware is likely to be obsolete by now (so this is in Greg's "hard" category #2). But on a checklist, the card reader might be considered supported. Another example is the Intel video on the same laptop. Ubuntu Gutsy was the first distro that actually allowed me to make full use of an external 1280x1024 TFT display in a dual-head setup, thanks to the new RandR support in Xorg. Previous versions of Xorg either crashed outright or, at best, forced me to use ugly XGA resolution on the TFT. I still (as of Hardy beta) can't switch between laptop-only and dual-head modes without logging out of X (and often having to use a messed-up console to restart GDM). In WinXP display hotplugging has worked (almost) perfectly for at least two years.
A Linux Driver Project status report
Posted Apr 8, 2008 13:56 UTC (Tue) by pointwood (guest, #2814) [Link]
Thanks a lot for all the work! I know nothing about driver development or hacking the kernel, so forgive me if there are reasons this isn't relevant at all, but I'm just thinking that it would be good idea to work together with the other open source operating systems like *BSD and so on? If the drivers are all licensed only under the GPL, that's not possible if I understand correctly)? If they were licensed under the BSD license (and maybe others), it would help the smaller teams like the *BSD teams and the *BSD drivers teams would of course be helping out as well, adding drivers to the pool. Anyway, when I think about now, you guys (being much smarter than I), have probably already thought about that and there's probably a good reason why it isn't like that already. Ps. I'm a Linux user, not a *BSD user, though I have long meant to try out FreeBSD, but never gotten around to it :)
A Linux Driver Project status report
Posted Apr 8, 2008 15:27 UTC (Tue) by mheily (subscriber, #27123) [Link]
This will never happen. Porting code between different kernels is hard enough without the licensing issue. Even if the code was BSD licensed, the OpenBSD developers are totally against the idea of importing device drivers without publicly available documentation. See this KernelTrap article for the reasons why.
A Linux Driver Project status report
Posted Apr 9, 2008 6:31 UTC (Wed) by pointwood (guest, #2814) [Link]
Well, OpenBSD isn't everyone and yes, I do remember reading that discussion when LDP started. I could imagine some FreeBSD developers would be interested, maybe the primary thing would be to get access to the documentation by signing a NDA. I would think having a company handle the legalese would be nice. Also, even though they would be developing for different platforms (Linux and FreeBSD), they could probably learn something from each other or help each other out understanding the documentation.
Linux Driver _Improvement_ Project?
Posted Apr 8, 2008 14:51 UTC (Tue) by jwb (guest, #15467) [Link]
Very interesting article. When I heard of the LDP, I also thought "Huh?" because all my hardware works with Linux. But I've also become accustomed to the variety of ways in which those devices and their drivers are broken and quirky. As an example, my laptop draws almost 8 times more current when sleeping under Linux than under Vista. This is probably because Linux device drivers don't shut everything down to the degree that Windows does. While all the devices are supported, the drivers haven't implemented all of their power saving features. Instead of another year of a Linux Driver Project focused on simply more "supported devices" that are half-working, how about a Linux Driver Improvement Project that focused on getting more features of more devices working correctly?
Linux Driver _Improvement_ Project?
Posted Apr 8, 2008 18:15 UTC (Tue) by jmorris42 (guest, #2203) [Link]
> ..how about a Linux Driver Improvement Project that focused on getting > more features of more devices working correctly? Amen! Lots of hardware sorta works but once you leave server land 'sorta works' is more the rule than the exception. Power management is the BIG elephant in the room, it is now finally getting some long overdue attention but we are probably still a few years away from parity with Windows. Laptops are a big black hole of driver issues. ACPI, docking, power, sleep mode, winmodems, oddball almost compatible devices. I see vendor loaded laptops that don't support everything. I'd offer up a goat in sacrifice to the computer demons if somebody could identify a half dozen (need some variety in size/weight/features) current production business laptops that are 100% supported. By business class I'm talking about reasonably durable, dockable a big plus, WiFi+Ethernet+modem for networking, support contracts (from the vendor, not Worst Buy) available, etc. More Thinkpad, less Dell Hell.
e.g. Thinkpad T60p - very well supported.
Posted Apr 9, 2008 12:15 UTC (Wed) by rankincj (subscriber, #4865) [Link]
Core 2 Duo, dockable, ethernet, wifi, onboard Intel sound, ATI onboard M66 video (which is definitely "getting there" since AMD opened up the GPU specifications), fingerprint reader, bluetooth: all working. The only issue is the modem, which I haven't even tried to use, but which I think that I saw some Suse drivers for somewhere. When docked, the serial and parallel kernel modules all "magically" load, the ethernet port transparently hands over from the laptop to the docking station, and the docking station's memory card reader is a USB mass-storage device and "just works" anyway. So why say "More Thinkpad, less Dell Hell" when you could just buy a Thinkpad?
e.g. Thinkpad T60p - very well supported.
Posted Apr 9, 2008 20:29 UTC (Wed) by jmorris42 (guest, #2203) [Link]
> So why say "More Thinkpad, less Dell Hell" when you could just buy a Thinkpad? So it ALL works? Can you undock? My X31 only partly works on the dock. The DVD/DCRW only works at 4X CD speeds, the USB ports on the dock don't work, the PC-Card slots don't work. But the network, video, serial, floppy and sound do. Can't find any way to trigger an undock. A coworker's T60 is in the same 'almost works' catagory. It will sorta dock (network may or may not attach) but won't undock.
e.g. Thinkpad T60p - very well supported.
Posted Apr 9, 2008 23:47 UTC (Wed) by rankincj (subscriber, #4865) [Link]
The USB and network ports on the dock all work fine, and I haven't installed any drive into the dock's multi-drive bay yet. (It will probably be an extra hard drive eventually, though - the laptop already has a DVD drive.) There is no PC Card on the dock because there's one on the laptop already, but that works too and currently has an Audigy2 ZS Notebook card in it. The microphone for this Audigy2 card does not work, but that's apparently a known ALSA bug rather than a laptop problem. So far, I have only needed to dock and undock "cold", but doing so "hot" looks to be a matter of turning a key, pressing a button and then pressing a second "eject" button when a light turns green. I have not tried this yet, because I haven't needed to.
Linux Driver _Improvement_ Project?
Posted Apr 9, 2008 17:19 UTC (Wed) by bersl2 (guest, #34928) [Link]
>Power management is the BIG elephant in the room, it is now finally getting some long overdue >attention but we are probably still a few years away from parity with Windows. PowerTOP helped make great strides in that area. I would say that it's not the Big One anymore, but then again, my laptop's been out of commission for months now.
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 8, 2008 17:39 UTC (Tue) by dwheeler (guest, #1216) [Link]
I disagree with Greg KH on one key point: There is still another major missing driver piece: _good_ FLOSS 3D drivers for the NVIDIA and ATI cards. Yes, there are some partial solutions, but it's not "stick in the install disk and everything works well", which is the only measure that matters.I'm well aware that a lot is not actually done in the Linux kernel. So what? The userspace/kernelspace division is great for organizing, but the only thing users care about is "does it work?"
I would REALLY like to see some of these "developers twiddling their thumbs" to accelerate development of FLOSS 3D drivers for NVIDIA and ATI. If necessary, through reverse engineering. This is a major stumblingblock right now. The NVIDIA proprietary code works, unless you update some other component, at which point they often break... so even if you're not big on FLOSS, they are still a big problem.
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 8, 2008 18:48 UTC (Tue) by NAR (subscriber, #1313) [Link]
Similar experience with fglrx for ATI. Works mostly fine for 2D, but sometimes some parts of the display are not updated when I switch desktops. Overlay mostly works, except when the whole X server crashes. Googleearth works, except the popup windows are either "see-through" or empty. Not to mention that I have to reboot the laptop when I take it off from the docking station, because I can't switch between the built-in LCD and the outputs on the docking station. Oh, and I haven't tested the TV-out yet. So it works, but there are a couple of but's. Of course, it might not be something that the LDP could fix.
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 8, 2008 20:26 UTC (Tue) by Ed_L. (guest, #24287) [Link]
Michael Larabel keeps up-to-the-minute status of the Open Source ATI and Nvidia drivers, and comparisons with their proprietary counterparts, over at Phoronix.com. I'd suggest a peek at some of his articles, for an idea of what is involved.
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 9, 2008 1:52 UTC (Wed) by drag (guest, #31333) [Link]
The Nvidia driver was the #1 reason Vista crashed as revealed by court released Microsoft documents. Over 28% of the crashes were caused by it and that's comparing it to _every_single_piece_of_hardware_ that Vista supports. Nearly a third. I am told that the core of the Windows driver is about the same as what is used in Linux. Soooo... That's not looking pretty. the thing about Linux and 3D drivers is that the driver model is f*ked. It's a huge mess. And it's not even Linux developer's fault.. it's all those years that Xfree stagnated.. Windows left Linux in the dust when it came to video drivers. Right now 2D and 3D are totally different code bases, totally different APIs. But yet they have to do very similar tasks on the same exact hardware at the same exact time. Not good. As far as 2D performance goes.. No video card maker has put any effort in improving it in years. In very modern cards there is _no_ 2D-only hardware. It will either done by internal emulation or simply lack any support for 2D acceleration at all. So a unified driver based on the GPU is going to be needed going forward. One that supports multiple APIs. To bad we don't have one yet. Except in very early development. (Gallium3D) Until we are able to get rid of the schism of 2D vs 3D in Linux/X.org (at the driver level..) it will not have the stability and performance that you get from Windows or OS X. Not so much in terms of crashing.. but just in terms of general ugliness, lack of performance, and difficulty (on the part of driver developers and end users). One example is during video playback many people will notice that if they use Linux for HD video there will be occasional tearing and lines across the middle of the screen were you have overlapping frames and such. This is because there is no way to sync video up with your refresh rate so that you get a nice solid frame of video ready for each screen refresh. Why? I donno. The design of Linux drivers simply won't allow it without exceptional difficulty I guess.
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 9, 2008 2:02 UTC (Wed) by drag (guest, #31333) [Link]
Oh. And it looks like Via has finally come around and decided to help out with driver development rather then just kinda do everything half-assed and piss of developers that are trying to make their hardware work good. http://www.phoronix.com/scan.php?page=article&item=vi... So that means that we have open source drivers development aided by: Intel -- open source code and documentation. ATI -- some open source code and reasonably full documentation. Via -- we will do what they are doing; see linux.via.com in a month. (there are two very cool things that Via does well that Linux users can benefit from.. Very fast hardware encryption engine and decent hardware acceleration for media playback on the very cheap.) Nvidia -- ?? It's amazing. Nvidia does have fast drivers for Linux, but they are so proprietary that they only support Windows for their new multimedia oriented ARM-based platform. This is a market were Linux outsells Windows for most things. A well. 3 out of 4 ain't bad. This means that Linux now has documentation for about.. what? 90% of video devices being sold? At least everybody should be happy that things are moving forward. (I wonder if OpenBSD will be contributing to 3D drivers now that documentation is avialable..)
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 18, 2008 23:22 UTC (Fri) by endecotp (guest, #36428) [Link]
> It looks like Via has finally come around and decided to help out That is good news. I have some embedded things with nano-itx boards in, and the scary "abandonware" nature of the framebuffer driver has been making me think about using a Geode board instead; I posted about this on LKML (http://thread.gmane.org/gmane.linux.kernel/656335) and got no replies. Fingers crossed that they take the right approach.
Sync to VBlank
Posted Apr 10, 2008 14:23 UTC (Thu) by dlarrick (guest, #5532) [Link]
There are actually two mechanisms to sync to VBlank under XOrg. OpenGL has the GLX_SGI_video_sync extension, and DRM has DRM_IOCTL_WAIT_VBLANK . One or both of these works on most modern hardware. Both of these are useable for video output -- MythTV, for example, will select whichever is available.
Need good FLOSS drivers for 3D cards (NVIDIA, ATI)
Posted Apr 10, 2008 8:14 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
The huge problem with nouveau is they're stuck in a "we'll merge later, it does not work perfectly now, merging it today would only result in issue reports" stance. As a result most Linux users do not have access to nouveau, and the merge when it happens is going to be as difficult as alsa was (we still have people that do not consider alsa the default linux sound system, and it's due in no little part to alsa having lived as an optionnal out-of-tree addon so long) If you don't get yourself mainlined, the rest of the software ecosystem organizes itself without you.
hauppage wintv150 known as 26xxmodel
Posted Apr 8, 2008 19:57 UTC (Tue) by dranembyte (guest, #51482) [Link]
Hauppage WinTV PVR PCI II (26xx) not currently supported with Ubuntu. :-( Vendor 4444 dev 0016 subsys 88010070 rev 01\4&CC5B14e&0&38A4 Can lspci it but no linux tv software will tune it dang it
hauppage wintv150 known as 26xxmodel
Posted Apr 10, 2008 20:34 UTC (Thu) by leoc (guest, #39773) [Link]
If you haven't done so already, you should post this to the LDP wiki.
iPod Nano 2nd gen
Posted Apr 9, 2008 2:33 UTC (Wed) by Richard_J_Neill (guest, #23093) [Link]
The ipod linux project was wonderful - especially since it allowed Ogg playback. Another consequence is that Rockbox works on the ipod, as a result of knowledge gained by porting Linux. BUT...neither Linux nor Rockbox work on any recent iPods (or the iPhone), because some idiot at Apple decided to encrypt the firmware. I can see why this is hard to break, but, it would be nice... Other projects badly in need of help include OpenMoko, and the XDA-developers - both are "almost" at the point of having fully working open-source phones, but it isn't ready yet. Lastly, I'm very excited about renouveau, but it too needs more help. Richard
iPod Nano 2nd gen
Posted Apr 9, 2008 3:15 UTC (Wed) by drag (guest, #31333) [Link]
> BUT...neither Linux nor Rockbox work on any recent iPods (or the iPhone), because some idiot at Apple decided to encrypt the firmware. I can see why this is hard to break, but, it would be nice... I don't think that is very suprising. Apple is a pro-DRM company that makes a lot of money from using open source software as a base for launching closed software and closed platforms. I mean, seriously. They refuse to incorporate code for a codec that is is widely distributed and very common (as far as non-mp3 codecs go). All of it is available for free and under a very liberal license. Even open hardware references they could use. Easy as pie. And this is even with hard evidence that their players have been capable of Ogg Vorbis playback from the very beginning. The real solution to all this mess is simply not give money to a company that treats it's customer base like driven cattle. :/
On Apple being "pro-DRM"
Posted Apr 15, 2008 2:56 UTC (Tue) by apollock (subscriber, #14629) [Link]
I'm no Apple apologist, I wish they'd lift their game in terms of interoperability, but I question calling the company "pro-DRM" in light of Steve Jobs' writing on the subject last year: http://www.apple.com/hotnews/thoughtsonmusic/
A Linux Driver Project status report
Posted Apr 10, 2008 20:07 UTC (Thu) by muwlgr (guest, #35359) [Link]
It would be interesting to see a separate list, of what drivers had really been implemented, completed or improved in the course of this project.
A Linux Driver Project status report
Posted Apr 11, 2008 20:24 UTC (Fri) by makomk (guest, #51493) [Link]
Video input devices is... interesting. I'm not sure about the webcam end of things (I think there are a lot of out-of-kernel drivers and random cheap chips in that area). For TV hardware, though, your typical piece of hardware integrates chips from several different manufacturers, and supporting it requires finding out not only how to use any unsupported chips but also how the manufacturer has connected them. There are literally hundreds of different pieces of hardware from different manufacturers, each with its own quirks. (Most of the card-specific stuff is reverse engineered.) This is all done in the developers' spare time. Also, while most, perhaps even all, chips used on TV cards do have full documentation, nearly nobody makes them public. Some companies are willing to release them under NDA, some aren't. As for the inter-personal conflicts, the less said the better.