|
|
Subscribe / Log in / New account

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, just rpm -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. 


Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds