Message-ID: <54C00046.1000305@bitmath.org>
Date:	Wed, 21 Jan 2015 20:38:46 +0100
From:	Henrik Rydberg <rydberg@...math.org>
To:	Benjamin Tissoires <benjamin.tissoires@...il.com>
CC:	Peter Hutterer <peter.hutterer@...-t.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joe Perches <joe@...ches.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	linux-input <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] MAINTAINERS: Update rydberg's addresses

Hi Benjamin,

> - there is a fragmentation problem: we would have to fix the bug in
> xorg-synaptics (which is slowly waiting for its death), libinput,
> ChromeOS, Qt Embedded, Kivy (I think), etc...

Indeed, this is the problem I wanted to highlight. As the fragmentation problem
grows (graphics, input, compositors, toolkits), the need for a common
denominator grows as well. However, I do not think the kernel should be the
single common denominator for all the world's problems. Rather, the purpose of
the kernel is to convey hardware information and control as accurately,
effectively and generically as possible.

> - it means that the mt protocol B can not be relied upon, because even
> if we state that each touch has its own slot, then it is false in this
> case.

The case we are talking about is due to information missing in the hardware. At
low enough sampling frequencies, there is no way to distinguish between a moving
finger and a lift-and-press action. We could flag this hardware deficiency
somehow, but making shit up in order to maintain the statue that we do have
enough information is just asking for trouble.

I agree that this point is valid: we cannot always trust the interpretation of
touchpoints for certain hardware. However, there is nothing we can do about
that, except flag for it.

> Also, if you compare the libinput implementation of the handling of
> the cursors jumps and the kernel implementation I proposed, there is a
> big difference in term of simplicity.

No, this is wrong.

> In the kernel, while we are assigning the tracking IDs, we detect that
> there is a jump, and we "just" have to generate a new slot and close
> the first (done by 1 assignment of -1 to the current tracking ID).

The kernel case would have to be accompanied by parameters, under the control of
some user process, where adjustments are made to accomodate different usecases
such as painting, gaming, air guitar playing, flick gestures, multi-user
tablets, etc, etc. That is complex and unwanted.

> In Libinput, well, you receive a slot, there is a jump, you detect it,
> then you have to create a new fake kernel event to stop the current
> slot, create a new one, and you then have to rewind the current state
> of the buttons, the hysteresis, add special case handling and
> hopefully, you did not introduced a bug in all the complex code. So
> you need to write unit tests (not an argument, I concede, but this is
> extra work), and in the future, someone will not understand what this
> is all about because the kernel should guarantee that the slots are
> sane.

You do not need to do any of this (except the test cases, which would be needed
anyway given the context-dependent interpretation of scarse data) if you
intercept the touch points as they come in from the kernel, before the contact
dynamics is fully trusted. Last time I checked that was mtdev or the touch frame
layer or Xinput.

> If I were grumpy (and I can be, ask Peter), I would say that sure, we
> can add such a case in the mtdev library, but the point of having the
> in-kernel tracking system was to slowly get away from the head over
> added by mtdev.

No, this was not the reason. The tree main reasons were actually latency and
power and code reduction. The mtdev layer still provides the functional bridge
needed. However, the latency and number of cpu cycles involved in transferring
the data to userland before throwing most of it away were much reduced by adding
the in-kernel tracking. Collecting the diversity of solutions for older hardware
was a maintainability bonus.

Regarding the practical problem at hand, that double taps sometimes get
misinterpreted as a "flash move", perhaps the problem really is in how we define
a double tap.

When I was writing a certain gesture engine, I realized I got issues with
multi-finger taps. In my case the problem was not due to misinterpreted finger
data, but simply because pressing four fingers simultaneously is not easy, and
really not needed in order to define the gesture per se. So in order to
correctly interpret gestures, I had to involve time in various ways; checking
for overlaps between fingers over a short time span, looking for the maximum
number of fingers within a certain timespan, etc. Not to mention palm detection;
in this context, the individual touch points really lose some meaning.

The double tap is no different in this regard. Nor is a flash move. But we would
not want a real flash move to be interpreted as double tap, would we?

My point is that the gesture context is where the ultimate decision can best be
made - where there is enough information to best approximate what the imperfect
hardware is trying to tell us. If the time between touch down and a fast
movement to a nearby point is consistent with a tap, then maybe it is a tap.

End rant. I hope it helps one way or the other.

Thanks,
Henrik

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists