From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Chris Bagwell <chris@cnpbagwell.com>
Cc: Russell Shaw <rjshaw@netspace.net.au>,
linux-input <linux-input@vger.kernel.org>
Subject: Re: Evdev uniq id
Date: Sat, 6 Nov 2010 08:39:24 -0700 [thread overview]
Message-ID: <20101106153924.GA17780@core.coreip.homeip.net> (raw)
In-Reply-To: <AANLkTi=HUAPfy=OChB+TqYmF8k_YkbzNionAzWK7NSYH@mail.gmail.com>
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
prev parent reply other threads:[~2010-11-06 15:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 4:42 Evdev uniq id Russell Shaw
2010-11-06 9:45 ` Dmitry Torokhov
2010-11-06 9:49 ` Russell Shaw
2010-11-06 14:47 ` Chris Bagwell
2010-11-06 15:39 ` Dmitry Torokhov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101106153924.GA17780@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=chris@cnpbagwell.com \
--cc=linux-input@vger.kernel.org \
--cc=rjshaw@netspace.net.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).