multi-touch-dev team mailing list archive

[Henrik Rydberg <rydberg@xxxxxxxxxxx>]

> Since you brought it up, I've been meaning to get your perspective on
> the current status.
> 
> Where do you think we stand today, and where do you think we will be in
> the next 2-3 months?

Ah, big question. Ok, I will try to break it down a bit. I might be summarizing
this a bit too lengthy, and from a personal perspective, but unlike most of you,
I have not been paid to do any of this, so maybe I may indulge just a little
bit. :-)

A. Understanding the applications

It all started in this end, but for me, it certainly got bigger than I expected.
We, the Linux community, all wanted to do stuff that could not be done with the
interfaces at the time. Seeing the humongous gap between poorly working
two-finger scroll on the one hand, and Jeff Han's demos on the other, was simply
unbearable. Something needed to be done, but I believe very few people really
knew what that something was. Today, the picture is clearer, and it has
expanded, beyond the world of controlling the desktop. The Gesture concept is
hot and still developing, no doubt, but much of what is out there is quite
gimmicky, to be honest. Quite like the voice recognition in mobile phones some
fifteen years back. Looking forward, at your paintings, for instance, I imagine
a drawing application has been a motivator for some people. And Whiteboards,
multi-user surfaces, practicing Arts, games, form factor, what not. I personally
did not see very far along this path a few years back. Maybe I am not alone. The
new gadgets on the market more or less guarantees we will see even more within
the next six months. Trying to dream up a progress bar, I would say we are 35%
done today, and will be 45% done six month from now. Still early development, in
other words.

B) Understanding the technique

Technically, we have gone from a kernel with no MT kernel support, and a few
scattered devices with two-finger scroll, to a mainstream kernel including the
MT protocol, and a whole bunch of devices supporting it, thanks mainly to ENAC.
New devices are being added continously, so the future looks bright. If we can
just get those new synaptics pads to work, I believe we will have complete MT
support for all major devices within a year.

C) Understanding the problem

I got into this whole business by coincidence. A friend convinced me to buy one
of those MacBook Airs while in the US, which I did. However, Darwin did not turn
out to be quite what I expected, so I soon wanted to run Linux on it. Of course
there was no driver for that glorious trackpad, so I wrote one. With the help of
an early reverse-engineer, it turned out pretty well. I was happy, and not much
happened for a year or so. Enters the next generation Macbooks, with integrated
button and trackpad. As soon as we got that working, I realized that
theoretically, there is no chance the OSX behavior can be mimicked without
knowledge of the individual fingers. Driven by this purely hobbyist view, I
wrote a protocol for multiple contacts to be padded on top of the existing
kernel protocol. It got accepted as the MT event protocol. I wrote an X driver
to go with it, utilizing some knowledge from my profession. The Multitouch X
Driver is, to my knowledge, still the only application with complete contact
tracking.


> How stable do you think the kernel<->user space boundary is now?
> As far as I can tell it looks like any near term kernel side changes
> shouldn't change things too far down stream, and should be adopted
> pretty quickly on the X side, does that sound about right to you?

The major technical hurdle has been solved since long, but exposed, the problem
has also created some confusion. The way I see it, interface-wise, we are
looking at a straight-forward path, which will quickly lead to full enablement
of multitouch, but in a slightly awkward way. Within a year or so, when the dust
has settled, some details will be different, mainly between the kernel and X. I
imagine that userspace can live on largely oblivient to this fact.

The MT event protocol first appeared upstream in 2.6.30, and it has been
identical since then, with the exception of the addition of ABS_MT_PRESSURE.
There are no plans to make any changes to it, but to further clarify remaining
ambiguities. That is what I would call a solid foundation, and as such, it is
expected that driver adoption will only become easier and easier.

The MT event slot extension, currently on review, deals with the tracking
capabilities of the kernel. Apart from simplifying userspace applications, this
protocol is largely driven by performance. There is nothing in the proposed
protocol that cannot be achieved with sufficient code in userspace, albeit with
degraded performance. Call this my pet project if you will, it is of much less
significance than the MT protocol as a whole. Therefore, I am confident that the
application-to-X protocol can be firmly set at this stage.


> Also, what's your opinion of your X multitouch driver vs. evdev?  Do you
> think we should try to merge multitouch into evdev?

Yes, that is the clear path forward, which achieves the goals above. But I would
be extremely happy if someone else would like to carry the ball. I have put up
the plans I have with the driver until 15JUN2010, after which I hope to be able
to do much less with it. To me, the driver has served its purpose of providing a
reference implementation for the MT protocol, and giving support to those
integrated trackpads, and I frankly have no further interest in it.

That said, I think the protocol code is far beyond the alpha stage - it has been
rock solid since 2009, and perfectly functional some three months or so. Well
worth integrating. Questions about license could perhaps be postponed.

Ok, some more words than you asked for, but there it is.

Thanks,
Henrik