On Mon, 07.02.11 23:12, Daniel Stone (dan...@fooishbar.org) wrote: > Hi, > > On Tue, Feb 08, 2011 at 08:32:16AM +1000, Peter Hutterer wrote: > > CC'ing Lennart, he can contribute more details I supposed. > > > > On Mon, Feb 07, 2011 at 08:58:22AM +1000, Daniel Stone wrote: > > > On Wed, Feb 02, 2011 at 03:32:54PM +1000, Peter Hutterer wrote: > > > > There is currently no mapping between XI devices and physical devices > > > > other > > > > than what can be extracted by parsing the Xorg logfile. Add new property > > > > "Device Node" to the driver to export the open device file. > > > > > > > > The client is responsible for detecting if the device is on the same > > > > host > > > > and converting the data into a more useful format (e.g. sysfs path). > > > > > > So, er, why? > > > > We expose a few features of the physical device through the X driver, but > > other information is available only through the kernel directly. There is no > > way of associating an input device with the X device it spawned off short of > > parsing the X.log. > > To be honest, it's not really the sort of thing I want to encourage; is > there anything in particular missing from Xi 2.1? Telling clients to > just mix and match the two and hope they haven't screwed up local vs. > remote, et al, sounds a tad unfortunate. Not to mention that they > probably don't have access to the devices.
For a long time we wanted to be able to match up X input devices such as the HID keyboards built into USB speakers or USB headsets with their particular sound cards, so that pressing the volume button on the device actually changes the volume on that one device instead of whatever has been chosen as the "default sound card". XI2 now finally allows us to track from which input device an input event came, but we don't have any way to then somehow match this up with a specific audio device although sysfs and the information exposed by the kernel would actually allow us to do that. A volume applet would use this information as a hint only: if no matching device is found (which is the very likely default case for the vol knobs on most mm keyboards) it would silently fall back to the current algorithm of just using the default device. Similar use cases exist for the various other USB devices which combine HID keyboards with some other functionality: USB scanners with a "scan now" button, webcams with a "take photo" button, rfkill key events, jack events, brightness keys, ... (of course, some of these would probably be handled better by code accessing the linux input layer directly, but at least the usb scanner, webcam and audio keys really should be routed through X) And there are more uses: it would be a good idea to be able to trace back the yubikey keypresses to the yubikey used, and then issue additional commands to it, and also know that those keys are primarily useful in the context of authentication. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
