[PATCH weston v2 2/2] evdev: Improve touchpad support and add motion filters

[Kristian Høgsberg]

On Thu, May 17, 2012 at 11:20 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Thu, May 17, 2012 at 5:13 PM, Chase Douglas
> <chase.douglas at canonical.com> wrote:
>> On 05/17/2012 07:53 AM, Daniel Stone wrote:
>>> Hi,
>>>
>>> On 17 May 2012 15:20, Chase Douglas <chase.douglas at canonical.com> wrote:
>>>> I know I don't have much (any?) clout in wayland, but I feel strongly
>>>> enough about moving this logic to a separate library that I'm going to
>>>> NACK this. We need to resolve this problem from the beginning, or else
>>>> we will end up in some of the same messes we have in the X server.
>>>
>>> No, it's a fair shout.  Ultimately we definitely want all of this to
>>> be in a separate library.  I worry that introducing a library now when
>>> we don't know what either the consumers really want or the producer
>>> can give us would be a massive pain though, especially for things like
>>> bisect.  I'd be much happier just dropping it in the source tree now,
>>> being careful to keep it as independent as possible, and then
>>> gradually evolve it to be a separate library that things like X can
>>> use.
>>
>> I would be very sad if we couldn't figure out a pointer acceleration
>> library interface at this point.
>>
>> If you're worried about API/ABI issues, most of the wayland protocol is
>> still in flux, as far as I understand. Even still, I don't think it will
>> be too hard to get this right the first time.
>>
>>> This also gets really hairy when touch comes into the mix, so for
>>> instance we'd need to deal with the interactions between touch events
>>> and tap-to-click etc ...
>>
>> tap-to-click is a separate issue. It's a trackpad "gesture" feature.
>> That should be handled by a separate, client-side library, imo. Right
>> now I'm only advocating for a simple library to handle pointer acceleration.
>>
>
> Maybe a simple middle way would be to put it into weston while
> enabling it to be compiled as a separate library. It's already fairly
> decoupled. It'll have a highly experimental weston specific API that
> will brake a lot but it will be possible to experiment with.

I'll merge the patch now.  It's a big step forward from what we have
and I don't want to drop this on the floor while we think about all
the different ways we could share code.  How are we going to share the
code?  I don't have an answer, but I think it's important to keep in
mind that code sharing itself isn't the end goal, consistent behavior
is.

As for sharing pointer acceleration, I'm not convinced we need that
under Wayland.  The example with moving a window with three-finger
motion will be handled all inside the compositor.  In cases where the
client needs to get involved (two finger scrolling/panning,  for
example) you can send out accelerated, relative events.  Those events
can thee be fed into a physics model in the client to drive a kinetic
scroll implementation.

Kristian