USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

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.

Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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.

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.

Cheers,

St.

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

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

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.

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.

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I agree 100% with you on this (well, I'd rather say that gestures and single touch emulation are two cases of input interpretation, but that's just my academical bias).

However this issue was discussed last year on this list and as far as I understood it was decided that single touch emulation was required in the kernel for some time...

St.

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

At that time, maybe the alternatives were not as clear as they are now. :-) I think what it all means is that over time, we will see less and less of the ABS_X/Y, since we will eventually stop adding it, and hardware inevitably ages.

Cheers,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Stéphan,

Can you explain in more detail why you chose an 'oldest' finger approach for single touch emulation? I wonder if it's the best mechanism. Take the following example:

1. User touches with one finger and intends to drag an object on screen
2. User touches another finger down, either accidentally or intentionally, while dragging the first finger
3. User releases first finger to end the drag
4. Object suddenly is dragged under the second finger

As I'm implementing support for the Magic Trackpad right now, I'm having to figure out the best way to do single-touch emulation. What I'm currently doing is converting the first finger touched for single-touch emulation, and when that finger is released no single-touch emulation can occur until all fingers have left the screen again.

This should hopefully become a moot point once everyone understands MT input, but sadly we have to deal with the reality of X not being MT aware quite yet :).

Thanks,

-- Chase

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Yes, the debate is what to do when the 'actual oldest' finger is
released: should the 'second oldest' take its place or should this be a release or should somthing else occur.

Some arguments in favour of the first option:
- My experience is that 'accidental' touches are transient. Therefore, the conjunction of having an accidental touch and a release is not very frequent.
- At the opposite, on very large screens, it may sometimes be
comfortable to "replace one finger with another", thus 'moving' the dragged object from one hand to the other.

More or less, the debate is about statistics and user experience design...

Cheers,

St.

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Thanks for the explanation! Since this comes down to what the user intends with multiple touches on the screen, I'll trust your experience over mine :).

However, while your 'eldest' method may be good for touchscreens, I think it's a moot point for touchpads since they are relative devices (even if they are really absolute in the driver). The user won't be able to continuously drag across the screen by using multiple fingers because each switch of coordinates from the eldest to the next eldest will generate a relative motion that will just shift the object back where we started a drag.

I'll probably leave my current implementation for the trackpad as is, since it's easier than the 'eldest' method and provides just as much functionality.

-- Chase

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Yes, the debate is what to do when the 'actual oldest' finger is
released: should the 'second oldest' take its place or should this be a release or should somthing else occur.

Some arguments in favour of the first option:
- My experience is that 'accidental' touches are transient. Therefore, the conjunction of having an accidental touch and a release is not very frequent.
- At the opposite, on very large screens, it may sometimes be
comfortable to "replace one finger with another", thus 'moving' the dragged object from one hand to the other.

More or less, the debate is about statistics and user experience design...

Cheers,

St.

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html