- 23 Apr, 2019 39 commits
-
-
Hans de Goede authored
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>
-
Hans de Goede authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Benjamin Tissoires authored
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:
-
Benjamin Tissoires authored
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 authored
Add support for the Logitech Bluetooth Mini-Receiver in HID proxy mode This requires some special handing in dj_find_receiver_dev because the BT Mini-Receiver contains a built-in hub and has separate USB-devices for the keyboard and mouse interfaces, rather then using 2 interfaces on a single USB device. Otherwise this receiver works identical to the standard non-unifying nano receivers. Signed-off-by:
-
Hans de Goede authored
Make the appending of the HID++ descriptors in logi_dj_ll_parse conditional. This is a preparation patch for adding support for the Logitech mini Bluetooth receiver in HID proxy mode (its default mode), where some of the paired devices may not be Logitech devices and thus may not be HID++ capable. This uses a fake bit 63 in reports_supported, which is changed from an u32 to an u64 for this. Bits <= 31 are not usable for this because that would cause a behavioral change in logi_dj_recv_forward_null_report. Signed-off-by:
-
Hans de Goede authored
The various functions queueing work-items do not check there already is a work-item queued before calling schedule_work(), as such they may race with each-other and with the re-queuing done by the delayedwork_callback itself. This is fine as the delayedwork_callback simply is a nop if scheduled once too much. I've actually seen the false-positive hid_err for this trigger in practice, so lets remove it. While at it also remove the somewhat overzealous debugging around the schedule_work() calls. Signed-off-by:
-
Hans de Goede authored
hidpp_unifying_get_name() does not work for devices attached to non-unifying receivers. Since we do get a device-type in the device- connection report, we can pick a better name for these devices in hid-logitech-dj.c . Signed-off-by:
-
Hans de Goede authored
My Aten cs1764a KVM adds an extra interface to the receiver through which it forwards mouse events, if a separate mouse is plugged in next to the receiver dongle. This interface is present even if no extra mouse is plugged in. logitech-dj trying to handle this extra interface causes mouse events send through the extra interface to not be properly handled. This commit fixes this by treating any extra interfaces as hid-generic interfaces. Signed-off-by:
-
Hans de Goede authored
Use hid_err consistently everywhere. While at it also tweak some of the messages for clarity, to consistently have a space after a ':' and in some cases to fit within 80 chars. Signed-off-by:
-
Hans de Goede authored
27 MHz mouse-only receivers send an unnumbered input report with the mouse data, add special handling for this and add the c51b product-id to the logi_dj_receivers table. Signed-off-by:
-
Hans de Goede authored
Most Logitech wireless keyboard and mice using the 27 MHz are hidpp10 devices, add support to logitech-dj for their receivers. Doing so leads to 2 improvements: 1) All these devices share the same USB product-id for their receiver, making it impossible to properly map some special keys / buttons which differ from device to device. Adding support to logitech-dj to see these as hidpp10 devices allows us to get the actual device-id from the keyboard / mouse. 2) It enables battery-monitoring of these devices This patch uses a new HID group for 27Mhz devices, since the logitech-hidpp code needs to be able to differentiate them from other devices instantiated by the logitech-dj code. Signed-off-by:
-
Benjamin Tissoires authored
This receiver is almost identical to the normal unifying ones except: - it is supposed to be paired to only one device (for performance reasons) - the mice reports have a greater ranges in their values, so they are using a different report ID. Tested on a G403 and a G900. Co-authored-by:
-
Hans de Goede authored
We emulate the DJ functionality through the driver. The receiver supports "fake device arrival" which behaves like the probing of DJ devices. A non-unifying receiver has 2 USB interfaces, the first one generates standard keypresses and is compatible with the USB Keyboard Boot Subclass. The second interface sends events for the mouse and special keys such as the consumer-page keys. Events are split this way for BIOS / Windows / generic-hid driver compatibility. This split does not actually match with which device the event originate from, e.g. the consumer-page key events originate from the keyboard but are delivered on the mouse interface. To make sure the events are actually delivered to the dj_device representing the originating device, we pick which dj_dev to forward a "regular" input-report to based on the report-number, rather then based on the originating interface. Co-authored-by:
-
Hans de Goede authored
Add a logi_dj_recv_queue_unknown_work helper and implement query rate-limiting inside this helper. The motivations behind this are: 1) We need to queue workitems for reports with no place to forward them from more places with the upcoming non-unifying receiver support, hence the addition of the helper function. 2) When we've missed a pairing info report (or there is a race between the report and input-events) and the input report is e.g. from a mouse being moved, we will get a lot of these before we've finished (re-) querying and enumerating the devices, hence the rate-limiting. Note this also removes the: if (!djrcv_dev->paired_dj_devices[hidpp_report->device_index]) check previously guarding the sending of an unknown workitem, the caller of logi_dj_recv_queue_notification already does this check before calling logi_dj_recv_queue_notification. Signed-off-by:
-
Hans de Goede authored
dj/HID++ receivers are really a single logical entity, but for BIOS/Windows compatibility they have multiple USB interfaces. For the upcoming non-unifying receiver support, we need to listen for events from / bind to all USB-interfaces of the receiver. This commit add support to the logitech-dj code for creating a single dj_receiver_dev struct for all interfaces belonging to a single USB-device / receiver, in preparation for adding non-unifying receiver support. Signed-off-by:
-
Hans de Goede authored
For the upcoming non-unifying receiver support, we are going to bind to all USB-interfaces of a receiver, sharing a single struct dj_receiver_dev between the interfaces. This means that dj_receiver_dev will contain multiple pointers to a struct hid_device. Rename the current hdev member to hidpp to prepare for this. While at it switch dev_err calls which we are touching anyways from dev_err to hid_err. Signed-off-by:
-
Hans de Goede authored
This protects against logi_dj_recv_add_djhid_device, adding a device to paired_dj_devices from the delayedwork callback, racing versus logi_dj_raw_event trying to access that device. Signed-off-by:
-
Hans de Goede authored
querying_devices is never set, so it can safely be removed. Signed-off-by:
-
Benjamin Tissoires authored
This is a preparatory patch for handling non DJ (HID++ only) receivers, through this module. We can not use the dj_report in the delayed work callback as the HID++ notifications are different both in size and meaning. There should be no functional change. Signed-off-by:
-
Benjamin Tissoires authored
It is better to rely on the actual content of the report descriptors to enable or not a HID interface. While at it, remove the other USB dependency to have a fully USB agnostic driver. Signed-off-by:
-
Benjamin Tissoires authored
For the non DJ receivers, we are going to need to re-use those constants, better have them properly defined. Signed-off-by:
-
Benjamin Tissoires authored
Use BIT() macro for RF Report types. Signed-off-by:
-
Benjamin Tissoires authored
we are not dealing with a dj_report but a hidpp_event. We don't need all of the struct description in this function, but having the variable named `dj_report` feels weird. Signed-off-by:
-
Benjamin Tissoires authored
logi_dj_recv_forward_report() was only intended for DJ reports. logi_dj_recv_forward_hidpp() is more generic at forwarding random HID reports. So rename logi_dj_recv_forward_report() into logi_dj_recv_forward_dj() and logi_dj_recv_forward_hidpp() into logi_dj_recv_forward_report(). Signed-off-by:
-
Benjamin Tissoires authored
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:
-
Benjamin Tissoires authored
I am actually suggesting people to not populate this list, and I should probably start to apply my advices to myself. The end result means that if your initrd is lacking hid-logitech-dj or hid-logitech-hidpp, but still contains hid-generic, then your keyboard will work during pre-init. Signed-off-by:
-
Benjamin Tissoires authored
-
Srinivas Pandruvada authored
Add Comet Lake PCI device ID to the supported device list. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
- 11 Apr, 2019 1 commit
-
-
Hui Wang authored
This reverts commit 74e7c6c8. It finally turns out the touchpad is an engineering sample and it is not the Synaptics touchpad. Let us revert this patch otherwise it will affect the real Synaptics touchpad. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
