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
          [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]

#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]

#1585738 — 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, Benjamin Tissoires wrote:

> Well, Wacom devices use to need a special driver, but the latest 
> generation should somewhat be able to work without a driver (IIRC). 

I vaguely recall this wasn't the case at all for the older generations 
I've had my hands on, and it wasn't just the matter of 
HID_QUIRK_NO_INIT_REPORTS quirk.

But anyway ... that wasn't reported as a regression for quite some time, 
so let's defer to what Ping and Jason have to say regarding 
protocol/driver compatibility.

I'll be pushing the RMI fix to Linus soon.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

#1585446 — 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 6:17 AM, Jiri Kosina <jikos@kernel.org> 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?

              Linus

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

#1585559 — 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, Jiri Kosina wrote:
> 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?
> 

Hi,

Sorry, I am on PTO for the rest of the week with limited internet
access.

Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

Sorry for the waste of time :(

Cheers,
Benjamin

> 
> 
> 
> 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]

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

On 02/21/2017 06:17 AM, Jiri Kosina wrote:
> 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?
>

I tested this patch and hid-core now correctly binds hid-mulitouch to 
the touchpad if CONFIG_HID_RMI is disabled. Sorry, about the oversight.

Tested-by: Andrew Duggan <aduggan@synaptics.com>

Thanks,
Andrew

>
>
> 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;
>   	}
>   
>

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

#1585163 — ath10k regression on XPS13

(Changing subject, adding Dave and relevant lists)

Linus Torvalds <torvalds@linux-foundation.org> writes:

> 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,

While talking about XPS13 also a heads-up from me as we have a nasty
regression in ath10k on XPS13 with QCA6174 (though not sure if you have
QCA6174, recent models seem to have that) which completely breaks driver
initialisation an error:

"ath10k_pci 0000:3a:00.0: failed to fetch board data for
bus=pci,vendor=168c,device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520
from ath10k/QCA6174/hw3.0/board-2.bin"

https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9

This is caused by this commit which I believe Dave will be sending to
you soon:

f2593cb1b291 ath10k: Search SMBIOS for OEM board file extension

As a workaround I recommend updating ath10k/QCA6174/hw3.0/board-2.bin
from this link _before_ updating the kernel:

https://github.com/kvalo/ath10k-firmware/blob/8d15818b0f9c7b09f743538ac2d3e1409779f52a/QCA6174/hw3.0/board-2.bin

We are working on a fix so that ath10k continues to work with older
board-2.bin, but that might take a day or two still.

-- 
Kalle Valo

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

#1585591 — Re: ath10k regression on XPS13

From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 11:32:49 +0200

> We are working on a fix so that ath10k continues to work with older
> board-2.bin, but that might take a day or two still.

Kalle I really wanted to send my net-next pull request to Linus later
today.  But I guess I have to wait for this ath10k first.

Please get this to me as soon as possible, thanks.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web