[PATCH evdev] Export device node as property.

[Lennart Poettering]

On Mon, 07.02.11 23:12, Daniel Stone (daniel at 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.