Re: BoF on hotplugging - summary

[Tim Jansen <ml@tjansen.de>]

On Tuesday 24 September 2002 00:00, Oliver Neukum wrote:
> Information needed by user space:
> Items of consensus:
> - physical path and all available device ids must be delivered
> - groupings of devices must be delivered
> - most crucial item: user space needs a mapping between physical and
> logical device - user space wants a device _name_
> - driverfs and the input layer must be documented

To go a step back, I think there are three four things that need to be done:

1. get a list of all device that implement an interface (eg. OSS, ALSA or V4L) 
and get information about the devices that can be presented to the user 
(name, manufacturer, bus). In an ideal world, the information could be 
retrieved without using the (OSS|V4l...) interface, so desktop environments 
can have a single dialog/widget for displaying all devices of a type. And it 
must be possible to get the path to the /dev node(s) that represent the 
device.

Use case:
- user wants to record sound
- app presents user all devices that can record sound (for example on-board 
sound, sound card, USB headset, webcams with build-in microphone - my 
computer has 4 OSS devices)
- user selects one of them
- application uses the selected sound device


2. identify a device.  An application should be able to 'remember' which 
device a user selected. When the user turns the computer off, the application 
should be able to find the device that the user has selected before. Even if 
it is in a different port or the user added a second device of the same type. 
This is not always possible, as many devices do not have a unique serial 
number, but the system should try to guess as well as possible. So if there 
is a serial number, use it. If there is no other information available, try 
to guess it using the port or the hub the device is/was connected to.

Use case:
- a user has two USB printers and selects one of them
- the user turns off the computer and the printers
- the next day, the user turns the computer the printer on again. Note that 
the user may or may not turn on the printers in the same order. If the user 
chooses a different order, the device nodes of the printers have changed
- when the user prints, he should print using the printer he selected 
yesterday


3. id for application-level drivers. For some devices you need an 
'application-level' driver. Examples are 'snapshot' buttons on webcams, the 
'scan' and 'copy' buttons on scanners and dozens of useless USB devices that 
can indicate that you have got an email (like this one: 
http://www.dytoy.com/e638.html). Most of them use a HID driver on the 
kernel-side. But they are completely useless unless there is a integration 
with the actual application, so the DE can start a scanner application when 
the user presses the 'scan' button, or a mail program can raise the flag of 
the email indicator. To do this, it is neccessary that you can get an 
identifier of the device (for a USB device, such an identifier would be bus 
identifier + vendor id + model id). Using the identifier and the /dev node 
path an 'application-level' driver could then do the functionality that the 
user expects

Use case:
- user has a scanner with a 'copy' button
- user presses the 'copy' button
- the desktop environment starts an application that scans a page and prints 
it on the default printer


4. Identify sub-devices of a compound device. Many devices have several 
sub-devices with independent drivers. For example the Philips ToUCam is a USB 
device that has a camera (V4L), microphone (OSS) and a 'snapshot' button 
(HID). It is often important for an application to know which sub-devices 
share the same physical device.

Use case:
- User has two ToUCams
- user presses the 'snapshot' button
- the camera, whose button the user pressed, makes a snapshot


bye...









-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel