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

Chase Douglas chase.douglas at canonical.com
Sun Aug 15 21:28:10 UTC 2010


On Sun, 2010-08-15 at 22:32 +0200, Henrik Rydberg wrote:
> 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.

Yep, I misread this the first time.

I still think I see an issue though. Say you touch one finger to the
screen, so a BTN_TOUCH down and ABS_{X,Y} is emitted for the finger. You
intend to use this touch to drag something on the screen. Now, BTN_TOUCH
down is emitted on every frame of data coming from the device. This
seems weird, but we'll leave that aside for now. Next, you touch a
second finger to the screen. I'll assume it's index in the array of
touches is higher, so the first finger is still driving the ABS_{X,Y}.

Now, you lift up the first finger. BTN_TOUCH never goes up because
single-touch emulation shifts immediately to the second finger. All of a
sudden your dragged item is dragged across the screen to somewhere else.
That seems like bad behavior to me.

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

The original code switches the BTN_TOUCH and ABS_{X,Y} to the oldest
touch when the current oldest touch is removed. After your patch, this
jumping around will still occur. That seems wrong to me, but this is a
murky area. There isn't a generally accepted mode of handling
single-touch legacy support in multitouch drivers (not that I'm aware of
at least, you may know more than I :). Thus, I'm wondering how well it
would work if we only sent these single-touch events for the first
touch, and no events for any further touches until they are all removed.
This would allow single-touch drag when multiple fingers are down to
behave right, in my opinion, such that the end of the finger doing the
dragging causes dragging to cease.

Of course, this is all an issue of MT -> ST translation, and hopefully
all apps will become MT aware and not depend on ABS_{X,Y} when ABS_MT_*
are available :).

-- Chase





More information about the kernel-team mailing list