[PATCH 0/2] [Maverick] UBUNTU: MT event slots (rev5)

[Tim Gardner]

On 06/10/2010 06:36 AM, Chase Douglas wrote:
> On Thu, 2010-06-10 at 11:17 +0200, Henrik Rydberg wrote:
>> These patches add MT event slots and documentation to the input
>> core. The patches have been discussed at LKML over the past couple of
>> months, and are now being queued for 2.6.36. Since the protocol
>> enhancements do not change any existing APIs, but are of great
>> interest to developers, it would make sense to carry them in Maverick.
>>
>> Best regards,
>> Henrik Rydberg
>>
>> Henrik Rydberg (2):
>>    UBUNTU: Introduce MT event slots (rev 5)
>>    UBUNTU: Document the MT event slot protocol (rev5)
>>
>>   Documentation/input/multi-touch-protocol.txt |  217 ++++++++++++++++++--------
>>   drivers/input/input.c                        |  105 ++++++++++---
>>   include/linux/input.h                        |   44 +++++
>>   3 files changed, 271 insertions(+), 95 deletions(-)
>
> FYI for those who aren't familiar with Henrik, he's been working on some
> great stuff upstream for multitouch input. We will be working with him
> to improve our multitouch stack in Maverick.
>
> These patches provide a second protocol over evdev for multitouch
> devices. This new protocol essentially trades stateless operation on
> both sides of the evdev interface for a better stateful approach. For
> example, if you have 10 fingers touching a screen and you move one of
> them, today you have to send all the attributes of every touch again.
> Using the slots protocol, only attributes about the finger that moved
> would be sent.
>
> The slots protocol these patches introduce is not used unless drivers
> explicitly are changed to use it. Merging it into our kernel by itself
> should not cause any regressions. However, later in this cycle or
> perhaps even after release we may change drivers to use the new
> interface.
>
> These patches has been confirmed as likely to go in for 2.6.36.
>
> Acked-by: Chase Douglas<chase.douglas at canonical.com>
>
>

I'm good with this since we'll be able to tell right away if it wreaks 
havoc with existing pointer devices. What is the maintainer's repo from 
which we can pull and monitor directly?

Acked-by: Tim Gardner <tim.gardner at canonical.com>

-- 
Tim Gardner tim.gardner at canonical.com