Re: [9fans] USB CDRW

[Sape Mullender <sape@plan9.bell-labs.com>]

> What is the status of USB support in Plan9...

We have a USB driver (which I'll make available as soon as I've cleaned
up the code, maybe in a few weeks).  Forsyth wrote the initial driver
and I've modified it extensively.

The current driver deals with hubs, mice, a joystick, one camera, printers
and most audio devices.

Adding simple devices such as keyboards is trivial.  All you have to
do is read and interpret the data stream and this is staightforward.

Adding complex devices, such as disks, cameras, network interfaces
and the like is much more complicated because they require many
message interchanges before they will do what they are supposed to do.

When I wrote the audio driver, for example, I had to write code to understand
all of the `configuration' messages from the device that tell the driver what the
audio device can do (can it do output?  input?  does it have volume control?
if yes, what's the max, what's the min?  what sample rates are supported?
what sample sizes?  how many channels? the list is endless).  The audio devices
I've seen adhere to the USB audio standard (you can find it on usb.org), but I
know that audio devices exist that do not conform to this standard (iMic for one).

Dhog has played with cameras.  He told me he found only one that obeys the USB
standard fro cameras.  For every other camera you're on your own trying to find out
what to send to the device to make it tick (or click).

The USB system for Plan 9 consists of a driver that only knows how to send and receive
USB data packets.  Packets are sent on `end points', think of them as USB device addresses.
Some devices have multiple addresses (e.g., one for audio data, one for audio control, and
one for buttons on the device).  The kernel makes them avalable as files of the form
/dev/usb/3/ep2data (endpoint 2 for device number 3).  The kernel does not
understand devices.  There is a usb daemon (usbd) which runs as a user program
that reads and interprets descriptors from the connected devices, finds out what they
are and tells the kernel to configure the appropriate endpoints and make the epndata
files.  Usbd understands and configures hubs, but no other devices.

Programs such as usbmouse and usbaudio will look among the device codes to find
mice or audio devices.  They will then configure these just like usbd configures hubs.
usbmouse takes mouse events and sends them to #m/mousein whete the system
mixes them with mouse events from the regular mouse. Usbaudio configures the audio
device and implements a file system with /dev/audio and /dev/volume making it look
like a sound blaster.

Printers are simple.  The end point must be configured and it can then be written just like
/dev/lpt0.  There's a program which finds a printer and binds its endpoint to /n/lp.
Print to that instead of /dev/lpt0.

Now that we finally understand how USB works in all of its rather unglorious detail,
dhog and I want to rewrite the thing.  It's become kind of ugly.  Be patient for another
week or two and we'll send out our driver.

	Sape