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
(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
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 >
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
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 >> > >
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.
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?
Hi, any chance to fix this ? regards
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
Created attachment 23964 [details] lsusb -vv for a CMP-BARSCAN30
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
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.
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. > >
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. > >
This bug seems to have been fixed: http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=commit;h=4bb9508bbbb06f10bc3e249dd34375b4a4d6bfc0
thx, closing