HID input dealing with multiple collections?

HID input dealing with multiple collections?

[Breton M. Saunders]

Hello,

   I've written a USB device which supports multiple input devices:
     * A touch surface digitizer (following Microsoft's specification)
     * A pen surface digitizer
     * A mouse emulator

   In windows each of these interfaces are exposed as a separate top 
level collection, e.g.:
   Usage_Page(Generic Desktop)
   Usage(Mouse)
   Collection(Application)
        ...
   End_Collection
   Usage_Page(Digitzer)
   Usage(Touch_Screen)
   Collection(Application)
      ...
   End_Collection
   Usage(Digitizer)
   Usage(Pen)
   Collection(Application)
      ...
   End_Collection

   Now this descriptor works well in Windows; all reporting channels are 
exposed correctly as hid devices and mouse/multitouch/pen input all 
works correctly as expected.  In linux, however, this is not the case.  
What I see is that if I drop out the touch/pen functionality then the 
mouse support works correctly.  Likewise, if I drop any pair of other 
top level collections such that I have exactly one top level collection 
the system works correctly.

   Am I missing something here - as in: Have I made an error in my usage 
of top level collections, or is linux-input's hid support incapable of 
dealing with multiple top level collections?

   Thanks in advance for any advice on this!

-bms20

Re: HID input dealing with multiple collections?

[Benjamin Tissoires]

Hi,

On Mon, Sep 9, 2013 at 2:56 PM, Breton M. Saunders <bms20@brettnet.eu> wrote:
> Hello,
>
>   I've written a USB device which supports multiple input devices:
>     * A touch surface digitizer (following Microsoft's specification)
>     * A pen surface digitizer
>     * A mouse emulator
>
>   In windows each of these interfaces are exposed as a separate top level
> collection, e.g.:
>   Usage_Page(Generic Desktop)
>   Usage(Mouse)
>   Collection(Application)
>        ...
>   End_Collection
>   Usage_Page(Digitzer)
>   Usage(Touch_Screen)
>   Collection(Application)
>      ...
>   End_Collection
>   Usage(Digitizer)
>   Usage(Pen)
>   Collection(Application)
>      ...
>   End_Collection
>
>   Now this descriptor works well in Windows; all reporting channels are
> exposed correctly as hid devices and mouse/multitouch/pen input all works
> correctly as expected.  In linux, however, this is not the case.  What I see
> is that if I drop out the touch/pen functionality then the mouse support
> works correctly.  Likewise, if I drop any pair of other top level
> collections such that I have exactly one top level collection the system
> works correctly.
>
>   Am I missing something here - as in: Have I made an error in my usage of
> top level collections, or is linux-input's hid support incapable of dealing
> with multiple top level collections?

If it works under Windows, there are huge chances that your report
descriptor is good.

However, under Linux, we use the report IDs to split (if required) the
different inputs.
The good thing for you is that if I understand correctly, the device
you are talking about should be handled through hid-multitouch. Since
kernel v3.10, we have introduced the support of devices showing both a
digitizer and a pen (they will show up as two input devices).

I would encourage you to test a 3.10 kernel, and/or send me some
traces of your devices by using hid-replay[1]. This way I will be able
to test your device on my laptop, and eventually figure out any
problem.

Cheers,
Benjamin

[1] http://bentiss.github.io/hid-replay-docs/

Re: HID input dealing with multiple collections?

[Breton M. Saunders]

On 09/09/13 14:12, Benjamin Tissoires wrote:
> Hi,
>
> On Mon, Sep 9, 2013 at 2:56 PM, Breton M. Saunders <bms20@brettnet.eu> wrote:
>> Hello,
>>
>>    I've written a USB device which supports multiple input devices:
>>      * A touch surface digitizer (following Microsoft's specification)
>>      * A pen surface digitizer
>>      * A mouse emulator
>>
>>    In windows each of these interfaces are exposed as a separate top level
>> collection, e.g.:
>>    Usage_Page(Generic Desktop)
>>    Usage(Mouse)
>>    Collection(Application)
>>         ...
>>    End_Collection
>>    Usage_Page(Digitzer)
>>    Usage(Touch_Screen)
>>    Collection(Application)
>>       ...
>>    End_Collection
>>    Usage(Digitizer)
>>    Usage(Pen)
>>    Collection(Application)
>>       ...
>>    End_Collection
>>
>>    Now this descriptor works well in Windows; all reporting channels are
>> exposed correctly as hid devices and mouse/multitouch/pen input all works
>> correctly as expected.  In linux, however, this is not the case.  What I see
>> is that if I drop out the touch/pen functionality then the mouse support
>> works correctly.  Likewise, if I drop any pair of other top level
>> collections such that I have exactly one top level collection the system
>> works correctly.
>>
>>    Am I missing something here - as in: Have I made an error in my usage of
>> top level collections, or is linux-input's hid support incapable of dealing
>> with multiple top level collections?
> If it works under Windows, there are huge chances that your report
> descriptor is good.
>
> However, under Linux, we use the report IDs to split (if required) the
> different inputs.
> The good thing for you is that if I understand correctly, the device
> you are talking about should be handled through hid-multitouch. Since
> kernel v3.10, we have introduced the support of devices showing both a
> digitizer and a pen (they will show up as two input devices).
>
> I would encourage you to test a 3.10 kernel, and/or send me some
> traces of your devices by using hid-replay[1]. This way I will be able
> to test your device on my laptop, and eventually figure out any
> problem.
>
> Cheers,
Hi Benjamin,

   Thanks for the quick reply.

   3.10 is a no-go for me; I need to get this working on a vanilla (or 
upgraded) version of Ubuntu 12.04; so something more like kernel version 
3.2.  (Unfortunately, its what people are using in the field).

   I will, however, install a more modern kernel to test against; esp. 
since I note your HID-replay tool requires 3.6 to test with.

   Would the correct approach here be to implement a composite USB 
device and have separate USB interfaces for mouse, touch and pen for 
compatibility with older kernel revisions?

     Cheers,

     -Brett

Re: HID input dealing with multiple collections?

[Benjamin Tissoires]

On Mon, Sep 9, 2013 at 4:01 PM, Breton M. Saunders <bms20@brettnet.eu> wrote:
> On 09/09/13 14:12, Benjamin Tissoires wrote:
>>
>> Hi,
>>
>> On Mon, Sep 9, 2013 at 2:56 PM, Breton M. Saunders <bms20@brettnet.eu>
>> wrote:
>>>
>>> Hello,
>>>
>>>    I've written a USB device which supports multiple input devices:
>>>      * A touch surface digitizer (following Microsoft's specification)
>>>      * A pen surface digitizer
>>>      * A mouse emulator
>>>
>>>    In windows each of these interfaces are exposed as a separate top
>>> level
>>> collection, e.g.:
>>>    Usage_Page(Generic Desktop)
>>>    Usage(Mouse)
>>>    Collection(Application)
>>>         ...
>>>    End_Collection
>>>    Usage_Page(Digitzer)
>>>    Usage(Touch_Screen)
>>>    Collection(Application)
>>>       ...
>>>    End_Collection
>>>    Usage(Digitizer)
>>>    Usage(Pen)
>>>    Collection(Application)
>>>       ...
>>>    End_Collection
>>>
>>>    Now this descriptor works well in Windows; all reporting channels are
>>> exposed correctly as hid devices and mouse/multitouch/pen input all works
>>> correctly as expected.  In linux, however, this is not the case.  What I
>>> see
>>> is that if I drop out the touch/pen functionality then the mouse support
>>> works correctly.  Likewise, if I drop any pair of other top level
>>> collections such that I have exactly one top level collection the system
>>> works correctly.
>>>
>>>    Am I missing something here - as in: Have I made an error in my usage
>>> of
>>> top level collections, or is linux-input's hid support incapable of
>>> dealing
>>> with multiple top level collections?
>>
>> If it works under Windows, there are huge chances that your report
>> descriptor is good.
>>
>> However, under Linux, we use the report IDs to split (if required) the
>> different inputs.
>> The good thing for you is that if I understand correctly, the device
>> you are talking about should be handled through hid-multitouch. Since
>> kernel v3.10, we have introduced the support of devices showing both a
>> digitizer and a pen (they will show up as two input devices).
>>
>> I would encourage you to test a 3.10 kernel, and/or send me some
>> traces of your devices by using hid-replay[1]. This way I will be able
>> to test your device on my laptop, and eventually figure out any
>> problem.
>>
>> Cheers,
>
> Hi Benjamin,
>
>   Thanks for the quick reply.
>
>   3.10 is a no-go for me; I need to get this working on a vanilla (or
> upgraded) version of Ubuntu 12.04; so something more like kernel version
> 3.2.  (Unfortunately, its what people are using in the field).

You can still try to use my backport available here:
https://github.com/bentiss/hid-multitouch

it _should_ work on a 3.2. You only have to add your VID/PID in
hid-multitouch to make it work.

>
>   I will, however, install a more modern kernel to test against; esp. since
> I note your HID-replay tool requires 3.6 to test with.

well, it requires the module uhid, which is available in 3.6, but also
in my backport :)
run "modprobe uhid_compat" and run hid-replay against the
/dev/hidraw-compatN device.

Anyway, if this is too much of a pain, just send me the report
descriptor in hexadecimal (and some hexadecimal captures of your
events), I'll do the formatting myself.

>
>   Would the correct approach here be to implement a composite USB device and
> have separate USB interfaces for mouse, touch and pen for compatibility with
> older kernel revisions?

I would say no because I don't know what would be the behavior of
Windows. But if you don't care about Windows and if this solution
works, it's entirely up to you.

Cheers,
Benjamin

Re: HID input dealing with multiple collections?

[Breton M. Saunders]

HI Benjamin,
> You can still try to use my backport available here:
> https://github.com/bentiss/hid-multitouch
Great - thanks for that!  It may be a solution.
>
> it _should_ work on a 3.2. You only have to add your VID/PID in
> hid-multitouch to make it work.

Unfortunately not. It seems that writes on the device to the interrupt 
endpoint never complete; I haven't had the USB analyzer on this yet, but 
I suspect that the host running kernel 3.2 is not polling the endpoint.

I did upgrade my Mint13 box to Ubuntu's latest kernel 3.11; and the 
multitouch support looks pretty good.  It worked out of the box. 
However, the mouse channel support isn't working - if I cat /dev/mouse1 
or /dev/mouse2 I see no data coming over when I report mouse events from 
my device.

>
>>    I will, however, install a more modern kernel to test against; esp. since
>> I note your HID-replay tool requires 3.6 to test with.
> well, it requires the module uhid, which is available in 3.6, but also
> in my backport :)
> run "modprobe uhid_compat" and run hid-replay against the
> /dev/hidraw-compatN device.
>
> Anyway, if this is too much of a pain, just send me the report
> descriptor in hexadecimal (and some hexadecimal captures of your
> events), I'll do the formatting myself.
Let me check if I can do this; I may get permission to open up the 
descriptors too.

>>    Would the correct approach here be to implement a composite USB device and
>> have separate USB interfaces for mouse, touch and pen for compatibility with
>> older kernel revisions?
> I would say no because I don't know what would be the behavior of
> Windows. But if you don't care about Windows and if this solution
> works, it's entirely up to you.
>

I may have to resort to that approach.  I believe Microsoft added the 
mouse top level collection to support windows xp; so it may also just 
work out of the box if a separate mouse appears on the same interface.

Cheers,

-Brett