All of lore.kernel.org
 help / color / mirror / Atom feed
* Baantoo multi-touch screen trouble
@ 2012-04-11 15:29 Tvrtko Ursulin
  2012-04-12 14:47 ` Tvrtko Ursulin
  0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2012-04-11 15:29 UTC (permalink / raw)
  To: linux-input


Hi all,

I am playing with a multi-touch capable touch screen from the
above mentioned vendor and are experiencing some problems here.
On a 3.1.0 derivative kernel it kind of works, looks like this:

[5523460.737596] usb 1-1.6.1.2: new full speed USB device number 18 using ehci_hcd
[5523460.824952] usb 1-1.6.1.2: New USB device found, idVendor=2453, idProduct=0100
[5523460.824959] usb 1-1.6.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[5523460.824964] usb 1-1.6.1.2: Product: SDW-190W2-M5T-XXX-XX-PRD   
[5523460.824968] usb 1-1.6.1.2: Manufacturer: Baanto
[5523460.824971] usb 1-1.6.1.2: SerialNumber: SDW190W2M5T
[5523460.833233] input: Baanto SDW-190W2-M5T-XXX-XX-PRD    as 
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.1/1-1.6.1.2/1-1.6.1.2:1.0/input/input159
[5523460.833926] generic-usb 0003:2453:0100.00A3: input,hiddev0,hidraw3: USB HID v1.10 Mouse [Baanto SDW-190W2-M5T-
XXX-XX-PRD   ] on usb-0000:00:1a.0-1.6.1.2/input0


On 3.3.0 it doesn't think it is an input device at all:

[   73.776660] usb 3-1: new full-speed USB device number 3 using xhci_hcd
[   73.817163] usb 3-1: New USB device found, idVendor=2453, idProduct=0100
[   73.817167] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   73.817169] usb 3-1: Product: SDW-190W2-M5T-XXX-XX-PRD   
[   73.817171] usb 3-1: Manufacturer: Baanto
[   73.817173] usb 3-1: SerialNumber: SDW190W2M5T

On 3.0 on the other hand it actually registered multiple HID devices, which is
what I think should happen with this device, because it's datasheet says this:

"""
The mid-size family of touch screens, when enumerated on the OS, expose 5 top
level USB HID collections. The following table describes these in detail:
following table describes these in detail:

Collection Description
----------------------
Win 7 Touch Collection
Microsoft Device Configuration Collection
Generic Mouse Collection
Generic Pointer Collection
Baanto Touch (Custom HID) Collection

Report Data
-----------
Multi Touch Packets
Control Packets
N\A – Future Use
Single Touch Packet
Multi Touch Packets\Control Packets
"""

Any ideas who is at fault here?

Thanks,

Tvrtko


Bus 003 Device 003: ID 2453:0100  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x2453 
  idProduct          0x0100 
  bcdDevice            4.0c
  iManufacturer           1 Baanto
  iProduct                2 SDW-190W2-M5T-XXX-XX-PRD   
  iSerial                 3 SDW190W2M5T
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    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 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     759
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0001
  Self Powered
--
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-11 15:29 Baantoo multi-touch screen trouble Tvrtko Ursulin
@ 2012-04-12 14:47 ` Tvrtko Ursulin
  2012-04-12 16:05   ` Benjamin Tissoires
  0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2012-04-12 14:47 UTC (permalink / raw)
  To: linux-input; +Cc: Jiri Kosina


[Jiri, I copied you as per get_maintainers.pl having trouble debugging
this issue in case linux-input mailing list is dead (can't find recent
archives). My original post plus some debug info is below.]

On Wednesday 11 Apr 2012 16:29:59 Tvrtko Ursulin wrote:
> Hi all,
> 
> I am playing with a multi-touch capable touch screen from the
> above mentioned vendor and are experiencing some problems here.
> On a 3.1.0 derivative kernel it kind of works, looks like this:
> 
> [5523460.737596] usb 1-1.6.1.2: new full speed USB device number 18 using
> ehci_hcd [5523460.824952] usb 1-1.6.1.2: New USB device found,
> idVendor=2453, idProduct=0100 [5523460.824959] usb 1-1.6.1.2: New USB
> device strings: Mfr=1, Product=2, SerialNumber=3 [5523460.824964] usb
> 1-1.6.1.2: Product: SDW-190W2-M5T-XXX-XX-PRD
> [5523460.824968] usb 1-1.6.1.2: Manufacturer: Baanto
> [5523460.824971] usb 1-1.6.1.2: SerialNumber: SDW190W2M5T
> [5523460.833233] input: Baanto SDW-190W2-M5T-XXX-XX-PRD    as
> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.1/1-1.6.1.2/1-1.6.1.2
> :1.0/input/input159 [5523460.833926] generic-usb 0003:2453:0100.00A3:
> input,hiddev0,hidraw3: USB HID v1.10 Mouse [Baanto SDW-190W2-M5T-
> XXX-XX-PRD   ] on usb-0000:00:1a.0-1.6.1.2/input0
> 
> 
> On 3.3.0 it doesn't think it is an input device at all:
> 
> [   73.776660] usb 3-1: new full-speed USB device number 3 using xhci_hcd
> [   73.817163] usb 3-1: New USB device found, idVendor=2453, idProduct=0100
> [   73.817167] usb 3-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3 [   73.817169] usb 3-1: Product: SDW-190W2-M5T-XXX-XX-PRD
> [   73.817171] usb 3-1: Manufacturer: Baanto
> [   73.817173] usb 3-1: SerialNumber: SDW190W2M5T
> 
> On 3.0 on the other hand it actually registered multiple HID devices, which
> is what I think should happen with this device, because it's datasheet
> says this:
> 
> """
> The mid-size family of touch screens, when enumerated on the OS, expose 5
> top level USB HID collections. The following table describes these in
> detail: following table describes these in detail:
> 
> Collection Description
> ----------------------
> Win 7 Touch Collection
> Microsoft Device Configuration Collection
> Generic Mouse Collection
> Generic Pointer Collection
> Baanto Touch (Custom HID) Collection
> 
> Report Data
> -----------
> Multi Touch Packets
> Control Packets
> N\A – Future Use
> Single Touch Packet
> Multi Touch Packets\Control Packets
> """
> 
> Any ideas who is at fault here?
> 
> Thanks,
> 
> Tvrtko
> 
> 
> Bus 003 Device 003: ID 2453:0100
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0        64
>   idVendor           0x2453
>   idProduct          0x0100
>   bcdDevice            4.0c
>   iManufacturer           1 Baanto
>   iProduct                2 SDW-190W2-M5T-XXX-XX-PRD
>   iSerial                 3 SDW190W2M5T
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           34
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0
>     bmAttributes         0xc0
>       Self Powered
>     MaxPower              500mA
>     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
>         HID Device Descriptor:
>           bLength                 9
>           bDescriptorType        33
>           bcdHID               1.10
>           bCountryCode           33 US
>           bNumDescriptors         1
>           bDescriptorType        34 Report
>           wDescriptorLength     759
>          Report Descriptors:
>            ** UNAVAILABLE **
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               1
> Device Status:     0x0001
>   Self Powered

This is all I see with HID debugging turned on (3.3.0) after plugging in the device:

[85409.156718] drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 0
[85409.176184] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0123 wIndex=0x0000 wLength=56
[85409.177652] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0125 wIndex=0x0000 wLength=6
[85409.179649] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0110 wIndex=0x0000 wLength=6
[85409.181639] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0109 wIndex=0x0000 wLength=64
[85409.183636] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010f wIndex=0x0000 wLength=64
[85409.185634] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010b wIndex=0x0000 wLength=64
[85409.187639] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010c wIndex=0x0000 wLength=64
[85409.189633] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010d wIndex=0x0000 wLength=64
[85409.191628] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0324 wIndex=0x0000 wLength=2
[85409.194619] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0327 wIndex=0x0000 wLength=3
[85409.196621] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0302 wIndex=0x0000 wLength=4
[85409.199617] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0303 wIndex=0x0000 wLength=13
[85409.202615] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0304 wIndex=0x0000 wLength=13
[85409.205606] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0305 wIndex=0x0000 wLength=3
[85409.208601] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0355 wIndex=0x0000 wLength=2
[85409.210603] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0377 wIndex=0x0000 wLength=2
[85409.212604] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0366 wIndex=0x0000 wLength=2
[85409.214597] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0388 wIndex=0x0000 wLength=2
[85409.216593] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0344 wIndex=0x0000 wLength=2

No input device of any kind registered after this point.

Hints about what is going wrong?

Tvrtko

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-12 14:47 ` Tvrtko Ursulin
@ 2012-04-12 16:05   ` Benjamin Tissoires
  2012-04-13  8:02     ` Tvrtko Ursulin
  0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Tissoires @ 2012-04-12 16:05 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: linux-input, Jiri Kosina

Hi Tvrtko,

I misread your first mail, sorry for that. I did not saw that your
device was a Hid one detected as a multitouch one. Under 3.3, just do:
$ sudo modprobe hid-multitouch

And the device should be handled by hid-multitouch.

The 3.3 kernel, detects that your device should be handled by
hid-multitouch, but it does not load it automatically. You may add
this module in the configuration file.

Cheers,
Benjamin

On Thu, Apr 12, 2012 at 16:47, Tvrtko Ursulin
<tvrtko.ursulin@onelan.co.uk> wrote:
>
> [Jiri, I copied you as per get_maintainers.pl having trouble debugging
> this issue in case linux-input mailing list is dead (can't find recent
> archives). My original post plus some debug info is below.]
>
> On Wednesday 11 Apr 2012 16:29:59 Tvrtko Ursulin wrote:
>> Hi all,
>>
>> I am playing with a multi-touch capable touch screen from the
>> above mentioned vendor and are experiencing some problems here.
>> On a 3.1.0 derivative kernel it kind of works, looks like this:
>>
>> [5523460.737596] usb 1-1.6.1.2: new full speed USB device number 18 using
>> ehci_hcd [5523460.824952] usb 1-1.6.1.2: New USB device found,
>> idVendor=2453, idProduct=0100 [5523460.824959] usb 1-1.6.1.2: New USB
>> device strings: Mfr=1, Product=2, SerialNumber=3 [5523460.824964] usb
>> 1-1.6.1.2: Product: SDW-190W2-M5T-XXX-XX-PRD
>> [5523460.824968] usb 1-1.6.1.2: Manufacturer: Baanto
>> [5523460.824971] usb 1-1.6.1.2: SerialNumber: SDW190W2M5T
>> [5523460.833233] input: Baanto SDW-190W2-M5T-XXX-XX-PRD    as
>> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.1/1-1.6.1.2/1-1.6.1.2
>> :1.0/input/input159 [5523460.833926] generic-usb 0003:2453:0100.00A3:
>> input,hiddev0,hidraw3: USB HID v1.10 Mouse [Baanto SDW-190W2-M5T-
>> XXX-XX-PRD   ] on usb-0000:00:1a.0-1.6.1.2/input0
>>
>>
>> On 3.3.0 it doesn't think it is an input device at all:
>>
>> [   73.776660] usb 3-1: new full-speed USB device number 3 using xhci_hcd
>> [   73.817163] usb 3-1: New USB device found, idVendor=2453, idProduct=0100
>> [   73.817167] usb 3-1: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3 [   73.817169] usb 3-1: Product: SDW-190W2-M5T-XXX-XX-PRD
>> [   73.817171] usb 3-1: Manufacturer: Baanto
>> [   73.817173] usb 3-1: SerialNumber: SDW190W2M5T
>>
>> On 3.0 on the other hand it actually registered multiple HID devices, which
>> is what I think should happen with this device, because it's datasheet
>> says this:
>>
>> """
>> The mid-size family of touch screens, when enumerated on the OS, expose 5
>> top level USB HID collections. The following table describes these in
>> detail: following table describes these in detail:
>>
>> Collection Description
>> ----------------------
>> Win 7 Touch Collection
>> Microsoft Device Configuration Collection
>> Generic Mouse Collection
>> Generic Pointer Collection
>> Baanto Touch (Custom HID) Collection
>>
>> Report Data
>> -----------
>> Multi Touch Packets
>> Control Packets
>> N\A – Future Use
>> Single Touch Packet
>> Multi Touch Packets\Control Packets
>> """
>>
>> Any ideas who is at fault here?
>>
>> Thanks,
>>
>> Tvrtko
>>
>>
>> Bus 003 Device 003: ID 2453:0100
>> Device Descriptor:
>>   bLength                18
>>   bDescriptorType         1
>>   bcdUSB               2.00
>>   bDeviceClass            0 (Defined at Interface level)
>>   bDeviceSubClass         0
>>   bDeviceProtocol         0
>>   bMaxPacketSize0        64
>>   idVendor           0x2453
>>   idProduct          0x0100
>>   bcdDevice            4.0c
>>   iManufacturer           1 Baanto
>>   iProduct                2 SDW-190W2-M5T-XXX-XX-PRD
>>   iSerial                 3 SDW190W2M5T
>>   bNumConfigurations      1
>>   Configuration Descriptor:
>>     bLength                 9
>>     bDescriptorType         2
>>     wTotalLength           34
>>     bNumInterfaces          1
>>     bConfigurationValue     1
>>     iConfiguration          0
>>     bmAttributes         0xc0
>>       Self Powered
>>     MaxPower              500mA
>>     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
>>         HID Device Descriptor:
>>           bLength                 9
>>           bDescriptorType        33
>>           bcdHID               1.10
>>           bCountryCode           33 US
>>           bNumDescriptors         1
>>           bDescriptorType        34 Report
>>           wDescriptorLength     759
>>          Report Descriptors:
>>            ** UNAVAILABLE **
>>       Endpoint Descriptor:
>>         bLength                 7
>>         bDescriptorType         5
>>         bEndpointAddress     0x81  EP 1 IN
>>         bmAttributes            3
>>           Transfer Type            Interrupt
>>           Synch Type               None
>>           Usage Type               Data
>>         wMaxPacketSize     0x0040  1x 64 bytes
>>         bInterval               1
>> Device Status:     0x0001
>>   Self Powered
>
> This is all I see with HID debugging turned on (3.3.0) after plugging in the device:
>
> [85409.156718] drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 0
> [85409.176184] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0123 wIndex=0x0000 wLength=56
> [85409.177652] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0125 wIndex=0x0000 wLength=6
> [85409.179649] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0110 wIndex=0x0000 wLength=6
> [85409.181639] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0109 wIndex=0x0000 wLength=64
> [85409.183636] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010f wIndex=0x0000 wLength=64
> [85409.185634] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010b wIndex=0x0000 wLength=64
> [85409.187639] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010c wIndex=0x0000 wLength=64
> [85409.189633] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x010d wIndex=0x0000 wLength=64
> [85409.191628] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0324 wIndex=0x0000 wLength=2
> [85409.194619] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0327 wIndex=0x0000 wLength=3
> [85409.196621] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0302 wIndex=0x0000 wLength=4
> [85409.199617] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0303 wIndex=0x0000 wLength=13
> [85409.202615] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0304 wIndex=0x0000 wLength=13
> [85409.205606] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0305 wIndex=0x0000 wLength=3
> [85409.208601] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0355 wIndex=0x0000 wLength=2
> [85409.210603] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0377 wIndex=0x0000 wLength=2
> [85409.212604] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0366 wIndex=0x0000 wLength=2
> [85409.214597] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0388 wIndex=0x0000 wLength=2
> [85409.216593] drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0344 wIndex=0x0000 wLength=2
>
> No input device of any kind registered after this point.
>
> Hints about what is going wrong?
>
> Tvrtko
>
> --
> 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
--
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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-12 16:05   ` Benjamin Tissoires
@ 2012-04-13  8:02     ` Tvrtko Ursulin
  2012-04-13  9:21       ` Benjamin Tissoires
  0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2012-04-13  8:02 UTC (permalink / raw)
  To: Benjamin Tissoires; +Cc: linux-input, Jiri Kosina

On Thursday 12 Apr 2012 17:05:34 Benjamin Tissoires wrote:
> Hi Tvrtko,
> 
> I misread your first mail, sorry for that. I did not saw that your
> device was a Hid one detected as a multitouch one. Under 3.3, just do:
> $ sudo modprobe hid-multitouch
> 
> And the device should be handled by hid-multitouch.
> 
> The 3.3 kernel, detects that your device should be handled by
> hid-multitouch, but it does not load it automatically. You may add
> this module in the configuration file.

Unfortunately nothing interesting happened with hid-multitouch loaded. Nonew 
kernel messages, no devices claimed/created.

Are there any tools (couldn't find any) which can probe/analyze this device 
from userspace? Or something that would explain why it works better with 
earlier kernels?

Tvrtko

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-13  8:02     ` Tvrtko Ursulin
@ 2012-04-13  9:21       ` Benjamin Tissoires
  2012-04-13  9:33         ` Tvrtko Ursulin
  0 siblings, 1 reply; 11+ messages in thread
From: Benjamin Tissoires @ 2012-04-13  9:21 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: linux-input, Jiri Kosina

Hi,

Oops, I think I assumed that the features that will come in 3.4 are
already in 3.3... sorry.

Once hid-multitouch is loaded, you have to manually tell him to handle
your device:
# echo 3 2453 0100 0 >
/sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id

That should do the trick.

If it's not working, then we may need the full report descriptors
(without the ** UNAVAILABLE **). You can do that by using the script
there: http://lii-enac.fr/en/architecture/linux-input/multitouch-howto.html#report

Cheers,
Benjamin

On Fri, Apr 13, 2012 at 10:02, Tvrtko Ursulin
<tvrtko.ursulin@onelan.co.uk> wrote:
> On Thursday 12 Apr 2012 17:05:34 Benjamin Tissoires wrote:
>> Hi Tvrtko,
>>
>> I misread your first mail, sorry for that. I did not saw that your
>> device was a Hid one detected as a multitouch one. Under 3.3, just do:
>> $ sudo modprobe hid-multitouch
>>
>> And the device should be handled by hid-multitouch.
>>
>> The 3.3 kernel, detects that your device should be handled by
>> hid-multitouch, but it does not load it automatically. You may add
>> this module in the configuration file.
>
> Unfortunately nothing interesting happened with hid-multitouch loaded. Nonew
> kernel messages, no devices claimed/created.
>
> Are there any tools (couldn't find any) which can probe/analyze this device
> from userspace? Or something that would explain why it works better with
> earlier kernels?
>
> Tvrtko

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-13  9:21       ` Benjamin Tissoires
@ 2012-04-13  9:33         ` Tvrtko Ursulin
  2012-04-13 12:42           ` Jiri Kosina
  0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2012-04-13  9:33 UTC (permalink / raw)
  To: Benjamin Tissoires; +Cc: linux-input, Jiri Kosina

On Friday 13 Apr 2012 10:21:22 Benjamin Tissoires wrote:
> Hi,
> 
> Oops, I think I assumed that the features that will come in 3.4 are
> already in 3.3... sorry.
> 
> Once hid-multitouch is loaded, you have to manually tell him to handle
> your device:
> # echo 3 2453 0100 0 >
> /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id
> 
> That should do the trick.

Yep, that makes it work.

Thanks for your help!

If you would want to have any additional data about this panel just shout, I 
will have access to it for a couple of more days.

Tvrtko

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-13  9:33         ` Tvrtko Ursulin
@ 2012-04-13 12:42           ` Jiri Kosina
  2012-04-13 13:30             ` Tvrtko Ursulin
  0 siblings, 1 reply; 11+ messages in thread
From: Jiri Kosina @ 2012-04-13 12:42 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Benjamin Tissoires, linux-input

On Fri, 13 Apr 2012, Tvrtko Ursulin wrote:

> > Oops, I think I assumed that the features that will come in 3.4 are
> > already in 3.3... sorry.
> > 
> > Once hid-multitouch is loaded, you have to manually tell him to handle
> > your device:
> > # echo 3 2453 0100 0 >
> > /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id
> > 
> > That should do the trick.
> 
> Yep, that makes it work.
> 
> Thanks for your help!
> 
> If you would want to have any additional data about this panel just shout, I 
> will have access to it for a couple of more days.

Guys, who of you is going to send me patch adding the device ID into 
in-kernel list?

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-13 12:42           ` Jiri Kosina
@ 2012-04-13 13:30             ` Tvrtko Ursulin
  2012-04-17  9:07               ` Jiri Kosina
  0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2012-04-13 13:30 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input

On Friday 13 Apr 2012 13:42:24 Jiri Kosina wrote:
> On Fri, 13 Apr 2012, Tvrtko Ursulin wrote:
> > > Oops, I think I assumed that the features that will come in 3.4 are
> > > already in 3.3... sorry.
> > > 
> > > Once hid-multitouch is loaded, you have to manually tell him to handle
> > > your device:
> > > # echo 3 2453 0100 0 >
> > > /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id
> > > 
> > > That should do the trick.
> > 
> > Yep, that makes it work.
> > 
> > Thanks for your help!
> > 
> > If you would want to have any additional data about this panel just
> > shout, I will have access to it for a couple of more days.
> 
> Guys, who of you is going to send me patch adding the device ID into
> in-kernel list?

It is unlikely to be me unless someone explains to me in detail what needs to 
be done, at which point it is probably quicker for that person to do it. I for 
example don't even understand why this, allegedly HID Multitouch class 
compliant, device needs explicit adding? Is it not compliant after all? Is it 
that multiple HID devices it exposes a non-standard thing? Does it then need a 
vendor specific class (looking at hid-multitouch.c). Sorry this whole area is 
just new and unknown to me.

Tvrtko

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-13 13:30             ` Tvrtko Ursulin
@ 2012-04-17  9:07               ` Jiri Kosina
  2012-04-17 12:12                 ` Tvrtko Ursulin
  0 siblings, 1 reply; 11+ messages in thread
From: Jiri Kosina @ 2012-04-17  9:07 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Benjamin Tissoires, linux-input

On Fri, 13 Apr 2012, Tvrtko Ursulin wrote:

> > Guys, who of you is going to send me patch adding the device ID into
> > in-kernel list?
> 
> It is unlikely to be me unless someone explains to me in detail what needs to 
> be done, at which point it is probably quicker for that person to do it. I for 
> example don't even understand why this, allegedly HID Multitouch class 
> compliant, device needs explicit adding? Is it not compliant after all? Is it 
> that multiple HID devices it exposes a non-standard thing? Does it then need a 
> vendor specific class (looking at hid-multitouch.c). Sorry this whole area is 
> just new and unknown to me.

Could you please verify that the patch below works for you? Thanks.



From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: multitouch: Add support for Baantoo touchscreen

Reported-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/hid/hid-core.c       |    1 +
 drivers/hid/hid-ids.h        |    3 +++
 drivers/hid/hid-multitouch.c |    4 ++++
 3 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 990fe19..d6c0b1c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1388,6 +1388,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS, USB_DEVICE_ID_ASUS_T91MT) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS, USB_DEVICE_ID_ASUSTEK_MULTITOUCH_YFO) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_BELKIN, USB_DEVICE_ID_FLIP_KVM) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_BAANTOO, USB_DEVICE_ID_BAANTOO_MT_190W2), },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_BTC, USB_DEVICE_ID_BTC_EMPREX_REMOTE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_BTC, USB_DEVICE_ID_BTC_EMPREX_REMOTE_2) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CANDO, USB_DEVICE_ID_CANDO_PIXCIR_MULTI_TOUCH) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3eb0090..fef15c4 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -157,6 +157,9 @@
 #define USB_VENDOR_ID_AVERMEDIA		0x07ca
 #define USB_DEVICE_ID_AVER_FM_MR800	0xb800
 
+#define USB_VENDOR_ID_BAANTOO		0x2453
+#define USB_DEVICE_ID_BAANTOO_MT_190W2	0x0100
+
 #define USB_VENDOR_ID_BELKIN		0x050d
 #define USB_DEVICE_ID_FLIP_KVM		0x3201
 
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 1d5b941..788aca3 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -749,6 +749,10 @@ static const struct hid_device_id mt_devices[] = {
 		HID_USB_DEVICE(USB_VENDOR_ID_ATMEL,
 			USB_DEVICE_ID_ATMEL_MXT_DIGITIZER) },
 
+	/* Baantoo multitouch devices */
+	{ .driver_data = MT_CLS_DEFAULT,
+		HID_USB_DEVICE(USB_VENDOR_ID_BAANTOO,
+			USB_DEVICE_ID_BAANTOO_MT_190W2) },
 	/* Cando panels */
 	{ .driver_data = MT_CLS_DUAL_INRANGE_CONTACTNUMBER,
 		HID_USB_DEVICE(USB_VENDOR_ID_CANDO,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-17  9:07               ` Jiri Kosina
@ 2012-04-17 12:12                 ` Tvrtko Ursulin
  2012-04-17 12:19                   ` Jiri Kosina
  0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2012-04-17 12:12 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input

On Tuesday 17 Apr 2012 10:07:19 Jiri Kosina wrote:
> On Fri, 13 Apr 2012, Tvrtko Ursulin wrote:
> > > Guys, who of you is going to send me patch adding the device ID into
> > > in-kernel list?
> > 
> > It is unlikely to be me unless someone explains to me in detail what
> > needs to be done, at which point it is probably quicker for that person
> > to do it. I for example don't even understand why this, allegedly HID
> > Multitouch class compliant, device needs explicit adding? Is it not
> > compliant after all? Is it that multiple HID devices it exposes a
> > non-standard thing? Does it then need a vendor specific class (looking
> > at hid-multitouch.c). Sorry this whole area is just new and unknown to
> > me.
> 
> Could you please verify that the patch below works for you? Thanks.


Works fine. I made a typo in the thread subject, one too many 'o' in vendor's 
name - Baanto is correct.

Thanks,

Tvrtko

P.S. I still do not understand why it is needed to explicitly add this device 
for it to work, but nevermind, I asked this enough time to know when to give 
up.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Baantoo multi-touch screen trouble
  2012-04-17 12:12                 ` Tvrtko Ursulin
@ 2012-04-17 12:19                   ` Jiri Kosina
  0 siblings, 0 replies; 11+ messages in thread
From: Jiri Kosina @ 2012-04-17 12:19 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Benjamin Tissoires, linux-input, Henrik Rydberg

On Tue, 17 Apr 2012, Tvrtko Ursulin wrote:

> > > It is unlikely to be me unless someone explains to me in detail what
> > > needs to be done, at which point it is probably quicker for that person
> > > to do it. I for example don't even understand why this, allegedly HID
> > > Multitouch class compliant, device needs explicit adding? Is it not
> > > compliant after all? Is it that multiple HID devices it exposes a
> > > non-standard thing? Does it then need a vendor specific class (looking
> > > at hid-multitouch.c). Sorry this whole area is just new and unknown to
> > > me.
> > 
> > Could you please verify that the patch below works for you? Thanks.
> 
> Works fine. I made a typo in the thread subject, one too many 'o' in vendor's 
> name - Baanto is correct.

Thanks, I will fix that up before applying.

> P.S. I still do not understand why it is needed to explicitly add this device 
> for it to work, but nevermind, I asked this enough time to know when to give 
> up.

Because currently there is no way how to auto-load proper module if the 
device is multitouch. Henrik is working in this area.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-04-17 12:19 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-11 15:29 Baantoo multi-touch screen trouble Tvrtko Ursulin
2012-04-12 14:47 ` Tvrtko Ursulin
2012-04-12 16:05   ` Benjamin Tissoires
2012-04-13  8:02     ` Tvrtko Ursulin
2012-04-13  9:21       ` Benjamin Tissoires
2012-04-13  9:33         ` Tvrtko Ursulin
2012-04-13 12:42           ` Jiri Kosina
2012-04-13 13:30             ` Tvrtko Ursulin
2012-04-17  9:07               ` Jiri Kosina
2012-04-17 12:12                 ` Tvrtko Ursulin
2012-04-17 12:19                   ` Jiri Kosina

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.