[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


More information about the kernel-team mailing list