[PATCH evdev] Export device node as property.

[Peter Korsgaard]

>>>>> "Peter" == Peter Hutterer <peter.hutterer at who-t.net> writes:

Hi,

 >> I obviously like the concept, but this assumption basically breaks
 >> remote X. What I think we really need is a unique identifier for XI
 >> devices (to be able to reapply properties at next login), and with
 >> hotplugging, the device node isn't really a good choice.
 >> 
 >> For evdev I still think our best bet for a unique identifier is
 >> EVIOCGPHYS, like I did back then:
 >> 
 >> http://peter.korsgaard.com/patches/xorg/evdev-add-phys-property-EVIOCGPHYS-as-stable-identifer-v2.patch
 >> 
 >> E.G. use something like usb-0000:00:1d.1-1/input0 rather than
 >> /dev/input/event14.

 Peter> the reasons why I chose the device node (after some feedback
 Peter> from Lennart)

 Peter> were:

 Peter> - the device node is the only reliable identifier we have in the
 Peter>   driver. on any system, irregardless of the platform, the device
 Peter>   node will be avaible.

Also on Windows / Cygwin?

 Peter> - the device node can be tracked back to the configuration
 Peter>   backend and the configuration. I configure devices in the
 Peter>   xorg.conf with /dev/input/eventX, not through the phys.

True. But most people presumably don't hand edit xorg.conf, but rather
use gnome-mouse-preferences or whatever.

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.

Talking about unique identifiers, us having the same first name is
mighty confusing ;)

 Peter> - drivers that use multiple backends cannot rely on the phys
 Peter>   identifier (e.g. synaptics) since the backend currently in use
 Peter>   may not support it.

Ok, the drivers can naturally only do the best they can. If the best
identifier they have is the device path, then that's probably what they
should do in that case.

 Peter> - /dev/input/eventX is quite simple to track back to the phys
 Peter> identifier in any client that cares about it. it takes a few
 Peter> lines only in a client to use EVIOCGPHYS and get that
 Peter> information on the device node received through the driver.

That only works locally and if you have read permissions on the evdev
node, which normal users won't have. You could presumably still work
around it in the local case, ny finding the corresponding
/sys/class/input/event*/device/phy and/or in /proc/bus/input/devices,
but that's a bit cumbersome (and doesn't work remotely).

 Peter> - the device node may not actually be a file at all, it could be a
 Peter>   IP address (though I've heard there's a shortage of those lately
 Peter>   ;)

So you just want it to be a (hopefully) stable identifier rather than
really the device node? Fine by me, but I still think EVIOCGPHYS is a
better choice for the evdev driver.

 Peter> In regards to the remote X problem - IMO it doesn't brake
 Peter> it. The property contains the device node of the input device,
 Peter> but that may not be the same host the client runs on. The
 Peter> display string helps the client to identify the host in question
 Peter> but in the end it is up to the client that uses this information
 Peter> to test if it is running locally.

Yes, but this means that you cannot interprete it is anything else than
a opaque identifier, and not look around in /sys or open the device for
more info.

 Peter> I'm not sure how the phys identifier would help there, tbh but
 Peter> maybe I'm missing something.

I hope it's clearer now. Otherwise let me know, and I'll try to explain.

 Peter> For the hotplugging issue:

 Peter> if the client simply buffers the EVIOCGPHYS value for each
 Peter> active device, it can compare this with devices as they come and
 Peter> go. This is IMO just a question of whether these few lines
 Peter> should reside in the server/driver or in the client and I'd
 Peter> rather have the X side of things be simple.

That's good for reapplying properties if you unplug and replug a device
while the system is active, but it doesn't help getting the same
settings applied the next day when you boot your system again.

-- 
Bye, Peter Korsgaard