Bug 13411 - Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Input Devices
All Linux
: P1 normal
Assigned To: drivers_input-devices
:
Depends on:
Blocks: 12398
  Show dependency treegraph
 
Reported: 2009-05-31 12:21 UTC by Guido
Modified: 2010-10-07 17:35 UTC (History)
6 users (show)

See Also:
Kernel Version: >= 2.6.28
Tree: Mainline
Regression: Yes


Attachments
Additional information (lsusb, lspci, ioports, iomem, kernel configs) (155.06 KB, text/plain)
2009-05-31 12:21 UTC, Guido
Details
lsusb -vv for a CMP-BARSCAN30 (5.54 KB, text/plain)
2009-11-27 08:13 UTC, Baguette Sébastien
Details

Description Guido 2009-05-31 12:21:57 UTC
Created attachment 21656 [details]
Additional information (lsusb, lspci, ioports, iomem, kernel configs)

My König CMP-BARSCAN 10 (being reported as ID 1130:0001 Tenx Technology, Inc.) stopped working in kernels upwards from 2.6.28. I'm running a Gentoo 64-bits system. 

The device is still being detected, however, no input-node is being created. Dmesg reports (under a 2.6.28 kernel):

usb 6-2: new low speed USB device using uhci_hcd and address 2
usb 6-2: configuration #1 chosen from 1 choice
usb 6-2: New USB device found, idVendor=1130, idProduct=0001
usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 62: Product: USB-TMU


Under 2.6.27.24 it does work as expected. Dmesg reports:

usb 6-2: new low speed USB device using uhci_hcd and address 2
usb 6-2: configuration #1 chosen from 1 choice
input: USB-TMU as /class/input/input6
input: USB HID v1.10 Keyboard [USB-TMU] on usb-0000:00:1d.0-2
usb 6-2: New USB device found, idVendor=1130, idProduct=0001
usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 6-2: Product: USB-TMU


Trying several kernels, I can conclude the following:

2.6.25-Gentoo-r9     --> Works
2.6.27-Gentoo-r8     --> Works
2.6.28-Gentoo-r5     --> Broken

2.6.27.10 (Vanilla)  --> Works
2.6.27.24 (Vanilla)  --> Works
2.6.28 (Vanilla)     --> Broken
2.6.28.9 (Vanilla)   --> Broken
2.6.29.4 (Vanilla)   --> Broken
2.6.30 RC7 (Vanilla) --> Broken


Additional information is attached in the attached text file, containing:
* lsusb -vv output
* Kernel 2.6.27 configuration
* Kernel 2.6.29 configuration
* /proc/ioports
* /proc/iomem
* lspci -vvv
Comment 1 Andrew Morton 2009-06-02 03:25:12 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Sun, 31 May 2009 12:21:58 GMT bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=13411
> 
>            Summary: Barscanner (USB HID Keyboard) stopped functioning in
>                     kernels >= 2.6.28
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: >= 2.6.28
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Input Devices
>         AssignedTo: drivers_input-devices@kernel-bugs.osdl.org
>         ReportedBy: bugzilla.kernel.org@starbase12.cjb.net
>         Regression: Yes

Does anyone want to claim this regression?  USB, HID or Input??

Thanks.

> 
> Created an attachment (id=21656)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=21656)
> Additional information (lsusb, lspci, ioports, iomem, kernel configs)
> 
> My K__nig CMP-BARSCAN 10 (being reported as ID 1130:0001 Tenx Technology, Inc.)
> stopped working in kernels upwards from 2.6.28. I'm running a Gentoo 64-bits
> system. 
> 
> The device is still being detected, however, no input-node is being created.
> Dmesg reports (under a 2.6.28 kernel):
> 
> usb 6-2: new low speed USB device using uhci_hcd and address 2
> usb 6-2: configuration #1 chosen from 1 choice
> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> usb 62: Product: USB-TMU
> 
> 
> Under 2.6.27.24 it does work as expected. Dmesg reports:
> 
> usb 6-2: new low speed USB device using uhci_hcd and address 2
> usb 6-2: configuration #1 chosen from 1 choice
> input: USB-TMU as /class/input/input6
> input: USB HID v1.10 Keyboard [USB-TMU] on usb-0000:00:1d.0-2
> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> usb 6-2: Product: USB-TMU
> 
> 
> Trying several kernels, I can conclude the following:
> 
> 2.6.25-Gentoo-r9     --> Works
> 2.6.27-Gentoo-r8     --> Works
> 2.6.28-Gentoo-r5     --> Broken
> 
> 2.6.27.10 (Vanilla)  --> Works
> 2.6.27.24 (Vanilla)  --> Works
> 2.6.28 (Vanilla)     --> Broken
> 2.6.28.9 (Vanilla)   --> Broken
> 2.6.29.4 (Vanilla)   --> Broken
> 2.6.30 RC7 (Vanilla) --> Broken
> 
> 
> Additional information is attached in the attached text file, containing:
> * lsusb -vv output
> * Kernel 2.6.27 configuration
> * Kernel 2.6.29 configuration
> * /proc/ioports
> * /proc/iomem
> * lspci -vvv
Comment 2 Maximiliano Castañón 2009-06-02 03:44:50 UTC
hi, is possible because this is not on usbtutils?
i was looking the usbutils, but only this:
1130  Tenx Technology, Inc.
	f211  audio headset

  idVendor           0x1130 Tenx Technology, Inc.
  idProduct          0x0001

can be possible that?


i found this, maybe can help you.
http://lkml.org/lkml/2009/2/10/434

2009/6/1, Andrew Morton <akpm@linux-foundation.org>:
>
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Sun, 31 May 2009 12:21:58 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13411
>>
>>            Summary: Barscanner (USB HID Keyboard) stopped functioning in
>>                     kernels >= 2.6.28
>>            Product: Drivers
>>            Version: 2.5
>>     Kernel Version: >= 2.6.28
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: Input Devices
>>         AssignedTo: drivers_input-devices@kernel-bugs.osdl.org
>>         ReportedBy: bugzilla.kernel.org@starbase12.cjb.net
>>         Regression: Yes
>
> Does anyone want to claim this regression?  USB, HID or Input??
>
> Thanks.
>
>>
>> Created an attachment (id=21656)
>>  --> (http://bugzilla.kernel.org/attachment.cgi?id=21656)
>> Additional information (lsusb, lspci, ioports, iomem, kernel configs)
>>
>> My K__nig CMP-BARSCAN 10 (being reported as ID 1130:0001 Tenx Technology,
>> Inc.)
>> stopped working in kernels upwards from 2.6.28. I'm running a Gentoo
>> 64-bits
>> system.
>>
>> The device is still being detected, however, no input-node is being
>> created.
>> Dmesg reports (under a 2.6.28 kernel):
>>
>> usb 6-2: new low speed USB device using uhci_hcd and address 2
>> usb 6-2: configuration #1 chosen from 1 choice
>> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
>> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>> usb 62: Product: USB-TMU
>>
>>
>> Under 2.6.27.24 it does work as expected. Dmesg reports:
>>
>> usb 6-2: new low speed USB device using uhci_hcd and address 2
>> usb 6-2: configuration #1 chosen from 1 choice
>> input: USB-TMU as /class/input/input6
>> input: USB HID v1.10 Keyboard [USB-TMU] on usb-0000:00:1d.0-2
>> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
>> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>> usb 6-2: Product: USB-TMU
>>
>>
>> Trying several kernels, I can conclude the following:
>>
>> 2.6.25-Gentoo-r9     --> Works
>> 2.6.27-Gentoo-r8     --> Works
>> 2.6.28-Gentoo-r5     --> Broken
>>
>> 2.6.27.10 (Vanilla)  --> Works
>> 2.6.27.24 (Vanilla)  --> Works
>> 2.6.28 (Vanilla)     --> Broken
>> 2.6.28.9 (Vanilla)   --> Broken
>> 2.6.29.4 (Vanilla)   --> Broken
>> 2.6.30 RC7 (Vanilla) --> Broken
>>
>>
>> Additional information is attached in the attached text file, containing:
>> * lsusb -vv output
>> * Kernel 2.6.27 configuration
>> * Kernel 2.6.29 configuration
>> * /proc/ioports
>> * /proc/iomem
>> * lspci -vvv
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Comment 3 Anonymous Emailer 2009-06-02 09:56:07 UTC
Reply-To: jkosina@suse.cz

On Mon, 1 Jun 2009, Andrew Morton wrote:

> > My K__nig CMP-BARSCAN 10 (being reported as ID 1130:0001 Tenx Technology, Inc.)
> > stopped working in kernels upwards from 2.6.28. I'm running a Gentoo 64-bits
> > system. 
> > 
> > The device is still being detected, however, no input-node is being created.
> > Dmesg reports (under a 2.6.28 kernel):
> > 
> > usb 6-2: new low speed USB device using uhci_hcd and address 2
> > usb 6-2: configuration #1 chosen from 1 choice
> > usb 6-2: New USB device found, idVendor=1130, idProduct=0001
> > usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > usb 62: Product: USB-TMU
> > 
> > 
> > Under 2.6.27.24 it does work as expected. Dmesg reports:
> > 
> > usb 6-2: new low speed USB device using uhci_hcd and address 2
> > usb 6-2: configuration #1 chosen from 1 choice
> > input: USB-TMU as /class/input/input6
> > input: USB HID v1.10 Keyboard [USB-TMU] on usb-0000:00:1d.0-2
> > usb 6-2: New USB device found, idVendor=1130, idProduct=0001
> > usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > usb 6-2: Product: USB-TMU

This is almost certainly because of this commit:

	commit d1d3a5f6eaee337d793ab9ac28e696f0262c3c8a
	Author: Remi Cattiau <remi@cattiau.com>
	Date:   Tue Sep 9 01:39:33 2008 +0200

	    HID: ignore iBuddy devices

	    iBuddy devices claim to be HID devices, but they are not.
	    Add them to the blacklist.

	    Signed-off-by: Remi Cattiau <remi@cattiau.com>
	    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

The problem apparently [1] is, that the vendor has been super-creative and 
assigned the same combination of idVendor/idProduct to completely 
different devices. Oh well.

Remi, could you please check your device against the lsusb data provided 
in bugzilla to check whether there is any possibility to distinguish these 
devices, so that we could put some ugly check in place probably?

Thanks.

[1] http://lkml.org/lkml/2009/2/10/434
Comment 4 Anonymous Emailer 2009-06-02 10:20:21 UTC
Reply-To: paulius.zaleckas@teltonika.lt

Maximi89 wrote:
> hi, is possible because this is not on usbtutils?
> i was looking the usbutils, but only this:
> 1130  Tenx Technology, Inc.
> 	f211  audio headset
> 
>   idVendor           0x1130 Tenx Technology, Inc.
>   idProduct          0x0001
> 
> can be possible that?
> 
> 
> i found this, maybe can help you.
> http://lkml.org/lkml/2009/2/10/434

Yes, this device is defined in hid_ignore_list[] (drivers/hid/hid-core.c)
 
> 2009/6/1, Andrew Morton <akpm@linux-foundation.org>:
>> (switched to email.  Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Sun, 31 May 2009 12:21:58 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=13411
>>>
>>>            Summary: Barscanner (USB HID Keyboard) stopped functioning in
>>>                     kernels >= 2.6.28
>>>            Product: Drivers
>>>            Version: 2.5
>>>     Kernel Version: >= 2.6.28
>>>           Platform: All
>>>         OS/Version: Linux
>>>               Tree: Mainline
>>>             Status: NEW
>>>           Severity: normal
>>>           Priority: P1
>>>          Component: Input Devices
>>>         AssignedTo: drivers_input-devices@kernel-bugs.osdl.org
>>>         ReportedBy: bugzilla.kernel.org@starbase12.cjb.net
>>>         Regression: Yes
>> Does anyone want to claim this regression?  USB, HID or Input??
>>
>> Thanks.
>>
>>> Created an attachment (id=21656)
>>>  --> (http://bugzilla.kernel.org/attachment.cgi?id=21656)
>>> Additional information (lsusb, lspci, ioports, iomem, kernel configs)
>>>
>>> My K__nig CMP-BARSCAN 10 (being reported as ID 1130:0001 Tenx Technology,
>>> Inc.)
>>> stopped working in kernels upwards from 2.6.28. I'm running a Gentoo
>>> 64-bits
>>> system.
>>>
>>> The device is still being detected, however, no input-node is being
>>> created.
>>> Dmesg reports (under a 2.6.28 kernel):
>>>
>>> usb 6-2: new low speed USB device using uhci_hcd and address 2
>>> usb 6-2: configuration #1 chosen from 1 choice
>>> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
>>> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>>> usb 62: Product: USB-TMU
>>>
>>>
>>> Under 2.6.27.24 it does work as expected. Dmesg reports:
>>>
>>> usb 6-2: new low speed USB device using uhci_hcd and address 2
>>> usb 6-2: configuration #1 chosen from 1 choice
>>> input: USB-TMU as /class/input/input6
>>> input: USB HID v1.10 Keyboard [USB-TMU] on usb-0000:00:1d.0-2
>>> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
>>> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>>> usb 6-2: Product: USB-TMU
>>>
>>>
>>> Trying several kernels, I can conclude the following:
>>>
>>> 2.6.25-Gentoo-r9     --> Works
>>> 2.6.27-Gentoo-r8     --> Works
>>> 2.6.28-Gentoo-r5     --> Broken
>>>
>>> 2.6.27.10 (Vanilla)  --> Works
>>> 2.6.27.24 (Vanilla)  --> Works
>>> 2.6.28 (Vanilla)     --> Broken
>>> 2.6.28.9 (Vanilla)   --> Broken
>>> 2.6.29.4 (Vanilla)   --> Broken
>>> 2.6.30 RC7 (Vanilla) --> Broken
>>>
>>>
>>> Additional information is attached in the attached text file, containing:
>>> * lsusb -vv output
>>> * Kernel 2.6.27 configuration
>>> * Kernel 2.6.29 configuration
>>> * /proc/ioports
>>> * /proc/iomem
>>> * lspci -vvv
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
>
Comment 5 Anonymous Emailer 2009-06-02 10:20:22 UTC
Reply-To: paulius.zaleckas@teltonika.lt

Maximi89 wrote:
> hi, is possible because this is not on usbtutils?
> i was looking the usbutils, but only this:
> 1130  Tenx Technology, Inc.
> 	f211  audio headset
> 
>   idVendor           0x1130 Tenx Technology, Inc.
>   idProduct          0x0001
> 
> can be possible that?
> 
> 
> i found this, maybe can help you.
> http://lkml.org/lkml/2009/2/10/434

Yes, this device is defined in hid_ignore_list[] (drivers/hid/hid-core.c)
 
> 2009/6/1, Andrew Morton <akpm@linux-foundation.org>:
>> (switched to email.  Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Sun, 31 May 2009 12:21:58 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=13411
>>>
>>>            Summary: Barscanner (USB HID Keyboard) stopped functioning in
>>>                     kernels >= 2.6.28
>>>            Product: Drivers
>>>            Version: 2.5
>>>     Kernel Version: >= 2.6.28
>>>           Platform: All
>>>         OS/Version: Linux
>>>               Tree: Mainline
>>>             Status: NEW
>>>           Severity: normal
>>>           Priority: P1
>>>          Component: Input Devices
>>>         AssignedTo: drivers_input-devices@kernel-bugs.osdl.org
>>>         ReportedBy: bugzilla.kernel.org@starbase12.cjb.net
>>>         Regression: Yes
>> Does anyone want to claim this regression?  USB, HID or Input??
>>
>> Thanks.
>>
>>> Created an attachment (id=21656)
>>>  --> (http://bugzilla.kernel.org/attachment.cgi?id=21656)
>>> Additional information (lsusb, lspci, ioports, iomem, kernel configs)
>>>
>>> My K__nig CMP-BARSCAN 10 (being reported as ID 1130:0001 Tenx Technology,
>>> Inc.)
>>> stopped working in kernels upwards from 2.6.28. I'm running a Gentoo
>>> 64-bits
>>> system.
>>>
>>> The device is still being detected, however, no input-node is being
>>> created.
>>> Dmesg reports (under a 2.6.28 kernel):
>>>
>>> usb 6-2: new low speed USB device using uhci_hcd and address 2
>>> usb 6-2: configuration #1 chosen from 1 choice
>>> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
>>> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>>> usb 62: Product: USB-TMU
>>>
>>>
>>> Under 2.6.27.24 it does work as expected. Dmesg reports:
>>>
>>> usb 6-2: new low speed USB device using uhci_hcd and address 2
>>> usb 6-2: configuration #1 chosen from 1 choice
>>> input: USB-TMU as /class/input/input6
>>> input: USB HID v1.10 Keyboard [USB-TMU] on usb-0000:00:1d.0-2
>>> usb 6-2: New USB device found, idVendor=1130, idProduct=0001
>>> usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>>> usb 6-2: Product: USB-TMU
>>>
>>>
>>> Trying several kernels, I can conclude the following:
>>>
>>> 2.6.25-Gentoo-r9     --> Works
>>> 2.6.27-Gentoo-r8     --> Works
>>> 2.6.28-Gentoo-r5     --> Broken
>>>
>>> 2.6.27.10 (Vanilla)  --> Works
>>> 2.6.27.24 (Vanilla)  --> Works
>>> 2.6.28 (Vanilla)     --> Broken
>>> 2.6.28.9 (Vanilla)   --> Broken
>>> 2.6.29.4 (Vanilla)   --> Broken
>>> 2.6.30 RC7 (Vanilla) --> Broken
>>>
>>>
>>> Additional information is attached in the attached text file, containing:
>>> * lsusb -vv output
>>> * Kernel 2.6.27 configuration
>>> * Kernel 2.6.29 configuration
>>> * /proc/ioports
>>> * /proc/iomem
>>> * lspci -vvv
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
>
Comment 6 Rafael J. Wysocki 2009-06-08 11:36:56 UTC
On Monday 08 June 2009, Jiri Kosina wrote:
> On Sun, 7 Jun 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13411
> > Subject		: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
> > Submitter	: Guido <bugzilla.kernel.org@starbase12.cjb.net>
> > Date		: 2009-05-31 12:21 (8 days old)
> 
> This is apparently caused by vendor releasing two different hardware 
> products under the same VID/PID and just one of them needing blacklist 
> entry. Sigh.
> 
> Waiting for verbose lsusb output from Remi, so that we could compare it 
> with the output provided by the bug reporter, to see what else could be 
> done to distinguish the devices from each other.
Comment 7 Martin Hohenberg 2009-07-14 10:57:59 UTC
Problem started today after upgrade, with a no-name barcode scanner, lsusb output follows ...

martin@mizar:~$ lsusb
Bus 002 Device 004: ID 1130:0001 Tenx Technology, Inc.

Is there any quick 'n dirty fix for this?
Comment 8 Hadmut Danisch 2009-10-18 11:03:03 UTC
Hi, 

any chance to fix this ?

regards
Comment 9 Baguette Sébastien 2009-11-27 08:12:49 UTC
Hi !

We just bought here some CMP-BARSCAN30, which is also concerned by this regression. The (double) verbose is added as an attachment.

If Mr Cattiau didn't sent his lsusb information, shouldn't we remove this device from the blacklist, and add it again when we have more information ? This bug is open for a quite long time, now.

Regards,

Baguette Sébastien
Comment 10 Baguette Sébastien 2009-11-27 08:13:35 UTC
Created attachment 23964 [details]
lsusb -vv for a CMP-BARSCAN30
Comment 11 Guido 2009-11-28 21:51:53 UTC
Op dinsdag 2 juni 2009 11:55:51 schreef Jiri Kosina:
> This is almost certainly because of this commit:
> 
> 	commit d1d3a5f6eaee337d793ab9ac28e696f0262c3c8a
> 	Author: Remi Cattiau <remi@cattiau.com>
> 	Date:   Tue Sep 9 01:39:33 2008 +0200
> 
> 	    HID: ignore iBuddy devices
> 
> 	    iBuddy devices claim to be HID devices, but they are not.
> 	    Add them to the blacklist.
> 
> 	    Signed-off-by: Remi Cattiau <remi@cattiau.com>
> 	    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> The problem apparently [1] is, that the vendor has been super-creative and
> assigned the same combination of idVendor/idProduct to completely
> different devices. Oh well.
> 
> Remi, could you please check your device against the lsusb data provided
> in bugzilla to check whether there is any possibility to distinguish these
> devices, so that we could put some ugly check in place probably?
> 
> Thanks.
> 
> [1] http://lkml.org/lkml/2009/2/10/434
> 

Hi all,
 
A belated thanks for having pointed me into the right direction to get my 
barcodescanner operational. However, as a thought since the bug is still 
present, why not solve it with something as simple as making the blacklisting 
user-configurable instead of blacklisting valid HID devices on purpose?

As an example of what I mean:


diff -urNb drivers/hid/hid-core.c drivers/hid/hid-core.c
--- drivers/hid/hid-core.c      2009-10-17 22:22:12.589447000 +0200
+++ drivers/hid/hid-core.c      2009-10-17 23:01:38.130911398 +0200
@@ -1627,7 +1627,9 @@
        { HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, 
USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3) },
        { HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, 
USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4) },
        { HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, 
USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5) },
+#if defined(CONFIG_HID_BLACKLIST_TENX_IBUDDY)
        { HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY1) },
        { HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY2) },
+#endif
        { HID_USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LABPRO) 
},
        { HID_USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_GOTEMP) 
},
diff -urNb drivers/hid/Kconfig drivers/hid/Kconfig
--- drivers/hid/Kconfig 2009-09-10 00:13:59.000000000 +0200
+++ drivers/hid/Kconfig 2009-10-17 23:04:23.538908607 +0200
@@ -31,6 +31,24 @@

          If unsure, say Y.

+config HID_BLACKLIST_TENX_IBUDDY
+       bool "Blacklist i-Buddy devices"
+       depends on HID
+       default n
+       ---help---
+       Barcode scanners using idVendor 1130 and idProduct 0001 were 
blacklisted
+       at the HID core level per September 9, 01:39:33, 2008. This because
+       i-Buddy devices claim to be HID devices, while not being so.
+       Unfortunately, the vendor has been super-creative and assigned the 
same
+       combination of idVendor/idProduct to completely different devices. 
Therefore,
+       blacklisting the i-Buddy as a HID device also blacklists several 
brands of
+       barcode scanners. Since blacklisting the i-Buddy by default will mean
+       blacklisting valid HID devices as well, it is now a configurable 
option.
+
+       If unsure, say N.
+       Unless of course you own an i-Buddy, say Y.
+
+
 config HID_DEBUG
        bool "HID debugging support"
        default y


Just my two cents for getting a working solution. :)

Tnx,
Regards,

Guido
Comment 12 Anonymous Emailer 2009-12-01 10:41:02 UTC
Reply-To: jkosina@suse.cz

On Sat, 28 Nov 2009, Guido Dorssers wrote:

> > The problem apparently [1] is, that the vendor has been super-creative and
> > assigned the same combination of idVendor/idProduct to completely
> > different devices. Oh well.
> > 
> > Remi, could you please check your device against the lsusb data provided
> > in bugzilla to check whether there is any possibility to distinguish these
> > devices, so that we could put some ugly check in place probably?
> > 
> > Thanks.
> > 
> > [1] http://lkml.org/lkml/2009/2/10/434
> > 
> 
> Hi all,
>  
> A belated thanks for having pointed me into the right direction to get my 
> barcodescanner operational. However, as a thought since the bug is still 
> present, why not solve it with something as simple as making the blacklisting 
> user-configurable instead of blacklisting valid HID devices on purpose?

Hi,

actually, my current plan is to remove the blacklist entry for this 
combination of VID/PID completely, and let the user decide and unbind the 
driver via sysfs eventually, if needed (maybe together with warning in 
dmesg).

As the vendor apparently messed up horribly, as far as I understand, I 
don't really see another option.
Comment 13 Anonymous Emailer 2009-12-01 11:04:23 UTC
Reply-To: remi@cattiau.com

I'll be @ home in 10 hours i'll check but it seems very ugly from thoses 
manufacturers. We may find a official list from some authorities about 
that no ?

Rémi

Le 01/12/2009 11:40, Jiri Kosina a écrit :
> On Sat, 28 Nov 2009, Guido Dorssers wrote:
>
>    
>>> The problem apparently [1] is, that the vendor has been super-creative and
>>> assigned the same combination of idVendor/idProduct to completely
>>> different devices. Oh well.
>>>
>>> Remi, could you please check your device against the lsusb data provided
>>> in bugzilla to check whether there is any possibility to distinguish these
>>> devices, so that we could put some ugly check in place probably?
>>>
>>> Thanks.
>>>
>>> [1] http://lkml.org/lkml/2009/2/10/434
>>>
>>>        
>> Hi all,
>>
>> A belated thanks for having pointed me into the right direction to get my
>> barcodescanner operational. However, as a thought since the bug is still
>> present, why not solve it with something as simple as making the blacklisting
>> user-configurable instead of blacklisting valid HID devices on purpose?
>>      
> Hi,
>
> actually, my current plan is to remove the blacklist entry for this
> combination of VID/PID completely, and let the user decide and unbind the
> driver via sysfs eventually, if needed (maybe together with warning in
> dmesg).
>
> As the vendor apparently messed up horribly, as far as I understand, I
> don't really see another option.
>
>
Comment 14 Anonymous Emailer 2009-12-01 19:58:26 UTC
Reply-To: remi@cattiau.com

Hello all,

Here my lsusb :
Bus 001 Device 006: ID 1130:0001 Tenx Technology, Inc.

Bus 001 Device 006: ID 1130:0001 Tenx Technology, Inc.
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               1.10
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0         8
   idVendor           0x1130 Tenx Technology, Inc.
   idProduct          0x0001
   bcdDevice            1.00
   iManufacturer           0
   iProduct                2
   iSerial                 0
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           59
     bNumInterfaces          2
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0x80
       (Bus Powered)
     MaxPower              100mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           1
       bInterfaceClass         3 Human Interface Device
       bInterfaceSubClass      0 No Subclass
       bInterfaceProtocol      0 None
       iInterface              0
       ** UNRECOGNIZED:  09 21 10 01 00 01 22 29 00
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0008  1x 8 bytes
         bInterval              10
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        1
       bAlternateSetting       0
       bNumEndpoints           1
       bInterfaceClass         3 Human Interface Device
       bInterfaceSubClass      0 No Subclass
       bInterfaceProtocol      0 None
       iInterface              0
       ** UNRECOGNIZED:  09 21 10 01 21 01 22 17 00
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0008  1x 8 bytes
         bInterval              10


I'll send an email to admin@usb.org <mailto:admin@usb.org>  to know 
which one is a valid member.
Let me know if any trouble

Rémi

Le 01/12/2009 11:40, Jiri Kosina a écrit :
> On Sat, 28 Nov 2009, Guido Dorssers wrote:
>
>    
>>> The problem apparently [1] is, that the vendor has been super-creative and
>>> assigned the same combination of idVendor/idProduct to completely
>>> different devices. Oh well.
>>>
>>> Remi, could you please check your device against the lsusb data provided
>>> in bugzilla to check whether there is any possibility to distinguish these
>>> devices, so that we could put some ugly check in place probably?
>>>
>>> Thanks.
>>>
>>> [1] http://lkml.org/lkml/2009/2/10/434
>>>
>>>        
>> Hi all,
>>
>> A belated thanks for having pointed me into the right direction to get my
>> barcodescanner operational. However, as a thought since the bug is still
>> present, why not solve it with something as simple as making the blacklisting
>> user-configurable instead of blacklisting valid HID devices on purpose?
>>      
> Hi,
>
> actually, my current plan is to remove the blacklist entry for this
> combination of VID/PID completely, and let the user decide and unbind the
> driver via sysfs eventually, if needed (maybe together with warning in
> dmesg).
>
> As the vendor apparently messed up horribly, as far as I understand, I
> don't really see another option.
>
>
Comment 16 Florian Mickler 2010-10-07 17:33:56 UTC
thx, closing

Note You need to log in before you can comment on or make changes to this bug.