* Re: BoF on hotplugging - summary
2002-09-23 22:00 BoF on hotplugging - summary Oliver Neukum
@ 2002-09-23 22:14 ` Brad Hards
2002-09-23 22:58 ` Greg KH
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Brad Hards @ 2002-09-23 22:14 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 24 Sep 2002 08:00, Oliver Neukum wrote:
> - groupings of devices must be delivered
This is an important issue that might be worth expanding on.
Some of the newer devices have multiple logical "interfaces" (read this in a
loose sense, not meant to equal USB interfaces). Somethimes the device offers
all the interfaces at once, sometimes you can choose one or the other.
USB example - speakers. There is an audio interface (usually with some
selection of sampling rates, which you might consider to be a choose 1 of N
interfaces) and a HID interface (for button controlling volume, etc).
We need some way of selecting the interfaces we want, and associating them
into sensible groups (so that if I have two speakers, and a multimedia
keyboard; I can get the volume controls on each set of speakers to only
control those speakers, and the volume control keys on my keyboard to control
the built-in (PCI bus) soundcard.
This is really a policy thing, and the kernel is probably provding enough when
we have topology, but there is a lot of userspace work to be done.
> - driverfs and the input layer must be documented
I'm working on the input layer docs now.
Greg: do you know of any plans to document how userspace should use driverfs?
Thanks for writing this up Oliver.
Brad
- --
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9j5ItW6pHgIdAuOMRAli6AKCAWxa4C1hHGwOII0zXExIuSvkIwwCdGVd4
7Wa+Bl46HL2f53soQNWIRXM=OSwE
-----END PGP SIGNATURE-----
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: BoF on hotplugging - summary
2002-09-23 22:00 BoF on hotplugging - summary Oliver Neukum
2002-09-23 22:14 ` Brad Hards
@ 2002-09-23 22:58 ` Greg KH
2002-09-23 23:00 ` Greg KH
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2002-09-23 22:58 UTC (permalink / raw)
To: linux-hotplug
On Tue, Sep 24, 2002 at 08:14:05AM +1000, Brad Hards wrote:
>
> Greg: do you know of any plans to document how userspace should use driverfs?
Yes, but the people involved are madly working to get the driverfs code
finished. It wouldn't make sense to write up documents that will be
wrong at this time.
But in short, take a look at the driverfs tree right now. If there's
anything in there that doesn't make sense, please let us know.
thanks,
greg k-h
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: BoF on hotplugging - summary
2002-09-23 22:00 BoF on hotplugging - summary Oliver Neukum
2002-09-23 22:14 ` Brad Hards
2002-09-23 22:58 ` Greg KH
@ 2002-09-23 23:00 ` Greg KH
2002-09-23 23:15 ` Tim Jansen
2002-11-06 18:49 ` David Brownell
4 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2002-09-23 23:00 UTC (permalink / raw)
To: linux-hotplug
On Tue, Sep 24, 2002 at 12:00:20AM +0200, Oliver Neukum wrote:
>
> There was absolute disagreement over devfs.
> Oppinions ranged from "devfs must go away" to "hotplugging without
> devfs is obviously stupid"
devfs will be redundant soon, and probably eventually just removed from
the kernel all together. See the old threads on lkml for the reasoning
behind this statement.
Oliver, thanks for writing this up.
greg k-h
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BoF on hotplugging - summary
2002-09-23 22:00 BoF on hotplugging - summary Oliver Neukum
` (2 preceding siblings ...)
2002-09-23 23:00 ` Greg KH
@ 2002-09-23 23:15 ` Tim Jansen
2002-11-06 18:49 ` David Brownell
4 siblings, 0 replies; 6+ messages in thread
From: Tim Jansen @ 2002-09-23 23:15 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: BoF on hotplugging - summary
2002-09-23 22:00 BoF on hotplugging - summary Oliver Neukum
` (3 preceding siblings ...)
2002-09-23 23:15 ` Tim Jansen
@ 2002-11-06 18:49 ` David Brownell
4 siblings, 0 replies; 6+ messages in thread
From: David Brownell @ 2002-11-06 18:49 UTC (permalink / raw)
To: linux-hotplug
> A suggestion was made that a demon should be introduced. That was not discussed
> fully. Later discussion with the X people which are to be continued shows
> that the X people would want to introduce an X extension for device discovery
> and notification issues.
How about adding a new kind of hotplug agent: daemons
that see events delivered through a filesystem socket or
pipe, like /var/run/hotplug/input.agent? Simple to add.
Easy to integrate with, and lots of people are already
working with similar models. It'd move the X discussions
to a more useful stage: here's the device, now what? :)
I suspect few of those daemons would ever be "part of"
the hotplug system, except in terms of hearing from it
through the /var/run/hotplug/*.agent files.
> Information needed by user space:
> Items of consensus:
> - physical path and all available device ids must be delivered
I'll submit a 2.5 patch to do that for USB, which currently
does not expose that through hotplug. (PCI does.) This is a
simple thing to add to 2.4.20, too, so updated user mode tools
(that know about physical paths) wouldn't need 2.5 to run.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
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
^ permalink raw reply [flat|nested] 6+ messages in thread