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."
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.
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.
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.