Hi Pablo,

On Mon, May 30, 2011 at 18:11, Pablo Cases [off-list ref] 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

quoted

-----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 [off-list ref]
wrote:

quoted

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

quoted

I´ll continue interleaving additional comments below.

-Pablo

quoted

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

[off-list ref]

quoted

quoted

wrote:

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

quoted

quoted

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

quoted

quoted

not very generic at this time).

quoted

Q: Is the Windows 7 multitouch USB HID descriptor the correct one

to

quoted

quoted

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.

quoted

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

quoted

quoted

parallel mode according to Microsoft document
http://msdn.microsoft.com/en-us/windows/hardware/gg487437.

quoted

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

quoted

quoted

the events/rdesc files in debugfs on Ubuntu 11.04 I have validated

the

quoted

quoted

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

quoted

quoted

didn't found the time to update this stuff, and this branch can not

be

quoted

quoted

used in ubuntu 11.04 (it contains code for 2.6.35 only, and there

were

quoted

quoted

changes in the hid layer after). If you only used the part "How to

add

quoted

quoted

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.

quoted

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

quoted

quoted

quoted

Example multitouch input report from

/sys/kernel/debug/hid/0003:xxxx:yyyy.0002/events looks correct:

quoted

report (size 14) (numbered) =  05 03 00 a5 12 32 0e 03 01 99 14 32

0e

quoted

quoted

02

quoted

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

quoted

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

quoted

quoted

quoted

The first touch in the report is correctly presented both on

Windows

quoted

quoted

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

quoted

quoted

the debugfs files that the data for the second touch data is

correctly

quoted

quoted

transferred and interpreted (see above), but the mapping to the

linux

quoted

quoted

input system seems a bit strange though (see below). My guess is

that I

quoted

quoted

have not been correctly registered as a multitouch device. I'm

assuming

quoted

quoted

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

quoted

Example mapping from

/sys/kernel/debug/hid/0003:xxxx:yyyy.0002/rdesc

quoted

quoted

that does not look entirely correct for the second touch:

quoted

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

quoted

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.

quoted

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

quoted

quoted

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

quoted

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

quoted

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