Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

From: Henrik Rydberg <rydberg@bitmath.org>
To: "Stéphane Chatty" <chatty@enac.fr>
Cc: linux-input <linux-input@vger.kernel.org>
Subject: Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet
Date: Tue, 17 Aug 2010 11:56:02 +0200	[thread overview]
Message-ID: <4C6A5CB2.6000603@bitmath.org> (raw)
In-Reply-To: <BFCA5963-D589-434B-B07B-6899A794F28F@enac.fr>

On 08/17/2010 09:49 AM, Stéphane Chatty wrote:

> 
> Le 16 août 10 à 17:30, Henrik Rydberg a écrit :
> 
>> Stéphane, Jiri,
>>
>> Regarding the several-hid-packets-per-actual-input-packet problem,
>> what do you
>> think about constructing a special MT HID device, using raw_event? It
>> could
>> encapsulate the current protocol a bit better and use the full HID
>> extension.
>>
> 
> Hi Henrik
> 
> This sounds like as a interesting direction for building a generic
> driver for MT devices. However, there still are device specificities
> that we need to deal with:
>  - the serial/parallel/hybrid issue, for which we have ideas but still
> nothing firm;

Not quite firm, but not too far from it either, IMO. Given that the hid-mt
device and its drivers handle all input device interaction, the idea is to
implement the details of the digitizer extension, such as hybrid mode, in the
hid-mt device.

>  - some devices need to be set in multitouch mode; we need some research
> to find out if this can be determined automatically from the report
> descriptors;

We could start off assuming all devices are different in this regard, and slowly
work our way towards unification.

>  - the single touch emulation is highly device dependent. I was (and
> still am) pretty proud of my choice of tracking the 'oldest' finger on
> the panel: this turns multitouch panels into single touch panels that
> are impervious to parasite touches. But the drawback is that currently
> there is no generic method for this tracking: I used whatever
> device-specific information I could use (order of fingers in a message,
> tracking id, etc).

Ah yes, the pointer emulation via ABS_X/Y. My personal view is that pointer
emulation is a gesture, and thus best implemented in userspace. During
multi-finger gestures, the pointer should either not move, or be hidden. The
majority of kernel drivers emit a BTN_TOUCH==1 when the first finger lands on
the surface, and a BTN_TOUCH==0 when the last finger leaves the surface. In
userspace, for touchscreens, the BTN_TOUCH event is traditionally mapped to a
button press, which is not what you want during a gesture. Thus, the pointer
emulation logic has to be remapped in userspace, anyways.

For new drivers, it would be best not to implement BTN_TOUCH/ABS_X/Y at all.
Since most MT devices support legacy mouse mode out-of-the-box via HID, perhaps
one can even argue that hid-mt does not _have_ to support ABS_X/Y. Or, to keep
compatibility, we could provide emulation code in hid-mt.

> As long as these issues are here, we still need a system for
> implementing device-specific behaviour. I must admit I was tempted to
> keep benefitting from the blacklist in hid-core.c until they are resolved.

I agree. The implementation details I have in mind are to take the extra
complexity involved using raw_event _once_, implement it in hid-mt, and then
pass the digested events on to the specialized drivers. If done carefully, I
imagine the changes to each individual driver to be fairly simple.

> An additional question is: how do we decide that a device is a
> multitouch one? Do we keep a list of devices? Or do we rely on a pattern
> found in the report descriptors? In my view it would be great to have a
> pattern matching system for identifying classes of input devices from
> report descriptors, but then it would reacher farther than multitouch only.

This sounds like an interesting idea for future development, but I would say we
can continue to rely on the device list for now.

Cheers,
Henrik
--
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