[PATCH evdev] Export device node as property.

[Peter Hutterer]

On Fri, Feb 04, 2011 at 02:17:18PM +0100, Peter Korsgaard wrote:
> >>>>> "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?

Well, the above is true for the xfree86 DDX only. xnest, xwin, XQuartz can't
do it since they don't have devices in the same manner. 

having said that, it's not the case for all devices anyway, e.g. XTest
devices do not have a device node attached to them so the property is
optional anyway.

as for the rest - different use cases as said elsewhere in the thread so we
should be looking at two different properties.

Cheers,
  Peter

 
>  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