* g_hid and hid-multitouch compatibility?
@ 2011-05-27 15:33 Pablo Cases
2011-05-27 16:09 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Cases @ 2011-05-27 15:33 UTC (permalink / raw)
To: linux-input
Hi all,
I have searched the net and the archives of linux-input for information on how to use the Linux g_hid kernel module on a device and the hid-multitouch kernel module on a host to communicate multitouch events. But unfortunately I can only get single touch working.
Q: Has anyone successfully completed a g_hid <-> hid-multitouch setup? And is there a description somewhere of such setup?
Q: Is the Windows 7 multitouch USB HID descriptor the correct one to use also for Linux hid-multitouch? Or is some tweaking necessary?
DETAILED DESCRIPTION BELOW
The device is a Linux device that uses g_hid (currently 2.6.37 kernel) and a USB HID Report Descriptor for multitouch using two-touch parallel mode according to Microsoft document http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
On the host (ubuntu 11.04, 2.6.38 kernel) I register dynamically according to the description at http://lii-enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html. Using the events/rdesc files in debugfs on Ubuntu 11.04 I have validated the parsing of the report descriptor and the input reports.
Example multitouch input report from /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14 32 0e 02
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 0
GenericDesktop.X = 4773
GenericDesktop.Y = 3634
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 1
GenericDesktop.X = 5273
GenericDesktop.Y = 3634
Digitizers.ContactCount = 2
The first touch in the report is correctly presented both on Windows and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak to display data from all devices not just multitouch ones). I can see in the debugfs files that the data for the second touch data is correctly transferred and interpreted (see above), but the mapping to the linux input system seems a bit strange though (see below). My guess is that I have not been correctly registered as a multitouch device. I'm assuming this also because I cannot see any activity from the hid-multitouch module other than it being initialized when I connect my device (probably another reason for the needed tweak in mtdiag above).
Example mapping from /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc that does not look entirely correct for the second touch:
Digitizers.TipSwitch ---> Key.Touch
Digitizers.InRange ---> Key.ToolPen
Digitizers.ContactID ---> Absolute.Misc
GenericDesktop.X ---> Absolute.X
GenericDesktop.Y ---> Absolute.Y
Digitizers.TipSwitch ---> Key.Touch
Digitizers.InRange ---> Key.ToolRubber
Digitizers.ContactID ---> Absolute.?
GenericDesktop.X ---> Absolute.Z
GenericDesktop.Y ---> Absolute.Rx
Digitizers.ContactCount ---> Absolute.?
Button.0001 ---> Key.LeftBtn
Button.0002 ---> Key.RightBtn
Button.0003 ---> Key.MiddleBtn
GenericDesktop.X ---> Relative.X
GenericDesktop.Y ---> Relative.Y
GenericDesktop.Wheel ---> Relative.Wheel
Regards,
Pablo Cases
-------------------------
Pablo Cases, M.Sc.
Development Engineer Software
FlatFrog Laboratories AB
Magistratsvägen 10
22643 Lund
Sweden
Tel: +46 708 393816
Mail: pc@flatfrog.com
Web: www.flatfrog.com
--
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] 10+ messages in thread
* Re: g_hid and hid-multitouch compatibility?
2011-05-27 15:33 g_hid and hid-multitouch compatibility? Pablo Cases
@ 2011-05-27 16:09 ` Benjamin Tissoires
2011-05-27 22:08 ` Pablo Cases
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2011-05-27 16:09 UTC (permalink / raw)
To: Pablo Cases
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Pablo,
Adding Stéphane, Henrik and Jiri in CC.
On Fri, May 27, 2011 at 17:33, Pablo Cases <pablo.cases@flatfrog.com> wrote:
>
> Hi all,
>
> I have searched the net and the archives of linux-input for information on how to use the Linux g_hid kernel module on a device and the hid-multitouch kernel module on a host to communicate multitouch events. But unfortunately I can only get single touch working.
Excuse my ignorance, I didn't know g_hid existed before your mail. If
I understand it well enough, it's an hid emulation from user-space.
Are you trying to inject events from a device in user-space to the
kernel? If so, I think it would be easier to use uinput. And the funny
think was that I'm currently writing a small lib to inject mulitouch
events in a uinput device in an easier way.
>
> Q: Has anyone successfully completed a g_hid <-> hid-multitouch setup? And is there a description somewhere of such setup?
I don't think so, hid-multitouch is really new (since 2.6.38, and was
not very generic at this time).
> Q: Is the Windows 7 multitouch USB HID descriptor the correct one to use also for Linux hid-multitouch? Or is some tweaking necessary?
Normally, any valid Windows 7 multitouch USB HID descriptor can be
handled by hid-multitouch.
But it's more the events that are sent to hid-multitouch that will
tell if your device is compatible or not.
>
> DETAILED DESCRIPTION BELOW
> The device is a Linux device that uses g_hid (currently 2.6.37 kernel) and a USB HID Report Descriptor for multitouch using two-touch parallel mode according to Microsoft document http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
>
> On the host (ubuntu 11.04, 2.6.38 kernel) I register dynamically according to the description at http://lii-enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html. Using the events/rdesc files in debugfs on Ubuntu 11.04 I have validated the parsing of the report descriptor and the input reports.
This is really a bad idea to use these howto with ubuntu 11.04 ATM. I
didn't found the time to update this stuff, and this branch can not be
used in ubuntu 11.04 (it contains code for 2.6.35 only, and there were
changes in the hid layer after). If you only used the part "How to add
your device to hid-multitouch from the user space" without updating
your hid module, then it's as if you have'nt done anything (the
generic hid module can not autodetect multitouch devices).
>
> Example multitouch input report from /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
> report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14 32 0e 02
> Digitizers.TipSwitch = 1
> Digitizers.InRange = 1
> Digitizers.ContactID = 0
> GenericDesktop.X = 4773
> GenericDesktop.Y = 3634
> Digitizers.TipSwitch = 1
> Digitizers.InRange = 1
> Digitizers.ContactID = 1
> GenericDesktop.X = 5273
> GenericDesktop.Y = 3634
> Digitizers.ContactCount = 2
>
Most of the time, the problematic part comes from the releases. But
it's a good start.
> The first touch in the report is correctly presented both on Windows and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak to display data from all devices not just multitouch ones). I can see in the debugfs files that the data for the second touch data is correctly transferred and interpreted (see above), but the mapping to the linux input system seems a bit strange though (see below). My guess is that I have not been correctly registered as a multitouch device. I'm assuming this also because I cannot see any activity from the hid-multitouch module other than it being initialized when I connect my device (probably another reason for the needed tweak in mtdiag above).
>
> Example mapping from /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc that does not look entirely correct for the second touch:
> Digitizers.TipSwitch ---> Key.Touch
> Digitizers.InRange ---> Key.ToolPen
> Digitizers.ContactID ---> Absolute.Misc
> GenericDesktop.X ---> Absolute.X
> GenericDesktop.Y ---> Absolute.Y
> Digitizers.TipSwitch ---> Key.Touch
> Digitizers.InRange ---> Key.ToolRubber
> Digitizers.ContactID ---> Absolute.?
> GenericDesktop.X ---> Absolute.Z
> GenericDesktop.Y ---> Absolute.Rx
This means that your device is handled by the generic usbhid and not
hid-multitouch.
If you are trying to inject events from the user space, I strongly
recommend to use uinput instead. Let me know if you want to have my
little uinput-multitouch lib.
Cheers,
Benjamin
> Digitizers.ContactCount ---> Absolute.?
> Button.0001 ---> Key.LeftBtn
> Button.0002 ---> Key.RightBtn
> Button.0003 ---> Key.MiddleBtn
> GenericDesktop.X ---> Relative.X
> GenericDesktop.Y ---> Relative.Y
> GenericDesktop.Wheel ---> Relative.Wheel
>
>
> Regards,
> Pablo Cases
>
> -------------------------
> Pablo Cases, M.Sc.
> Development Engineer Software
> FlatFrog Laboratories AB
> Magistratsvägen 10
> 22643 Lund
> Sweden
> Tel: +46 708 393816
> Mail: pc@flatfrog.com
> Web: www.flatfrog.com
> --
> 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] 10+ messages in thread
* RE: g_hid and hid-multitouch compatibility?
2011-05-27 16:09 ` Benjamin Tissoires
@ 2011-05-27 22:08 ` Pablo Cases
2011-05-27 22:41 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Cases @ 2011-05-27 22:08 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Benjamin,
Thanks for the response. It is my ignorance that should be excused as I have shown/will show that I am the novice with regards to USB HID and multitouch in this forum :)
I´ll continue interleaving additional comments below.
-Pablo
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> Sent: den 27 maj 2011 18:10
> To: Pablo Cases
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> input@vger.kernel.org
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo,
>
> Adding Stéphane, Henrik and Jiri in CC.
>
> On Fri, May 27, 2011 at 17:33, Pablo Cases <pablo.cases@flatfrog.com>
> wrote:
> >
> > Hi all,
> >
> > I have searched the net and the archives of linux-input for
> information on how to use the Linux g_hid kernel module on a device and
> the hid-multitouch kernel module on a host to communicate multitouch
> events. But unfortunately I can only get single touch working.
>
> Excuse my ignorance, I didn't know g_hid existed before your mail. If
> I understand it well enough, it's an hid emulation from user-space.
> Are you trying to inject events from a device in user-space to the
> kernel? If so, I think it would be easier to use uinput. And the funny
> think was that I'm currently writing a small lib to inject mulitouch
> events in a uinput device in an easier way.
>
Maybe I misunderstand your explanation above but we´re not running g_hid and hid-multitouch on the same system. We have a separate hardware USB device running Linux with the g_hid kernel module loaded. On this device we then have (thanks to g_hid) a userspace file called /dev/hidg0 that we can write USB HID input reports to, which then will be sent through the device's gadget usb framework, through an physical USB cable, to a separate PC host running hid-multitouch.
> >
> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
> setup? And is there a description somewhere of such setup?
>
> I don't think so, hid-multitouch is really new (since 2.6.38, and was
> not very generic at this time).
>
> > Q: Is the Windows 7 multitouch USB HID descriptor the correct one to
> use also for Linux hid-multitouch? Or is some tweaking necessary?
>
> Normally, any valid Windows 7 multitouch USB HID descriptor can be
> handled by hid-multitouch.
> But it's more the events that are sent to hid-multitouch that will
> tell if your device is compatible or not.
>
> >
> > DETAILED DESCRIPTION BELOW
> > The device is a Linux device that uses g_hid (currently 2.6.37
> kernel) and a USB HID Report Descriptor for multitouch using two-touch
> parallel mode according to Microsoft document
> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
> >
> > On the host (ubuntu 11.04, 2.6.38 kernel) I register dynamically
> according to the description at http://lii-
> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html. Using
> the events/rdesc files in debugfs on Ubuntu 11.04 I have validated the
> parsing of the report descriptor and the input reports.
>
> This is really a bad idea to use these howto with ubuntu 11.04 ATM. I
> didn't found the time to update this stuff, and this branch can not be
> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there were
> changes in the hid layer after). If you only used the part "How to add
> your device to hid-multitouch from the user space" without updating
> your hid module, then it's as if you have'nt done anything (the
> generic hid module can not autodetect multitouch devices).
Currently I am using the hid-multitouch code as existing in the source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-get. In the page referred to above I have only used the "How to add your device to hid-multitouch from the user space", and not the 2.6.35 related parts.
Ok, so for autodetection of multitouch devices to work I need to update the hid-multitouch module to a newer version (than was available in 2.6.38), preferably head on a git master branch somewhere? Another option is to add a static configuration field in hid-multitouch and hid-ids.h for my USB device's VID/PID. But then again, maybe it's better to do that on the latest available code as well?
> >
> > Example multitouch input report from
> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14 32 0e
> 02
> > Digitizers.TipSwitch = 1
> > Digitizers.InRange = 1
> > Digitizers.ContactID = 0
> > GenericDesktop.X = 4773
> > GenericDesktop.Y = 3634
> > Digitizers.TipSwitch = 1
> > Digitizers.InRange = 1
> > Digitizers.ContactID = 1
> > GenericDesktop.X = 5273
> > GenericDesktop.Y = 3634
> > Digitizers.ContactCount = 2
> >
>
> Most of the time, the problematic part comes from the releases. But
> it's a good start.
With "releases" I assume you mean the finger removal from the touch surface, like a "touch-up" event? I have not implemented that part yet, but our Microsoft contact informed us that for Windows 7 compatibility it should be reported as a final touch report with
TipSwitch = 0
InRange = 1
Is this applicable to hid-multitouch too?
> > The first touch in the report is correctly presented both on Windows
> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak to
> display data from all devices not just multitouch ones). I can see in
> the debugfs files that the data for the second touch data is correctly
> transferred and interpreted (see above), but the mapping to the linux
> input system seems a bit strange though (see below). My guess is that I
> have not been correctly registered as a multitouch device. I'm assuming
> this also because I cannot see any activity from the hid-multitouch
> module other than it being initialized when I connect my device
> (probably another reason for the needed tweak in mtdiag above).
> >
> > Example mapping from /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
> that does not look entirely correct for the second touch:
> > Digitizers.TipSwitch ---> Key.Touch
> > Digitizers.InRange ---> Key.ToolPen
> > Digitizers.ContactID ---> Absolute.Misc
> > GenericDesktop.X ---> Absolute.X
> > GenericDesktop.Y ---> Absolute.Y
> > Digitizers.TipSwitch ---> Key.Touch
> > Digitizers.InRange ---> Key.ToolRubber
> > Digitizers.ContactID ---> Absolute.?
> > GenericDesktop.X ---> Absolute.Z
> > GenericDesktop.Y ---> Absolute.Rx
>
> This means that your device is handled by the generic usbhid and not
> hid-multitouch.
That is what troubles me. I can see in the host's dmesg that "generic-usb" seems to be the driver chosen for my device when it is connected to the host. And according to your comment above I might not have correctly registered my device in hid-multitouch which would be the source of the problem...
As a side note; I have sprinkled printk() here and there hid-multitouch.c and hid-core.c. While running the code I can only see that mt_init() and mt_exit() are called during module loading/unloading; never do I see any evidence of that the probing or mapping functions in hid-multitouch are used, only the generic usb parts are used for parsing the report descriptors and input reports.
Could you point me to the location in the code where the decision is taken to use the hid-multitouch driver for a hid-multitouch supported device? I'm guessing it is somewhere in hid-core.c but I have not been able to pinpoint the location exactly. I could use this location as a start point to backtrace why we're not considered as a hid-multitouch supported device.
> If you are trying to inject events from the user space, I strongly
> recommend to use uinput instead. Let me know if you want to have my
> little uinput-multitouch lib.
>
> Cheers,
> Benjamin
>
> > Digitizers.ContactCount ---> Absolute.?
> > Button.0001 ---> Key.LeftBtn
> > Button.0002 ---> Key.RightBtn
> > Button.0003 ---> Key.MiddleBtn
> > GenericDesktop.X ---> Relative.X
> > GenericDesktop.Y ---> Relative.Y
> > GenericDesktop.Wheel ---> Relative.Wheel
> >
> >
> > Regards,
> > Pablo Cases
> >
> > -------------------------
> > Pablo Cases, M.Sc.
> > Development Engineer Software
> > FlatFrog Laboratories AB
> > Magistratsvägen 10
> > 22643 Lund
> > Sweden
> > Tel: +46 708 393816
> > Mail: pc@flatfrog.com
> > Web: www.flatfrog.com
> > --
> > 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] 10+ messages in thread
* Re: g_hid and hid-multitouch compatibility?
2011-05-27 22:08 ` Pablo Cases
@ 2011-05-27 22:41 ` Benjamin Tissoires
2011-05-30 16:11 ` Pablo Cases
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2011-05-27 22:41 UTC (permalink / raw)
To: Pablo Cases
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Pablo
On Sat, May 28, 2011 at 00:08, Pablo Cases <pablo.cases@flatfrog.com> wrote:
> Hi Benjamin,
>
> Thanks for the response. It is my ignorance that should be excused as I have shown/will show that I am the novice with regards to USB HID and multitouch in this forum :)
> I´ll continue interleaving additional comments below.
>
> -Pablo
>
>> -----Original Message-----
>> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>> Sent: den 27 maj 2011 18:10
>> To: Pablo Cases
>> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>> input@vger.kernel.org
>> Subject: Re: g_hid and hid-multitouch compatibility?
>>
>> Hi Pablo,
>>
>> Adding Stéphane, Henrik and Jiri in CC.
>>
>> On Fri, May 27, 2011 at 17:33, Pablo Cases <pablo.cases@flatfrog.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > I have searched the net and the archives of linux-input for
>> information on how to use the Linux g_hid kernel module on a device and
>> the hid-multitouch kernel module on a host to communicate multitouch
>> events. But unfortunately I can only get single touch working.
>>
>> Excuse my ignorance, I didn't know g_hid existed before your mail. If
>> I understand it well enough, it's an hid emulation from user-space.
>> Are you trying to inject events from a device in user-space to the
>> kernel? If so, I think it would be easier to use uinput. And the funny
>> think was that I'm currently writing a small lib to inject mulitouch
>> events in a uinput device in an easier way.
>>
>
> Maybe I misunderstand your explanation above but we´re not running g_hid and hid-multitouch on the same system. We have a separate hardware USB device running Linux with the g_hid kernel module loaded. On this device we then have (thanks to g_hid) a userspace file called /dev/hidg0 that we can write USB HID input reports to, which then will be sent through the device's gadget usb framework, through an physical USB cable, to a separate PC host running hid-multitouch.
Thanks for the explaination. I didn't knew that it was possible to do
such things. Linux is really a wonderful world ;-)
>
>> >
>> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
>> setup? And is there a description somewhere of such setup?
>>
>> I don't think so, hid-multitouch is really new (since 2.6.38, and was
>> not very generic at this time).
>>
>> > Q: Is the Windows 7 multitouch USB HID descriptor the correct one to
>> use also for Linux hid-multitouch? Or is some tweaking necessary?
>>
>> Normally, any valid Windows 7 multitouch USB HID descriptor can be
>> handled by hid-multitouch.
>> But it's more the events that are sent to hid-multitouch that will
>> tell if your device is compatible or not.
>>
>> >
>> > DETAILED DESCRIPTION BELOW
>> > The device is a Linux device that uses g_hid (currently 2.6.37
>> kernel) and a USB HID Report Descriptor for multitouch using two-touch
>> parallel mode according to Microsoft document
>> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
>> >
>> > On the host (ubuntu 11.04, 2.6.38 kernel) I register dynamically
>> according to the description at http://lii-
>> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html. Using
>> the events/rdesc files in debugfs on Ubuntu 11.04 I have validated the
>> parsing of the report descriptor and the input reports.
>>
>> This is really a bad idea to use these howto with ubuntu 11.04 ATM. I
>> didn't found the time to update this stuff, and this branch can not be
>> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there were
>> changes in the hid layer after). If you only used the part "How to add
>> your device to hid-multitouch from the user space" without updating
>> your hid module, then it's as if you have'nt done anything (the
>> generic hid module can not autodetect multitouch devices).
>
> Currently I am using the hid-multitouch code as existing in the source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-get. In the page referred to above I have only used the "How to add your device to hid-multitouch from the user space", and not the 2.6.35 related parts.
So there are no autodetection in your kernel.
>
> Ok, so for autodetection of multitouch devices to work I need to update the hid-multitouch module to a newer version (than was available in 2.6.38), preferably head on a git master branch somewhere? Another option is to add a static configuration field in hid-multitouch and hid-ids.h for my USB device's VID/PID. But then again, maybe it's better to do that on the latest available code as well?
Autodetection is not available upstream too, sorry. The latest
available code is on Jiri's tree. I'll try to maintain a bunch of
patches to backport the work done on hid-multitouch since 2.6.35 on
http://lii-enac.fr/en/architecture/linux-input/multitouch-howto.html#hid-multitouch
but I'm a little late for the backports right now.
Jiri's tree is at
http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
>
>> >
>> > Example multitouch input report from
>> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
>> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14 32 0e
>> 02
>> > Digitizers.TipSwitch = 1
>> > Digitizers.InRange = 1
>> > Digitizers.ContactID = 0
>> > GenericDesktop.X = 4773
>> > GenericDesktop.Y = 3634
>> > Digitizers.TipSwitch = 1
>> > Digitizers.InRange = 1
>> > Digitizers.ContactID = 1
>> > GenericDesktop.X = 5273
>> > GenericDesktop.Y = 3634
>> > Digitizers.ContactCount = 2
>> >
>>
>> Most of the time, the problematic part comes from the releases. But
>> it's a good start.
>
> With "releases" I assume you mean the finger removal from the touch surface, like a "touch-up" event? I have not implemented that part yet, but our Microsoft contact informed us that for Windows 7 compatibility it should be reported as a final touch report with
> TipSwitch = 0
> InRange = 1
> Is this applicable to hid-multitouch too?
Exactly, I meant touch-up. Your behavior is applicable to hid-multitouch.
Once registering your device with hid-multitouch, you can choose a
class that controls how optimized your driver will be. Normally, the
MT_CLS_DEFAULT class will work with any Win 7 compliant device
(crossing fingers).
Then, you can optimize it by looking for the classes that have
MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time, you
can also optimize the way your device actually does the match between
slots (from 0 to N-1 with N the maximum contact count of your device)
and the tracking_id reported by the device (or the position in the hid
report).
For dual touches only devices, the differences are not big, but we
prefer to optimize things all the time ;-)
>
>> > The first touch in the report is correctly presented both on Windows
>> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak to
>> display data from all devices not just multitouch ones). I can see in
>> the debugfs files that the data for the second touch data is correctly
>> transferred and interpreted (see above), but the mapping to the linux
>> input system seems a bit strange though (see below). My guess is that I
>> have not been correctly registered as a multitouch device. I'm assuming
>> this also because I cannot see any activity from the hid-multitouch
>> module other than it being initialized when I connect my device
>> (probably another reason for the needed tweak in mtdiag above).
>> >
>> > Example mapping from /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>> that does not look entirely correct for the second touch:
>> > Digitizers.TipSwitch ---> Key.Touch
>> > Digitizers.InRange ---> Key.ToolPen
>> > Digitizers.ContactID ---> Absolute.Misc
>> > GenericDesktop.X ---> Absolute.X
>> > GenericDesktop.Y ---> Absolute.Y
>> > Digitizers.TipSwitch ---> Key.Touch
>> > Digitizers.InRange ---> Key.ToolRubber
>> > Digitizers.ContactID ---> Absolute.?
>> > GenericDesktop.X ---> Absolute.Z
>> > GenericDesktop.Y ---> Absolute.Rx
>>
>> This means that your device is handled by the generic usbhid and not
>> hid-multitouch.
>
> That is what troubles me. I can see in the host's dmesg that "generic-usb" seems to be the driver chosen for my device when it is connected to the host. And according to your comment above I might not have correctly registered my device in hid-multitouch which would be the source of the problem...
>
> As a side note; I have sprinkled printk() here and there hid-multitouch.c and hid-core.c. While running the code I can only see that mt_init() and mt_exit() are called during module loading/unloading; never do I see any evidence of that the probing or mapping functions in hid-multitouch are used, only the generic usb parts are used for parsing the report descriptors and input reports.
Yep, hid-multitouch does not handle your device. There is currently no
user-space way to tell usbhid (the generic) not to handle a device.
You'll have to add your VID-PID to the hid_have_special_driver list
(in hid-core.c) to disable generic usb hid handling for your device.
You can check the latest patches adding a specific device to
hid-multitouch to have some examples.
>
> Could you point me to the location in the code where the decision is taken to use the hid-multitouch driver for a hid-multitouch supported device? I'm guessing it is somewhere in hid-core.c but I have not been able to pinpoint the location exactly. I could use this location as a start point to backtrace why we're not considered as a hid-multitouch supported device.
it's just above ;-) hid_have_special_driver in hid-core.c
Cheers,
Benjamin
>
>> If you are trying to inject events from the user space, I strongly
>> recommend to use uinput instead. Let me know if you want to have my
>> little uinput-multitouch lib.
>>
>> Cheers,
>> Benjamin
>>
>> > Digitizers.ContactCount ---> Absolute.?
>> > Button.0001 ---> Key.LeftBtn
>> > Button.0002 ---> Key.RightBtn
>> > Button.0003 ---> Key.MiddleBtn
>> > GenericDesktop.X ---> Relative.X
>> > GenericDesktop.Y ---> Relative.Y
>> > GenericDesktop.Wheel ---> Relative.Wheel
>> >
>> >
>> > Regards,
>> > Pablo Cases
>> >
>> > -------------------------
>> > Pablo Cases, M.Sc.
>> > Development Engineer Software
>> > FlatFrog Laboratories AB
>> > Magistratsvägen 10
>> > 22643 Lund
>> > Sweden
>> > Tel: +46 708 393816
>> > Mail: pc@flatfrog.com
>> > Web: www.flatfrog.com
>> > --
>> > 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] 10+ messages in thread
* RE: g_hid and hid-multitouch compatibility?
2011-05-27 22:41 ` Benjamin Tissoires
@ 2011-05-30 16:11 ` Pablo Cases
2011-05-31 11:19 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Cases @ 2011-05-30 16:11 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Benjamin,
Now things seem to work a lot better thanks to your input :) I'm still on the 2.6.38 version of the multitouch code, but static registering works after adding our faked USB VIP/PID to hid.ids.c, hid-core.c and hid-multitouch.c:
Digitizers.TipSwitch ---> Key.Touch
Digitizers.InRange ---> Sync.Report
Digitizers.ContactID ---> Sync.Report
GenericDesktop.X ---> Absolute.MTPositionX
GenericDesktop.Y ---> Absolute.MTPositionY
Digitizers.TipSwitch ---> Key.Touch
Digitizers.InRange ---> Sync.Report
Digitizers.ContactID ---> Sync.Report
GenericDesktop.X ---> Absolute.MTPositionX
GenericDesktop.Y ---> Absolute.MTPositionY
Digitizers.ContactCount ---> Sync.Report
Button.0001 ---> Key.LeftBtn
Button.0002 ---> Key.RightBtn
Button.0003 ---> Key.MiddleBtn
GenericDesktop.X ---> Absolute.MTPositionX
GenericDesktop.Y ---> Absolute.MTPositionY
GenericDesktop.Wheel ---> Relative.Wheel
Running some diagnostics:
workstation$ sudo python eviocg.py /dev/input/event3
the device '/dev/input/event3' is multitouch enabled with the protocol B.
An unmodified version of mtdiag now discovers our multitouch device, but I cannot get any valid touch output in the "drawing surface" of the application. You mentioned that I could optimize things by using some of the quirk defined, but is this necessary or optional? If I'm reporting as the Windows 7 specification describes do I still need to use any of the quirks? Specially I'm wondering about the quirks that relate to contact id/contact number and slots. Do I really need to think about slots at all if I have valid ContactIDs in my reports?
Regards,
Pablo
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> Sent: den 28 maj 2011 00:42
> To: Pablo Cases
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> input@vger.kernel.org
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo
>
> On Sat, May 28, 2011 at 00:08, Pablo Cases <pablo.cases@flatfrog.com>
> wrote:
> > Hi Benjamin,
> >
> > Thanks for the response. It is my ignorance that should be excused as
> I have shown/will show that I am the novice with regards to USB HID and
> multitouch in this forum :)
> > I´ll continue interleaving additional comments below.
> >
> > -Pablo
> >
> >> -----Original Message-----
> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> >> Sent: den 27 maj 2011 18:10
> >> To: Pablo Cases
> >> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> >> input@vger.kernel.org
> >> Subject: Re: g_hid and hid-multitouch compatibility?
> >>
> >> Hi Pablo,
> >>
> >> Adding Stéphane, Henrik and Jiri in CC.
> >>
> >> On Fri, May 27, 2011 at 17:33, Pablo Cases
> <pablo.cases@flatfrog.com>
> >> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > I have searched the net and the archives of linux-input for
> >> information on how to use the Linux g_hid kernel module on a device
> and
> >> the hid-multitouch kernel module on a host to communicate multitouch
> >> events. But unfortunately I can only get single touch working.
> >>
> >> Excuse my ignorance, I didn't know g_hid existed before your mail.
> If
> >> I understand it well enough, it's an hid emulation from user-space.
> >> Are you trying to inject events from a device in user-space to the
> >> kernel? If so, I think it would be easier to use uinput. And the
> funny
> >> think was that I'm currently writing a small lib to inject mulitouch
> >> events in a uinput device in an easier way.
> >>
> >
> > Maybe I misunderstand your explanation above but we´re not running
> g_hid and hid-multitouch on the same system. We have a separate
> hardware USB device running Linux with the g_hid kernel module loaded.
> On this device we then have (thanks to g_hid) a userspace file called
> /dev/hidg0 that we can write USB HID input reports to, which then will
> be sent through the device's gadget usb framework, through an physical
> USB cable, to a separate PC host running hid-multitouch.
>
> Thanks for the explaination. I didn't knew that it was possible to do
> such things. Linux is really a wonderful world ;-)
>
> >
> >> >
> >> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
> >> setup? And is there a description somewhere of such setup?
> >>
> >> I don't think so, hid-multitouch is really new (since 2.6.38, and
> was
> >> not very generic at this time).
> >>
> >> > Q: Is the Windows 7 multitouch USB HID descriptor the correct one
> to
> >> use also for Linux hid-multitouch? Or is some tweaking necessary?
> >>
> >> Normally, any valid Windows 7 multitouch USB HID descriptor can be
> >> handled by hid-multitouch.
> >> But it's more the events that are sent to hid-multitouch that will
> >> tell if your device is compatible or not.
> >>
> >> >
> >> > DETAILED DESCRIPTION BELOW
> >> > The device is a Linux device that uses g_hid (currently 2.6.37
> >> kernel) and a USB HID Report Descriptor for multitouch using two-
> touch
> >> parallel mode according to Microsoft document
> >> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
> >> >
> >> > On the host (ubuntu 11.04, 2.6.38 kernel) I register dynamically
> >> according to the description at http://lii-
> >> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html.
> Using
> >> the events/rdesc files in debugfs on Ubuntu 11.04 I have validated
> the
> >> parsing of the report descriptor and the input reports.
> >>
> >> This is really a bad idea to use these howto with ubuntu 11.04 ATM.
> I
> >> didn't found the time to update this stuff, and this branch can not
> be
> >> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there
> were
> >> changes in the hid layer after). If you only used the part "How to
> add
> >> your device to hid-multitouch from the user space" without updating
> >> your hid module, then it's as if you have'nt done anything (the
> >> generic hid module can not autodetect multitouch devices).
> >
> > Currently I am using the hid-multitouch code as existing in the
> source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-get.
> In the page referred to above I have only used the "How to add your
> device to hid-multitouch from the user space", and not the 2.6.35
> related parts.
>
> So there are no autodetection in your kernel.
>
> >
> > Ok, so for autodetection of multitouch devices to work I need to
> update the hid-multitouch module to a newer version (than was available
> in 2.6.38), preferably head on a git master branch somewhere? Another
> option is to add a static configuration field in hid-multitouch and
> hid-ids.h for my USB device's VID/PID. But then again, maybe it's
> better to do that on the latest available code as well?
>
> Autodetection is not available upstream too, sorry. The latest
> available code is on Jiri's tree. I'll try to maintain a bunch of
> patches to backport the work done on hid-multitouch since 2.6.35 on
> http://lii-enac.fr/en/architecture/linux-input/multitouch-
> howto.html#hid-multitouch
> but I'm a little late for the backports right now.
>
> Jiri's tree is at
> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
>
> >
> >> >
> >> > Example multitouch input report from
> >> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
> >> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14 32
> 0e
> >> 02
> >> > Digitizers.TipSwitch = 1
> >> > Digitizers.InRange = 1
> >> > Digitizers.ContactID = 0
> >> > GenericDesktop.X = 4773
> >> > GenericDesktop.Y = 3634
> >> > Digitizers.TipSwitch = 1
> >> > Digitizers.InRange = 1
> >> > Digitizers.ContactID = 1
> >> > GenericDesktop.X = 5273
> >> > GenericDesktop.Y = 3634
> >> > Digitizers.ContactCount = 2
> >> >
> >>
> >> Most of the time, the problematic part comes from the releases. But
> >> it's a good start.
> >
> > With "releases" I assume you mean the finger removal from the touch
> surface, like a "touch-up" event? I have not implemented that part yet,
> but our Microsoft contact informed us that for Windows 7 compatibility
> it should be reported as a final touch report with
> > TipSwitch = 0
> > InRange = 1
> > Is this applicable to hid-multitouch too?
>
> Exactly, I meant touch-up. Your behavior is applicable to hid-
> multitouch.
>
> Once registering your device with hid-multitouch, you can choose a
> class that controls how optimized your driver will be. Normally, the
> MT_CLS_DEFAULT class will work with any Win 7 compliant device
> (crossing fingers).
>
> Then, you can optimize it by looking for the classes that have
> MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time, you
> can also optimize the way your device actually does the match between
> slots (from 0 to N-1 with N the maximum contact count of your device)
> and the tracking_id reported by the device (or the position in the hid
> report).
> For dual touches only devices, the differences are not big, but we
> prefer to optimize things all the time ;-)
>
> >
> >> > The first touch in the report is correctly presented both on
> Windows
> >> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak to
> >> display data from all devices not just multitouch ones). I can see
> in
> >> the debugfs files that the data for the second touch data is
> correctly
> >> transferred and interpreted (see above), but the mapping to the
> linux
> >> input system seems a bit strange though (see below). My guess is
> that I
> >> have not been correctly registered as a multitouch device. I'm
> assuming
> >> this also because I cannot see any activity from the hid-multitouch
> >> module other than it being initialized when I connect my device
> >> (probably another reason for the needed tweak in mtdiag above).
> >> >
> >> > Example mapping from
> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
> >> that does not look entirely correct for the second touch:
> >> > Digitizers.TipSwitch ---> Key.Touch
> >> > Digitizers.InRange ---> Key.ToolPen
> >> > Digitizers.ContactID ---> Absolute.Misc
> >> > GenericDesktop.X ---> Absolute.X
> >> > GenericDesktop.Y ---> Absolute.Y
> >> > Digitizers.TipSwitch ---> Key.Touch
> >> > Digitizers.InRange ---> Key.ToolRubber
> >> > Digitizers.ContactID ---> Absolute.?
> >> > GenericDesktop.X ---> Absolute.Z
> >> > GenericDesktop.Y ---> Absolute.Rx
> >>
> >> This means that your device is handled by the generic usbhid and not
> >> hid-multitouch.
> >
> > That is what troubles me. I can see in the host's dmesg that
> "generic-usb" seems to be the driver chosen for my device when it is
> connected to the host. And according to your comment above I might not
> have correctly registered my device in hid-multitouch which would be
> the source of the problem...
> >
> > As a side note; I have sprinkled printk() here and there hid-
> multitouch.c and hid-core.c. While running the code I can only see that
> mt_init() and mt_exit() are called during module loading/unloading;
> never do I see any evidence of that the probing or mapping functions in
> hid-multitouch are used, only the generic usb parts are used for
> parsing the report descriptors and input reports.
>
> Yep, hid-multitouch does not handle your device. There is currently no
> user-space way to tell usbhid (the generic) not to handle a device.
> You'll have to add your VID-PID to the hid_have_special_driver list
> (in hid-core.c) to disable generic usb hid handling for your device.
> You can check the latest patches adding a specific device to
> hid-multitouch to have some examples.
>
> >
> > Could you point me to the location in the code where the decision is
> taken to use the hid-multitouch driver for a hid-multitouch supported
> device? I'm guessing it is somewhere in hid-core.c but I have not been
> able to pinpoint the location exactly. I could use this location as a
> start point to backtrace why we're not considered as a hid-multitouch
> supported device.
>
> it's just above ;-) hid_have_special_driver in hid-core.c
>
> Cheers,
> Benjamin
>
> >
> >> If you are trying to inject events from the user space, I strongly
> >> recommend to use uinput instead. Let me know if you want to have my
> >> little uinput-multitouch lib.
> >>
> >> Cheers,
> >> Benjamin
> >>
> >> > Digitizers.ContactCount ---> Absolute.?
> >> > Button.0001 ---> Key.LeftBtn
> >> > Button.0002 ---> Key.RightBtn
> >> > Button.0003 ---> Key.MiddleBtn
> >> > GenericDesktop.X ---> Relative.X
> >> > GenericDesktop.Y ---> Relative.Y
> >> > GenericDesktop.Wheel ---> Relative.Wheel
> >> >
> >> >
> >> > Regards,
> >> > Pablo Cases
> >> >
> >> > -------------------------
> >> > Pablo Cases, M.Sc.
> >> > Development Engineer Software
> >> > FlatFrog Laboratories AB
> >> > Magistratsvägen 10
> >> > 22643 Lund
> >> > Sweden
> >> > Tel: +46 708 393816
> >> > Mail: pc@flatfrog.com
> >> > Web: www.flatfrog.com
> >> > --
> >> > 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] 10+ messages in thread
* Re: g_hid and hid-multitouch compatibility?
2011-05-30 16:11 ` Pablo Cases
@ 2011-05-31 11:19 ` Benjamin Tissoires
2011-05-31 16:03 ` Pablo Cases
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2011-05-31 11:19 UTC (permalink / raw)
To: Pablo Cases
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Pablo,
On Mon, May 30, 2011 at 18:11, Pablo Cases <pablo.cases@flatfrog.com> wrote:
> Hi Benjamin,
>
> Now things seem to work a lot better thanks to your input :) I'm still on the 2.6.38 version of the multitouch code, but static registering works after adding our faked USB VIP/PID to hid.ids.c, hid-core.c and hid-multitouch.c:
>
> Digitizers.TipSwitch ---> Key.Touch
> Digitizers.InRange ---> Sync.Report
> Digitizers.ContactID ---> Sync.Report
> GenericDesktop.X ---> Absolute.MTPositionX
> GenericDesktop.Y ---> Absolute.MTPositionY
> Digitizers.TipSwitch ---> Key.Touch
> Digitizers.InRange ---> Sync.Report
> Digitizers.ContactID ---> Sync.Report
> GenericDesktop.X ---> Absolute.MTPositionX
> GenericDesktop.Y ---> Absolute.MTPositionY
> Digitizers.ContactCount ---> Sync.Report
> Button.0001 ---> Key.LeftBtn
> Button.0002 ---> Key.RightBtn
> Button.0003 ---> Key.MiddleBtn
> GenericDesktop.X ---> Absolute.MTPositionX
> GenericDesktop.Y ---> Absolute.MTPositionY
> GenericDesktop.Wheel ---> Relative.Wheel
>
> Running some diagnostics:
> workstation$ sudo python eviocg.py /dev/input/event3
> the device '/dev/input/event3' is multitouch enabled with the protocol B.
Can you send me the output of the command "evtest /dev/input/event3"
while moving/releasing fingers? I'm particularly interested in the
headers of this output (with the maximum of the ABS_MT_SLOTS).
Can you also send the full reports descriptor from
/sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>
> An unmodified version of mtdiag now discovers our multitouch device, but I cannot get any valid touch output in the "drawing surface" of the application. You mentioned that I could optimize things by using some of the quirk defined, but is this necessary or optional?
purely optional. (normally)
> If I'm reporting as the Windows 7 specification describes do I still need to use any of the quirks?
the point is that many hardware makers interpreted differently this
documentation (that's why we have those quirks). I'm not sure how
Microsoft handles this mess, but it may be even more complicated than
our hid-multitouch... So I can not guarantee that it will work out of
the box.
The big point lies in the understanding of the different
significations of the fields during a touch life time.
> Specially I'm wondering about the quirks that relate to contact id/contact number and slots. Do I really need to think about slots at all if I have valid ContactIDs in my reports?
Well it's optimization, so it's optional (though I prefer, because it
avoids finding elements in lists).
Cheers,
Benjamin
>
> Regards,
> Pablo
>
>
>> -----Original Message-----
>> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>> Sent: den 28 maj 2011 00:42
>> To: Pablo Cases
>> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>> input@vger.kernel.org
>> Subject: Re: g_hid and hid-multitouch compatibility?
>>
>> Hi Pablo
>>
>> On Sat, May 28, 2011 at 00:08, Pablo Cases <pablo.cases@flatfrog.com>
>> wrote:
>> > Hi Benjamin,
>> >
>> > Thanks for the response. It is my ignorance that should be excused as
>> I have shown/will show that I am the novice with regards to USB HID and
>> multitouch in this forum :)
>> > I´ll continue interleaving additional comments below.
>> >
>> > -Pablo
>> >
>> >> -----Original Message-----
>> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>> >> Sent: den 27 maj 2011 18:10
>> >> To: Pablo Cases
>> >> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>> >> input@vger.kernel.org
>> >> Subject: Re: g_hid and hid-multitouch compatibility?
>> >>
>> >> Hi Pablo,
>> >>
>> >> Adding Stéphane, Henrik and Jiri in CC.
>> >>
>> >> On Fri, May 27, 2011 at 17:33, Pablo Cases
>> <pablo.cases@flatfrog.com>
>> >> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > I have searched the net and the archives of linux-input for
>> >> information on how to use the Linux g_hid kernel module on a device
>> and
>> >> the hid-multitouch kernel module on a host to communicate multitouch
>> >> events. But unfortunately I can only get single touch working.
>> >>
>> >> Excuse my ignorance, I didn't know g_hid existed before your mail.
>> If
>> >> I understand it well enough, it's an hid emulation from user-space.
>> >> Are you trying to inject events from a device in user-space to the
>> >> kernel? If so, I think it would be easier to use uinput. And the
>> funny
>> >> think was that I'm currently writing a small lib to inject mulitouch
>> >> events in a uinput device in an easier way.
>> >>
>> >
>> > Maybe I misunderstand your explanation above but we´re not running
>> g_hid and hid-multitouch on the same system. We have a separate
>> hardware USB device running Linux with the g_hid kernel module loaded.
>> On this device we then have (thanks to g_hid) a userspace file called
>> /dev/hidg0 that we can write USB HID input reports to, which then will
>> be sent through the device's gadget usb framework, through an physical
>> USB cable, to a separate PC host running hid-multitouch.
>>
>> Thanks for the explaination. I didn't knew that it was possible to do
>> such things. Linux is really a wonderful world ;-)
>>
>> >
>> >> >
>> >> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
>> >> setup? And is there a description somewhere of such setup?
>> >>
>> >> I don't think so, hid-multitouch is really new (since 2.6.38, and
>> was
>> >> not very generic at this time).
>> >>
>> >> > Q: Is the Windows 7 multitouch USB HID descriptor the correct one
>> to
>> >> use also for Linux hid-multitouch? Or is some tweaking necessary?
>> >>
>> >> Normally, any valid Windows 7 multitouch USB HID descriptor can be
>> >> handled by hid-multitouch.
>> >> But it's more the events that are sent to hid-multitouch that will
>> >> tell if your device is compatible or not.
>> >>
>> >> >
>> >> > DETAILED DESCRIPTION BELOW
>> >> > The device is a Linux device that uses g_hid (currently 2.6.37
>> >> kernel) and a USB HID Report Descriptor for multitouch using two-
>> touch
>> >> parallel mode according to Microsoft document
>> >> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
>> >> >
>> >> > On the host (ubuntu 11.04, 2.6.38 kernel) I register dynamically
>> >> according to the description at http://lii-
>> >> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html.
>> Using
>> >> the events/rdesc files in debugfs on Ubuntu 11.04 I have validated
>> the
>> >> parsing of the report descriptor and the input reports.
>> >>
>> >> This is really a bad idea to use these howto with ubuntu 11.04 ATM.
>> I
>> >> didn't found the time to update this stuff, and this branch can not
>> be
>> >> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there
>> were
>> >> changes in the hid layer after). If you only used the part "How to
>> add
>> >> your device to hid-multitouch from the user space" without updating
>> >> your hid module, then it's as if you have'nt done anything (the
>> >> generic hid module can not autodetect multitouch devices).
>> >
>> > Currently I am using the hid-multitouch code as existing in the
>> source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-get.
>> In the page referred to above I have only used the "How to add your
>> device to hid-multitouch from the user space", and not the 2.6.35
>> related parts.
>>
>> So there are no autodetection in your kernel.
>>
>> >
>> > Ok, so for autodetection of multitouch devices to work I need to
>> update the hid-multitouch module to a newer version (than was available
>> in 2.6.38), preferably head on a git master branch somewhere? Another
>> option is to add a static configuration field in hid-multitouch and
>> hid-ids.h for my USB device's VID/PID. But then again, maybe it's
>> better to do that on the latest available code as well?
>>
>> Autodetection is not available upstream too, sorry. The latest
>> available code is on Jiri's tree. I'll try to maintain a bunch of
>> patches to backport the work done on hid-multitouch since 2.6.35 on
>> http://lii-enac.fr/en/architecture/linux-input/multitouch-
>> howto.html#hid-multitouch
>> but I'm a little late for the backports right now.
>>
>> Jiri's tree is at
>> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
>>
>> >
>> >> >
>> >> > Example multitouch input report from
>> >> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
>> >> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14 32
>> 0e
>> >> 02
>> >> > Digitizers.TipSwitch = 1
>> >> > Digitizers.InRange = 1
>> >> > Digitizers.ContactID = 0
>> >> > GenericDesktop.X = 4773
>> >> > GenericDesktop.Y = 3634
>> >> > Digitizers.TipSwitch = 1
>> >> > Digitizers.InRange = 1
>> >> > Digitizers.ContactID = 1
>> >> > GenericDesktop.X = 5273
>> >> > GenericDesktop.Y = 3634
>> >> > Digitizers.ContactCount = 2
>> >> >
>> >>
>> >> Most of the time, the problematic part comes from the releases. But
>> >> it's a good start.
>> >
>> > With "releases" I assume you mean the finger removal from the touch
>> surface, like a "touch-up" event? I have not implemented that part yet,
>> but our Microsoft contact informed us that for Windows 7 compatibility
>> it should be reported as a final touch report with
>> > TipSwitch = 0
>> > InRange = 1
>> > Is this applicable to hid-multitouch too?
>>
>> Exactly, I meant touch-up. Your behavior is applicable to hid-
>> multitouch.
>>
>> Once registering your device with hid-multitouch, you can choose a
>> class that controls how optimized your driver will be. Normally, the
>> MT_CLS_DEFAULT class will work with any Win 7 compliant device
>> (crossing fingers).
>>
>> Then, you can optimize it by looking for the classes that have
>> MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time, you
>> can also optimize the way your device actually does the match between
>> slots (from 0 to N-1 with N the maximum contact count of your device)
>> and the tracking_id reported by the device (or the position in the hid
>> report).
>> For dual touches only devices, the differences are not big, but we
>> prefer to optimize things all the time ;-)
>>
>> >
>> >> > The first touch in the report is correctly presented both on
>> Windows
>> >> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak to
>> >> display data from all devices not just multitouch ones). I can see
>> in
>> >> the debugfs files that the data for the second touch data is
>> correctly
>> >> transferred and interpreted (see above), but the mapping to the
>> linux
>> >> input system seems a bit strange though (see below). My guess is
>> that I
>> >> have not been correctly registered as a multitouch device. I'm
>> assuming
>> >> this also because I cannot see any activity from the hid-multitouch
>> >> module other than it being initialized when I connect my device
>> >> (probably another reason for the needed tweak in mtdiag above).
>> >> >
>> >> > Example mapping from
>> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>> >> that does not look entirely correct for the second touch:
>> >> > Digitizers.TipSwitch ---> Key.Touch
>> >> > Digitizers.InRange ---> Key.ToolPen
>> >> > Digitizers.ContactID ---> Absolute.Misc
>> >> > GenericDesktop.X ---> Absolute.X
>> >> > GenericDesktop.Y ---> Absolute.Y
>> >> > Digitizers.TipSwitch ---> Key.Touch
>> >> > Digitizers.InRange ---> Key.ToolRubber
>> >> > Digitizers.ContactID ---> Absolute.?
>> >> > GenericDesktop.X ---> Absolute.Z
>> >> > GenericDesktop.Y ---> Absolute.Rx
>> >>
>> >> This means that your device is handled by the generic usbhid and not
>> >> hid-multitouch.
>> >
>> > That is what troubles me. I can see in the host's dmesg that
>> "generic-usb" seems to be the driver chosen for my device when it is
>> connected to the host. And according to your comment above I might not
>> have correctly registered my device in hid-multitouch which would be
>> the source of the problem...
>> >
>> > As a side note; I have sprinkled printk() here and there hid-
>> multitouch.c and hid-core.c. While running the code I can only see that
>> mt_init() and mt_exit() are called during module loading/unloading;
>> never do I see any evidence of that the probing or mapping functions in
>> hid-multitouch are used, only the generic usb parts are used for
>> parsing the report descriptors and input reports.
>>
>> Yep, hid-multitouch does not handle your device. There is currently no
>> user-space way to tell usbhid (the generic) not to handle a device.
>> You'll have to add your VID-PID to the hid_have_special_driver list
>> (in hid-core.c) to disable generic usb hid handling for your device.
>> You can check the latest patches adding a specific device to
>> hid-multitouch to have some examples.
>>
>> >
>> > Could you point me to the location in the code where the decision is
>> taken to use the hid-multitouch driver for a hid-multitouch supported
>> device? I'm guessing it is somewhere in hid-core.c but I have not been
>> able to pinpoint the location exactly. I could use this location as a
>> start point to backtrace why we're not considered as a hid-multitouch
>> supported device.
>>
>> it's just above ;-) hid_have_special_driver in hid-core.c
>>
>> Cheers,
>> Benjamin
>>
>> >
>> >> If you are trying to inject events from the user space, I strongly
>> >> recommend to use uinput instead. Let me know if you want to have my
>> >> little uinput-multitouch lib.
>> >>
>> >> Cheers,
>> >> Benjamin
>> >>
>> >> > Digitizers.ContactCount ---> Absolute.?
>> >> > Button.0001 ---> Key.LeftBtn
>> >> > Button.0002 ---> Key.RightBtn
>> >> > Button.0003 ---> Key.MiddleBtn
>> >> > GenericDesktop.X ---> Relative.X
>> >> > GenericDesktop.Y ---> Relative.Y
>> >> > GenericDesktop.Wheel ---> Relative.Wheel
>> >> >
>> >> >
>> >> > Regards,
>> >> > Pablo Cases
>> >> >
>> >> > -------------------------
>> >> > Pablo Cases, M.Sc.
>> >> > Development Engineer Software
>> >> > FlatFrog Laboratories AB
>> >> > Magistratsvägen 10
>> >> > 22643 Lund
>> >> > Sweden
>> >> > Tel: +46 708 393816
>> >> > Mail: pc@flatfrog.com
>> >> > Web: www.flatfrog.com
>> >> > --
>> >> > 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] 10+ messages in thread
* RE: g_hid and hid-multitouch compatibility?
2011-05-31 11:19 ` Benjamin Tissoires
@ 2011-05-31 16:03 ` Pablo Cases
2011-05-31 16:55 ` Benjamin Tissoires
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Cases @ 2011-05-31 16:03 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
[-- Attachment #1: Type: text/plain, Size: 16687 bytes --]
Hi Benjamin,
I've attached some logs (rdesc.txt, events.txt and evtest.txt) showing a simulated 2-touch sequence spanning over four frames (last frame is a "untouch" event). Looking at the logs I'd say that I have a problem with the MIN/MAX limit decoding as evtest says limits are -127/127 but that is not what we're reporting according to rdesc.
While we're at it I have some more questions:
Q: Do we need to acknowledge the Device Configuration Feature Report sent from the host to the device (instructing the device to report "multi-touch" events)?
Q: Do we need to send the ContactCountMaximum Feature Report as described in the Windows 7 specification? Because I can see that these values are hardcoded (or just initialized?) in hid-multitouch for each supported device.
Regards,
Pablo
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> Sent: den 31 maj 2011 13:19
> To: Pablo Cases
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> input@vger.kernel.org
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo,
>
> On Mon, May 30, 2011 at 18:11, Pablo Cases <pablo.cases@flatfrog.com>
> wrote:
> > Hi Benjamin,
> >
> > Now things seem to work a lot better thanks to your input :) I'm
> still on the 2.6.38 version of the multitouch code, but static
> registering works after adding our faked USB VIP/PID to hid.ids.c, hid-
> core.c and hid-multitouch.c:
> >
> > Digitizers.TipSwitch ---> Key.Touch
> > Digitizers.InRange ---> Sync.Report
> > Digitizers.ContactID ---> Sync.Report
> > GenericDesktop.X ---> Absolute.MTPositionX
> > GenericDesktop.Y ---> Absolute.MTPositionY
> > Digitizers.TipSwitch ---> Key.Touch
> > Digitizers.InRange ---> Sync.Report
> > Digitizers.ContactID ---> Sync.Report
> > GenericDesktop.X ---> Absolute.MTPositionX
> > GenericDesktop.Y ---> Absolute.MTPositionY
> > Digitizers.ContactCount ---> Sync.Report
> > Button.0001 ---> Key.LeftBtn
> > Button.0002 ---> Key.RightBtn
> > Button.0003 ---> Key.MiddleBtn
> > GenericDesktop.X ---> Absolute.MTPositionX
> > GenericDesktop.Y ---> Absolute.MTPositionY
> > GenericDesktop.Wheel ---> Relative.Wheel
> >
> > Running some diagnostics:
> > workstation$ sudo python eviocg.py /dev/input/event3
> > the device '/dev/input/event3' is multitouch enabled with the
> protocol B.
>
> Can you send me the output of the command "evtest /dev/input/event3"
> while moving/releasing fingers? I'm particularly interested in the
> headers of this output (with the maximum of the ABS_MT_SLOTS).
>
> Can you also send the full reports descriptor from
> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>
> >
> > An unmodified version of mtdiag now discovers our multitouch device,
> but I cannot get any valid touch output in the "drawing surface" of the
> application. You mentioned that I could optimize things by using some
> of the quirk defined, but is this necessary or optional?
>
> purely optional. (normally)
>
> > If I'm reporting as the Windows 7 specification describes do I still
> need to use any of the quirks?
>
> the point is that many hardware makers interpreted differently this
> documentation (that's why we have those quirks). I'm not sure how
> Microsoft handles this mess, but it may be even more complicated than
> our hid-multitouch... So I can not guarantee that it will work out of
> the box.
> The big point lies in the understanding of the different
> significations of the fields during a touch life time.
>
> > Specially I'm wondering about the quirks that relate to contact
> id/contact number and slots. Do I really need to think about slots at
> all if I have valid ContactIDs in my reports?
>
> Well it's optimization, so it's optional (though I prefer, because it
> avoids finding elements in lists).
>
> Cheers,
> Benjamin
>
> >
> > Regards,
> > Pablo
> >
> >
> >> -----Original Message-----
> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> >> Sent: den 28 maj 2011 00:42
> >> To: Pablo Cases
> >> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> >> input@vger.kernel.org
> >> Subject: Re: g_hid and hid-multitouch compatibility?
> >>
> >> Hi Pablo
> >>
> >> On Sat, May 28, 2011 at 00:08, Pablo Cases
> <pablo.cases@flatfrog.com>
> >> wrote:
> >> > Hi Benjamin,
> >> >
> >> > Thanks for the response. It is my ignorance that should be excused
> as
> >> I have shown/will show that I am the novice with regards to USB HID
> and
> >> multitouch in this forum :)
> >> > I´ll continue interleaving additional comments below.
> >> >
> >> > -Pablo
> >> >
> >> >> -----Original Message-----
> >> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> >> >> Sent: den 27 maj 2011 18:10
> >> >> To: Pablo Cases
> >> >> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> >> >> input@vger.kernel.org
> >> >> Subject: Re: g_hid and hid-multitouch compatibility?
> >> >>
> >> >> Hi Pablo,
> >> >>
> >> >> Adding Stéphane, Henrik and Jiri in CC.
> >> >>
> >> >> On Fri, May 27, 2011 at 17:33, Pablo Cases
> >> <pablo.cases@flatfrog.com>
> >> >> wrote:
> >> >> >
> >> >> > Hi all,
> >> >> >
> >> >> > I have searched the net and the archives of linux-input for
> >> >> information on how to use the Linux g_hid kernel module on a
> device
> >> and
> >> >> the hid-multitouch kernel module on a host to communicate
> multitouch
> >> >> events. But unfortunately I can only get single touch working.
> >> >>
> >> >> Excuse my ignorance, I didn't know g_hid existed before your
> mail.
> >> If
> >> >> I understand it well enough, it's an hid emulation from user-
> space.
> >> >> Are you trying to inject events from a device in user-space to
> the
> >> >> kernel? If so, I think it would be easier to use uinput. And the
> >> funny
> >> >> think was that I'm currently writing a small lib to inject
> mulitouch
> >> >> events in a uinput device in an easier way.
> >> >>
> >> >
> >> > Maybe I misunderstand your explanation above but we´re not running
> >> g_hid and hid-multitouch on the same system. We have a separate
> >> hardware USB device running Linux with the g_hid kernel module
> loaded.
> >> On this device we then have (thanks to g_hid) a userspace file
> called
> >> /dev/hidg0 that we can write USB HID input reports to, which then
> will
> >> be sent through the device's gadget usb framework, through an
> physical
> >> USB cable, to a separate PC host running hid-multitouch.
> >>
> >> Thanks for the explaination. I didn't knew that it was possible to
> do
> >> such things. Linux is really a wonderful world ;-)
> >>
> >> >
> >> >> >
> >> >> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
> >> >> setup? And is there a description somewhere of such setup?
> >> >>
> >> >> I don't think so, hid-multitouch is really new (since 2.6.38, and
> >> was
> >> >> not very generic at this time).
> >> >>
> >> >> > Q: Is the Windows 7 multitouch USB HID descriptor the correct
> one
> >> to
> >> >> use also for Linux hid-multitouch? Or is some tweaking necessary?
> >> >>
> >> >> Normally, any valid Windows 7 multitouch USB HID descriptor can
> be
> >> >> handled by hid-multitouch.
> >> >> But it's more the events that are sent to hid-multitouch that
> will
> >> >> tell if your device is compatible or not.
> >> >>
> >> >> >
> >> >> > DETAILED DESCRIPTION BELOW
> >> >> > The device is a Linux device that uses g_hid (currently 2.6.37
> >> >> kernel) and a USB HID Report Descriptor for multitouch using two-
> >> touch
> >> >> parallel mode according to Microsoft document
> >> >> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
> >> >> >
> >> >> > On the host (ubuntu 11.04, 2.6.38 kernel) I register
> dynamically
> >> >> according to the description at http://lii-
> >> >> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html.
> >> Using
> >> >> the events/rdesc files in debugfs on Ubuntu 11.04 I have
> validated
> >> the
> >> >> parsing of the report descriptor and the input reports.
> >> >>
> >> >> This is really a bad idea to use these howto with ubuntu 11.04
> ATM.
> >> I
> >> >> didn't found the time to update this stuff, and this branch can
> not
> >> be
> >> >> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there
> >> were
> >> >> changes in the hid layer after). If you only used the part "How
> to
> >> add
> >> >> your device to hid-multitouch from the user space" without
> updating
> >> >> your hid module, then it's as if you have'nt done anything (the
> >> >> generic hid module can not autodetect multitouch devices).
> >> >
> >> > Currently I am using the hid-multitouch code as existing in the
> >> source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-
> get.
> >> In the page referred to above I have only used the "How to add your
> >> device to hid-multitouch from the user space", and not the 2.6.35
> >> related parts.
> >>
> >> So there are no autodetection in your kernel.
> >>
> >> >
> >> > Ok, so for autodetection of multitouch devices to work I need to
> >> update the hid-multitouch module to a newer version (than was
> available
> >> in 2.6.38), preferably head on a git master branch somewhere?
> Another
> >> option is to add a static configuration field in hid-multitouch and
> >> hid-ids.h for my USB device's VID/PID. But then again, maybe it's
> >> better to do that on the latest available code as well?
> >>
> >> Autodetection is not available upstream too, sorry. The latest
> >> available code is on Jiri's tree. I'll try to maintain a bunch of
> >> patches to backport the work done on hid-multitouch since 2.6.35 on
> >> http://lii-enac.fr/en/architecture/linux-input/multitouch-
> >> howto.html#hid-multitouch
> >> but I'm a little late for the backports right now.
> >>
> >> Jiri's tree is at
> >> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
> >>
> >> >
> >> >> >
> >> >> > Example multitouch input report from
> >> >> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
> >> >> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14
> 32
> >> 0e
> >> >> 02
> >> >> > Digitizers.TipSwitch = 1
> >> >> > Digitizers.InRange = 1
> >> >> > Digitizers.ContactID = 0
> >> >> > GenericDesktop.X = 4773
> >> >> > GenericDesktop.Y = 3634
> >> >> > Digitizers.TipSwitch = 1
> >> >> > Digitizers.InRange = 1
> >> >> > Digitizers.ContactID = 1
> >> >> > GenericDesktop.X = 5273
> >> >> > GenericDesktop.Y = 3634
> >> >> > Digitizers.ContactCount = 2
> >> >> >
> >> >>
> >> >> Most of the time, the problematic part comes from the releases.
> But
> >> >> it's a good start.
> >> >
> >> > With "releases" I assume you mean the finger removal from the
> touch
> >> surface, like a "touch-up" event? I have not implemented that part
> yet,
> >> but our Microsoft contact informed us that for Windows 7
> compatibility
> >> it should be reported as a final touch report with
> >> > TipSwitch = 0
> >> > InRange = 1
> >> > Is this applicable to hid-multitouch too?
> >>
> >> Exactly, I meant touch-up. Your behavior is applicable to hid-
> >> multitouch.
> >>
> >> Once registering your device with hid-multitouch, you can choose a
> >> class that controls how optimized your driver will be. Normally, the
> >> MT_CLS_DEFAULT class will work with any Win 7 compliant device
> >> (crossing fingers).
> >>
> >> Then, you can optimize it by looking for the classes that have
> >> MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time,
> you
> >> can also optimize the way your device actually does the match
> between
> >> slots (from 0 to N-1 with N the maximum contact count of your
> device)
> >> and the tracking_id reported by the device (or the position in the
> hid
> >> report).
> >> For dual touches only devices, the differences are not big, but we
> >> prefer to optimize things all the time ;-)
> >>
> >> >
> >> >> > The first touch in the report is correctly presented both on
> >> Windows
> >> >> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak
> to
> >> >> display data from all devices not just multitouch ones). I can
> see
> >> in
> >> >> the debugfs files that the data for the second touch data is
> >> correctly
> >> >> transferred and interpreted (see above), but the mapping to the
> >> linux
> >> >> input system seems a bit strange though (see below). My guess is
> >> that I
> >> >> have not been correctly registered as a multitouch device. I'm
> >> assuming
> >> >> this also because I cannot see any activity from the hid-
> multitouch
> >> >> module other than it being initialized when I connect my device
> >> >> (probably another reason for the needed tweak in mtdiag above).
> >> >> >
> >> >> > Example mapping from
> >> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
> >> >> that does not look entirely correct for the second touch:
> >> >> > Digitizers.TipSwitch ---> Key.Touch
> >> >> > Digitizers.InRange ---> Key.ToolPen
> >> >> > Digitizers.ContactID ---> Absolute.Misc
> >> >> > GenericDesktop.X ---> Absolute.X
> >> >> > GenericDesktop.Y ---> Absolute.Y
> >> >> > Digitizers.TipSwitch ---> Key.Touch
> >> >> > Digitizers.InRange ---> Key.ToolRubber
> >> >> > Digitizers.ContactID ---> Absolute.?
> >> >> > GenericDesktop.X ---> Absolute.Z
> >> >> > GenericDesktop.Y ---> Absolute.Rx
> >> >>
> >> >> This means that your device is handled by the generic usbhid and
> not
> >> >> hid-multitouch.
> >> >
> >> > That is what troubles me. I can see in the host's dmesg that
> >> "generic-usb" seems to be the driver chosen for my device when it is
> >> connected to the host. And according to your comment above I might
> not
> >> have correctly registered my device in hid-multitouch which would be
> >> the source of the problem...
> >> >
> >> > As a side note; I have sprinkled printk() here and there hid-
> >> multitouch.c and hid-core.c. While running the code I can only see
> that
> >> mt_init() and mt_exit() are called during module loading/unloading;
> >> never do I see any evidence of that the probing or mapping functions
> in
> >> hid-multitouch are used, only the generic usb parts are used for
> >> parsing the report descriptors and input reports.
> >>
> >> Yep, hid-multitouch does not handle your device. There is currently
> no
> >> user-space way to tell usbhid (the generic) not to handle a device.
> >> You'll have to add your VID-PID to the hid_have_special_driver list
> >> (in hid-core.c) to disable generic usb hid handling for your device.
> >> You can check the latest patches adding a specific device to
> >> hid-multitouch to have some examples.
> >>
> >> >
> >> > Could you point me to the location in the code where the decision
> is
> >> taken to use the hid-multitouch driver for a hid-multitouch
> supported
> >> device? I'm guessing it is somewhere in hid-core.c but I have not
> been
> >> able to pinpoint the location exactly. I could use this location as
> a
> >> start point to backtrace why we're not considered as a hid-
> multitouch
> >> supported device.
> >>
> >> it's just above ;-) hid_have_special_driver in hid-core.c
> >>
> >> Cheers,
> >> Benjamin
> >>
> >> >
> >> >> If you are trying to inject events from the user space, I
> strongly
> >> >> recommend to use uinput instead. Let me know if you want to have
> my
> >> >> little uinput-multitouch lib.
> >> >>
> >> >> Cheers,
> >> >> Benjamin
> >> >>
> >> >> > Digitizers.ContactCount ---> Absolute.?
> >> >> > Button.0001 ---> Key.LeftBtn
> >> >> > Button.0002 ---> Key.RightBtn
> >> >> > Button.0003 ---> Key.MiddleBtn
> >> >> > GenericDesktop.X ---> Relative.X
> >> >> > GenericDesktop.Y ---> Relative.Y
> >> >> > GenericDesktop.Wheel ---> Relative.Wheel
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> > Pablo Cases
> >> >> >
> >> >> > -------------------------
> >> >> > Pablo Cases, M.Sc.
> >> >> > Development Engineer Software
> >> >> > FlatFrog Laboratories AB
> >> >> > Magistratsvägen 10
> >> >> > 22643 Lund
> >> >> > Sweden
> >> >> > Tel: +46 708 393816
> >> >> > Mail: pc@flatfrog.com
> >> >> > Web: www.flatfrog.com
> >> >> > --
> >> >> > 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
> >> >> >
> >> >
> >
[-- Attachment #2: rdesc.txt --]
[-- Type: text/plain, Size: 5840 bytes --]
05 0d 09 04 a1 01 85 05 09 22 a1 02 15 00 25 01 75 01 95 01 09 42 81 02 09 32 81 02 95 06 81 03 25 7f 75 08 95 01 09 51 81 02 05 01 75 10 65 f1 55 0f 26 a6 2b 35 00 46 48 1b 09 30 81 02 26 90 18 46 59 0f 09 31 81 02 c0 05 0d 09 22 65 00 55 00 a1 02 45 00 05 0d 15 00 25 01 75 01 95 01 09 42 81 02 09 32 81 02 95 06 81 03 25 7f 75 08 95 01 09 51 81 02 05 01 75 10 65 f1 55 0f 26 a6 2b 35 00 46 48 1b 09 30 81 02 26 90 18 46 59 0f 09 31 81 02 c0 05 0d 09 54 65 00 55 00 95 01 75 08 45 00 15 00 25 08 81 02 09 55 85 06 25 0a b1 02 c0 09 0e a1 01 85 03 09 23 a1 02 09 52 09 53 15 00 25 0a 75 08 95 02 b1 02 c0 c0 05 01 09 02 a1 01 85 04 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 01 75 05 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0
INPUT(5)[INPUT]
Field(0)
Logical(Digitizers.Finger)
Usage(1)
Digitizers.TipSwitch
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(1)
Report Offset(0)
Flags( Variable Absolute )
Field(1)
Logical(Digitizers.Finger)
Usage(1)
Digitizers.InRange
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(1)
Report Offset(1)
Flags( Variable Absolute )
Field(2)
Logical(Digitizers.Finger)
Usage(1)
Digitizers.ContactID
Logical Minimum(0)
Logical Maximum(127)
Report Size(8)
Report Count(1)
Report Offset(8)
Flags( Variable Absolute )
Field(3)
Logical(Digitizers.Finger)
Usage(1)
GenericDesktop.X
Logical Minimum(0)
Logical Maximum(11174)
Physical Minimum(0)
Physical Maximum(6984)
Unit Exponent(15)
Unit(SI Linear : Centimeter^-1)
Report Size(16)
Report Count(1)
Report Offset(16)
Flags( Variable Absolute )
Field(4)
Logical(Digitizers.Finger)
Usage(1)
GenericDesktop.Y
Logical Minimum(0)
Logical Maximum(6288)
Physical Minimum(0)
Physical Maximum(3929)
Unit Exponent(15)
Unit(SI Linear : Centimeter^-1)
Report Size(16)
Report Count(1)
Report Offset(32)
Flags( Variable Absolute )
Field(5)
Logical(Digitizers.Finger)
Usage(1)
Digitizers.TipSwitch
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(1)
Report Offset(48)
Flags( Variable Absolute )
Field(6)
Logical(Digitizers.Finger)
Usage(1)
Digitizers.InRange
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(1)
Report Offset(49)
Flags( Variable Absolute )
Field(7)
Logical(Digitizers.Finger)
Usage(1)
Digitizers.ContactID
Logical Minimum(0)
Logical Maximum(127)
Report Size(8)
Report Count(1)
Report Offset(56)
Flags( Variable Absolute )
Field(8)
Logical(Digitizers.Finger)
Usage(1)
GenericDesktop.X
Logical Minimum(0)
Logical Maximum(11174)
Physical Minimum(0)
Physical Maximum(6984)
Unit Exponent(15)
Unit(SI Linear : Centimeter^-1)
Report Size(16)
Report Count(1)
Report Offset(64)
Flags( Variable Absolute )
Field(9)
Logical(Digitizers.Finger)
Usage(1)
GenericDesktop.Y
Logical Minimum(0)
Logical Maximum(6288)
Physical Minimum(0)
Physical Maximum(3929)
Unit Exponent(15)
Unit(SI Linear : Centimeter^-1)
Report Size(16)
Report Count(1)
Report Offset(80)
Flags( Variable Absolute )
Field(10)
Usage(1)
Digitizers.ContactCount
Logical Minimum(0)
Logical Maximum(8)
Report Size(8)
Report Count(1)
Report Offset(96)
Flags( Variable Absolute )
INPUT(4)[INPUT]
Field(0)
Physical(GenericDesktop.Pointer)
Usage(3)
Button.0001
Button.0002
Button.0003
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(3)
Report Offset(0)
Flags( Variable Absolute )
Field(1)
Physical(GenericDesktop.Pointer)
Usage(3)
GenericDesktop.X
GenericDesktop.Y
GenericDesktop.Wheel
Logical Minimum(-127)
Logical Maximum(127)
Report Size(8)
Report Count(3)
Report Offset(8)
Flags( Variable Relative )
FEATURE(6)[FEATURE]
Field(0)
Usage(1)
Digitizers.ContactMaximumNumber
Logical Minimum(0)
Logical Maximum(10)
Report Size(8)
Report Count(1)
Report Offset(0)
Flags( Variable Absolute )
FEATURE(3)[FEATURE]
Field(0)
Logical(Digitizers.0023)
Usage(2)
Digitizers.InputMode
Digitizers.DeviceIndex
Logical Minimum(0)
Logical Maximum(10)
Report Size(8)
Report Count(2)
Report Offset(0)
Flags( Variable Absolute )
Digitizers.TipSwitch ---> Key.Touch
Digitizers.InRange ---> Sync.Report
Digitizers.ContactID ---> Sync.Report
GenericDesktop.X ---> Absolute.MTPositionX
GenericDesktop.Y ---> Absolute.MTPositionY
Digitizers.TipSwitch ---> Key.Touch
Digitizers.InRange ---> Sync.Report
Digitizers.ContactID ---> Sync.Report
GenericDesktop.X ---> Absolute.MTPositionX
GenericDesktop.Y ---> Absolute.MTPositionY
Digitizers.ContactCount ---> Sync.Report
Button.0001 ---> Key.LeftBtn
Button.0002 ---> Key.RightBtn
Button.0003 ---> Key.MiddleBtn
GenericDesktop.X ---> Absolute.MTPositionX
GenericDesktop.Y ---> Absolute.MTPositionY
GenericDesktop.Wheel ---> Relative.Wheel
[-- Attachment #3: events.txt.txt --]
[-- Type: text/plain, Size: 1414 bytes --]
report (size 14) (numbered) = 05 03 00 88 13 b8 0b 03 01 7c 15 b8 0b 02
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 0
GenericDesktop.X = 5000
GenericDesktop.Y = 3000
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 1
GenericDesktop.X = 5500
GenericDesktop.Y = 3000
Digitizers.ContactCount = 2
report (size 14) (numbered) = 05 03 00 87 13 d0 0b 03 01 7b 15 d0 0b 02
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 0
GenericDesktop.X = 4999
GenericDesktop.Y = 3024
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 1
GenericDesktop.X = 5499
GenericDesktop.Y = 3024
Digitizers.ContactCount = 2
report (size 14) (numbered) = 05 03 00 86 13 e9 0b 03 01 7a 15 e9 0b 02
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 0
GenericDesktop.X = 4998
GenericDesktop.Y = 3049
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
Digitizers.ContactID = 1
GenericDesktop.X = 5498
GenericDesktop.Y = 3049
Digitizers.ContactCount = 2
report (size 14) (numbered) = 05 02 00 00 00 00 00 02 01 00 00 00 00 02
Digitizers.TipSwitch = 0
Digitizers.InRange = 1
Digitizers.ContactID = 0
GenericDesktop.X = 0
GenericDesktop.Y = 0
Digitizers.TipSwitch = 0
Digitizers.InRange = 1
Digitizers.ContactID = 1
GenericDesktop.X = 0
GenericDesktop.Y = 0
Digitizers.ContactCount = 2
[-- Attachment #4: evtest.txt.txt --]
[-- Type: text/plain, Size: 3409 bytes --]
workstation>$ sudo evtest /dev/input/event3
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0xff0 product 0x1234 version 0x111
Input device name: "Flatfrog Multitouch 3200"
Supported events:
Event type 0 (Sync)
Event type 1 (Key)
Event code 330 (Touch)
Event type 3 (Absolute)
Event code 0 (X)
Value 0
Min -127
Max 127
Event code 1 (Y)
Value 0
Min -127
Max 127
Event code 47 (?)
Value 0
Min 0
Max 1
Event code 53 (?)
Value 0
Min -127
Max 127
Event code 54 (?)
Value 0
Min -127
Max 127
Event code 57 (?)
Value 0
Min 0
Max 65535
Testing ... (interrupt to exit)
Event: time 1306852756.624325, type 3 (Absolute), code 57 (?), value 0
Event: time 1306852756.624331, type 3 (Absolute), code 53 (?), value 5000
Event: time 1306852756.624332, type 3 (Absolute), code 54 (?), value 3000
Event: time 1306852756.624333, type 3 (Absolute), code 47 (?), value 1
Event: time 1306852756.624333, type 3 (Absolute), code 57 (?), value 1
Event: time 1306852756.624334, type 3 (Absolute), code 53 (?), value 5500
Event: time 1306852756.624334, type 3 (Absolute), code 54 (?), value 3000
Event: time 1306852756.624336, type 1 (Key), code 330 (Touch), value 1
Event: time 1306852756.624337, type 3 (Absolute), code 0 (X), value 5000
Event: time 1306852756.624337, type 3 (Absolute), code 1 (Y), value 3000
Event: time 1306852756.624338, -------------- Report Sync ------------
Event: time 1306852756.629475, type 3 (Absolute), code 47 (?), value 0
Event: time 1306852756.629477, type 3 (Absolute), code 53 (?), value 4999
Event: time 1306852756.629477, type 3 (Absolute), code 54 (?), value 3024
Event: time 1306852756.629478, type 3 (Absolute), code 47 (?), value 1
Event: time 1306852756.629479, type 3 (Absolute), code 53 (?), value 5499
Event: time 1306852756.629479, type 3 (Absolute), code 54 (?), value 3024
Event: time 1306852756.629481, type 3 (Absolute), code 0 (X), value 4999
Event: time 1306852756.629482, type 3 (Absolute), code 1 (Y), value 3024
Event: time 1306852756.629482, -------------- Report Sync ------------
Event: time 1306852756.631954, type 3 (Absolute), code 47 (?), value 0
Event: time 1306852756.631956, type 3 (Absolute), code 53 (?), value 4998
Event: time 1306852756.631960, type 3 (Absolute), code 54 (?), value 3049
Event: time 1306852756.631969, type 3 (Absolute), code 47 (?), value 1
Event: time 1306852756.631970, type 3 (Absolute), code 53 (?), value 5498
Event: time 1306852756.631974, type 3 (Absolute), code 54 (?), value 3049
Event: time 1306852756.631986, type 3 (Absolute), code 0 (X), value 4998
Event: time 1306852756.631990, type 3 (Absolute), code 1 (Y), value 3049
Event: time 1306852756.631994, -------------- Report Sync ------------
Event: time 1306852756.644943, type 3 (Absolute), code 47 (?), value 0
Event: time 1306852756.644948, type 3 (Absolute), code 57 (?), value -1
Event: time 1306852756.644958, type 3 (Absolute), code 47 (?), value 1
Event: time 1306852756.644961, type 3 (Absolute), code 57 (?), value -1
Event: time 1306852756.644968, type 1 (Key), code 330 (Touch), value 0
Event: time 1306852756.644972, -------------- Report Sync ------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: g_hid and hid-multitouch compatibility?
2011-05-31 16:03 ` Pablo Cases
@ 2011-05-31 16:55 ` Benjamin Tissoires
[not found] ` <35E4813F-ADBF-4988-A80E-6D4DC254AE22@flatfrog.com>
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2011-05-31 16:55 UTC (permalink / raw)
To: Pablo Cases
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
On Tue, May 31, 2011 at 18:03, Pablo Cases <pablo.cases@flatfrog.com> wrote:
>
> Hi Benjamin,
>
> I've attached some logs (rdesc.txt, events.txt and evtest.txt) showing a simulated 2-touch sequence spanning over four frames (last frame is a "untouch" event). Looking at the logs I'd say that I have a problem with the MIN/MAX limit decoding as evtest says limits are -127/127 but that is not what we're reporting according to rdesc.
Indeed, there are troubles with ranges of X and Y. The good point is
that besides that, hid-multitouch seems to work well.
However, what strikes me is that the values are not clamped by the input layer.
The problems comes from your mouse emulation, here:
INPUT(4)[INPUT]
Field(0)
....
Field(1)
Physical(GenericDesktop.Pointer)
Usage(3)
GenericDesktop.X
GenericDesktop.Y
GenericDesktop.Wheel
Logical Minimum(-127) <---------
Logical Maximum(127) <---------
Report Size(8)
Report Count(3)
Report Offset(8)
Flags( Variable Relative )
the values are not coherent with the one reported above. Maybe we
should patch hid-multitouch to ignore non mt inputs... ;-) but I
really don"t have the time to do it right now.
Maybe you don't need to introduce this mouse emulation at all in your
device (it depends if your "firmware" will support it or not).
There is also a problem with the feature
Digitizers.ContactMaximumNumber. Apparently, I would say that you put
the initial value is at 2 instead of 10 as your maximum value
suggests. If it's intentional, it's fine, but you won't be able to
send more than two touches, even by changing this number later...
(just saw the question after)
>
> While we're at it I have some more questions:
> Q: Do we need to acknowledge the Device Configuration Feature Report sent from the host to the device (instructing the device to report "multi-touch" events)?
If you are talking about the "Digitizers.InputMode" setting, then, we
just send the signal and we don't wait for an answer. My memory is
quite confusing here, but again, if you don't intend to support mouse
emulation, dropping this input in the reports will ease things.
> Q: Do we need to send the ContactCountMaximum Feature Report as described in the Windows 7 specification? Because I can see that these values are hardcoded (or just initialized?) in hid-multitouch for each supported device.
So, the first implementation of hid-multitouch did not care about this
feature. Now, I tried to use it for devices that send it correctly. As
I did not asked all the owners of the devices to redo the tests, some
device still got .maxcontact
I'd rather not have this thing hardcoded in order to be able to reuse
the different classes with a lot of devices.
Cheers,
Benjamin
>
> Regards,
> Pablo
>
>
>> -----Original Message-----
>> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>> Sent: den 31 maj 2011 13:19
>> To: Pablo Cases
>> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>> input@vger.kernel.org
>> Subject: Re: g_hid and hid-multitouch compatibility?
>>
>> Hi Pablo,
>>
>> On Mon, May 30, 2011 at 18:11, Pablo Cases <pablo.cases@flatfrog.com>
>> wrote:
>> > Hi Benjamin,
>> >
>> > Now things seem to work a lot better thanks to your input :) I'm
>> still on the 2.6.38 version of the multitouch code, but static
>> registering works after adding our faked USB VIP/PID to hid.ids.c, hid-
>> core.c and hid-multitouch.c:
>> >
>> > Digitizers.TipSwitch ---> Key.Touch
>> > Digitizers.InRange ---> Sync.Report
>> > Digitizers.ContactID ---> Sync.Report
>> > GenericDesktop.X ---> Absolute.MTPositionX
>> > GenericDesktop.Y ---> Absolute.MTPositionY
>> > Digitizers.TipSwitch ---> Key.Touch
>> > Digitizers.InRange ---> Sync.Report
>> > Digitizers.ContactID ---> Sync.Report
>> > GenericDesktop.X ---> Absolute.MTPositionX
>> > GenericDesktop.Y ---> Absolute.MTPositionY
>> > Digitizers.ContactCount ---> Sync.Report
>> > Button.0001 ---> Key.LeftBtn
>> > Button.0002 ---> Key.RightBtn
>> > Button.0003 ---> Key.MiddleBtn
>> > GenericDesktop.X ---> Absolute.MTPositionX
>> > GenericDesktop.Y ---> Absolute.MTPositionY
>> > GenericDesktop.Wheel ---> Relative.Wheel
>> >
>> > Running some diagnostics:
>> > workstation$ sudo python eviocg.py /dev/input/event3
>> > the device '/dev/input/event3' is multitouch enabled with the
>> protocol B.
>>
>> Can you send me the output of the command "evtest /dev/input/event3"
>> while moving/releasing fingers? I'm particularly interested in the
>> headers of this output (with the maximum of the ABS_MT_SLOTS).
>>
>> Can you also send the full reports descriptor from
>> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>>
>> >
>> > An unmodified version of mtdiag now discovers our multitouch device,
>> but I cannot get any valid touch output in the "drawing surface" of the
>> application. You mentioned that I could optimize things by using some
>> of the quirk defined, but is this necessary or optional?
>>
>> purely optional. (normally)
>>
>> > If I'm reporting as the Windows 7 specification describes do I still
>> need to use any of the quirks?
>>
>> the point is that many hardware makers interpreted differently this
>> documentation (that's why we have those quirks). I'm not sure how
>> Microsoft handles this mess, but it may be even more complicated than
>> our hid-multitouch... So I can not guarantee that it will work out of
>> the box.
>> The big point lies in the understanding of the different
>> significations of the fields during a touch life time.
>>
>> > Specially I'm wondering about the quirks that relate to contact
>> id/contact number and slots. Do I really need to think about slots at
>> all if I have valid ContactIDs in my reports?
>>
>> Well it's optimization, so it's optional (though I prefer, because it
>> avoids finding elements in lists).
>>
>> Cheers,
>> Benjamin
>>
>> >
>> > Regards,
>> > Pablo
>> >
>> >
>> >> -----Original Message-----
>> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>> >> Sent: den 28 maj 2011 00:42
>> >> To: Pablo Cases
>> >> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>> >> input@vger.kernel.org
>> >> Subject: Re: g_hid and hid-multitouch compatibility?
>> >>
>> >> Hi Pablo
>> >>
>> >> On Sat, May 28, 2011 at 00:08, Pablo Cases
>> <pablo.cases@flatfrog.com>
>> >> wrote:
>> >> > Hi Benjamin,
>> >> >
>> >> > Thanks for the response. It is my ignorance that should be excused
>> as
>> >> I have shown/will show that I am the novice with regards to USB HID
>> and
>> >> multitouch in this forum :)
>> >> > I´ll continue interleaving additional comments below.
>> >> >
>> >> > -Pablo
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>> >> >> Sent: den 27 maj 2011 18:10
>> >> >> To: Pablo Cases
>> >> >> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>> >> >> input@vger.kernel.org
>> >> >> Subject: Re: g_hid and hid-multitouch compatibility?
>> >> >>
>> >> >> Hi Pablo,
>> >> >>
>> >> >> Adding Stéphane, Henrik and Jiri in CC.
>> >> >>
>> >> >> On Fri, May 27, 2011 at 17:33, Pablo Cases
>> >> <pablo.cases@flatfrog.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I have searched the net and the archives of linux-input for
>> >> >> information on how to use the Linux g_hid kernel module on a
>> device
>> >> and
>> >> >> the hid-multitouch kernel module on a host to communicate
>> multitouch
>> >> >> events. But unfortunately I can only get single touch working.
>> >> >>
>> >> >> Excuse my ignorance, I didn't know g_hid existed before your
>> mail.
>> >> If
>> >> >> I understand it well enough, it's an hid emulation from user-
>> space.
>> >> >> Are you trying to inject events from a device in user-space to
>> the
>> >> >> kernel? If so, I think it would be easier to use uinput. And the
>> >> funny
>> >> >> think was that I'm currently writing a small lib to inject
>> mulitouch
>> >> >> events in a uinput device in an easier way.
>> >> >>
>> >> >
>> >> > Maybe I misunderstand your explanation above but we´re not running
>> >> g_hid and hid-multitouch on the same system. We have a separate
>> >> hardware USB device running Linux with the g_hid kernel module
>> loaded.
>> >> On this device we then have (thanks to g_hid) a userspace file
>> called
>> >> /dev/hidg0 that we can write USB HID input reports to, which then
>> will
>> >> be sent through the device's gadget usb framework, through an
>> physical
>> >> USB cable, to a separate PC host running hid-multitouch.
>> >>
>> >> Thanks for the explaination. I didn't knew that it was possible to
>> do
>> >> such things. Linux is really a wonderful world ;-)
>> >>
>> >> >
>> >> >> >
>> >> >> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
>> >> >> setup? And is there a description somewhere of such setup?
>> >> >>
>> >> >> I don't think so, hid-multitouch is really new (since 2.6.38, and
>> >> was
>> >> >> not very generic at this time).
>> >> >>
>> >> >> > Q: Is the Windows 7 multitouch USB HID descriptor the correct
>> one
>> >> to
>> >> >> use also for Linux hid-multitouch? Or is some tweaking necessary?
>> >> >>
>> >> >> Normally, any valid Windows 7 multitouch USB HID descriptor can
>> be
>> >> >> handled by hid-multitouch.
>> >> >> But it's more the events that are sent to hid-multitouch that
>> will
>> >> >> tell if your device is compatible or not.
>> >> >>
>> >> >> >
>> >> >> > DETAILED DESCRIPTION BELOW
>> >> >> > The device is a Linux device that uses g_hid (currently 2.6.37
>> >> >> kernel) and a USB HID Report Descriptor for multitouch using two-
>> >> touch
>> >> >> parallel mode according to Microsoft document
>> >> >> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
>> >> >> >
>> >> >> > On the host (ubuntu 11.04, 2.6.38 kernel) I register
>> dynamically
>> >> >> according to the description at http://lii-
>> >> >> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html.
>> >> Using
>> >> >> the events/rdesc files in debugfs on Ubuntu 11.04 I have
>> validated
>> >> the
>> >> >> parsing of the report descriptor and the input reports.
>> >> >>
>> >> >> This is really a bad idea to use these howto with ubuntu 11.04
>> ATM.
>> >> I
>> >> >> didn't found the time to update this stuff, and this branch can
>> not
>> >> be
>> >> >> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there
>> >> were
>> >> >> changes in the hid layer after). If you only used the part "How
>> to
>> >> add
>> >> >> your device to hid-multitouch from the user space" without
>> updating
>> >> >> your hid module, then it's as if you have'nt done anything (the
>> >> >> generic hid module can not autodetect multitouch devices).
>> >> >
>> >> > Currently I am using the hid-multitouch code as existing in the
>> >> source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-
>> get.
>> >> In the page referred to above I have only used the "How to add your
>> >> device to hid-multitouch from the user space", and not the 2.6.35
>> >> related parts.
>> >>
>> >> So there are no autodetection in your kernel.
>> >>
>> >> >
>> >> > Ok, so for autodetection of multitouch devices to work I need to
>> >> update the hid-multitouch module to a newer version (than was
>> available
>> >> in 2.6.38), preferably head on a git master branch somewhere?
>> Another
>> >> option is to add a static configuration field in hid-multitouch and
>> >> hid-ids.h for my USB device's VID/PID. But then again, maybe it's
>> >> better to do that on the latest available code as well?
>> >>
>> >> Autodetection is not available upstream too, sorry. The latest
>> >> available code is on Jiri's tree. I'll try to maintain a bunch of
>> >> patches to backport the work done on hid-multitouch since 2.6.35 on
>> >> http://lii-enac.fr/en/architecture/linux-input/multitouch-
>> >> howto.html#hid-multitouch
>> >> but I'm a little late for the backports right now.
>> >>
>> >> Jiri's tree is at
>> >> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
>> >>
>> >> >
>> >> >> >
>> >> >> > Example multitouch input report from
>> >> >> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
>> >> >> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14
>> 32
>> >> 0e
>> >> >> 02
>> >> >> > Digitizers.TipSwitch = 1
>> >> >> > Digitizers.InRange = 1
>> >> >> > Digitizers.ContactID = 0
>> >> >> > GenericDesktop.X = 4773
>> >> >> > GenericDesktop.Y = 3634
>> >> >> > Digitizers.TipSwitch = 1
>> >> >> > Digitizers.InRange = 1
>> >> >> > Digitizers.ContactID = 1
>> >> >> > GenericDesktop.X = 5273
>> >> >> > GenericDesktop.Y = 3634
>> >> >> > Digitizers.ContactCount = 2
>> >> >> >
>> >> >>
>> >> >> Most of the time, the problematic part comes from the releases.
>> But
>> >> >> it's a good start.
>> >> >
>> >> > With "releases" I assume you mean the finger removal from the
>> touch
>> >> surface, like a "touch-up" event? I have not implemented that part
>> yet,
>> >> but our Microsoft contact informed us that for Windows 7
>> compatibility
>> >> it should be reported as a final touch report with
>> >> > TipSwitch = 0
>> >> > InRange = 1
>> >> > Is this applicable to hid-multitouch too?
>> >>
>> >> Exactly, I meant touch-up. Your behavior is applicable to hid-
>> >> multitouch.
>> >>
>> >> Once registering your device with hid-multitouch, you can choose a
>> >> class that controls how optimized your driver will be. Normally, the
>> >> MT_CLS_DEFAULT class will work with any Win 7 compliant device
>> >> (crossing fingers).
>> >>
>> >> Then, you can optimize it by looking for the classes that have
>> >> MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time,
>> you
>> >> can also optimize the way your device actually does the match
>> between
>> >> slots (from 0 to N-1 with N the maximum contact count of your
>> device)
>> >> and the tracking_id reported by the device (or the position in the
>> hid
>> >> report).
>> >> For dual touches only devices, the differences are not big, but we
>> >> prefer to optimize things all the time ;-)
>> >>
>> >> >
>> >> >> > The first touch in the report is correctly presented both on
>> >> Windows
>> >> >> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak
>> to
>> >> >> display data from all devices not just multitouch ones). I can
>> see
>> >> in
>> >> >> the debugfs files that the data for the second touch data is
>> >> correctly
>> >> >> transferred and interpreted (see above), but the mapping to the
>> >> linux
>> >> >> input system seems a bit strange though (see below). My guess is
>> >> that I
>> >> >> have not been correctly registered as a multitouch device. I'm
>> >> assuming
>> >> >> this also because I cannot see any activity from the hid-
>> multitouch
>> >> >> module other than it being initialized when I connect my device
>> >> >> (probably another reason for the needed tweak in mtdiag above).
>> >> >> >
>> >> >> > Example mapping from
>> >> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>> >> >> that does not look entirely correct for the second touch:
>> >> >> > Digitizers.TipSwitch ---> Key.Touch
>> >> >> > Digitizers.InRange ---> Key.ToolPen
>> >> >> > Digitizers.ContactID ---> Absolute.Misc
>> >> >> > GenericDesktop.X ---> Absolute.X
>> >> >> > GenericDesktop.Y ---> Absolute.Y
>> >> >> > Digitizers.TipSwitch ---> Key.Touch
>> >> >> > Digitizers.InRange ---> Key.ToolRubber
>> >> >> > Digitizers.ContactID ---> Absolute.?
>> >> >> > GenericDesktop.X ---> Absolute.Z
>> >> >> > GenericDesktop.Y ---> Absolute.Rx
>> >> >>
>> >> >> This means that your device is handled by the generic usbhid and
>> not
>> >> >> hid-multitouch.
>> >> >
>> >> > That is what troubles me. I can see in the host's dmesg that
>> >> "generic-usb" seems to be the driver chosen for my device when it is
>> >> connected to the host. And according to your comment above I might
>> not
>> >> have correctly registered my device in hid-multitouch which would be
>> >> the source of the problem...
>> >> >
>> >> > As a side note; I have sprinkled printk() here and there hid-
>> >> multitouch.c and hid-core.c. While running the code I can only see
>> that
>> >> mt_init() and mt_exit() are called during module loading/unloading;
>> >> never do I see any evidence of that the probing or mapping functions
>> in
>> >> hid-multitouch are used, only the generic usb parts are used for
>> >> parsing the report descriptors and input reports.
>> >>
>> >> Yep, hid-multitouch does not handle your device. There is currently
>> no
>> >> user-space way to tell usbhid (the generic) not to handle a device.
>> >> You'll have to add your VID-PID to the hid_have_special_driver list
>> >> (in hid-core.c) to disable generic usb hid handling for your device.
>> >> You can check the latest patches adding a specific device to
>> >> hid-multitouch to have some examples.
>> >>
>> >> >
>> >> > Could you point me to the location in the code where the decision
>> is
>> >> taken to use the hid-multitouch driver for a hid-multitouch
>> supported
>> >> device? I'm guessing it is somewhere in hid-core.c but I have not
>> been
>> >> able to pinpoint the location exactly. I could use this location as
>> a
>> >> start point to backtrace why we're not considered as a hid-
>> multitouch
>> >> supported device.
>> >>
>> >> it's just above ;-) hid_have_special_driver in hid-core.c
>> >>
>> >> Cheers,
>> >> Benjamin
>> >>
>> >> >
>> >> >> If you are trying to inject events from the user space, I
>> strongly
>> >> >> recommend to use uinput instead. Let me know if you want to have
>> my
>> >> >> little uinput-multitouch lib.
>> >> >>
>> >> >> Cheers,
>> >> >> Benjamin
>> >> >>
>> >> >> > Digitizers.ContactCount ---> Absolute.?
>> >> >> > Button.0001 ---> Key.LeftBtn
>> >> >> > Button.0002 ---> Key.RightBtn
>> >> >> > Button.0003 ---> Key.MiddleBtn
>> >> >> > GenericDesktop.X ---> Relative.X
>> >> >> > GenericDesktop.Y ---> Relative.Y
>> >> >> > GenericDesktop.Wheel ---> Relative.Wheel
>> >> >> >
>> >> >> >
>> >> >> > Regards,
>> >> >> > Pablo Cases
>> >> >> >
>> >> >> > -------------------------
>> >> >> > Pablo Cases, M.Sc.
>> >> >> > Development Engineer Software
>> >> >> > FlatFrog Laboratories AB
>> >> >> > Magistratsvägen 10
>> >> >> > 22643 Lund
>> >> >> > Sweden
>> >> >> > Tel: +46 708 393816
>> >> >> > Mail: pc@flatfrog.com
>> >> >> > Web: www.flatfrog.com
>> >> >> > --
>> >> >> > 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] 10+ messages in thread
* Re: g_hid and hid-multitouch compatibility?
[not found] ` <35E4813F-ADBF-4988-A80E-6D4DC254AE22@flatfrog.com>
@ 2011-06-01 17:21 ` Benjamin Tissoires
2011-06-07 6:25 ` Pablo Cases
0 siblings, 1 reply; 10+ messages in thread
From: Benjamin Tissoires @ 2011-06-01 17:21 UTC (permalink / raw)
To: Pablo Cases
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Pablo,
On Tue, May 31, 2011 at 20:44, Pablo Cases <pablo.cases@flatfrog.com> wrote:
>
> On 31 maj 2011, at 18:55, "Benjamin Tissoires"
> <benjamin.tissoires@gmail.com> wrote:
>
> On Tue, May 31, 2011 at 18:03, Pablo Cases <pablo.cases@flatfrog.com> wrote:
>
> Hi Benjamin,
>
> I've attached some logs (rdesc.txt, events.txt and evtest.txt) showing a
> simulated 2-touch sequence spanning over four frames (last frame is a
> "untouch" event). Looking at the logs I'd say that I have a problem with the
> MIN/MAX limit decoding as evtest says limits are -127/127 but that is not
> what we're reporting according to rdesc.
>
> Indeed, there are troubles with ranges of X and Y. The good point is
> that besides that, hid-multitouch seems to work well.
> However, what strikes me is that the values are not clamped by the input
> layer.
>
> The problems comes from your mouse emulation, here:
>
> INPUT(4)[INPUT]
> Field(0)
> ....
> Field(1)
> Physical(GenericDesktop.Pointer)
> Usage(3)
> GenericDesktop.X
> GenericDesktop.Y
> GenericDesktop.Wheel
> Logical Minimum(-127) <---------
> Logical Maximum(127) <---------
> Report Size(8)
> Report Count(3)
> Report Offset(8)
> Flags( Variable Relative )
>
> the values are not coherent with the one reported above. Maybe we
> should patch hid-multitouch to ignore non mt inputs... ;-) but I
> really don"t have the time to do it right now.
> Maybe you don't need to introduce this mouse emulation at all in your
> device (it depends if your "firmware" will support it or not).
>
> Ok, we'll skip mouse reporting for now to avoid confusing the drivers.
> Anyway, my understanding from the win7 documentation is that mouse and
> single-touch input modes are just backup modes for older Windows versions,
> and that win7 always defaults to multitiouch mode.
Yes, and so does hid-multitouch. It sends the value "2" on the input
mode to switch to multitouch mode. If you want to keep it, use a
touchscreen emulation (and not a mouse one) with the same ranges for X
and Y and no wheel.
>
> There is also a problem with the feature
> Digitizers.ContactMaximumNumber. Apparently, I would say that you put
> the initial value is at 2 instead of 10 as your maximum value
> suggests. If it's intentional, it's fine, but you won't be able to
> send more than two touches, even by changing this number later...
> (just saw the question after)
>
> This part of the communication I don't really understand completely.
> Q: Where/how am I initially reporting a limit of two touches?
The value of the feature countactMaximumNumber is at 2. I don't know
how this came out, but your ABS_MT_SLOT max shows that.
> Q: Is the driver using the logical_maximum value of the ContactCountMaximum
> in the Report Descriptor as the default value for my device? I thought these
> logical_max/min values were only used for data validation, like XSL schemas
> validate XML data.
Nope, the driver use the value of the field and not the min/max. And
once we got that (while plugging the device), the driver can not send
more than this number of touches.
This choice is made in the function mt_feature_mapping. I did not
introduced logical_max as all the devices I saw were working with
that.
>
>
> While we're at it I have some more questions:
>
> Q: Do we need to acknowledge the Device Configuration Feature Report sent
> from the host to the device (instructing the device to report "multi-touch"
> events)?
>
> If you are talking about the "Digitizers.InputMode" setting, then, we
> just send the signal and we don't wait for an answer. My memory is
> quite confusing here, but again, if you don't intend to support mouse
> emulation, dropping this input in the reports will ease things.
>
> We'll drop this part also to test if it improves the situation :)
This is the switch that allows the driver to send either touchscreen
emulation or multitouch. So if you drop the touchscreen emulation,
drop the input mode, if not, then by default (1 I suppose) send
touchscreen emulation, and once you received 2 on the input mode, send
multitouch data.
Cheers,
Benjamin
>
> Q: Do we need to send the ContactCountMaximum Feature Report as described in
> the Windows 7 specification? Because I can see that these values are
> hardcoded (or just initialized?) in hid-multitouch for each supported
> device.
>
> So, the first implementation of hid-multitouch did not care about this
> feature. Now, I tried to use it for devices that send it correctly. As
> I did not asked all the owners of the devices to redo the tests, some
> device still got .maxcontact
> I'd rather not have this thing hardcoded in order to be able to reuse
> the different classes with a lot of devices.
>
> Cheers,
> Benjamin
>
>
> Regards,
>
> Pablo
>
>
> -----Original Message-----
>
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>
> Sent: den 31 maj 2011 13:19
>
> To: Pablo Cases
>
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>
> input@vger.kernel.org
>
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo,
>
> On Mon, May 30, 2011 at 18:11, Pablo Cases <pablo.cases@flatfrog.com>
>
> wrote:
>
> Hi Benjamin,
>
> Now things seem to work a lot better thanks to your input :) I'm
>
> still on the 2.6.38 version of the multitouch code, but static
>
> registering works after adding our faked USB VIP/PID to hid.ids.c, hid-
>
> core.c and hid-multitouch.c:
>
> Digitizers.TipSwitch ---> Key.Touch
>
> Digitizers.InRange ---> Sync.Report
>
> Digitizers.ContactID ---> Sync.Report
>
> GenericDesktop.X ---> Absolute.MTPositionX
>
> GenericDesktop.Y ---> Absolute.MTPositionY
>
> Digitizers.TipSwitch ---> Key.Touch
>
> Digitizers.InRange ---> Sync.Report
>
> Digitizers.ContactID ---> Sync.Report
>
> GenericDesktop.X ---> Absolute.MTPositionX
>
> GenericDesktop.Y ---> Absolute.MTPositionY
>
> Digitizers.ContactCount ---> Sync.Report
>
> Button.0001 ---> Key.LeftBtn
>
> Button.0002 ---> Key.RightBtn
>
> Button.0003 ---> Key.MiddleBtn
>
> GenericDesktop.X ---> Absolute.MTPositionX
>
> GenericDesktop.Y ---> Absolute.MTPositionY
>
> GenericDesktop.Wheel ---> Relative.Wheel
>
> Running some diagnostics:
>
> workstation$ sudo python eviocg.py /dev/input/event3
>
> the device '/dev/input/event3' is multitouch enabled with the
>
> protocol B.
>
> Can you send me the output of the command "evtest /dev/input/event3"
>
> while moving/releasing fingers? I'm particularly interested in the
>
> headers of this output (with the maximum of the ABS_MT_SLOTS).
>
> Can you also send the full reports descriptor from
>
> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>
>
> An unmodified version of mtdiag now discovers our multitouch device,
>
> but I cannot get any valid touch output in the "drawing surface" of the
>
> application. You mentioned that I could optimize things by using some
>
> of the quirk defined, but is this necessary or optional?
>
> purely optional. (normally)
>
> If I'm reporting as the Windows 7 specification describes do I still
>
> need to use any of the quirks?
>
> the point is that many hardware makers interpreted differently this
>
> documentation (that's why we have those quirks). I'm not sure how
>
> Microsoft handles this mess, but it may be even more complicated than
>
> our hid-multitouch... So I can not guarantee that it will work out of
>
> the box.
>
> The big point lies in the understanding of the different
>
> significations of the fields during a touch life time.
>
> Specially I'm wondering about the quirks that relate to contact
>
> id/contact number and slots. Do I really need to think about slots at
>
> all if I have valid ContactIDs in my reports?
>
> Well it's optimization, so it's optional (though I prefer, because it
>
> avoids finding elements in lists).
>
> Cheers,
>
> Benjamin
>
>
> Regards,
>
> Pablo
>
>
> -----Original Message-----
>
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>
> Sent: den 28 maj 2011 00:42
>
> To: Pablo Cases
>
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>
> input@vger.kernel.org
>
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo
>
> On Sat, May 28, 2011 at 00:08, Pablo Cases
>
> <pablo.cases@flatfrog.com>
>
> wrote:
>
> Hi Benjamin,
>
> Thanks for the response. It is my ignorance that should be excused
>
> as
>
> I have shown/will show that I am the novice with regards to USB HID
>
> and
>
> multitouch in this forum :)
>
> I´ll continue interleaving additional comments below.
>
> -Pablo
>
> -----Original Message-----
>
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
>
> Sent: den 27 maj 2011 18:10
>
> To: Pablo Cases
>
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
>
> input@vger.kernel.org
>
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo,
>
> Adding Stéphane, Henrik and Jiri in CC.
>
> On Fri, May 27, 2011 at 17:33, Pablo Cases
>
> <pablo.cases@flatfrog.com>
>
> wrote:
>
> Hi all,
>
> I have searched the net and the archives of linux-input for
>
> information on how to use the Linux g_hid kernel module on a
>
> device
>
> and
>
> the hid-multitouch kernel module on a host to communicate
>
> multitouch
>
> events. But unfortunately I can only get single touch working.
>
> Excuse my ignorance, I didn't know g_hid existed before your
>
> mail.
>
> If
>
> I understand it well enough, it's an hid emulation from user-
>
> space.
>
> Are you trying to inject events from a device in user-space to
>
> the
>
> kernel? If so, I think it would be easier to use uinput. And the
>
> funny
>
> think was that I'm currently writing a small lib to inject
>
> mulitouch
>
> events in a uinput device in an easier way.
>
>
> Maybe I misunderstand your explanation above but we´re not running
>
> g_hid and hid-multitouch on the same system. We have a separate
>
> hardware USB device running Linux with the g_hid kernel module
>
> loaded.
>
> On this device we then have (thanks to g_hid) a userspace file
>
> called
>
> /dev/hidg0 that we can write USB HID input reports to, which then
>
> will
>
> be sent through the device's gadget usb framework, through an
>
> physical
>
> USB cable, to a separate PC host running hid-multitouch.
>
> Thanks for the explaination. I didn't knew that it was possible to
>
> do
>
> such things. Linux is really a wonderful world ;-)
>
>
>
> Q: Has anyone successfully completed a g_hid <-> hid-multitouch
>
> setup? And is there a description somewhere of such setup?
>
> I don't think so, hid-multitouch is really new (since 2.6.38, and
>
> was
>
> not very generic at this time).
>
> Q: Is the Windows 7 multitouch USB HID descriptor the correct
>
> one
>
> to
>
> use also for Linux hid-multitouch? Or is some tweaking necessary?
>
> Normally, any valid Windows 7 multitouch USB HID descriptor can
>
> be
>
> handled by hid-multitouch.
>
> But it's more the events that are sent to hid-multitouch that
>
> will
>
> tell if your device is compatible or not.
>
>
> DETAILED DESCRIPTION BELOW
>
> The device is a Linux device that uses g_hid (currently 2.6.37
>
> kernel) and a USB HID Report Descriptor for multitouch using two-
>
> touch
>
> parallel mode according to Microsoft document
>
> http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
>
> On the host (ubuntu 11.04, 2.6.38 kernel) I register
>
> dynamically
>
> according to the description at http://lii-
>
> enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html.
>
> Using
>
> the events/rdesc files in debugfs on Ubuntu 11.04 I have
>
> validated
>
> the
>
> parsing of the report descriptor and the input reports.
>
> This is really a bad idea to use these howto with ubuntu 11.04
>
> ATM.
>
> I
>
> didn't found the time to update this stuff, and this branch can
>
> not
>
> be
>
> used in ubuntu 11.04 (it contains code for 2.6.35 only, and there
>
> were
>
> changes in the hid layer after). If you only used the part "How
>
> to
>
> add
>
> your device to hid-multitouch from the user space" without
>
> updating
>
> your hid module, then it's as if you have'nt done anything (the
>
> generic hid module can not autodetect multitouch devices).
>
> Currently I am using the hid-multitouch code as existing in the
>
> source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-
>
> get.
>
> In the page referred to above I have only used the "How to add your
>
> device to hid-multitouch from the user space", and not the 2.6.35
>
> related parts.
>
> So there are no autodetection in your kernel.
>
>
> Ok, so for autodetection of multitouch devices to work I need to
>
> update the hid-multitouch module to a newer version (than was
>
> available
>
> in 2.6.38), preferably head on a git master branch somewhere?
>
> Another
>
> option is to add a static configuration field in hid-multitouch and
>
> hid-ids.h for my USB device's VID/PID. But then again, maybe it's
>
> better to do that on the latest available code as well?
>
> Autodetection is not available upstream too, sorry. The latest
>
> available code is on Jiri's tree. I'll try to maintain a bunch of
>
> patches to backport the work done on hid-multitouch since 2.6.35 on
>
> http://lii-enac.fr/en/architecture/linux-input/multitouch-
>
> howto.html#hid-multitouch
>
> but I'm a little late for the backports right now.
>
> Jiri's tree is at
>
> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
>
>
>
> Example multitouch input report from
>
> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
>
> report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14
>
> 32
>
> 0e
>
> 02
>
> Digitizers.TipSwitch = 1
>
> Digitizers.InRange = 1
>
> Digitizers.ContactID = 0
>
> GenericDesktop.X = 4773
>
> GenericDesktop.Y = 3634
>
> Digitizers.TipSwitch = 1
>
> Digitizers.InRange = 1
>
> Digitizers.ContactID = 1
>
> GenericDesktop.X = 5273
>
> GenericDesktop.Y = 3634
>
> Digitizers.ContactCount = 2
>
>
> Most of the time, the problematic part comes from the releases.
>
> But
>
> it's a good start.
>
> With "releases" I assume you mean the finger removal from the
>
> touch
>
> surface, like a "touch-up" event? I have not implemented that part
>
> yet,
>
> but our Microsoft contact informed us that for Windows 7
>
> compatibility
>
> it should be reported as a final touch report with
>
> TipSwitch = 0
>
> InRange = 1
>
> Is this applicable to hid-multitouch too?
>
> Exactly, I meant touch-up. Your behavior is applicable to hid-
>
> multitouch.
>
> Once registering your device with hid-multitouch, you can choose a
>
> class that controls how optimized your driver will be. Normally, the
>
> MT_CLS_DEFAULT class will work with any Win 7 compliant device
>
> (crossing fingers).
>
> Then, you can optimize it by looking for the classes that have
>
> MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time,
>
> you
>
> can also optimize the way your device actually does the match
>
> between
>
> slots (from 0 to N-1 with N the maximum contact count of your
>
> device)
>
> and the tracking_id reported by the device (or the position in the
>
> hid
>
> report).
>
> For dual touches only devices, the differences are not big, but we
>
> prefer to optimize things all the time ;-)
>
>
> The first touch in the report is correctly presented both on
>
> Windows
>
> and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak
>
> to
>
> display data from all devices not just multitouch ones). I can
>
> see
>
> in
>
> the debugfs files that the data for the second touch data is
>
> correctly
>
> transferred and interpreted (see above), but the mapping to the
>
> linux
>
> input system seems a bit strange though (see below). My guess is
>
> that I
>
> have not been correctly registered as a multitouch device. I'm
>
> assuming
>
> this also because I cannot see any activity from the hid-
>
> multitouch
>
> module other than it being initialized when I connect my device
>
> (probably another reason for the needed tweak in mtdiag above).
>
> Example mapping from
>
> /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
>
> that does not look entirely correct for the second touch:
>
> Digitizers.TipSwitch ---> Key.Touch
>
> Digitizers.InRange ---> Key.ToolPen
>
> Digitizers.ContactID ---> Absolute.Misc
>
> GenericDesktop.X ---> Absolute.X
>
> GenericDesktop.Y ---> Absolute.Y
>
> Digitizers.TipSwitch ---> Key.Touch
>
> Digitizers.InRange ---> Key.ToolRubber
>
> Digitizers.ContactID ---> Absolute.?
>
> GenericDesktop.X ---> Absolute.Z
>
> GenericDesktop.Y ---> Absolute.Rx
>
> This means that your device is handled by the generic usbhid and
>
> not
>
> hid-multitouch.
>
> That is what troubles me. I can see in the host's dmesg that
>
> "generic-usb" seems to be the driver chosen for my device when it is
>
> connected to the host. And according to your comment above I might
>
> not
>
> have correctly registered my device in hid-multitouch which would be
>
> the source of the problem...
>
> As a side note; I have sprinkled printk() here and there hid-
>
> multitouch.c and hid-core.c. While running the code I can only see
>
> that
>
> mt_init() and mt_exit() are called during module loading/unloading;
>
> never do I see any evidence of that the probing or mapping functions
>
> in
>
> hid-multitouch are used, only the generic usb parts are used for
>
> parsing the report descriptors and input reports.
>
> Yep, hid-multitouch does not handle your device. There is currently
>
> no
>
> user-space way to tell usbhid (the generic) not to handle a device.
>
> You'll have to add your VID-PID to the hid_have_special_driver list
>
> (in hid-core.c) to disable generic usb hid handling for your device.
>
> You can check the latest patches adding a specific device to
>
> hid-multitouch to have some examples.
>
>
> Could you point me to the location in the code where the decision
>
> is
>
> taken to use the hid-multitouch driver for a hid-multitouch
>
> supported
>
> device? I'm guessing it is somewhere in hid-core.c but I have not
>
> been
>
> able to pinpoint the location exactly. I could use this location as
>
> a
>
> start point to backtrace why we're not considered as a hid-
>
> multitouch
>
> supported device.
>
> it's just above ;-) hid_have_special_driver in hid-core.c
>
> Cheers,
>
> Benjamin
>
>
> If you are trying to inject events from the user space, I
>
> strongly
>
> recommend to use uinput instead. Let me know if you want to have
>
> my
>
> little uinput-multitouch lib.
>
> Cheers,
>
> Benjamin
>
> Digitizers.ContactCount ---> Absolute.?
>
> Button.0001 ---> Key.LeftBtn
>
> Button.0002 ---> Key.RightBtn
>
> Button.0003 ---> Key.MiddleBtn
>
> GenericDesktop.X ---> Relative.X
>
> GenericDesktop.Y ---> Relative.Y
>
> GenericDesktop.Wheel ---> Relative.Wheel
>
>
> Regards,
>
> Pablo Cases
>
> -------------------------
>
> Pablo Cases, M.Sc.
>
> Development Engineer Software
>
> FlatFrog Laboratories AB
>
> Magistratsvägen 10
>
> 22643 Lund
>
> Sweden
>
> Tel: +46 708 393816
>
> Mail: pc@flatfrog.com
>
> Web: www.flatfrog.com
>
> --
>
> 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] 10+ messages in thread
* RE: g_hid and hid-multitouch compatibility?
2011-06-01 17:21 ` Benjamin Tissoires
@ 2011-06-07 6:25 ` Pablo Cases
0 siblings, 0 replies; 10+ messages in thread
From: Pablo Cases @ 2011-06-07 6:25 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Stéphane Chatty, Henrik Rydberg, Jiri Kosina, linux-input
Hi Benjamin,
We finally got multitouch working; first in Ubuntu 11.04 then in Windows 7 :)
Mainly we've done two changes:
* removed mouse support from our report descriptor (to at least not confuse hid-multitouch)
* hacked g_hid kernel module (on the sender side) to properly autoreply to the HID Get_Report(ContactCountMaximum) request from the host. Previously the g_hid module autoreplied with empty packages to all HID Get_Report requests...
Also, it might be good to know that if testing against an application like Paint on Windows 7, then it appears that the application needs to be started AFTER the multitouch device has been plugged into the system. Otherwise Paint will be started in single touch mode...
I've added some more comments to the issues below.
Thanks for all the help.
/Pablo
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> Sent: den 1 juni 2011 19:21
> To: Pablo Cases
> Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> input@vger.kernel.org
> Subject: Re: g_hid and hid-multitouch compatibility?
>
> Hi Pablo,
>
> On Tue, May 31, 2011 at 20:44, Pablo Cases <pablo.cases@flatfrog.com>
> wrote:
> >
> > On 31 maj 2011, at 18:55, "Benjamin Tissoires"
> > <benjamin.tissoires@gmail.com> wrote:
> >
> > On Tue, May 31, 2011 at 18:03, Pablo Cases <pablo.cases@flatfrog.com>
> wrote:
> >
> > Hi Benjamin,
> >
> > I've attached some logs (rdesc.txt, events.txt and evtest.txt)
> showing a
> > simulated 2-touch sequence spanning over four frames (last frame is a
> > "untouch" event). Looking at the logs I'd say that I have a problem
> with the
> > MIN/MAX limit decoding as evtest says limits are -127/127 but that is
> not
> > what we're reporting according to rdesc.
> >
> > Indeed, there are troubles with ranges of X and Y. The good point is
> > that besides that, hid-multitouch seems to work well.
> > However, what strikes me is that the values are not clamped by the
> input
> > layer.
> >
> > The problems comes from your mouse emulation, here:
> >
> > INPUT(4)[INPUT]
> > Field(0)
> > ....
> > Field(1)
> > Physical(GenericDesktop.Pointer)
> > Usage(3)
> > GenericDesktop.X
> > GenericDesktop.Y
> > GenericDesktop.Wheel
> > Logical Minimum(-127) <---------
> > Logical Maximum(127) <---------
> > Report Size(8)
> > Report Count(3)
> > Report Offset(8)
> > Flags( Variable Relative )
> >
> > the values are not coherent with the one reported above. Maybe we
> > should patch hid-multitouch to ignore non mt inputs... ;-) but I
> > really don"t have the time to do it right now.
> > Maybe you don't need to introduce this mouse emulation at all in your
> > device (it depends if your "firmware" will support it or not).
> >
> > Ok, we'll skip mouse reporting for now to avoid confusing the
> drivers.
> > Anyway, my understanding from the win7 documentation is that mouse
> and
> > single-touch input modes are just backup modes for older Windows
> versions,
> > and that win7 always defaults to multitiouch mode.
>
> Yes, and so does hid-multitouch. It sends the value "2" on the input
> mode to switch to multitouch mode. If you want to keep it, use a
> touchscreen emulation (and not a mouse one) with the same ranges for X
> and Y and no wheel.
Ok. We skipped all mouse/mouse emulation support for now. We have initially kept the Device Configuration report because we could not get Windows multitouch to work otherwise.
>
> >
> > There is also a problem with the feature
> > Digitizers.ContactMaximumNumber. Apparently, I would say that you put
> > the initial value is at 2 instead of 10 as your maximum value
> > suggests. If it's intentional, it's fine, but you won't be able to
> > send more than two touches, even by changing this number later...
> > (just saw the question after)
> >
> > This part of the communication I don't really understand completely.
> > Q: Where/how am I initially reporting a limit of two touches?
>
> The value of the feature countactMaximumNumber is at 2. I don't know
> how this came out, but your ABS_MT_SLOT max shows that.
>
I'm assuming you deciphered this value from the evtest output lines wich code 47 (0x2f)? I had forgot that I hacked the declaration of MT_CLS_DEFAULT for testing purposes and set .maxcontacts=2 instead of the default value of 10.
> > Q: Is the driver using the logical_maximum value of the
> ContactCountMaximum
> > in the Report Descriptor as the default value for my device? I
> thought these
> > logical_max/min values were only used for data validation, like XSL
> schemas
> > validate XML data.
>
> Nope, the driver use the value of the field and not the min/max. And
> once we got that (while plugging the device), the driver can not send
> more than this number of touches.
> This choice is made in the function mt_feature_mapping. I did not
> introduced logical_max as all the devices I saw were working with
> that.
This took us a while to understand. Because we were not seeing the ContactCountMaximum request in userspace on the sender side of the g_hid kernel module. It appears though that the g_hid module autoreplies with empty packages to all HID Get_Report() requests. These empty autoreplies were by obvious reasons not "accepted" on the host side as valid replies. The original lines in f-hid.c are:
case ((USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
| HID_REQ_GET_REPORT):
VDBG(cdev, "get_report\n");
/* send an empty report */
length = min_t(unsigned, length, hidg->report_length);
memset(req->buf, 0x0, length);
goto respond;
break;
> >
> >
> > While we're at it I have some more questions:
> >
> > Q: Do we need to acknowledge the Device Configuration Feature Report
> sent
> > from the host to the device (instructing the device to report "multi-
> touch"
> > events)?
> >
> > If you are talking about the "Digitizers.InputMode" setting, then, we
> > just send the signal and we don't wait for an answer. My memory is
> > quite confusing here, but again, if you don't intend to support mouse
> > emulation, dropping this input in the reports will ease things.
> >
> > We'll drop this part also to test if it improves the situation :)
>
> This is the switch that allows the driver to send either touchscreen
> emulation or multitouch. So if you drop the touchscreen emulation,
> drop the input mode, if not, then by default (1 I suppose) send
> touchscreen emulation, and once you received 2 on the input mode, send
> multitouch data.
We're keeping the Device Configuration report for now (even if we're including mouse emulation or single-touch support). It seems like Windows works better if this report is included. On the receiver side we're only replying with an ACK, no other confirmation is sent to the host.
> Cheers,
> Benjamin
>
>
> >
> > Q: Do we need to send the ContactCountMaximum Feature Report as
> described in
> > the Windows 7 specification? Because I can see that these values are
> > hardcoded (or just initialized?) in hid-multitouch for each supported
> > device.
> >
> > So, the first implementation of hid-multitouch did not care about
> this
> > feature. Now, I tried to use it for devices that send it correctly.
> As
> > I did not asked all the owners of the devices to redo the tests, some
> > device still got .maxcontact
> > I'd rather not have this thing hardcoded in order to be able to reuse
> > the different classes with a lot of devices.
> >
> > Cheers,
> > Benjamin
> >
> >
> > Regards,
> >
> > Pablo
> >
> >
> > -----Original Message-----
> >
> > From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> >
> > Sent: den 31 maj 2011 13:19
> >
> > To: Pablo Cases
> >
> > Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> >
> > input@vger.kernel.org
> >
> > Subject: Re: g_hid and hid-multitouch compatibility?
> >
> > Hi Pablo,
> >
> > On Mon, May 30, 2011 at 18:11, Pablo Cases <pablo.cases@flatfrog.com>
> >
> > wrote:
> >
> > Hi Benjamin,
> >
> > Now things seem to work a lot better thanks to your input :) I'm
> >
> > still on the 2.6.38 version of the multitouch code, but static
> >
> > registering works after adding our faked USB VIP/PID to hid.ids.c,
> hid-
> >
> > core.c and hid-multitouch.c:
> >
> > Digitizers.TipSwitch ---> Key.Touch
> >
> > Digitizers.InRange ---> Sync.Report
> >
> > Digitizers.ContactID ---> Sync.Report
> >
> > GenericDesktop.X ---> Absolute.MTPositionX
> >
> > GenericDesktop.Y ---> Absolute.MTPositionY
> >
> > Digitizers.TipSwitch ---> Key.Touch
> >
> > Digitizers.InRange ---> Sync.Report
> >
> > Digitizers.ContactID ---> Sync.Report
> >
> > GenericDesktop.X ---> Absolute.MTPositionX
> >
> > GenericDesktop.Y ---> Absolute.MTPositionY
> >
> > Digitizers.ContactCount ---> Sync.Report
> >
> > Button.0001 ---> Key.LeftBtn
> >
> > Button.0002 ---> Key.RightBtn
> >
> > Button.0003 ---> Key.MiddleBtn
> >
> > GenericDesktop.X ---> Absolute.MTPositionX
> >
> > GenericDesktop.Y ---> Absolute.MTPositionY
> >
> > GenericDesktop.Wheel ---> Relative.Wheel
> >
> > Running some diagnostics:
> >
> > workstation$ sudo python eviocg.py /dev/input/event3
> >
> > the device '/dev/input/event3' is multitouch enabled with the
> >
> > protocol B.
> >
> > Can you send me the output of the command "evtest /dev/input/event3"
> >
> > while moving/releasing fingers? I'm particularly interested in the
> >
> > headers of this output (with the maximum of the ABS_MT_SLOTS).
> >
> > Can you also send the full reports descriptor from
> >
> > /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
> >
> >
> > An unmodified version of mtdiag now discovers our multitouch device,
> >
> > but I cannot get any valid touch output in the "drawing surface" of
> the
> >
> > application. You mentioned that I could optimize things by using some
> >
> > of the quirk defined, but is this necessary or optional?
> >
> > purely optional. (normally)
> >
> > If I'm reporting as the Windows 7 specification describes do I still
> >
> > need to use any of the quirks?
> >
> > the point is that many hardware makers interpreted differently this
> >
> > documentation (that's why we have those quirks). I'm not sure how
> >
> > Microsoft handles this mess, but it may be even more complicated than
> >
> > our hid-multitouch... So I can not guarantee that it will work out of
> >
> > the box.
> >
> > The big point lies in the understanding of the different
> >
> > significations of the fields during a touch life time.
> >
> > Specially I'm wondering about the quirks that relate to contact
> >
> > id/contact number and slots. Do I really need to think about slots at
> >
> > all if I have valid ContactIDs in my reports?
> >
> > Well it's optimization, so it's optional (though I prefer, because it
> >
> > avoids finding elements in lists).
> >
> > Cheers,
> >
> > Benjamin
> >
> >
> > Regards,
> >
> > Pablo
> >
> >
> > -----Original Message-----
> >
> > From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> >
> > Sent: den 28 maj 2011 00:42
> >
> > To: Pablo Cases
> >
> > Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> >
> > input@vger.kernel.org
> >
> > Subject: Re: g_hid and hid-multitouch compatibility?
> >
> > Hi Pablo
> >
> > On Sat, May 28, 2011 at 00:08, Pablo Cases
> >
> > <pablo.cases@flatfrog.com>
> >
> > wrote:
> >
> > Hi Benjamin,
> >
> > Thanks for the response. It is my ignorance that should be excused
> >
> > as
> >
> > I have shown/will show that I am the novice with regards to USB HID
> >
> > and
> >
> > multitouch in this forum :)
> >
> > I´ll continue interleaving additional comments below.
> >
> > -Pablo
> >
> > -----Original Message-----
> >
> > From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> >
> > Sent: den 27 maj 2011 18:10
> >
> > To: Pablo Cases
> >
> > Cc: Stéphane Chatty; Henrik Rydberg; Jiri Kosina; linux-
> >
> > input@vger.kernel.org
> >
> > Subject: Re: g_hid and hid-multitouch compatibility?
> >
> > Hi Pablo,
> >
> > Adding Stéphane, Henrik and Jiri in CC.
> >
> > On Fri, May 27, 2011 at 17:33, Pablo Cases
> >
> > <pablo.cases@flatfrog.com>
> >
> > wrote:
> >
> > Hi all,
> >
> > I have searched the net and the archives of linux-input for
> >
> > information on how to use the Linux g_hid kernel module on a
> >
> > device
> >
> > and
> >
> > the hid-multitouch kernel module on a host to communicate
> >
> > multitouch
> >
> > events. But unfortunately I can only get single touch working.
> >
> > Excuse my ignorance, I didn't know g_hid existed before your
> >
> > mail.
> >
> > If
> >
> > I understand it well enough, it's an hid emulation from user-
> >
> > space.
> >
> > Are you trying to inject events from a device in user-space to
> >
> > the
> >
> > kernel? If so, I think it would be easier to use uinput. And the
> >
> > funny
> >
> > think was that I'm currently writing a small lib to inject
> >
> > mulitouch
> >
> > events in a uinput device in an easier way.
> >
> >
> > Maybe I misunderstand your explanation above but we´re not running
> >
> > g_hid and hid-multitouch on the same system. We have a separate
> >
> > hardware USB device running Linux with the g_hid kernel module
> >
> > loaded.
> >
> > On this device we then have (thanks to g_hid) a userspace file
> >
> > called
> >
> > /dev/hidg0 that we can write USB HID input reports to, which then
> >
> > will
> >
> > be sent through the device's gadget usb framework, through an
> >
> > physical
> >
> > USB cable, to a separate PC host running hid-multitouch.
> >
> > Thanks for the explaination. I didn't knew that it was possible to
> >
> > do
> >
> > such things. Linux is really a wonderful world ;-)
> >
> >
> >
> > Q: Has anyone successfully completed a g_hid <-> hid-multitouch
> >
> > setup? And is there a description somewhere of such setup?
> >
> > I don't think so, hid-multitouch is really new (since 2.6.38, and
> >
> > was
> >
> > not very generic at this time).
> >
> > Q: Is the Windows 7 multitouch USB HID descriptor the correct
> >
> > one
> >
> > to
> >
> > use also for Linux hid-multitouch? Or is some tweaking necessary?
> >
> > Normally, any valid Windows 7 multitouch USB HID descriptor can
> >
> > be
> >
> > handled by hid-multitouch.
> >
> > But it's more the events that are sent to hid-multitouch that
> >
> > will
> >
> > tell if your device is compatible or not.
> >
> >
> > DETAILED DESCRIPTION BELOW
> >
> > The device is a Linux device that uses g_hid (currently 2.6.37
> >
> > kernel) and a USB HID Report Descriptor for multitouch using two-
> >
> > touch
> >
> > parallel mode according to Microsoft document
> >
> > http://msdn.microsoft.com/en-us/windows/hardware/gg487437.
> >
> > On the host (ubuntu 11.04, 2.6.38 kernel) I register
> >
> > dynamically
> >
> > according to the description at http://lii-
> >
> > enac.fr/en/architecture/linux-input/multitouch-ubuntu-howto.html.
> >
> > Using
> >
> > the events/rdesc files in debugfs on Ubuntu 11.04 I have
> >
> > validated
> >
> > the
> >
> > parsing of the report descriptor and the input reports.
> >
> > This is really a bad idea to use these howto with ubuntu 11.04
> >
> > ATM.
> >
> > I
> >
> > didn't found the time to update this stuff, and this branch can
> >
> > not
> >
> > be
> >
> > used in ubuntu 11.04 (it contains code for 2.6.35 only, and there
> >
> > were
> >
> > changes in the hid layer after). If you only used the part "How
> >
> > to
> >
> > add
> >
> > your device to hid-multitouch from the user space" without
> >
> > updating
> >
> > your hid module, then it's as if you have'nt done anything (the
> >
> > generic hid module can not autodetect multitouch devices).
> >
> > Currently I am using the hid-multitouch code as existing in the
> >
> > source distribution of a 2.6.38 Ubuntu 11.04 fetched through apt-
> >
> > get.
> >
> > In the page referred to above I have only used the "How to add your
> >
> > device to hid-multitouch from the user space", and not the 2.6.35
> >
> > related parts.
> >
> > So there are no autodetection in your kernel.
> >
> >
> > Ok, so for autodetection of multitouch devices to work I need to
> >
> > update the hid-multitouch module to a newer version (than was
> >
> > available
> >
> > in 2.6.38), preferably head on a git master branch somewhere?
> >
> > Another
> >
> > option is to add a static configuration field in hid-multitouch and
> >
> > hid-ids.h for my USB device's VID/PID. But then again, maybe it's
> >
> > better to do that on the latest available code as well?
> >
> > Autodetection is not available upstream too, sorry. The latest
> >
> > available code is on Jiri's tree. I'll try to maintain a bunch of
> >
> > patches to backport the work done on hid-multitouch since 2.6.35 on
> >
> > http://lii-enac.fr/en/architecture/linux-input/multitouch-
> >
> > howto.html#hid-multitouch
> >
> > but I'm a little late for the backports right now.
> >
> > Jiri's tree is at
> >
> > http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=summary
> >
> >
> >
> > Example multitouch input report from
> >
> > /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:
> >
> > report (size 14) (numbered) = 05 03 00 a5 12 32 0e 03 01 99 14
> >
> > 32
> >
> > 0e
> >
> > 02
> >
> > Digitizers.TipSwitch = 1
> >
> > Digitizers.InRange = 1
> >
> > Digitizers.ContactID = 0
> >
> > GenericDesktop.X = 4773
> >
> > GenericDesktop.Y = 3634
> >
> > Digitizers.TipSwitch = 1
> >
> > Digitizers.InRange = 1
> >
> > Digitizers.ContactID = 1
> >
> > GenericDesktop.X = 5273
> >
> > GenericDesktop.Y = 3634
> >
> > Digitizers.ContactCount = 2
> >
> >
> > Most of the time, the problematic part comes from the releases.
> >
> > But
> >
> > it's a good start.
> >
> > With "releases" I assume you mean the finger removal from the
> >
> > touch
> >
> > surface, like a "touch-up" event? I have not implemented that part
> >
> > yet,
> >
> > but our Microsoft contact informed us that for Windows 7
> >
> > compatibility
> >
> > it should be reported as a final touch report with
> >
> > TipSwitch = 0
> >
> > InRange = 1
> >
> > Is this applicable to hid-multitouch too?
> >
> > Exactly, I meant touch-up. Your behavior is applicable to hid-
> >
> > multitouch.
> >
> > Once registering your device with hid-multitouch, you can choose a
> >
> > class that controls how optimized your driver will be. Normally, the
> >
> > MT_CLS_DEFAULT class will work with any Win 7 compliant device
> >
> > (crossing fingers).
> >
> > Then, you can optimize it by looking for the classes that have
> >
> > MT_QUIRK_VALID_IS_INRANGE (or adding a new one). In the same time,
> >
> > you
> >
> > can also optimize the way your device actually does the match
> >
> > between
> >
> > slots (from 0 to N-1 with N the maximum contact count of your
> >
> > device)
> >
> > and the tracking_id reported by the device (or the position in the
> >
> > hid
> >
> > report).
> >
> > For dual touches only devices, the differences are not big, but we
> >
> > prefer to optimize things all the time ;-)
> >
> >
> > The first touch in the report is correctly presented both on
> >
> > Windows
> >
> > and on Ubuntu 11.04 (using ENAC's mtdiag tool with a minor tweak
> >
> > to
> >
> > display data from all devices not just multitouch ones). I can
> >
> > see
> >
> > in
> >
> > the debugfs files that the data for the second touch data is
> >
> > correctly
> >
> > transferred and interpreted (see above), but the mapping to the
> >
> > linux
> >
> > input system seems a bit strange though (see below). My guess is
> >
> > that I
> >
> > have not been correctly registered as a multitouch device. I'm
> >
> > assuming
> >
> > this also because I cannot see any activity from the hid-
> >
> > multitouch
> >
> > module other than it being initialized when I connect my device
> >
> > (probably another reason for the needed tweak in mtdiag above).
> >
> > Example mapping from
> >
> > /sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc
> >
> > that does not look entirely correct for the second touch:
> >
> > Digitizers.TipSwitch ---> Key.Touch
> >
> > Digitizers.InRange ---> Key.ToolPen
> >
> > Digitizers.ContactID ---> Absolute.Misc
> >
> > GenericDesktop.X ---> Absolute.X
> >
> > GenericDesktop.Y ---> Absolute.Y
> >
> > Digitizers.TipSwitch ---> Key.Touch
> >
> > Digitizers.InRange ---> Key.ToolRubber
> >
> > Digitizers.ContactID ---> Absolute.?
> >
> > GenericDesktop.X ---> Absolute.Z
> >
> > GenericDesktop.Y ---> Absolute.Rx
> >
> > This means that your device is handled by the generic usbhid and
> >
> > not
> >
> > hid-multitouch.
> >
> > That is what troubles me. I can see in the host's dmesg that
> >
> > "generic-usb" seems to be the driver chosen for my device when it is
> >
> > connected to the host. And according to your comment above I might
> >
> > not
> >
> > have correctly registered my device in hid-multitouch which would be
> >
> > the source of the problem...
> >
> > As a side note; I have sprinkled printk() here and there hid-
> >
> > multitouch.c and hid-core.c. While running the code I can only see
> >
> > that
> >
> > mt_init() and mt_exit() are called during module loading/unloading;
> >
> > never do I see any evidence of that the probing or mapping functions
> >
> > in
> >
> > hid-multitouch are used, only the generic usb parts are used for
> >
> > parsing the report descriptors and input reports.
> >
> > Yep, hid-multitouch does not handle your device. There is currently
> >
> > no
> >
> > user-space way to tell usbhid (the generic) not to handle a device.
> >
> > You'll have to add your VID-PID to the hid_have_special_driver list
> >
> > (in hid-core.c) to disable generic usb hid handling for your device.
> >
> > You can check the latest patches adding a specific device to
> >
> > hid-multitouch to have some examples.
> >
> >
> > Could you point me to the location in the code where the decision
> >
> > is
> >
> > taken to use the hid-multitouch driver for a hid-multitouch
> >
> > supported
> >
> > device? I'm guessing it is somewhere in hid-core.c but I have not
> >
> > been
> >
> > able to pinpoint the location exactly. I could use this location as
> >
> > a
> >
> > start point to backtrace why we're not considered as a hid-
> >
> > multitouch
> >
> > supported device.
> >
> > it's just above ;-) hid_have_special_driver in hid-core.c
> >
> > Cheers,
> >
> > Benjamin
> >
> >
> > If you are trying to inject events from the user space, I
> >
> > strongly
> >
> > recommend to use uinput instead. Let me know if you want to have
> >
> > my
> >
> > little uinput-multitouch lib.
> >
> > Cheers,
> >
> > Benjamin
> >
> > Digitizers.ContactCount ---> Absolute.?
> >
> > Button.0001 ---> Key.LeftBtn
> >
> > Button.0002 ---> Key.RightBtn
> >
> > Button.0003 ---> Key.MiddleBtn
> >
> > GenericDesktop.X ---> Relative.X
> >
> > GenericDesktop.Y ---> Relative.Y
> >
> > GenericDesktop.Wheel ---> Relative.Wheel
> >
> >
> > Regards,
> >
> > Pablo Cases
> >
> > -------------------------
> >
> > Pablo Cases, M.Sc.
> >
> > Development Engineer Software
> >
> > FlatFrog Laboratories AB
> >
> > Magistratsvägen 10
> >
> > 22643 Lund
> >
> > Sweden
> >
> > Tel: +46 708 393816
> >
> > Mail: pc@flatfrog.com
> >
> > Web: www.flatfrog.com
> >
> > --
> >
> > 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] 10+ messages in thread
end of thread, other threads:[~2011-06-07 6:25 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-27 15:33 g_hid and hid-multitouch compatibility? Pablo Cases
2011-05-27 16:09 ` Benjamin Tissoires
2011-05-27 22:08 ` Pablo Cases
2011-05-27 22:41 ` Benjamin Tissoires
2011-05-30 16:11 ` Pablo Cases
2011-05-31 11:19 ` Benjamin Tissoires
2011-05-31 16:03 ` Pablo Cases
2011-05-31 16:55 ` Benjamin Tissoires
[not found] ` <35E4813F-ADBF-4988-A80E-6D4DC254AE22@flatfrog.com>
2011-06-01 17:21 ` Benjamin Tissoires
2011-06-07 6:25 ` Pablo Cases
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.