Re: Evdev uniq id

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 06, 2010 at 09:47:30AM -0500, Chris Bagwell wrote:
> On Sat, Nov 6, 2010 at 4:49 AM, Russell Shaw <rjshaw@xxxxxxxxxxxxxxx> wrote:
> > On 06/11/10 20:45, Dmitry Torokhov wrote:
> >>
> >> Hi Russell,
> >>
> >> On Fri, Nov 05, 2010 at 03:42:19PM +1100, Russell Shaw wrote:
> >>>
> >>> Hi,
> >>> In X, i want an application program to apply settings to a specific
> >>> mouse/puck device, regardless of how many other devices have been
> >>> plugged in since the last session.
> >>>
> >>> Prefereably, a manufacturer-model-serial_number call would be available
> >>> from evdev.
> >>>
> >>> Minimally, a uniq non-changing ID could be useful. I found this in
> >>> linux-2.6.31.1/drivers/input/evdev.c:
> >>>
> >>>   if (_IOC_NR(cmd) == _IOC_NR(EVIOCGUNIQ(0)))
> >>>     return str_to_user(dev->uniq, _IOC_SIZE(cmd), p);
> >>>
> >>> How is "dev->uniq" constructed?
> >>
> >> USB HID devices populate this field with data from
> >> descriptor.iSerialNumber.
> >> I suppose we should do that in other USB drivers as well, patches are
> >> welcome.
> >
> > Hi Dmitry.T,
> > I was just getting around to seeing if i could add manufacturer-model-
> > serial_number ioctl functionality.
> 
> I'm looking for similar feature so that X app and X driver can tell
> that inputs from two USB end points are from same device.  For config
> GUI case, unique value lets it show it as a whole device.  It would be
> best for GUI if the value lasted across reboots as well.
> 
> In my case of Wacom, the hardware does not report a serial # and it
> sounds like thats pretty common.  So I do not have a good way to
> generate this uniq string.

Yep, I think most of them do not have serial number filled in.

> 
> I guess as a fall back when uniq is empty string then the response
> from EVIOCGPHYS could be used for both our cases?  At least as long as
> users are not moving cables around.  For my case, take off the last
> ".x" value if it exists and if strings are same then its same device.

You could add heuristics to your algorithm, yes. In case where there is
only one device VID/PID is enough and you can even handle moving to
different port. Otherwise you'd have to add phys into the mix and try
matching again, hoping that the device is still plugged into the same
port.

All such schemes will fail in general case...

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux