[PATCH evdev] Export device node as property.

[Peter Hutterer]

On Tue, Feb 08, 2011 at 07:42:31AM +0100, Lennart Poettering wrote:
> 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.

Daniel, Peter, any comments on this? Yay or nay?

Cheers,
  Peter