Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Andrew Morton]

(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

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Maximi89]

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
>


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Paulius Zaleckas]

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
>>
> 
> 

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Jiri Kosina]

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-O/wO+J8fF4JBDgjK7y7TUQ@public.gmane.org>
	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/wO+J8fF4JBDgjK7y7TUQ@public.gmane.org>
	    Signed-off-by: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>

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

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Guido Dorssers]

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-O/wO+J8fF4JBDgjK7y7TUQ@public.gmane.org>
> 	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/wO+J8fF4JBDgjK7y7TUQ@public.gmane.org>
> 	    Signed-off-by: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
> 
> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Jiri Kosina]

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.

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

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Rémi Cattiau]

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.
>
>    


-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13411] New: Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28

[Rémi Cattiau]

  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 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html