Commit Graph

130 Commits

Author SHA1 Message Date
Hamza Mahfooz
b23cdfbddb HID: logitech-hidpp: battery: provide CAPACITY property for newer devices
For devices that only support the BATTERY_VOLTAGE (0x1001) feature, UPower
requires the additional information provided by this patch, to set them up.

Signed-off-by: Hamza Mahfooz <someguy@effective-light.com>
Reviewed-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-08-20 14:32:39 +02:00
Christophe JAILLET
46dcd1cc2b HID: logitech-hidpp: Use 'atomic_inc_return' instead of hand-writing it
This function logs a warning if the workqueue gets too big.
In order to save a few cycles, use 'atomic_inc_return()' instead of an
'atomic_inc()/atomic_read()' sequence.

This axes a line of code and saves a 'atomic_read()' call.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-08-20 14:20:34 +02:00
Jiri Kosina
8f4ef88eba Merge branch 'for-5.14/logitech' into for-linus
- support for LCD menu keys + LCD brightness control on the Logitech Z-10
  speakers (with LCD) which use the same protocol as the G15 keyboards
  from Hans de Goede
2021-06-30 09:12:44 +02:00
Tom Rix
81c8bf9170 HID: logitech-hidpp: initialize level variable
Static analysis reports this representative problem

hid-logitech-hidpp.c:1356:23: warning: Assigned value is
  garbage or undefined
        hidpp->battery.level = level;
                             ^ ~~~~~

In some cases, 'level' is never set in hidpp20_battery_map_status_voltage()
Since level is not available on all hw, initialize level to unknown.

Fixes: be281368f2 ("hid-logitech-hidpp: read battery voltage from newer devices")
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-05-27 15:40:34 +02:00
Hans de Goede
7383354ad5 HID: logitech-dj/hidpp: Add info/warn/err messages about 27 MHz keyboard encryption
By default 27 MHz Logitech keyboards send the keypresses to the receiver
in plain text. Logitech's Windows "Keyboard and Mouse settings" tool allows
configuring encryption for the keyboard wireless link.

Now there also is a Linux tool for setting this up:
https://gitlab.freedesktop.org/jwrdegoede/logitech-27mhz-keyboard-encryption-setup

Once a keyboard is paired in encrypted mode, it will no longer work with
any receiver other then the receiver it was paired with.
If a user accidentally tries to pair another keyboard with the receiver
with which a keyboard has been paired in encrypted mode, then the receiver
looses the encryption key and the originally paired keyboard will no longer
work with either that receiver, or another receiver until the keyboard's
encryption key is rewritten by another encrypted mode pairing using the
tool. Or until it is reset by following a special reset procedure.

This commit adds 3 new log messages related to 27 MHz keyboard link
encryption to the Logitech dj / hidpp drivers:

1. An info level message when keyboard encryption is being used
2. A warning message when keyboard encryption is not used
3. An error message when the encryption key has been lost and the
   keyboard will not work because of this

Messages 2. and 3. contain a link to the userspace tool to setup the
encryption. The linked page also contains instructions to clear the key
(without needing the tool) to help a user recover from the keyboard not
working in case 3.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-05-05 14:28:12 +02:00
Lee Jones
3f37fdcd31 HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote abuses
Fixes the following W=1 kernel build warning(s):

 drivers/hid/hid-logitech-hidpp.c:275: warning: Function parameter or member 'hidpp' not described in 'hidpp_send_message_sync'
 drivers/hid/hid-logitech-hidpp.c:275: warning: Function parameter or member 'message' not described in 'hidpp_send_message_sync'
 drivers/hid/hid-logitech-hidpp.c:275: warning: Function parameter or member 'response' not described in 'hidpp_send_message_sync'
 drivers/hid/hid-logitech-hidpp.c:275: warning: expecting prototype for and something else(). Prototype was for hidpp_send_message_sync() instead
 drivers/hid/hid-logitech-hidpp.c:427: warning: wrong kernel-doc identifier on line:
 drivers/hid/hid-logitech-hidpp.c:470: warning: Function parameter or member 'input_dev' not described in 'hidpp_scroll_counter_handle_scroll'
 drivers/hid/hid-logitech-hidpp.c:1894: warning: Function parameter or member 'hidpp' not described in 'hidpp_touchpad_fw_items_set'
 drivers/hid/hid-logitech-hidpp.c:1894: warning: Function parameter or member 'feature_index' not described in 'hidpp_touchpad_fw_items_set'
 drivers/hid/hid-logitech-hidpp.c:1894: warning: Function parameter or member 'items' not described in 'hidpp_touchpad_fw_items_set'
 drivers/hid/hid-logitech-hidpp.c:1894: warning: expecting prototype for send a set state command to the device by reading the current items(). Prototype was for hidpp_touchpad_fw_items_set() instead

Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Lopez Casado <nlopezcasad@logitech.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2021-04-07 18:46:20 +02:00
Filipe Laíns
e037acf0b1 HID: logitech-hidpp: add support for Unified Battery (1004) feature
This new feature present in new devices replaces the old Battery Level Status
(0x1000) feature. It keeps essentially the same information for levels
(reporting critical, low, good and full) but makes these levels optional, the
device exports a capability setting which describes which levels it supports.
In addition to this, there is an optional state_of_charge paramenter that
exports the battery percentage.

This patch adds support for this new feature. There were some implementation
choices, as described below and in the code.

If the device supports the state_of_charge parameter, we will just export the
battery percentage and not the levels, which the device might still support.

Since this feature can co-exist with the Battery Voltage (0x1001) feature and
we currently only support one battery feature, I changed the battery feature
discovery to try to use 0x1000 and 0x1004 first and only then 0x1001, the
battery voltage feature.

In the future we could uncouple this and make the battery feature co-exists
with 0x1000 and 0x1004, allowing the device to export voltage information in
addition to the battery percentage or level.

I tested this patch with a MX Anywhere 3, which supports the new feature. Since
I don't have any device that doesn't support the state_of_charge parameter of
this feature, I forced the MX Anywhere 3 to use the level information, instead
of battery percentage, to test that part of the implementation.

I also tested with a MX Master 3, which supports the Battery Level Status
(0x1000) feature, and a G703 Hero, which supports the Battery Voltage (0x1001)
feature, to make sure nothing broke there.

[jkosina@suse.cz: fix comment]
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-01-18 11:01:03 +01:00
Nicholas Miell
7de843dbaa HID: logitech-hidpp: Add product ID for MX Ergo in Bluetooth mode
The Logitech MX Ergo trackball supports HID++ 4.5 over Bluetooth. Add its
product ID to the table so we can get battery monitoring support.
(The hid-logitech-hidpp driver already recognizes it when connected via
a Unifying Receiver.)

[jkosina@suse.cz: fix whitespace damage]
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-01-14 13:27:35 +01:00
Hans de Goede
ba876cdc6a HID: logitech-hidpp: Add hid_device_id for V470 bluetooth mouse
The Logitech V470 bluetooth mouse supports HID++-1.0 over bluetooth,
add its id to the hidpp driver so that it handles it.

This enables battery monitoring support.

Note this mouse does not support hi-resolution scroll-wheel events.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-11-25 13:59:01 +01:00
Hans de Goede
b4c00e7976 HID: logitech-dj: Fix Dinovo Mini when paired with a MX5x00 receiver
Some users are pairing the Dinovo keyboards with the MX5000 or MX5500
receivers, instead of with the Dinovo receivers. The receivers are
mostly the same (and the air protocol obviously is compatible) but
currently the Dinovo receivers are handled by hid-lg.c while the
MX5x00 receivers are handled by logitech-dj.c.

When using a Dinovo keyboard, with its builtin touchpad, through
logitech-dj.c then the touchpad stops working because when asking the
receiver for paired devices, we get only 1 paired device with
a device_type of REPORT_TYPE_KEYBOARD. And since we don't see a paired
mouse, we have nowhere to send mouse-events to, so we drop them.

Extend the existing fix for the Dinovo Edge for this to also cover the
Dinovo Mini keyboard and also add a mapping to logitech-hidpp for the
Media key on the Dinovo Mini, so that that keeps working too.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1811424
Fixes: f2113c3020 ("HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2020-11-19 16:27:51 +01:00
Hans de Goede
c27168a04a HID: logitech-hidpp: Add HIDPP_CONSUMER_VENDOR_KEYS quirk for the Dinovo Edge
Like the MX5000 and MX5500 quad/bluetooth keyboards the Dinovo Edge also
needs the HIDPP_CONSUMER_VENDOR_KEYS quirk for some special keys to work.
Specifically without this the "Phone" and the 'A' - 'D' Smart Keys do not
send any events.

In addition to fixing these keys not sending any events, adding the
Bluetooth match, so that hid-logitech-hidpp is used instead of the
generic HID driver, also adds battery monitoring support when the
keyboard is connected over Bluetooth.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2020-11-12 16:01:13 +01:00
Harry Cutts
b59f38dbfd HID: logitech-hidpp: Add PID for MX Anywhere 2
It seems that the PID 0x4072 was missing from the list Logitech gave me
for this mouse, as I found one with it in the wild (with which I tested
this patch).

Fixes: 4435ff2f09 ("HID: logitech: Enable high-resolution scrolling on Logitech mice")
Signed-off-by: Harry Cutts <hcutts@chromium.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-10-22 11:56:42 +02:00
Maciej S. Szmigiero
e13762abf3 HID: logitech-hidpp: avoid repeated "multiplier = " log messages
These messages appear each time the mouse wakes from sleep, in my case
(Logitech M705), every minute or so.
Let's downgrade them to the "debug" level so they don't fill the kernel log
by default.

While we are at it, let's make clear that this is a wheel multiplier (and
not, for example, XY movement multiplier).

Fixes: 4435ff2f09 ("HID: logitech: Enable high-resolution scrolling on Logitech mice")
Cc: stable@vger.kernel.org
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-07-07 12:40:26 +02:00
Filipe Laíns
c08ce25503 HID: logitech: drop outdated references to unifying receivers
The hid-logitech-{dj,hidpp} were originally developed for unifying
receivers but since then they have evolved and now support other types
of receivers and devices. This patch adjusts the original descriptions
with this in mind.

Signed-off-by: Filipe Laíns <lains@archlinux.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-04-06 11:38:35 +02:00
Filipe Laíns
4ab2bb3c31 HID: logitech-hidpp: BatteryVoltage: only read chargeStatus if extPower is active
In the HID++ 2.0 function getBatteryInfo() from the BatteryVoltage
(0x1001) feature, chargeStatus is only valid if extPower is active.

Previously we were ignoring extPower, which resulted in wrong values.

Example:
    With an unplugged mouse

    $ cat /sys/class/power_supply/hidpp_battery_0/status
    Charging

This patch fixes that, it also renames charge_sts to flags as
charge_sts can be confused with chargeStatus from the spec.

Spec:
+--------+-------------------------------------------------------------------------+
|  byte  |                                    2                                    |
+--------+--------------+------------+------------+----------+----------+----------+
|   bit  |     0..2     |      3     |      4     |     5    |     6    |     7    |
+--------+--------------+------------+------------+----------+----------+----------+
| buffer | chargeStatus | fastCharge | slowCharge | critical | (unused) | extPower |
+--------+--------------+------------+------------+----------+----------+----------+
Table 1 - battery voltage (0x1001), getBatteryInfo() (ASE 0), 3rd byte

+-------+--------------------------------------+
| value |                meaning               |
+-------+--------------------------------------+
|   0   | Charging                             |
+-------+--------------------------------------+
|   1   | End of charge (100% charged)         |
+-------+--------------------------------------+
|   2   | Charge stopped (any "normal" reason) |
+-------+--------------------------------------+
|   7   | Hardware error                       |
+-------+--------------------------------------+
Table 2 - chargeStatus value

Signed-off-by: Filipe Laíns <lains@archlinux.org>
Tested-by: Pedro Vanzella <pedro@pedrovanzella.com>
Reviewed-by: Pedro Vanzella <pedro@pedrovanzella.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2020-01-28 15:51:19 +01:00
Christophe JAILLET
8f2828d737 HID: logitech-hidpp: avoid duplicate error handling code in 'hidpp_probe()'
'hid_hw_stop()' is already in the error handling path when branching to
the 'hid_hw_open_fail' label.
There is no point in calling it twice, so remove one.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-01-13 13:26:43 +01:00
Pedro Vanzella
be281368f2 hid-logitech-hidpp: read battery voltage from newer devices
Newer Logitech mice report their battery voltage through feature 0x1001
instead of the battery levels through feature 0x1000.

When the device is brought up and we try to query the battery, figure
out if it supports the old or the new feature. If it supports the new
feature, record the feature index and read the battery voltage and
its charge status. The device will respond with three bytes: the first
two are its voltage, and the last one is a bitset, reporting if the
battery is charging, fast or slow, in critical level or discharging.

If everything went correctly, record the fact that we're capable
of querying battery voltage.

Note that the protocol only gives us the current voltage in mV.
We store that as-is, but when queried, we report it in uV as
expected by sysfs.

Like we do for other ways of interacting with the battery for other
devices, refresh the battery status and notify the power supply
subsystem of the changes in voltage and status.

Since there are no known devices which implement both the old and the
new battery feature, we make sure to try the newer feature first and
only fall back to the old one if that fails.

Signed-off-by: Pedro Vanzella <pedro@pedrovanzella.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-12-18 15:36:15 +01:00
Adrian Freund
04bd68171e HID: logitech: Add MX Master 3 Mouse
This patch adds support for the Logitech MX Master 3 Mouse using the
Logitech Unifying Receiver and Bluetooth LE.

Signed-off-by: Adrian Freund <adrian@freund.io>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-12-18 15:36:01 +01:00
Mazin Rezk
0da0a63b7c HID: logitech-hidpp: Support WirelessDeviceStatus connect events
This patch allows hidpp_report_is_connect_event to support
WirelessDeviceStatus connect events.

The WirelessDeviceStatus feature index is stored in hidpp_device when
probed. The connect event's fap feature_index is compared against it if the
device supports it.

Signed-off-by: Mazin Rezk <mnrzk@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-12-18 15:35:25 +01:00
Mazin Rezk
c2a932717a HID: logitech-hidpp: Support translations from short to long reports
This patch allows short reports to be translated into long reports.

hidpp_validate_device now returns a u8 instead of a bool which represents
the supported reports. The corresponding bits (i.e.
HIDPP_REPORT_*_SUPPORTED) are set if an HID++ report is supported.

If a short report is being sent and the device does not support it, it is
instead sent as a long report.

This patch also introduces support for the MX Master (b01e and b012).

Signed-off-by: Mazin Rezk <mnrzk@protonmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-12-18 15:35:25 +01:00
Jiri Kosina
a820e45039 Merge branch 'for-5.5/logitech' into for-linus
- Support for Logitech G15 (Hans de Goede)
- silencing of non-informative error flow in dmesg from
  logitechi-hiddpp (Hans de Goede)
2019-11-29 20:37:55 +01:00
Hans de Goede
61005d65b6 HID: logitech-hidpp: Silence intermittent get_battery_capacity errors
My Logitech M185 (PID:4038) 2.4 GHz wireless HID++ mouse is causing
intermittent errors like these in the log:

[11091.034857] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09
[12388.031260] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09
[16613.718543] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09
[23529.938728] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09

We are already silencing error-code 0x09 (HIDPP_ERROR_RESOURCE_ERROR)
errors in other places, lets do the same in
hidpp20_batterylevel_get_battery_capacity to remove these harmless,
but scary looking errors from the dmesg output.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-11-15 13:18:47 +01:00
Andrey Smirnov
08c453f6d0 HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()
All of the FF-related resources belong to corresponding FF device, so
they should be freed as a part of hidpp_ff_destroy() to avoid
potential race condidions.

Fixes: ff21a635dd ("HID: logitech-hidpp: Force feedback support for the Logitech G920")
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Cc: Austin Palmer <austinp@valvesoftware.com>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-10-18 15:29:56 +02:00
Andrey Smirnov
905d754c53 HID: logitech-hidpp: rework device validation
G920 device only advertises REPORT_ID_HIDPP_LONG and
REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
prevent G920 to be recognized as a valid HID++ device.

To fix this and improve some other aspects, modify
hidpp_validate_device() as follows:

  - Inline the code of hidpp_validate_report() to simplify
    distingushing between non-present and invalid report descriptors

  - Drop the check for id >= HID_MAX_IDS || id < 0 since all of our
    IDs are static and known to satisfy that at compile time

  - Change the algorithms to check all possible report
    types (including very long report) and deem the device as a valid
    HID++ device if it supports at least one

  - Treat invalid report length as a hard stop for the validation
    algorithm, meaning that if any of the supported reports has
    invalid length we assume the worst and treat the device as a
    generic HID device.

  - Fold initialization of hidpp->very_long_report_length into
    hidpp_validate_device() since it already fetches very long report
    length and validates its value

Fixes: fe3ee1ec00 ("HID: logitech-hidpp: allow non HID++ devices to be handled by this module")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
Reported-by: Sam Bazely <sambazley@fastmail.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Cc: Austin Palmer <austinp@valvesoftware.com>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-10-18 15:29:56 +02:00
Andrey Smirnov
abdd3d0b34 HID: logitech-hidpp: split g920_get_config()
Original version of g920_get_config() contained two kind of actions:

    1. Device specific communication to query/set some parameters
       which requires active communication channel with the device,
       or, put in other way, for the call to be sandwiched between
       hid_device_io_start() and hid_device_io_stop().

    2. Input subsystem specific FF controller initialization which, in
       order to access a valid 'struct hid_input' via
       'hid->inputs.next', requires claimed hidinput which means be
       executed after the call to hid_hw_start() with connect_mask
       containing HID_CONNECT_HIDINPUT.

Location of g920_get_config() can only fulfill requirements for #1 and
not #2, which might result in following backtrace:

[   88.312258] logitech-hidpp-device 0003:046D:C262.0005: HID++ 4.2 device connected.
[   88.320298] BUG: kernel NULL pointer dereference, address: 0000000000000018
[   88.320304] #PF: supervisor read access in kernel mode
[   88.320307] #PF: error_code(0x0000) - not-present page
[   88.320309] PGD 0 P4D 0
[   88.320315] Oops: 0000 [#1] SMP PTI
[   88.320320] CPU: 1 PID: 3080 Comm: systemd-udevd Not tainted 5.4.0-rc1+ #31
[   88.320322] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS 149.0.0.0.0 09/17/2018
[   88.320334] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp]
[   88.320338] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 <48> 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80
[   88.320341] RSP: 0018:ffffb0a6824aba68 EFLAGS: 00010246
[   88.320345] RAX: 0000000000000000 RBX: ffff93a50756e000 RCX: 0000000000010408
[   88.320347] RDX: 0000000000000000 RSI: ffff93a51f0ad0a0 RDI: 000000000002d0a0
[   88.320350] RBP: ffff93a50416da28 R08: ffff93a50416da70 R09: ffff93a50416da70
[   88.320352] R10: 000000148ae9e60c R11: 00000000000f1525 R12: ffff93a50756e000
[   88.320354] R13: ffff93a50756f8d0 R14: 0000000000000000 R15: ffff93a50756fc38
[   88.320358] FS:  00007f8d8c1e0940(0000) GS:ffff93a51f080000(0000) knlGS:0000000000000000
[   88.320361] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   88.320363] CR2: 0000000000000018 CR3: 00000003996d8003 CR4: 00000000001606e0
[   88.320366] Call Trace:
[   88.320377]  ? _cond_resched+0x15/0x30
[   88.320387]  ? create_pinctrl+0x2f/0x3c0
[   88.320393]  ? kernfs_link_sibling+0x94/0xe0
[   88.320398]  ? _cond_resched+0x15/0x30
[   88.320402]  ? kernfs_activate+0x5f/0x80
[   88.320406]  ? kernfs_add_one+0xe2/0x130
[   88.320411]  hid_device_probe+0x106/0x170
[   88.320419]  really_probe+0x147/0x3c0
[   88.320424]  driver_probe_device+0xb6/0x100
[   88.320428]  device_driver_attach+0x53/0x60
[   88.320433]  __driver_attach+0x8a/0x150
[   88.320437]  ? device_driver_attach+0x60/0x60
[   88.320440]  bus_for_each_dev+0x78/0xc0
[   88.320445]  bus_add_driver+0x14d/0x1f0
[   88.320450]  driver_register+0x6c/0xc0
[   88.320453]  ? 0xffffffffc0d67000
[   88.320457]  __hid_register_driver+0x4c/0x80
[   88.320464]  do_one_initcall+0x46/0x1f4
[   88.320469]  ? _cond_resched+0x15/0x30
[   88.320474]  ? kmem_cache_alloc_trace+0x162/0x220
[   88.320481]  ? do_init_module+0x23/0x230
[   88.320486]  do_init_module+0x5c/0x230
[   88.320491]  load_module+0x26e1/0x2990
[   88.320502]  ? ima_post_read_file+0xf0/0x100
[   88.320508]  ? __do_sys_finit_module+0xaa/0x110
[   88.320512]  __do_sys_finit_module+0xaa/0x110
[   88.320520]  do_syscall_64+0x5b/0x180
[   88.320525]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   88.320528] RIP: 0033:0x7f8d8d1f01fd
[   88.320532] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5b 8c 0c 00 f7 d8 64 89 01 48
[   88.320535] RSP: 002b:00007ffefa3bb068 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   88.320539] RAX: ffffffffffffffda RBX: 000055922040cb40 RCX: 00007f8d8d1f01fd
[   88.320541] RDX: 0000000000000000 RSI: 00007f8d8ce4984d RDI: 0000000000000006
[   88.320543] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007
[   88.320545] R10: 0000000000000006 R11: 0000000000000246 R12: 00007f8d8ce4984d
[   88.320547] R13: 0000000000000000 R14: 000055922040efc0 R15: 000055922040cb40
[   88.320551] Modules linked in: hid_logitech_hidpp(+) fuse rfcomm ccm xt_CHECKSUM xt_MASQUERADE bridge stp llc nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat tun iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc dm_crypt nls_utf8 hfsplus intel_rapl_msr intel_rapl_common ath9k_htc ath9k_common x86_pkg_temp_thermal intel_powerclamp b43 ath9k_hw coretemp snd_hda_codec_hdmi cordic kvm_intel snd_hda_codec_cirrus mac80211 snd_hda_codec_generic ledtrig_audio kvm snd_hda_intel snd_intel_nhlt irqbypass snd_hda_codec btusb btrtl snd_hda_core ath btbcm ssb snd_hwdep btintel snd_seq crct10dif_pclmul iTCO_wdt snd_seq_device crc32_pclmul bluetooth mmc_core iTCO_vendor_support joydev cfg80211
[   88.320602]  applesmc ghash_clmulni_intel ecdh_generic snd_pcm input_polldev intel_cstate ecc intel_uncore thunderbolt snd_timer i2c_i801 libarc4 rfkill intel_rapl_perf lpc_ich mei_me pcspkr bcm5974 snd bcma mei soundcore acpi_als sbs kfifo_buf sbshc industrialio apple_bl i915 i2c_algo_bit drm_kms_helper drm uas crc32c_intel usb_storage video hid_apple
[   88.320630] CR2: 0000000000000018
[   88.320633] ---[ end trace 933491c8a4fadeb7 ]---
[   88.320642] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp]
[   88.320645] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 <48> 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80
[   88.320647] RSP: 0018:ffffb0a6824aba68 EFLAGS: 00010246
[   88.320650] RAX: 0000000000000000 RBX: ffff93a50756e000 RCX: 0000000000010408
[   88.320652] RDX: 0000000000000000 RSI: ffff93a51f0ad0a0 RDI: 000000000002d0a0
[   88.320655] RBP: ffff93a50416da28 R08: ffff93a50416da70 R09: ffff93a50416da70
[   88.320657] R10: 000000148ae9e60c R11: 00000000000f1525 R12: ffff93a50756e000
[   88.320659] R13: ffff93a50756f8d0 R14: 0000000000000000 R15: ffff93a50756fc38
[   88.320662] FS:  00007f8d8c1e0940(0000) GS:ffff93a51f080000(0000) knlGS:0000000000000000
[   88.320664] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   88.320667] CR2: 0000000000000018 CR3: 00000003996d8003 CR4: 00000000001606e0

To solve this issue:

   1. Split g920_get_config() such that all of the device specific
      communication remains a part of the function and input subsystem
      initialization bits go to hidpp_ff_init()

   2. Move call to hidpp_ff_init() from being a part of
      g920_get_config() to be the last step of .probe(), right after a
      call to hid_hw_start() with connect_mask containing
      HID_CONNECT_HIDINPUT.

Fixes: 91cf9a98ae ("HID: logitech-hidpp: make .probe usbhid capable")
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Sam Bazley <sambazley@fastmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Cc: Austin Palmer <austinp@valvesoftware.com>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-10-18 15:29:56 +02:00
Alan Stern
d9d4b1e46d HID: Fix assumption that devices have inputs
The syzbot fuzzer found a slab-out-of-bounds write bug in the hid-gaff
driver.  The problem is caused by the driver's assumption that the
device must have an input report.  While this will be true for all
normal HID input devices, a suitably malicious device can violate the
assumption.

The same assumption is present in over a dozen other HID drivers.
This patch fixes them by checking that the list of hid_inputs for the
hid_device is nonempty before allowing it to be used.

Reported-and-tested-by: syzbot+403741a091bf41d4ae79@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-10-03 15:36:40 -04:00
Benjamin Tissoires
a3384b8d9f HID: logitech-hidpp: remove support for the G700 over USB
The G700 suffers from the same issue than the G502:
when plugging it in, the driver tries to contact it but it fails.

This timeout is problematic as it introduce a delay in the boot,
and having only the mouse event node means that the hardware
macros keys can not be relayed to the userspace.

Link: https://github.com/libratbag/libratbag/issues/797
Fixes: 91cf9a98ae ("HID: logitech-hidpp: make .probe usbhid capable")
Cc: stable@vger.kernel.org # v5.2
Reviewed-by: Filipe Laíns <lains@archlinux.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-08-13 16:29:46 +02:00
Benjamin Tissoires
addf3382c4 Revert "HID: logitech-hidpp: add USB PID for a few more supported mice"
This partially reverts commit 27fc32fd94.

It turns out that the G502 has some issues with hid-logitech-hidpp:
when plugging it in, the driver tries to contact it but it fails.
So the driver bails out leaving only the mouse event node available.

This timeout is problematic as it introduce a delay in the boot,
and having only the mouse event node means that the hardware
macros keys can not be relayed to the userspace.

Filipe and I just gave a shot at the following devices:

G403 Wireless (0xC082)
G703 (0xC087)
G703 Hero (0xC090)
G903 (0xC086)
G903 Hero (0xC091)
G Pro (0xC088)

Reverting the devices we are not sure that works flawlessly.

Reviewed-by: Filipe Laíns <lains@archlinux.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-08-13 16:29:17 +02:00
Filipe Laíns
27fc32fd94 HID: logitech-hidpp: add USB PID for a few more supported mice
Add more device IDs to logitech-hidpp driver.

Signed-off-by: Filipe Laíns <lains@archlinux.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-07-17 13:29:54 +02:00
Jiri Kosina
74acee309f Merge branches 'for-5.2/fixes', 'for-5.3/doc', 'for-5.3/ish', 'for-5.3/logitech' and 'for-5.3/wacom' into for-linus 2019-07-10 01:39:57 +02:00
Linus Torvalds
c11fb13a11 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:

 - regression fixes (reverts) for module loading changes that turned out
   to be incompatible with some userspace, from Benjamin Tissoires

 - regression fix for special Logitech unifiying receiver 0xc52f, from
   Hans de Goede

 - a few device ID additions to logitech driver, from Hans de Goede

 - fix for Bluetooth support on 2nd-gen Wacom Intuos Pro, from Jason
   Gerecke

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
  HID: logitech-dj: Fix 064d:c52f receiver support
  Revert "HID: core: Call request_module before doing device_add"
  Revert "HID: core: Do not call request_module() in async context"
  Revert "HID: Increase maximum report size allowed by hid_field_extract()"
  HID: a4tech: fix horizontal scrolling
  HID: hyperv: Add a module description line
  HID: logitech-hidpp: Add support for the S510 remote control
  HID: multitouch: handle faulty Elo touch device
  HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary
  HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth
  HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact
  HID: wacom: Don't report anything prior to the tool entering range
  HID: wacom: Don't set tool type until we're in range
  HID: rmi: Use SET_REPORT request on control endpoint for Acer Switch 3 and 5
  HID: logitech-hidpp: add support for the MX5500 keyboard
  HID: logitech-dj: add support for the Logitech MX5500's Bluetooth Mini-Receiver
  HID: i2c-hid: add iBall Aer3 to descriptor override
2019-06-13 05:59:05 -10:00
Thomas Gleixner
b886d83c5b treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation version 2 of the license

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 315 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Armijn Hemel <armijn@tjaldur.nl>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05 17:37:17 +02:00
Hans de Goede
2409877d38 HID: logitech-hidpp: Add support for the S510 remote control
The S510 remote-control shows up as a second keyboard (keypad) on the
receiver. It has a scroll-wheel, which normally sends wheel event
originating from the mouse's evdev node.

Add a HIDPP_QUIRK_KBD_SCROLL_WHEEL quirk for it, so that the wheel events
properly originate from the evdev node of the remote control itself.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-05-22 13:20:15 +02:00
Colin Ian King
a96a8a576b HID: logitech-hidpp: HID: make const array consumer_rdesc_start static
Don't populate the array consumer_rdesc_start on the stack but instead
make it static. Makes the object code smaller by 88 bytes.

Before:
   text	   data	    bss	    dec	    hex	filename
  59155	   9840	    448	  69443	  10f43	drivers/hid/hid-logitech-hidpp.o

After:
   text	   data	    bss	    dec	    hex	filename
  59003	   9904	    448	  69355	  10eeb	drivers/hid/hid-logitech-hidpp.o

(gcc version 8.3.0, amd64)

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-05-22 13:18:44 +02:00
Hans de Goede
ced2c0c53d HID: logitech-hidpp: add support for the MX5500 keyboard
The MX5500 keyboard needs the HIDPP_CONSUMER_VENDOR_KEYS quirk to report
events for the 'A' - 'D' Smart Keys and for the "Photo Gallery" and
"Gadgets" keys.

In addition to this adding the Bluetooth match, so that hid-logitech-hidpp
is used instead of the generic HID driver, also adds battery monitoring
support when the keyboard is connected over Bluetooth.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-05-09 21:31:22 +02:00
Hans de Goede
42bc4f3129 HID: logitech-hidpp: add support for HID++ 1.0 consumer keys reports
All Logitech 27 MHz keyboards and also the MX5000 bluetooth keyboard use
Logitech custom usages of 0x10xx in the consumer page. The descriptor for
the consumer input-report only declares usages up to 652, so we end up
dropping all the input-reports reporting 0x10xx usages without reporting
events for these to userspace.

This commit adds a descriptor_fixup function for this which changes the
usage and logical maximum to 0x107f. Mapping these usages to something
other then KEY_UNKNOWN is left to userspace (hwdb). Note:
1. The old descriptor_fixup for this in hid-lg.c used a maximimum of 0x104d
   this is not high enough, the S520 keyboard battery key sends 0x106f.
2. The descriptor_fixup is flexible so that it works with both the kbd-
   desc. passed by the logitech-dj code and with bluetooth descriptors.

The descriptor_fixup makes most keys work on 27 MHz keyboards, but it is
not enough to get all keys to work on 27 MHz keyboards and just the fixup
is not enough to get the MX5000 to generate 0x10xx events:

1) The LX501 and MX3000 27 MHz kbds both have a button labelled "media"
(called "Media Player" by SetPoint) and a button with a remote-control
symbol ("Media Life" in SetPoint) which both send an identical consumer
usage-page code (0x0183) making the 2 buttons indistinguishable,
switching to HID++ 1.0 consumer keys reports makes the remote-control
symbol button generate a 0x10xx Logitech specific code instead.

2) The MX5000 Bluetooth keyboard has 11 keys which report 0x10xx consumer
page usages, but unlike 27 MHz devices which happily send 0x10xx codes in
their normal consumer-page input-report, the MX5000 honors the maximum of
652 from its descriptor and sends a 0x0000 code (so release) whenever these
keys are pressed. When switching to HID++ sub-id 0x03 HID++ 1.0 consumer
keys reports these 0x10xx codes do get properly reported.

This commit adds support for HID++ 1.0 consumer keys reports and enables
this for all 27 MHz keyboards and for the MX5000.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:03:06 +02:00
Hans de Goede
7457bc1b0e HID: logitech-hidpp: add support for HID++ 1.0 extra mouse buttons reports
Some mice have extra buttons which are only reported through HID++ 1.0
extra mouse buttons reports, this commit adds support for this and
automatically enables this support for all 27 MHz mice.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:03:05 +02:00
Hans de Goede
4a79bcc64a HID: logitech-hidpp: add support for HID++ 1.0 wheel reports
Add a quirk for switching wheel event reporting to using the HID++
report for this.

This has 2 advantages:
1) Without this tilting the scrollwheel left / right will send a
   scroll-lock + cursor-left/-right + scroll-lock key-sequence instead of
   hwheel events

2) The HID++ reports contain the device index instead of using the generic
   HID implementation, so this will make scroll-wheel events from the wheel
   on some keyboards be emitted by the right event node.

2. also fixes keyboard scroll-wheel events getting lost in the (mostly
theoretical) case of there not being a mouse paired with the receiver.

This commit enables this quirk for all 27Mhz mice, it cannot hurt to have
it enabled and this avoids the need to keep adding more and more quirks for
this. This has been tested in 5 different 27MHz mice, 3 of which have a
wheel which can tilt.

This commit also adds explicit quirks for 3 keyboards with a zoom-/scroll-
wheel. The MX3000 keyboard scroll-wheel can also tilt. I've defined aliases
to the new HIDPP_QUIRK_HIDPP_WHEELS for this, so that it is clear why the
keyboard has the quirk and in case we want to handle the keyboard wheels
and especially the keyboard zoom-wheels differently in the future.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:03:05 +02:00
Hans de Goede
35839f7723 HID: logitech-hidpp: make hidpp10_set_register_bit a bit more generic
Make hidpp10_set_register_bit() take a mask and value for the register
byte being changed, rather then making it only set a single bit.

While at it also at defines for the bits which we will be using.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:03:04 +02:00
Hans de Goede
0610430e3d HID: logitech-hidpp: add input_device ptr to struct hidpp_device
Most device-class specific code needs access to the input_device, instead
of storing that in the class specific data-struct, simply store this into
the hidpp_device struct itself.

In case of the m560 this avoids the need for having private data at all
and this will also avoid the need to add private data in some upcoming
patches.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:57 +02:00
Hans de Goede
d71b18f7c7 HID: logitech-hidpp: do not hardcode very long report length
The HID++ spec says the following about the very long report length:
"n Bytes, depends on HID++ collection declaration".

Hardcoding this breaks talking to some HID++ devices over BlueTooth, since
they declare only 45 bytes data for the very long report, rather then the
hardcoded 63.

This commit fixes this by getting the actual report length from the
descriptors.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:52 +02:00
Hans de Goede
754a308848 HID: logitech-hidpp: handle devices attached to 27MHz wireless receivers
Logitech 27MHz devices are HID++ devices, so handle them in the hidpp
driver, this enables battery monitoring on these devices (and more in
follow-up patches).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:51 +02:00
Hans de Goede
096377525c HID: logitech-hidpp: use RAP instead of FAP to get the protocol version
According to the logitech_hidpp_2.0_specification_draft_2012-06-04.pdf doc:
https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf

We should use a register-access-protocol request using the short input /
output report ids. This is necessary because 27MHz HID++ receivers have
a max-packetsize on their HIP++ endpoint of 8, so they cannot support
long reports. Using a feature-access-protocol request (which is always
long or very-long) with these will cause a timeout error, followed by
the hidpp driver treating the device as not being HID++ capable.

This commit fixes this by switching to using a rap request to get the
protocol version.

Besides being tested with a (046d:c517) 27MHz receiver with various
27MHz keyboards and mice, this has also been tested to not cause
regressions on a non-unifying dual-HID++ nano receiver (046d:c534) with
k270 and m185 HID++-2.0 devices connected and on a unifying/dj receiver
(046d:c52b) with a HID++-2.0 Logitech Rechargeable Touchpad T650.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:46 +02:00
Hans de Goede
e54abaf675 HID: logitech-hidpp: remove unused origin_is_hid_core function parameter
All the various populate_input functions have an origin_is_hid_core
function parameter, but none use it, remove it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:45 +02:00
Hans de Goede
205a2ab0c9 HID: logitech-hidpp: remove double assignment from __hidpp_send_report
The hidpp variable is already initialized with hid_get_drvdata(hdev)
when it is declared, drop the second no-op assignment.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:44 +02:00
Hans de Goede
2ddf07f388 HID: logitech-hidpp: do not make failure to get the name fatal
With devices attached to a non-unifying 2.4GHz receiver we sometimes fail
to get the name. This is not a fatal error, we can just continue with the
original name.

So instead of bailing out, continue with battery-initialization when this
happens. This fixes the battery not getting registered when we fail to
get the name.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:44 +02:00
Hans de Goede
22bf6bdef4 HID: logitech-hidpp: ignore very-short or empty names
Some devices report an empty or very short name, in this case stick
with the name generated by the logitech-dj code instead of overriding it
with e.g. "Logitech ".

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:43 +02:00
Benjamin Tissoires
91cf9a98ae HID: logitech-hidpp: make .probe usbhid capable
The current custom solution for the G920 is not the best because
hid_hw_start() is not called at the end of the .probe().
It means that any configuration retrieved after the initial hid_hw_start
would not be exposed to user space without races.

We can simply force hid_hw_start to just enable the transport layer by
not using a connect_mask. This way, we can have a common path between
USB, Unifying and Bluetooth devices.

With this change, we can now support the non DJ receivers for low end
devices, which will allow us to fetch the actual names of the paired
device (instead of 'Logitech Wireless Receiver')

Tested with a M185 with the non unifying receiver, a T650 and many other
unifying devices, and the T651 over Bluetooth.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:39 +02:00
Benjamin Tissoires
fe3ee1ec00 HID: logitech-hidpp: allow non HID++ devices to be handled by this module
On the gaming mice, there are 2 interfaces, one for the mouse and one
for the macros. Better allow everybody to go through hid-logitech-hidpp
than trying to be smarter.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 18:02:26 +02:00
Benjamin Tissoires
43cd97af70 HID: logitech: Stop setting drvdata to NULL on probe failure and remove
There is no need to set drvdata to NULL on probe failure and remove,
the driver-core already does this for us.

[hdegoede@redhat.com: Isolate Logitech changes into a separate patch]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-04-23 17:59:01 +02:00