[PATCH evdev] Export device node as property.

[Peter Hutterer]

On Wed, Feb 02, 2011 at 06:17:22AM -0800, Dan Nicholson wrote:
> On Tue, Feb 1, 2011 at 9:32 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > There is currently no mapping between XI devices and physical devices other
> > than what can be extracted by parsing the Xorg logfile. Add new property
> > "Device Node" to the driver to export the open device file.
> >
> > The client is responsible for detecting if the device is on the same host
> > and converting the data into a more useful format (e.g. sysfs path).
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> > Got poked again for this at LCA. turns out what I asked Peter to do ages
> > ago isn't actually feasable. I wanted this to be in the server so the
> > drivers can share this property without re-implementation everywhere. Now,
> > this doesn't work as the server can read the 'Option "Device"' value but
> > there's no guarantee that the content of that is actually the device patch.
> > e.g. synaptics may use "auto-dev".
> >
> > So here's a re-implementation that simply sets the property to the device
> > path the driver opened. Everything else is up to the client, it's quite
> > simple to get the sysfs path from the device node (about 5 lines with
> > libudev).
> >
> > The bit that goes in the server is the property name so we can at least
> > "standardise" on that.
> 
> Do you see it being an issue that the property name is being defined
> in evdev.h but it's intended to be generic? It seems like something
> you'd want to export from a server header if you wanted all the
> drivers to standardize.

it's defined in evdev.h so we can ship evdev (and build it :) without the
server having the define yet. I sent the matching two-line server patch out
as part of this thread. So it will be defined in the server.

> Thinking about an in-server solution, the device node is available in
> InputAttributes for hotplugged devices. I'm not sure those are still
> available by the time you want to set the property, though (you
> probably looked into this).

it comes down to the same argument. In the end the driver decides whether
the device is really the value of the device option. For a while, we had
synaptics search the nodes for event devices if the device option was
invalid (i.e. not a synaptics device). this was a bug, but it still
illustrates the point quite well.
 
Cheers,
  Peter