On Fri, Feb 4, 2011 at 6:24 AM, Peter Korsgaard <jac...@sunsite.dk> wrote: >>>>>> "Dan" == Dan Nicholson <dbn.li...@gmail.com> writes: > > Hi, > > >> The question is perhaps what the use case for this property is? To > >> easily figure out what xinput id corresponds to a config entry in > >> xorg.conf? The reason I wanted the property was slightly different. As > >> the xinput ids are not stable, I wanted a stable identifier so I can > >> reapply xinput settings at login time (E.G. for the coordinate > >> transformation matrix for multihead touchscreens) through > >> gnome-settings-daemon, similar to how it does for the xrandr setup. > > Dan> Maybe another property is needed to satisfy that. What about "Device > Dan> UID", which is string setup by the driver. On evdev, it uses > Dan> EVIOCGPHYS, but it's up to the driver since it has the most details > Dan> about the device. > > That's fine by me as well. > > Dan> I still think "Device Node" is useful, but I see your point about > Dan> needing a unique identifier. Then gnome-settings-daemon can look > Dan> at the combination of DISPLAY hostname and "Device UID" to know > Dan> which cached settings to grab. > > What is the use case about 'Device Node'? Purely informational like I > mentioned above, or is there another need for it?
I think informational, but as Peter H. mentioned, mapping from xinput output to actual device node can be pretty useful. Arguably if you have EVIOCGPHYS, you can look in /proc/bus/input/devices and map back to device node, but I think what people typically want is the device node. -- Dan _______________________________________________ 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