Message-ID: <20170301032409.GA8206@jelly>
Date:   Wed, 1 Mar 2017 13:24:09 +1000
From:   Peter Hutterer <peter.hutterer@...-t.net>
To:     Andrew Duggan <aduggan@...aptics.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] HID for 4.11

On Tue, Feb 28, 2017 at 06:31:10PM -0800, Andrew Duggan wrote:
> On 02/28/2017 04:56 PM, Linus Torvalds wrote:
> > On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > > Yeah, so enabling HID_RMI makes my touchpad work again.
> > .. so I just noticed something: it works subtly differently.
> > 
> > When I drag something around, I mostly just double-tap and move, and
> > that still works fine.
> > 
> > But sometimes I click (and hold) with one finger, and then move around
> > with another. That's occasionally very useful when you move longer
> > distances, because you can just raise and move that other finger
> > multiple times.
> > 
> > That doesn't seem to work with the RMI driver. I seem to get scroll
> > events instead.

fwiw, scroll events are implemented in userspace, so this would be a bug in
libinput or the synaptics driver if you're using that one.

> > I'm sure there's some setting for mouse gestures. But it's a bit odd
> > when they change just because the driver changes. And gnome certainly
> > doesn't believe in settings, because these things are obviously
> > "intuitive".
> > 
> > Ideas? Or am I just dreaming, and the click-and-move never worked?
> > Because I'm pretty sure it did, but sometimes the meds kick in.

it definitely should work and it shouldn't be affected much by these kernel
driver changes. more specifically, scrolling should never happen while
BTN_LEFT is down.

> The RMI driver does report input events a little differently then the
> hid-multitouch driver. It may report different min / max values for axis,
> different resolution values, and it also reports ABS_MT_PRESSURE. Also,
> depending on how the touchpad's firmware was configured it may also report
> additional fingers. It probably also reports a few other properties which
> hid-multitouch does not. Since it is the input handling libraries in
> userspace which interpret the input events and decide what is a drag and
> what is a scroll I suspect the issue may be in userspace. The additional
> properties reported by the input device may be causing the input handler to
> potentially misidentify the device and treat it differently. That's at least
> where I would start looking.
> 
> For what it's worth, I'm using libinput and the RMI driver on my touchpad.
> Click and drag works well with libinput's "ClickMethod" parameter set to
> "clickfinger".

fwiw, should work with software buttons as well. but as I said above, scroll
events should never trigger as long as a button is down, at least not with
only two fingers on the touchpad.

I suspect you're just triggering a bug that wasn't triggered by the ps/2
emulation. you can run linput-debug-events --verbose and have a look at the
various state debugging information, that may hint at what's going on (e.g.
a finger mistaken as palm touch, or something). Or record one such
interaction with evemu-record and send it to me (preferrably here [1], if
you're using libinput). Also, what version of libinput/synaptics are you on?

Cheers,
   Peter

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=wayland&component=libinput

Powered by blists - more mailing lists