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

Peter Hutterer peter.hutterer at who-t.net
Wed Apr 28 16:38:27 PDT 2010


On Wed, Apr 28, 2010 at 08:08:25PM +0200, Peter Korsgaard wrote:
> >>>>> "Dan" == Dan Nicholson <dbn.lists at gmail.com> writes:
> 
> Hi,
> 
>  >> 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.
> 
>  Dan> You probably could get the information from udev (DEVPATH/DEVNAME)
>  Dan> and hal (linux.sysfs_path/input.device), but I'm not sure exactly
>  Dan> how to pass that down to the driver to be associated since we
>  Dan> throw away the InputAttributes. Currently we stuff things into
>  Dan> Options, but that seems wrong. Maybe in some ABI breaking future
>  Dan> we could pass along the InputAttributes to the driver so it has
>  Dan> all that information on hand.
> 
> We do get the device node name and can get the evdev phys using the
> EVIOCGPHYS ioctl, and sysfs can be retrieved from those by lookup in
> /proc/bus/input/devices, so it's not that bad.

the "Device" option is accessible in the server. So we could init the
property's first value in the server and then let the driver add the
driver-specific string if possible.
This is kind-of needed anyway, since drivers like synaptics support
different backends and thus require different approaches.

The server basically just guarantees that the property's first value is
there.

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

I disagree here. Once the property is in a released driver, people will
start using it in scripts or other tools. Which means we have to support it
for at least some reasonable time, ending up with two properties that are
the same (but maybe have subtle differences). Property aliasing is possible
but not trivial enough to make it a mental no-op.
It also seems unnecessary when we could just do it right the first time
round.
 
Cheers,
  Peter


More information about the xorg-devel mailing list