New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

Bugme-new Andrew Morton 6 participants 7 messages Jun 2, 2009 – Dec 1, 2009 4 messages not in the archive HID

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author

2009-06-02 03:26 UTC #1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 17 lines · On Sun, 31 May 2009 12:21:58 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        Regression: Yes

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

Thanks.

Quoted 51 lines

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

Maximi89

2009-06-02 03:44 UTC #2 lore raw

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 <[email protected]>:

Quoted 89 lines

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 17 lines · On Sun, 31 May 2009 12:21:58 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        Regression: Yes
Does anyone want to claim this regression? USB, HID or Input??
Thanks.
Quoted 47 lines
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
Quoted 7 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 7 lines

Maximiliano Augusto Castañón Araneda
Santiago, Chile
Linux user # 394821
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Paulius Zaleckas

2009-06-02 10:20 UTC #3 lore raw

Quoted 5 lines · 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

Quoted 8 lines

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)

Quoted 88 lines

2009/6/1, Andrew Morton <[email protected]>:
Quoted 85 lines
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 17 lines · On Sun, 31 May 2009 12:21:58 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        Regression: Yes
Does anyone want to claim this regression? USB, HID or Input??
Thanks.
Quoted 46 lines
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
Quoted 7 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20090601202509.87f57ef9.akpm-de/[email protected]

Jiri Kosina

2009-06-02 09:55 UTC #5 lore raw

Quoted 16 lines · Andrew Morton

Quoted 16 lines
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:

Quoted 7 lines

Quoted 7 lines
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-O/[email protected]>
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-O/[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

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

Signature · 7 lines

Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): alpine.LRH.2.00.0906021148140.29471-1ReQVI26iDCaZKY3DrU6dA@public.gmane.org

Guido Dorssers

2009-11-28 21:51 UTC #7 lore raw

Op dinsdag 2 juni 2009 11:55:51 schreef Jiri Kosina:

Quoted 18 lines

This is almost certainly because of this commit:
commit d1d3a5f6eaee337d793ab9ac28e696f0262c3c8a
Author: Remi Cattiau <remi-O/[email protected]>
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-O/[email protected]>
Signed-off-by Jiri Kosina <[email protected]>
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.

Quoted 8 lines

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:

hid/hid-core.c 2009-10-17 23:01:38.130911398 +0200 renamed from hid/hid-core.c 2009-10-17 22:22:12.589447000 +0200 +0 -0

diff -urNb drivers/hid/hid-core.c drivers/hid/hid-core.c
@@ -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)
},

hid/Kconfig 2009-10-17 23:04:23.538908607 +0200 renamed from hid/Kconfig 2009-09-10 00:13:59.000000000 +0200 +6 -0

diff -urNb drivers/hid/Kconfig drivers/hid/Kconfig
@@ -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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 200911282251.28780.bugzilla.kernel.org-Dy4KJ/[email protected]

Jiri Kosina

2009-12-01 10:40 UTC #9 lore raw

Quoted 13 lines · Guido Dorssers

Quoted 4 lines
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.
Quoted 8 lines
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

Quoted 6 lines

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.

Signature · 6 lines

Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rémi Cattiau

2009-12-01 11:37 UTC #10 lore raw

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

Quoted 34 lines · Jiri Kosina

Quoted 13 lines · Guido Dorssers
Quoted 4 lines
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.
Quoted 9 lines
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
Quoted 7 lines
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.

Signature · 8 lines

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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