[PATCH] hid: 3m: Simplify touchsreen emulation logic

Henrik Rydberg rydberg at euromail.se
Sun Aug 15 20:32:00 UTC 2010


On 08/15/2010 07:42 PM, Chase Douglas wrote:

> On Sat, 2010-08-14 at 17:29 +0100, Henrik Rydberg wrote:
>> The ten-finger 3M screen M2256PW has a kernel driver already
>> (hid-3m-pct), but with a couple of glitches:
>>
>> 1. The one-touch down/up, which emits BTN_TOUCH events, sometimes does
>> not work properly. This results in buttons getting stuck in the
>> button-down state in the window manager.
>>
>> 2. The action after touch-up in one spot followed by a touch-down in
>> another spot sometimes causes a sequence of strange finger-tracing
>> events along the perimeter of the rectangle between the two spots. The
>> root of the problem lies in how the kernel inteprets the HID hybrid
>> event type which is used by the 3M device [1].
>>
>> While a proper HID solution is being worked out upstream, this patch
>> simplifies the driver logic such that BTN_TOUCH and ABS_X/Y events are
>> emitted properly, in effect papering over the worst problems. Suggested
>> for inclusion in Maverick.
>>
>> [1] Suggested by Stephane Chatty, who also confirms the observed problems.
>>
>> Signed-off-by: Henrik Rydberg <rydberg at euromail.se>

[...]
>

> Won't this emit a button touch down and ABS_{X,Y} event every time any
> finger moves?


No. The input subsystem only emits changes to states. Moreover, only the
position of the first used slot is reported. Other used slots have no effect at all.

> I can think of many ways this could break things,
> including the ABS_{X,Y} values flittering back and forth between all
> fingers touching the screen. This would make dragging and dropping a

> nightmare if you accidentally or intentionally touch more than one
> finger to the display at a time.


This has no effect when running the MT stack in userspace, since multi-finger
touches produce no output. Besides, the problem can only present itself if the
device switches contact identity on the slots.

> Is the one-touch button down/up issue caused by driver logic or hardware
> issues?


As stated in the pretext, the kernel hid implementation is doing the wrong thing
when receiving a hybrid MT event from the device, leading to spurious SYN_REPORT
events. Whether this also breaks the current state logic is yet to be
investigated. The simplified state logic presented in this patch is resilient to
the spurious SYN_REPORT events, and therefore works properly.


> I wonder if a better solution would be single-touch emulation by only
> sending BTN_TOUCH and ABS_{X,Y} events on the first touch started and
> not sending these events on the second touch started when the first is
> released.


As stated in the pretext, the patch is a temporary solution until a proper
solution involving the hid core has been found. The logic you describe is
basically what Stephane Chatty implemented, and which this patch temporarily
removes.

Henrik




More information about the kernel-team mailing list