This should help people identify the receiver. there are several receivers used
in gaming mice. the "lightspeed" technology is pretty well advertise so this
won't just be an obscure name.
Signed-off-by: NFilipe Laíns <lains@archlinux.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The HID++ spec also defines very long HID++ reports, with a reportid of
0x12. The MX5000 and MX5500 keyboards use 0x12 output reports for sending
messages to display on their buildin LCD.

Userspace (libmx5000) supports this, in order for this to work when talking
to the HID devices instantiated for the keyboard by hid-logitech-dj,
we need to properly forward these reports to the device.

This commit fixes logi_dj_ll_raw_request not forwarding these reports.

Fixes: f2113c30 ("HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We should return 'retval' as the correct return value
instead of always zero.

Fixes: 74808f91 ("HID: logitech-dj: add support for non unifying receivers")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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 version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details you should have received a copy of the gnu general
  public license along with this program if not write to the free
  software foundation inc 59 temple place suite 330 boston ma 02111
  1307 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 136 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAlexios Zavras <alexios.zavras@intel.com>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000436.384967451@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The c52f nano receiver is a mouse only receiver. This means that it needs
some special handling compared to the c534 nano receiver:

1) It sends unnumbered mouse reports with a size of 8 bytes, so we need
   to extend the unnumbered mouse report handling to support reports upto
   8 bytes large

2) It mouse reports have the same high-resolution format as those from the
   gaming mouse receivers

3) It can report consumer/multimedia buttons on its second interface, since
   this is a mouse-only receiver these must be forwarded to the mouse child
   device and not to the keyboard child-device (which will not exist)

Link: https://bugzilla.kernel.org/show_bug.cgi?id=203619Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Don't populate the array template  on the stack but instead make it
static. Makes the object code smaller by 10 bytes. Also reformat
the declaration.

Before:
   text	   data	    bss	    dec	    hex	filename
  29376	   9360	    128	  38864	   97d0	drivers/hid/hid-logitech-dj.o

After:
   text	   data	    bss	    dec	    hex	filename
  29270	   9456	    128	  38854	   97c6	drivers/hid/hid-logitech-dj.o

(gcc version 8.3.0, amd64)
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Testing has shown that, as expected, the MX3000 receiver is fully
compatible with the existing 27MHz receiver support in hid-logitech-dj.c.

After this the only, presumably also compatible, receiver id left in
hid-lg.c is the USB_DEVICE_ID_S510_RECEIVER / 0xc50c id. If we can get
someone to confirm that this receiver works with the dj 27Mhz support too,
then the handling of the LG_RDESC and LG_WIRELESS quirks can be removed
from hid-lg.c.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for the HID proxy mode of the Logitech Bluetooth Mini-Receiver
which comes with the Logitech MX5500 keyboard. This receiver works the same
as the Bluetooth Mini-Receiver coming with the MX5000 keyboard and also
presents itself as an USB-hub with 2 separate USB devices for the keyboard
(boot sub-class) interface and for the (boot sub-class) mouse interface.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is a spelling mistake in a hid_err error message, fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

querying_devices is never set, so it can safely be removed.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

For the non DJ receivers, we are going to need to re-use those constants,
better have them properly defined.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Use BIT() macro for RF Report types.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Register 0xB5 should be handled specially no matter what function is
used. This allows to retrieve the serial and the Quad ID from
hid-logitech-hidpp directly.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Malicious USB devices can send bogus reports smaller than the expected
buffer size. Ensure that the length is valid to avoid reading out of
bounds.
Signed-off-by: NPeter Wu <peter@lekensteyn.nl>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The receiver can send HID++ notifications to the DJ devices when the
physical devices are connected/disconnected.
Enable this feature by default.

This command uses a HID++ command instead of a DJ one, so use a direct
call to usbhid instead of using logi_dj_recv_send_report()
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The names of the DJ devices are stored in the receiver. These names
can be retrieved through a HID++ command. However, the protocol says
that you have to ask the receiver for that, not the device iteself.

Introduce a special case in the DJ handling where a device can request
its unifying name, and when such a name is given, forward it also to
the corresponding device.

On the HID++ side, the receiver talks only HID++ 1.0, so we need to
implement this part of the protocol in the module.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID++ is a Logitech-specific protocol for communicating with HID
devices. DJ devices implement HID++, and so we can add the HID++
collection in the report descriptor and forward the incoming
reports from the receiver to the appropriate DJ device.

The same can be done in the other way, if someone calls a
.raw_request(), we can forward it to the correct dj device
by overriding the device_index in the HID++ report.
Signed-off-by: NBenjamin Tisssoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Devices connected through the Logitech Wireless Receiver are HID++ devices.
We can handle them here to benefit from this new module and activate
enhaced support of the various wireless touchpad or mice with touch
sensors on them.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is no point in keeping the header in a separate file, nobody
but hid-logitech-dj should have access to its content.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Several benefits here:
- we can drop the macro is_dj_device: I never been really conviced by
  this macro as we could fall into a null pointer anytime. Anyway time
  showed that this never happened.
- we can simplify the hid driver logitech-djdevice, and make it aware
  of any new receiver VID/PID.
- we can use the Wireless PID of the DJ device as the product id of the
  hid device, this way the sysfs will differentiate between different
  DJ devices.
Signed-off-by: NBenjamin Tisssoires <benjamin.tissoires@redhat.com>
Tested-by: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We can do once the test of the validity of the dj_device, which removes
some duplicated code in various functions.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>