[PATCH] evdev: add phys property (EVIOCGPHYS) as stable identifier

[Dan Nicholson]

On Tue, Apr 27, 2010 at 7:04 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Mon, Apr 26, 2010 at 09:33:16PM +0200, Peter Korsgaard wrote:
>> xinput ids are not guaranteed to be stable between reboots (or hotplugs),
>> so add a "Evdev physical" property containing the output of the
>> EVIOCGPHYS ioctl as a stable identifier. This is needed to be able to
>> apply device-specific parameters at runtime (E.G. touchscreen
>> transformation in multi-head setups).
>>
>> EVIOCGPHYS is used rather than E.G. the device node or sysfs path,
>> as it is (supposed to be) unique, simple to access and the remaining
>> information can be retrieved through /proc/bus/input/devices, which
>> doesn't require any special privileges.
>>
>> Signed-off-by: Peter Korsgaard <peter.korsgaard at barco.com>
>> ---
>>  include/evdev-properties.h |    3 +++
>>  src/evdev.c                |   16 ++++++++++++++--
>>  2 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/evdev-properties.h b/include/evdev-properties.h
>> index 7df2876..6ab42b3 100644
>> --- a/include/evdev-properties.h
>> +++ b/include/evdev-properties.h
>> @@ -66,4 +66,7 @@
>>  /* BOOL */
>>  #define EVDEV_PROP_SWAP_AXES "Evdev Axes Swap"
>>
>> +/* Physical location of input device as defined by the kernel */
>> +#define EVDEV_PROP_PHYSICAL "Evdev Physical"
>> +
>
> Please name this "Evdev Physical Path".
>
> I'm also wondering if we should make this a two-string property to export
> the "Device" option and the Phys path at the same time. especially for
> xorg.conf settings, there is no mapping between what had a given device path
> and what had a phys.
>
> Which also brings us to the question of whether this should be implemented
> in the server instead then? I'm sure the other drivers could benefit from
> this as well.

You probably could get the information from udev (DEVPATH/DEVNAME) and
hal (linux.sysfs_path/input.device), but I'm not sure exactly how to
pass that down to the driver to be associated since we throw away the
InputAttributes. Currently we stuff things into Options, but that
seems wrong. Maybe in some ABI breaking future we could pass along the
InputAttributes to the driver so it has all that information on hand.

That's kind of orthogonal to this issue, though. It seems you could
carry the driver specific property for now until a server level
solution could be built up.

--
Dan