On Tue, Feb 08, 2011 at 07:42:31AM +0100, Lennart Poettering wrote: > 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.
Daniel, Peter, any comments on this? Yay or nay? Cheers, Peter _______________________________________________ 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