>>>>> "Peter" == Peter Hutterer <peter.hutte...@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 _______________________________________________ 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
