[PATCH evdev] Export device node as property.

[Dan Nicholson]

On Wed, Feb 2, 2011 at 1:21 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 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.

Gah. Now I see it. And it's guarded here by #ifndef, so that's good.

>> 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.

Yeah, I guess you're right about that. It's probably rare that the
driver would do something different than using the device it was told,
but ultimately that's in the driver's court. It would be cool if the
server set the property by default, though.

Acked-by: Dan Nicholson <dbn.lists at gmail.com>