On Wed, Apr 28, 2010 at 08:08:25PM +0200, Peter Korsgaard wrote: > >>>>> "Dan" == Dan Nicholson <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
