Slashdot Mirror
Know Any Hardware Needing Better Linux Support?
Dev Null writes "The Linux device driver project has hit something of a snag: they have lots of developers, but few devices to work on, so they're looking for input concerning which devices aren't well-supported in Linux. If any of you know of devices that could use better support, you can help out by listing them on the project's wiki."
These are kernel developers, not userspace developers. Hence, userspace issues are outside the scope of their efforts. It doesn't mean that they're ignoring it; it's just not what they do.
Wikipedia has good links to tell you more about kernel and userspace, if that's your sticking point.
--
Given enough personal experience, all stereotypes are shallow.
Linux is a kernel. Almost every other program running on a Linux-based system, be it GNU/Linux or uClinux, is an application running in user space, a part of memory separate from "kernel space". The drivers for printers are "filters" for an application called CUPS, the drivers for scanners are modules for an application called SANE, and the drivers for video cards are modules for an application called X.Org X11.
The people who made this request for proposals are interested in projects that need specific support from kernel space. The kernel side of scanning and printing is solved through libusb.
I have an nvidia 8600 on a P35 motherboard. Tried 4 different distros, each crashed in the installation. Then I tried a text-based installer. Works fine.
Really, I have about half a dozen webcams here which I cannot use, alas I only have one of each so it sort of kills any gain for me to send them the webcam so they can develop the driver (Great, another webcam supported but not in my set of cams :( ).
What's dreadfully bad about webcams is that even with the same model number/name you can end up with a completely different bridge or sensor chip inside either due to a revision change or locality, really, it's pot luck at best.
As for wifi cards, it's really more of a situation where a few of the current drivers are incredibly fickle - perhaps it's the nature of the beast? I've got a RT2400 type card which if it doesn't get its setup parameters within ~2 seconds of the module being loaded it utterly refuses to accept anything else until a complete restart. Things like that make me feel like I'm playing in Windows again.
NVidia cards? What about ATI - the latest release of their Linux drivers perform even worse than the previous version. At the moment, as an ATI Linux user, my next gfx purchase it definitely going to be an NVidia card as their drivers are currently far superior.
Last time I checked webcam support was implemented as a kernel module (gspca or spca5xx):
http://mxhaard.free.fr/index.html
Added in 2.6.19.
If your monitor and VGA card aren't completely braindead, these days, X, if properly configured to do so, will use DDC to extract your monitor's make, model and claimed EDID specifications automagically, and use that to pick an optimum resolution. If your monitor lies about its specification, or can't do DDC (hint: my 15" Iiyama CRT from 1995 can), then you're out of luck. If your distro doesn't configure X to use DDC, again, you're out of luck.
Kroah-Hartman asked the Linux Foundation, which has made improved driver support No. 3 on its Linux to-do list, "Specifically what devices did they see in common use that are not supported by Linux (the obvious two video cards [ATI and Nvidia] being a known exception.) Despite this being such a high priority for this group, they had no examples to provide." I'm sure they had examples to provide, but he kept saying, "Sorry, that's a userspace issue." But to a user, when the printer doesn't print or the scanner doesn't scan that's a driver issue. Maybe there's a technical distinction between userspace and kernel drivers, but all the user is going to see is that his printer doesn't work. Hartman can't say driver support is an overstated issue if he's pushed all the work to userspace. That's why the OP's criticism is dead on.
ALSA has had both hardware and software mixing from almost day one. It will use hardware mixing if your card supports it, and software mixing (ala dmix) if you don't. If mixing isn't working on your machine, then ALSA isn't configured properly. Check your distro's instructions on how to set it up.
Uhm, have you checked the kernel in the last 12 months?
GPS Receivers (USB and/or Bluetooth)
Mod points are a dangerous tool. Abuse them wisely.
Devices that use userspace USB drivers:
- Printers (CUPS)
- Scanners (SANE)
- Cameras (gPhoto2)
Devices that use kernelspace USB drivers:
- USB Mass storage (card readers/pendrives/media players/etc)
- USB Networking
- USB Bluetooth
- USB to serial/parallel converters
- USB HID Input
- USB Audio
- USB Video Capture
That USB devices are a userspace issue is a lie. They go both ways.
Besides, Trance Vibrator support is already in... the kernel.
That has the one thing that has really put me of ever running Linux on a laptop (along with the terrible selection of commercial software) - its great on the server, great on the technical workstation but when it comes to the laptop and general purpose computing, it falls apart.
Such a thing already exists, it's called The Linux Documentation Project.
Need I say more?
From an end user's perspective, "userspace" is what you see, the programs you start up and interact with. "kernelspace" is something you only encounter when the system crashes or a floppy drive is stuck or a line printer on fire etc.
From a technological point of view, Unix-like operating systems have a clear separation between "kernelspace" and "userspace". The kernel is a program that always runs and "does everything". It is supposed to only do the low-level tasks, close to hardware, such as scheduling (which userspace program is allowed to run next) and I/O (send bits to a parallel port printer and wait x microseconds).
Between kernel and userspace is a software library called the system library; for Unix-like OSes usually written in C, libc. This contains functions like write() and read() that are implemented by sending commands to the kernel to do something via "system calls". Whether those commands are actually executed then depends on the permissions model, because programs using the system library are all run as if executed by a "user".
This brings us to userspace: an end-user wanting to print something in the gimp program presses a button, the gimp program is running under the privileges of that end user, the userspace programmers who wrote gimp tied the "print button press" action to a gimp function which at one point does a libc call write(printer, data), the C library function write() takes the data and <start handwaving> invokes the kernel's SYS_write() call (I think) with permissions from that end user and a pointer to the data in user memory and a pointer to the printer device special file (everything looks like a file in Unix) and then the gimp program will just sleep and halt and be activated again when the kernel decides to give it another slice of CPU time (for example, after the kernel has done the actual printing, or at least called the kernel functions to get the actual what-have-you brand printer driver functions to do their voodoo with the user-presented data).</end vague handwaving>
But as you can probably tell I'm not a real system programmer so I'll gladly let someone else correct me from here :-)
To be, or not to be: isn't that quite logical, Slashdot Beta?
Following up to myself here: maybe the foregoing was confusing, because printing is a bit special because the low-level functions (how long to wait etc.) are presumably standardized (either standard parallel port or send it over ethernet I guess), but here the high-level functions (i.e. how to encode the data to be sent to the printer) is not. And this high-level encoding is done in user-space by a program library called CUPS. And if the printer maker refuses to give the documentation necessary to write a CUPS driver (Adobe .ppd file) for your printer, well then you should just return the printer to them or complain to your country's consumer organization because you're S.O.L.
To be, or not to be: isn't that quite logical, Slashdot Beta?
No, it makes perfect sense -- it's just confusing because of an odd use of terminology (at least as compared to Windows).
When people complain about printer drivers under Linux, they're not talking about kernel modules -- what most of us would think of as "drivers" in the traditional sense. Linux already has USB/parallel port/whatever kernel modules that handle everything related to the communication with the device. The complaint is in the "device-specific-properties" end; since the USB/parallel port/whatever kernel modules are generic, handling only the lowest layers of how communications on the bus takes place, they don't know anything about the type of data the device expects.
To make a useful-but-not-quite-right analogy, your network interface card knows about how to send 1s and 0s over the net; but it doesn't know anything about what kind of sequences of 1s and 0s will make sense to anything on the other end. Instead, you've got software layers above it that are responsible for taking a bunch of outgoing data and cutting it up into an ordered sequence of chunks wrapped in headers to allow re-assembly (the TCP part), then wrapping them in shipping headers so they'll reach their destination (the IP part), before sending them to the NIC. But even those software layers don't know that the device on the other end will be passing this data to a web browser; so the chunk of data being sent better look like sensible HTML. That's taken care of by other layers of software in user space.
In Linux, kernel modules handle the communication with the device; but they don't know (and don't care) what form the device is expecting the data to be in. For printers, that's handled by a separate "filter" layer that comes before the kernel modules do their work. The filter layer is typically some sort of translation program that runs in userspace, takes a stream of data as input (from a file, from another program, or whatever), and encodes it into some other form and/or breaks it into chunks and/or wraps it in headers. The "encoding into some other form" would include putting in the stuff that exploits specific printer features. It's these filters which are sometimes missing or feature-incomplete in Linux, and are what people refer to when they talk about printer drivers.
You can think of "userspace" as the programs which can be run without special priviledges.
I think that few devices can be programmed in userspace...but device drivers can be accessed and instructed (I want to say programmed, but in this context that's ambiguous) from usersapce.
CUPS is one particular very complex driver. It's got it's own special project just to handle printers, because handling printers is complicated. (And the manufacturers don't make it easier.) It's also because handling printers is one of the first things that systems had to start doing. I think they were right after teletypes and before hard disks. (Not sure where tape drives fit in...or what interface they had.)
The result is that printer driver development is done through the CUPS project. The Linux Driver project was set up to deal with a bunch of later devices (light-pens, whatever). These are generally rather small devices...or at least they generally have rather small drivers. They also generally have a rather small number of users, who tend to be rather specialized.
P.S.: This *ISN'T* an authroitative reply. I've read a few articles is all, and was here watching as some history happened. But lots of projects "just grow". The Linux Drivers project wasn't one of the very early ones, so some driver projects got started before it ever showed up, and others started separately and never merged. (That might include SANE [Scanner Access Now Easy], but I'm not sure.)
I think we've pushed this "anyone can grow up to be president" thing too far.
I think the confusion in this discussion about printer drivers is like this: the low-level printer drivers are in the Linux kernel and are therefore programmed by what you could call "kernel programmers". These people have offered to write drivers for all kinds of equipment if the manufacturers can't be bothered to write them due to perceived lack of marketshare.
The problem with printers is that these low-level drivers are all already written and working; what they are is the parallel port driver, the USB drivers, the network drivers. Still, if you bought a printer, and it is connected via a parallel port or USB or network driver, for some brands of printers it will not work. Why is my printer not supported by Linux? Are these kernel people lying, or lazy?
I think the most plausible answer to that riddle is that, even though you can send your page of printed text to the printer (either in text format or PostScript or even PCL), and Linux will dutifully transmit it with the correct protocol and parameters, some printers just refuse to print it..
I can speculate as well as anyone else why this is, but except if you have buggy parallel port or USB or network drivers, none of this can really be blamed on the Linux programmers IMHO: no matter how many you let work on the problem, you won't get any improvement: it's just not a "kernelspace" problem but a "userspace" problem, i.e. how does the page of text have to look in order to be printed by your printer.
<speculation>
I don't actually know much about printing, but from what I gather, printers refusing to print can often be caused by one of these two causes, both clearly the domain of the printer manufacturer:
I'm not saying there aren't reasons for these two cases (e.g. the PostScript language is patented so a printer manufacturer would have to charge you extra to repay those royalties for the PostScript chip in your printer) but it does make it more difficult for anyone to make a userspace program that can take your document, transform it to a format the printer reluctantly accepts, and let the Linux kernel feed it to the printer.
To be, or not to be: isn't that quite logical, Slashdot Beta?
gtkPod works great. Check it out.
Lack of wireless chipset drivers is one of, if not the most, serious impediment to growing the Linux user base at this point in time. Broadcom is one of the most popular brands but by no means the only one without proper support under Linux.
Linux Device Driver Dev: "Hey, I need something to work on."
Me: "Wifi drivers for 802.11n, WPA2 and Broadcom chipsets."
LDDD: "Something besides those."
Me: "Get lost and stop wasting my time."
Xfce: Lighter than some, heavier than others. Just right.
In my experience at a large corporation
you are not allowed to consult with the customers (That's a BA) (and you are not allowed to talk to the people that talk directly to customers very often either).
writing the specification (That's the designer or architect)
getting the specification approved (Project Manager)
user-interface testing (Okay maybe you except at super large companies)
load-testing (ITQA, or not done because too expensive)
support and maintenenance for the life-cycle of the project (usually handed over to programmers stuck on the maintenance and support crew)
as well as the actual implementation (this is you- and before you are finished, you are over allocated to two other projects at "highest priority" to fix as well.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.