Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1584664 > unrolled thread

[GIT PULL] HID for 4.11

Back to article view | Back to linux.kernel

Contents

  [GIT PULL] HID for 4.11 Jiri Kosina <jikos@kernel.org> - 2017-02-20 16:30 +0100
    Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 03:50 +0100
      Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 04:10 +0100
        Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 04:20 +0100
        Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 05:20 +0100
          Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 05:40 +0100
            Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-01 02:00 +0100
              Re: [GIT PULL] HID for 4.11 Andrew Duggan <aduggan@synaptics.com> - 2017-03-01 03:40 +0100
                Re: [GIT PULL] HID for 4.11 Peter Hutterer <peter.hutterer@who-t.net> - 2017-03-01 06:00 +0100
                  Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-01 06:10 +0100
                    Re: [GIT PULL] HID for 4.11 Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2017-03-01 10:10 +0100
                      Re: [GIT PULL] HID for 4.11 Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-03-01 19:10 +0100
                    Re: [GIT PULL] HID for 4.11 Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2017-03-01 10:30 +0100
                      Re: [GIT PULL] HID for 4.11 Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-03-01 19:00 +0100
                        Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-01 21:10 +0100
                      Re: [GIT PULL] HID for 4.11 Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-01 20:00 +0100
          [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not  built (was Re: [GIT PULL] HID for 4.11) Jiri Kosina <jikos@kernel.org> - 2017-02-21 15:20 +0100
            Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Jiri Kosina <jikos@kernel.org> - 2017-02-21 16:50 +0100
              Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 17:00 +0100
                Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2017-02-21 18:50 +0100
                  Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Jiri Kosina <jikos@kernel.org> - 2017-02-21 22:10 +0100
            Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 16:50 +0100
            Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2017-02-21 18:40 +0100
            Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is  not built (was Re: [GIT PULL] HID for 4.11) Andrew Duggan <aduggan@synaptics.com> - 2017-02-21 22:20 +0100
      ath10k regression on XPS13 Kalle Valo <kvalo@codeaurora.org> - 2017-02-21 10:40 +0100
        Re: ath10k regression on XPS13 David Miller <davem@davemloft.net> - 2017-02-21 19:20 +0100
          Re: ath10k regression on XPS13 Kalle Valo <kvalo@codeaurora.org> - 2017-02-21 19:40 +0100
            Re: ath10k regression on XPS13 David Miller <davem@davemloft.net> - 2017-02-21 20:00 +0100
              Re: ath10k regression on XPS13 Kalle Valo <kvalo@codeaurora.org> - 2017-02-21 20:50 +0100
                Re: ath10k regression on XPS13 David Miller <davem@davemloft.net> - 2017-02-21 22:10 +0100
          Re: ath10k regression on XPS13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-21 20:00 +0100
            Re: ath10k regression on XPS13 David Miller <davem@davemloft.net> - 2017-02-21 22:10 +0100

Page 1 of 2  [1] 2  Next page →

#1584664 — [GIT PULL] HID for 4.11

Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus

to receive HID subsystem updates for 4.11:

=====
- a lot of Wacom driver updates; most notably second generation Intuos Pro
  is now supported, code from Aaron Armstrong Skomra and Jason Gerecke
- Surface 3 and 4 Type Cover Pro support from Daniel Keller, Dennis Chen 
  and Yuta Kobayashi
- hid-rmi is now generic transport driver, used by synaptics-rmi4; Support 
  the Lenovo Thinkpad X1 Tablet dock follows on top, from Andrew Duggan
- a few misc bugfixes and improvements here and there
=====

Thanks.

----------------------------------------------------------------
Aaron Armstrong Skomra (5):
      HID: wacom: generic: remove input_event_flag
      HID: wacom: generic: add support for touchring
      HID: wacom: generic: add vendor defined touch
      HID: wacom: generic: support generic touch switch
      HID: wacom: generic: support LEDs

Andrew Duggan (3):
      HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
      HID: rmi: Handle all Synaptics touchpads using hid-rmi
      HID: rmi: Support the Lenovo Thinkpad X1 Tablet dock using hid-rmi

Benjamin Tissoires (4):
      HID: wacom: release the resources before leaving despite devm
      HID: wacom: remove warning while disconnecting devices
      HID: wacom: do not attempt to switch mode while in probe
      HID: multitouch: fix LG Melfas touchscreen

Bhumika Goyal (1):
      HID: intel-ish-hid: constify device_type structure

Corentin Labbe (1):
      HID: intel-ish-hid: Remove unneeded linux/miscdevice.h include

Daniel Keller (1):
      HID: multitouch: enable Surface 4 Type Cover Pro (non-JP) to report multitouch data

Dennis Chen (2):
      HID: multitouch: enable Surface 3 Type Cover Pro to report multitouch data
      HID: whitespace cleanup

Even Xu (1):
      HID: intel-ish-hid: ipc: check FW status to distinguish ISH resume paths

Grant Grundler (1):
      HID: remove use of DRIVER_LICENSE

Jason Gerecke (4):
      HID: wacom: Enable HID_GENERIC codepath for Bluetooth devices
      HID: wacom: Move WAC_CMD_* into wacom_wac.h
      HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface
      HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range

Marcel Hasler (2):
      HID: add device ID for updated Mayflash/Dragonrise GameCube adapter
      HID: hid-mf: add force feedback support for Mayflash DolphinBar and GameCube

Nicolas Iooss (2):
      HID: intel-ish-hid: add printf attribute to print_log()
      HID: intel-ish-hid: format 32-bit integers with %X

Ping Cheng (1):
      HID: wacom: don't apply generic settings to old devices

Yuta Kobayashi (1):
      HID: multitouch: enable the Surface 4 Type Cover Pro (JP) to report multitouch data

 drivers/hid/Kconfig                         |   5 +
 drivers/hid/hid-core.c                      |  27 +-
 drivers/hid/hid-ids.h                       |  11 +-
 drivers/hid/hid-mf.c                        |  19 +-
 drivers/hid/hid-microsoft.c                 |  12 -
 drivers/hid/hid-multitouch.c                |  44 ++
 drivers/hid/hid-rmi.c                       | 975 ++++------------------------
 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h |   8 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h      |  12 +
 drivers/hid/intel-ish-hid/ipc/pci-ish.c     |  38 +-
 drivers/hid/intel-ish-hid/ishtp-hid.c       |   2 +-
 drivers/hid/intel-ish-hid/ishtp/bus.c       |   2 +-
 drivers/hid/intel-ish-hid/ishtp/hbm.c       |   1 -
 drivers/hid/intel-ish-hid/ishtp/init.c      |   1 -
 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h |   3 +-
 drivers/hid/usbhid/hid-core.c               |   3 +-
 drivers/hid/usbhid/hid-quirks.c             |  12 +-
 drivers/hid/usbhid/usbkbd.c                 |   3 +-
 drivers/hid/usbhid/usbmouse.c               |   3 +-
 drivers/hid/wacom.h                         |   5 +-
 drivers/hid/wacom_sys.c                     | 147 ++++-
 drivers/hid/wacom_wac.c                     | 289 ++++++++-
 drivers/hid/wacom_wac.h                     |  37 +-
 23 files changed, 698 insertions(+), 961 deletions(-)

-- 
Jiri Kosina
SUSE Labs

[toc] | [next] | [standalone]

#1585002

On Mon, Feb 20, 2017 at 7:20 AM, Jiri Kosina <jikos@kernel.org> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>
> to receive HID subsystem updates for 4.11:

The touchpad on my XPS13 no longer works. It might not be this pull
request, and I'll bisect the exact cause, but this pull seems the most
likely culprit.

Just an early heads-up,

                Linus

[toc] | [prev] | [next] | [standalone]

#1585007

On Mon, Feb 20, 2017 at 6:48 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Feb 20, 2017 at 7:20 AM, Jiri Kosina <jikos@kernel.org> wrote:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>>
>> to receive HID subsystem updates for 4.11:
>
> The touchpad on my XPS13 no longer works. It might not be this pull
> request, and I'll bisect the exact cause, but this pull seems the most
> likely culprit.

It's bisecting right into the HID pull request, so you can consider
that confirmed.  There's something badly broken in this pull.

I'll have a more specific commit (or range) soon.

               Linus

[toc] | [prev] | [next] | [standalone]

#1585010

On Mon, Feb 20, 2017 at 7:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> It's bisecting right into the HID pull request, so you can consider
> that confirmed.  There's something badly broken in this pull.

Side note, the touchpad messages from a working kernel are as

  psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2a1,
caps: 0xf00223/0x840300/0x12e800/0x0, board id: 3038, fw id: 2011643
  input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio1/input/input6
  input: DLL0704:01 06CB:76AE Touchpad as
/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DLL0704:01/0018:06CB:76AE.0002/input/input19

whereas a bad kernel seems to miss that third line.

               Linus

[toc] | [prev] | [next] | [standalone]

#1585023

On Mon, Feb 20, 2017 at 7:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'll have a more specific commit (or range) soon.

Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
touchpads using hid-rmi").

And the reason seems to be stupid: I don't have RMI enabled at all,
because that didn't use to work or make a difference.

Maybe that "let's use RMI" code should depend on RMI actually being
enabled? Because as-is, that code now breaks existing configurations.

               Linus

[toc] | [prev] | [next] | [standalone]

#1585031

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 20, 2017 at 8:13 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
> touchpads using hid-rmi").
>
> And the reason seems to be stupid: I don't have RMI enabled at all,
> because that didn't use to work or make a difference.
>
> Maybe that "let's use RMI" code should depend on RMI actually being
> enabled? Because as-is, that code now breaks existing configurations.

Yeah, so enabling HID_RMI makes my touchpad work again.

But this really was a stupid waste of time, and I really think that
the synaptics code should leave the HID group as generic or
multitouch-win8 _unless_ the HID RMI support is actually enabled.

IOW, something like the attached (untested) patch, perhaps?

              Linus

[toc] | [prev] | [next] | [standalone]

#1589918

On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds
<torvalds@linux-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.

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.

                 Linus

[toc] | [prev] | [next] | [standalone]

#1589953

On 02/28/2017 04:56 PM, Linus Torvalds wrote:
> On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds
> <torvalds@linux-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.
>
> 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.
>
>                   Linus

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".

Andrew

[toc] | [prev] | [next] | [standalone]

#1589978

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@linux-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

[toc] | [prev] | [next] | [standalone]

#1589980

On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
>
> 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?

bug reported (it's bug 100014).

This is libinput-1.5.4 on Fedora 24. I attached both the
libinput-debug-events output as well as evemu-report output, which
hopefully fills in all the details.

                 Linus

[toc] | [prev] | [next] | [standalone]

#1590108

[I forgot to add Dmitry in the loop, sorry for the noise.]

On Mar 01 2017 or thereabouts, Benjamin Tissoires wrote:
> On Feb 28 2017 or thereabouts, Linus Torvalds wrote:
> > On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> > <peter.hutterer@who-t.net> wrote:
> > >
> > > 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?
> > 
> > bug reported (it's bug 100014).
> > 
> 
> Thanks for the report.
> 
> As Peter mentioned in the bug, there is a missing property on the kernel
> node (INPUT_PROP_BUTTONPAD). 
> 
> The thing is this property is solely driven in the current driver by the
> provided platform_data, so there is no way we ever set it through
> hid-rmi. I wonder how we missed that.
> 
> Anyway, the good news is that the evemu record shows only one exportted
> button, so we can infer the property quite easily in the module. Would
> something like that work for you?
> 
> From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Wed, 1 Mar 2017 09:57:00 +0100
> Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the
>  button count
> 
> INPUT_PROP_BUTTONPAD is currently only set through the platform data.
> The RMI4 header doc says that this property is there to force the
> buttonpad property, so we also need to detect it by looking at
> the exported buttons count.
> 
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>  drivers/input/rmi4/rmi_f30.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> index 3422464..1986786 100644
> --- a/drivers/input/rmi4/rmi_f30.c
> +++ b/drivers/input/rmi4/rmi_f30.c
> @@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
>  
>  	/*
>  	 * Buttonpad could be also inferred from f30->has_mech_mouse_btns,
> -	 * but I am not sure, so use only the pdata info.
> +	 * but I am not sure, so use only the pdata info and the number of
> +	 * mapped buttons.
>  	 */
> -	if (pdata->f30_data.buttonpad)
> +	if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
>  		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
>  
>  	return 0;
> -- 
> 2.9.3
> 
> Dmitry, Andrew, would this work for you too?
> 
> Cheers,
> Benjamin

[toc] | [prev] | [next] | [standalone]

#1590544

Hi Benjamin,

On Wed, Mar 01, 2017 at 10:06:35AM +0100, Benjamin Tissoires wrote:
> [I forgot to add Dmitry in the loop, sorry for the noise.]
> 
> On Mar 01 2017 or thereabouts, Benjamin Tissoires wrote:
> > On Feb 28 2017 or thereabouts, Linus Torvalds wrote:
> > > On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> > > <peter.hutterer@who-t.net> wrote:
> > > >
> > > > 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?
> > > 
> > > bug reported (it's bug 100014).
> > > 
> > 
> > Thanks for the report.
> > 
> > As Peter mentioned in the bug, there is a missing property on the kernel
> > node (INPUT_PROP_BUTTONPAD). 
> > 
> > The thing is this property is solely driven in the current driver by the
> > provided platform_data, so there is no way we ever set it through
> > hid-rmi. I wonder how we missed that.
> > 
> > Anyway, the good news is that the evemu record shows only one exportted
> > button, so we can infer the property quite easily in the module. Would
> > something like that work for you?
> > 
> > From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Date: Wed, 1 Mar 2017 09:57:00 +0100
> > Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the
> >  button count
> > 
> > INPUT_PROP_BUTTONPAD is currently only set through the platform data.
> > The RMI4 header doc says that this property is there to force the
> > buttonpad property, so we also need to detect it by looking at
> > the exported buttons count.
> > 
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> >  drivers/input/rmi4/rmi_f30.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> > index 3422464..1986786 100644
> > --- a/drivers/input/rmi4/rmi_f30.c
> > +++ b/drivers/input/rmi4/rmi_f30.c
> > @@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
> >  
> >  	/*
> >  	 * Buttonpad could be also inferred from f30->has_mech_mouse_btns,
> > -	 * but I am not sure, so use only the pdata info.
> > +	 * but I am not sure, so use only the pdata info and the number of
> > +	 * mapped buttons.
> >  	 */
> > -	if (pdata->f30_data.buttonpad)
> > +	if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
> >  		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);

Would prefer if we changed button_mapped to n_buttons_mapped counter and
used that, instead of doing calculations on event code.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1590130

On Feb 28 2017 or thereabouts, Linus Torvalds wrote:
> On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> >
> > 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?
> 
> bug reported (it's bug 100014).
> 

Thanks for the report.

As Peter mentioned in the bug, there is a missing property on the kernel
node (INPUT_PROP_BUTTONPAD). 

The thing is this property is solely driven in the current driver by the
provided platform_data, so there is no way we ever set it through
hid-rmi. I wonder how we missed that.

Anyway, the good news is that the evemu record shows only one exportted
button, so we can infer the property quite easily in the module. Would
something like that work for you?

From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Wed, 1 Mar 2017 09:57:00 +0100
Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the
 button count

INPUT_PROP_BUTTONPAD is currently only set through the platform data.
The RMI4 header doc says that this property is there to force the
buttonpad property, so we also need to detect it by looking at
the exported buttons count.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
 drivers/input/rmi4/rmi_f30.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
index 3422464..1986786 100644
--- a/drivers/input/rmi4/rmi_f30.c
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
 
 	/*
 	 * Buttonpad could be also inferred from f30->has_mech_mouse_btns,
-	 * but I am not sure, so use only the pdata info.
+	 * but I am not sure, so use only the pdata info and the number of
+	 * mapped buttons.
 	 */
-	if (pdata->f30_data.buttonpad)
+	if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
 		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
 
 	return 0;
-- 
2.9.3

Dmitry, Andrew, would this work for you too?

Cheers,
Benjamin

[toc] | [prev] | [next] | [standalone]

#1590543

On Wed, Mar 01, 2017 at 09:54:07AM -0800, Linus Torvalds wrote:
> On Wed, Mar 1, 2017 at 1:03 AM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> > As Peter mentioned in the bug, there is a missing property on the kernel
> > node (INPUT_PROP_BUTTONPAD).
> >
> > The thing is this property is solely driven in the current driver by the
> > provided platform_data, so there is no way we ever set it through
> > hid-rmi. I wonder how we missed that.
> >
> > Anyway, the good news is that the evemu record shows only one exportted
> > button, so we can infer the property quite easily in the module. Would
> > something like that work for you?
> >
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Date: Wed, 1 Mar 2017 09:57:00 +0100
> > Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the button count
> 
> Yes, this fixes the problem for me. My click-and-drag works again, so
> you can add a
> 
>   Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> I see that Dmitry doesn't love the patch, but I'm assuming I'll get
> that or something equivalent soon. In the meantime, I'll just keep it
> on my laptop as a workaround.

Given that it does work for you just apply it. The objections I raised
was more of a bikeshedding.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1590605

On Wed, Mar 1, 2017 at 9:58 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Given that it does work for you just apply it. The objections I raised
> was more of a bikeshedding.

Ok. Patch applied directly and in my tree now,

                  Linus

[toc] | [prev] | [next] | [standalone]

#1590569

On Wed, Mar 1, 2017 at 1:03 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> As Peter mentioned in the bug, there is a missing property on the kernel
> node (INPUT_PROP_BUTTONPAD).
>
> The thing is this property is solely driven in the current driver by the
> provided platform_data, so there is no way we ever set it through
> hid-rmi. I wonder how we missed that.
>
> Anyway, the good news is that the evemu record shows only one exportted
> button, so we can infer the property quite easily in the module. Would
> something like that work for you?
>
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Wed, 1 Mar 2017 09:57:00 +0100
> Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the button count

Yes, this fixes the problem for me. My click-and-drag works again, so
you can add a

  Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>

I see that Dmitry doesn't love the patch, but I'm assuming I'll get
that or something equivalent soon. In the meantime, I'll just keep it
on my laptop as a workaround.

Thanks,

                   Linus

[toc] | [prev] | [next] | [standalone]

#1585367 — [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

On Mon, 20 Feb 2017, Linus Torvalds wrote:

> > I'll have a more specific commit (or range) soon.
> 
> Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
> touchpads using hid-rmi").
> 
> And the reason seems to be stupid: I don't have RMI enabled at all,
> because that didn't use to work or make a difference.
> 
> Maybe that "let's use RMI" code should depend on RMI actually being
> enabled? Because as-is, that code now breaks existing configurations.

I agree; that's in line with what we usually try to stick to (force 
specific drivers if the device doesn't work with the generic at all and 
switch over to generic in compile-time for devices that have limited 
functionality with the generic driver).

Andrew, Benjamin, how about the patch below?




From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built

Commit 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
unconditionally switches over handling of all Synaptics touchpads to hid-rmi
(to make use of extended features of the HW); in case CONFIG_HID_RMI is
disabled though this renders the touchpad unusable, as the

	HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)

match doesn't exist and generic/multitouch doesn't bind to it either (due
to hid group mismatch).

Fix this by switching over to hid-rmi only if it has been actually built.

Fixes: 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/hid/hid-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 538ff697a4cf..e9e87d337446 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -827,7 +827,8 @@ static int hid_scan_report(struct hid_device *hid)
 				 * hid-rmi should take care of them,
 				 * not hid-generic
 				 */
-				hid->group = HID_GROUP_RMI;
+				if (IS_ENABLED(CONFIG_HID_RMI))
+					hid->group = HID_GROUP_RMI;
 		break;
 	}
 

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1585444 — Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

On Tue, 21 Feb 2017, Linus Torvalds wrote:

> > I agree; that's in line with what we usually try to stick to (force
> > specific drivers if the device doesn't work with the generic at all and
> > switch over to generic in compile-time for devices that have limited
> > functionality with the generic driver).
> 
> .. and maybe we should do this same thing for the WACOM case a couple
> of lines up from your patch?

Well, that's far more questionable. I am pretty sure Wacom devices are 
completely dysfunctional without a specific driver, as they have their own 
protocol.

Adding Ping and Jason to CC.

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1585469 — Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

On Tue, Feb 21, 2017 at 7:46 AM, Jiri Kosina <jikos@kernel.org> wrote:
> On Tue, 21 Feb 2017, Linus Torvalds wrote:
>>
>> .. and maybe we should do this same thing for the WACOM case a couple
>> of lines up from your patch?
>
> Well, that's far more questionable. I am pretty sure Wacom devices are
> completely dysfunctional without a specific driver, as they have their own
> protocol.

Ah, ok. Never mind then.

            Linus

[toc] | [prev] | [next] | [standalone]

#1585567 — Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

On Feb 21 2017 or thereabouts, Linus Torvalds wrote:
> On Tue, Feb 21, 2017 at 7:46 AM, Jiri Kosina <jikos@kernel.org> wrote:
> > On Tue, 21 Feb 2017, Linus Torvalds wrote:
> >>
> >> .. and maybe we should do this same thing for the WACOM case a couple
> >> of lines up from your patch?
> >
> > Well, that's far more questionable. I am pretty sure Wacom devices are
> > completely dysfunctional without a specific driver, as they have their own
> > protocol.
> 
> Ah, ok. Never mind then.
> 
>             Linus

Well, Wacom devices use to need a special driver, but the latest
generation should somewhat be able to work without a driver (IIRC).
The only thing I can think of is that Wacom devices require
HID_QUIRK_NO_INIT_REPORTS, so they might not work out of the box after
all.

Let's see what Ping and Jason think about the question.

Cheers,
Benjamin

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web