Evdev uniq id

Evdev uniq id

[Russell Shaw]

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?

Re: Evdev uniq id

[Dmitry Torokhov]

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.

Thanks.

-- 
Dmitry

Re: Evdev uniq id

[Russell Shaw]

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.

Re: Evdev uniq id

[Chris Bagwell]

On Sat, Nov 6, 2010 at 4:49 AM, Russell Shaw <rjshaw@netspace.net.au> 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.

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.

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

Re: Evdev uniq id

[Dmitry Torokhov]

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@netspace.net.au> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html