From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Jansen Date: Mon, 23 Sep 2002 23:15:27 +0000 Subject: Re: BoF on hotplugging - summary Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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