Using hidpp for the M720 adds battery info reporting and hires
scrolling support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add Logitech MX Anywhere 3 connected over Bluetooth to the device table
to get hidpi scroll supported. USB connection over the Unifying receiver
is already supported by the wildcard entry LDJ_DEVICE(HID_ANY_ID).
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds support for the Pro X Superlight over wired USB.
The device now reports the status of its battery.
Co-developed-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As per the upstream "hidpp" helpers commit:
"
There has been some confusion about error value 5 but feature specs that
refer to it generally use NOT_ALLOWED.
"
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: 80c3fecfcd
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Previously, support for the G502 had been attempted in commit
'27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported
mice")'
This caused some issues and was reverted by
'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more
supported mice"")'.
Since then, a new version of this mouse has been released (Lightpseed
Wireless), and works correctly.
This device has support for battery reporting with the driver
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection
For this device, this provides battery reporting on top of hid-generic
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It seems we forgot the normal case to terminate the retry loop,
making us asking 3 times each command, which is probably a little bit
too much.
And remove the ugly "goto exit" that can be replaced by a simpler "break"
Fixes: 586e8fede7 ("HID: logitech-hidpp: Retry commands when device is busy")
Suggested-by: Mark Lord <mlord@pobox.com>
Tested-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If an attempt at contacting a receiver or a device fails because the
receiver or device never responds, don't restart the communication, only
restart it if the receiver or device answers that it's busy, as originally
intended.
This was the behaviour on communication timeout before commit 586e8fede7
("HID: logitech-hidpp: Retry commands when device is busy").
This fixes some overly long waits in a critical path on boot, when
checking whether the device is connected by getting its HID++ version.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Suggested-by: Mark Lord <mlord@pobox.com>
Fixes: 586e8fede7 ("HID: logitech-hidpp: Retry commands when device is busy")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that USB HID++ devices can gather a serial number that matches the
one that would be gathered when connected through a Unifying receiver,
remove the last difference by dropping the product ID as devices
usually have different product IDs when connected through USB or
Unifying.
For example, on the serials on a G903 wired/wireless mouse:
- Unifying before patch: 4067-e8-ce-cd-45
- USB before patch: c086-e8-ce-cd-45
- Unifying and USB after patch: e8-ce-cd-45
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230302130117.3975-2-hadess@hadess.net
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
For devices that support the 0x0003 feature (Device Information) version 4,
set the serial based on the output of that feature, rather than relying
on the usbhid code setting the USB serial.
This should allow the serial when connected through USB to (nearly)
match the one when connected through a unifying receiver.
For example, on the serials on a G903 wired/wireless mouse:
- Unifying: 4067-e8-ce-cd-45
- USB before patch: 017C385C3837
- USB after patch: c086-e8-ce-cd-45
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230302130117.3975-1-hadess@hadess.net
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Handle the busy error coming from the device or receiver. The
documentation says a busy error can be returned when:
"
Device (or receiver) cannot answer immediately to this request
for any reason i.e:
- already processing a request from the same or another SW
- pipe full
"
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230209154916.462158-1-hadess@hadess.net
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
HIDPP_QUIRK_NO_HIDINPUT isn't used by any devices but still happens to
work as HIDPP_QUIRK_DELAYED_INIT is defined to the same value. Remove
HIDPP_QUIRK_NO_HIDINPUT and use HIDPP_QUIRK_DELAYED_INIT everywhere
instead.
Tested on a T650 which requires that quirk, and a number of unifying and
Bluetooth devices that don't.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230125121723.3122-2-hadess@hadess.net
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Now that we're in 2022, and the majority of desktop environments can and
should support touchpad gestures through libinput, remove the legacy
module parameter that made it possible to use gestures implemented in
firmware.
This will eventually allow simplifying the driver's initialisation code.
This reverts commit 9188dbaed6.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221220154345.474596-1-hadess@hadess.net
This reverts commit 532223c8ac.
As reported in [0], hid-logitech-hidpp now binds on all bluetooth mice,
but there are corner cases where hid-logitech-hidpp just gives up on
the mouse. This leads the end user with a dead mouse.
Given that we are at -rc8, we are definitively too late to find a proper
fix. We already identified 2 issues less than 24 hours after the bug
report. One in that ->match() was never designed to be used anywhere else
than in hid-generic, and the other that hid-logitech-hidpp has corner
cases where it gives up on devices it is not supposed to.
So we have no choice but postpone this patch to the next kernel release.
[0] https://lore.kernel.org/linux-input/CAJZ5v0g-_o4AqMgNwihCb0jrwrcJZfRrX=jv8aH54WNKO7QB8A@mail.gmail.com/
Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 8544c812e4.
We need to revert commit 532223c8ac ("HID: logitech-hidpp: Enable HID++
for all the Logitech Bluetooth devices") because that commit might make
hid-logitech-hidpp bind on mice that are not well enough supported by
hid-logitech-hidpp, and the end result is that the probe of those mice
is now returning -ENODEV, leaving the end user with a dead mouse.
Given that commit 8544c812e4 ("HID: logitech-hidpp: Remove special-casing
of Bluetooth devices") is a direct dependency of 532223c8ac, revert it
too.
Note that this also adapt according to commit 908d325e16 ("HID:
logitech-hidpp: Detect hi-res scrolling support") to re-add support of
the devices that were removed from that commit too.
I have locally an MX Master and I tested this device with that revert,
ensuring we still have high-res scrolling.
Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
According to docs a SwID should be sent for GetProtocolVersion.
> 0x10.DeviceIndex.0x00.0x1n
where n is SwID.
Signed-off-by: Andreas Bergmeier <abergmeier@gmx.net>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Rather than relying on a never-ending stream of patches for quirks.
This change will detect whether HID++ 1.0 hi-res scroll, HID++ 2.0
hi-res scroll or HID++ 2.0 hi-res scroll wheel is supported, and enable
the feature without the need for quirks.
Tested on a Logitech M705 mouse that was unsupported before this change.
[ 9.365324] logitech-hidpp-device 0003:046D:406D.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech M705] on usb-0000:00:14.0-4/input2:3
[ 57.472434] logitech-hidpp-device 0003:046D:406D.0006: HID++ 4.5 device connected.
[ 57.616429] logitech-hidpp-device 0003:046D:406D.0006: Detected HID++ 2.0 hi-res scroll wheel
[ 57.712424] logitech-hidpp-device 0003:046D:406D.0006: wheel multiplier = 8
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216480
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
Tested-by: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20220914132146.6435-1-hadess@hadess.net
Some HID++ 2.0 commands had correctly set a non-zero software identifier
directly as part of their function identifiers, but it's more correct to
define the function identifier and the software identifier separately
before combined them when the command is sent.
As this is now done in the previous commit, remove the hard-coded 0x1
software identifiers in the function definitions.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Always set a non-zero "Sw. Id." in the lower nibble of the Function/ASE
and Software Identifier byte in HID++ 2.0 commands.
As per the "Protocol HID++2.0 essential features" section in
https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf
"
Software identifier (4 bits, unsigned)
A number uniquely defining the software that sends a request. The
firmware must copy the software identifier in the response but does
not use it in any other ways.
0 Do not use (allows to distinguish a notification from a response).
"
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215699
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that all the Logitech Bluetooth devices are probed for HID++
support, remove the handling of those 2 devices without any quirks, as
they're duplicates.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Probe for HID++ support over Bluetooth for all the Logitech Bluetooth
devices. As Logitech doesn't have a list of Bluetooth devices that
support HID++ over Bluetooth, probe every device. The HID++ driver
will fall back to plain HID if the device does not support HID++,
or to a another device-specific driver if it is part of the
unhandled_hidpp_devices array, used in the match function.
Note that this change might cause upower to export 2 batteries for
certain Bluetooth LE devices which export their battery information
through the Bluetooth BATT profile. This particular bug is tracked at:
https://gitlab.freedesktop.org/upower/upower/-/issues/166
Tested with a Logitech Signature M650 mouse, over Bluetooth
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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>
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>
- 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
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>
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>
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>
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>
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>
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>
