[PATCH evdev] Export device node as property.

[Peter Hutterer]

On Wed, Feb 02, 2011 at 09:45:13AM +0100, Peter Korsgaard wrote:
> >>>>> "Peter" == Peter Hutterer <peter.hutterer at who-t.net> writes:
> 
> Hi Peter,
> 
> Thanks for picking this up again, I unfortunately have been busy with
> other things ..
> 
>  Peter> There is currently no mapping between XI devices and physical
>  Peter> devices other than what can be extracted by parsing the Xorg
>  Peter> logfile. Add new property "Device Node" to the driver to export
>  Peter> the open device file.
> 
>  Peter> The client is responsible for detecting if the device is on the
>  Peter> same host and converting the data into a more useful format
>  Peter> (e.g. sysfs path).
> 
>  Peter> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
>  Peter> ---
> 
>  Peter> Got poked again for this at LCA. turns out what I asked Peter to
>  Peter> do ages ago isn't actually feasable. I wanted this to be in the
>  Peter> server so the drivers can share this property without
>  Peter> re-implementation everywhere. Now, this doesn't work as the
>  Peter> server can read the 'Option "Device"' value but there's no
>  Peter> guarantee that the content of that is actually the device patch.
>  Peter> e.g. synaptics may use "auto-dev".
> 
>  Peter> So here's a re-implementation that simply sets the property to
>  Peter> the device path the driver opened. Everything else is up to the
>  Peter> client, it's quite simple to get the sysfs path from the device
>  Peter> node (about 5 lines with libudev).
> 
> 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.

the reasons why I chose the device node (after some feedback from Lennart)
were:
- the device node is the only reliable identifier we have in the driver. on
  any system, irregardless of the platform, the device node will be avaible.
- the device node can be tracked back to the configuration backend and the
  configuration. I configure devices in the xorg.conf with
  /dev/input/eventX, not through the phys.
- drivers that use multiple backends cannot rely on the phys identifier
  (e.g. synaptics) since the backend currently in use may not support it.
- /dev/input/eventX is quite simple to track back to the phys identifier in
  any client that cares about it. it takes a few lines only in a client to
  use EVIOCGPHYS and get that information on the device node received
  through the driver.
- the device node may not actually be a file at all, it could be a IP
  address (though I've heard there's a shortage of those lately ;)

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

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

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

Any comments?

Cheers,
  Peter