From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] USB CDRW From: Sape Mullender MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20011003122416.AB23D19A28@mail.cse.psu.edu> Date: Wed, 3 Oct 2001 08:27:54 -0400 Topicbox-Message-UUID: fbc6b826-eac9-11e9-9e20-41e7f4b1d025 > 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. 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 tow and we'll send out our driver.