mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Melchior FRANZ <melchior.franz@gmail.com>
Cc: linux-input@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Dima Zavin <dmitriyz@google.com>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Amit Kucheria <amit.kucheria@verdurent.com>,
	Jean Delvare <khali@linux-fr.org>, Greg KH <greg@kroah.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-iio@vger.kernel.org
Subject: Re: [BUG?] hid-core.c: hid->name = dev->manufacturer + dev->product ... why not + dev->serial?
Date: Tue, 9 Mar 2010 00:22:16 -0800	[thread overview]
Message-ID: <20100309082216.GG17288@core.coreip.homeip.net> (raw)
In-Reply-To: <201003071655.06644@rk-nord.at>

Hi Melchior,

I'm adding a few CCs and takinng discussion a bit away from your patch
;)

On Sun, Mar 07, 2010 at 04:55:06PM +0100, Melchior FRANZ wrote:
> Hi,
> 
> just recently I purchased two data acquisition HID devices that pretend to be
> joysticks[1], because that way no special kernel drivers are required, and
> because they are usually used for joystick-like purposes. The devices identify
> themselves as
> 
>   idVendor           0x16c0
>   idProduct          0x05ba 
>   iManufacturer      1 Leo Bodnar
>   iProduct           2 BU0836A Interface
>   iSerial            3 A10123
> 
> The Linux kernel creates the HID/"joystick name" from only iManufacturer and
> iProduct, ignoring iSerial. That way, JSIOCGNAME returns the same string
> for all such devices, making an actual identification impossible.
> joystick-api.txt says about JSIOCGNAME:
> 
>   #define JSIOCGNAME(len) /* get identifier string        char    */
>   ...
>   JSIOCGNAME(len) allows you to get the name string of the joystick
> 
> But this isn't actually true. "Leo Bodnar BU0836A Interface" is only
> the name of the product, but not of the actual (joystick or whatever)
> device. If you have more of these devices on the bus, then software has
> no way to know which is which -- which is the one with the temperature
> sensor on axis 0 etc. (Apart from doing all the USB querying itself,
> of course.)
> 

This is nicely illustrates one of the reasons why input subsystem is
ill-suited for generic data acquisition. I call it "device anonymity" -
input subsystem only interested in the type of event (ABS_X, ABS_Y) but
not necessarily the device it came from. You may have 2 joysticks and
prefer to use one in one game and other in another game. With default
setup you could grab either one and start playing, ABS_X from either
mapping on horizontal movements, ABS_Y on vertical... Same with
keyboards - you plug an external keyboard into laptop and you just start
typing (sans multi-seat setups that we don't support well at the
moment). In other words for input we care very much about capabilities
of a device but care much less about the device itself.

Which data acquisition you care not only about hypothetical
ABS_TEMPERATIRE event but it is also _very_ important the exact device
or probe the data is coming from. Temperature from device A can't be
used in place of temperature form device B.

> The patch below fixed the problem for me. But, certainly, the current
> (mis)behaviour wasn't an accident, but intentional. But what was the
> intention? What happens if I attach two actual identical joysticks?
> What's the purpose of them having the same name on the system under
> /dev/input/{js,event}? 

They will have different event nodes.

> Not even two (human) identical twins have the
> same first name, and for a reason!
> 

But you as an observer have no idea what their names are, and they look the
same to you. And in case of joysticks ther serials are not easily
visible on them when you quickly grab one.

Nevertheless serials are exported in sysfs ('uniq' attribute). Also udev
can give persistent names device nodes based on physocal connection,
serial numbers, etc.

-- 
Dmitry

       reply	other threads:[~2010-03-09  8:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201003071655.06644@rk-nord.at>
2010-03-09  8:22 ` Dmitry Torokhov [this message]
2010-03-09 12:42   ` Melchior FRANZ
2010-03-09 18:41     ` Dmitry Torokhov
2010-03-09 18:52       ` Melchior FRANZ
2010-03-09 18:57         ` Dmitry Torokhov

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=20100309082216.GG17288@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=amit.kucheria@verdurent.com \
    --cc=dmitriyz@google.com \
    --cc=greg@kroah.com \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=melchior.franz@gmail.com \
    --cc=rui.zhang@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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

all inboxes | Powered by JetHome®