[PATCH] HID: logitech-dj: Re-announce connected devices on reset-resume

[PATCH] HID: logitech-dj: Re-announce connected devices on reset-resume

[Mark Pariente]

If a receiver is reset on resume, for example because a USB KVM switch
moved it to another host while the system was suspended, its paired
devices may have reconnected to it while the host was not listening.
The connection notification the receiver queued for the host is lost
in the USB reset, so hid-logitech-hidpp never re-runs its connect
handling for the device.

Devices drop host-configured state when they reconnect, so whatever
hidpp configured on connect is silently lost. The most visible case is
HID++ 2.0 hi-res scrolling: the mouse reverts to low-resolution wheel
reports while hidpp keeps scaling them by the hi-res multiplier, so
scrolling becomes extremely slow (1/15 of the normal speed on an MX
Master 3) until the receiver is replugged or the mouse power cycled.

logi_dj_reset_resume() only switches the receiver back to DJ mode. Also
ask the receiver to re-announce its connected devices with the HID++
"fake device arrival" request, which is already used to query paired
devices on non-DJ receivers, and which Solaar sends to all receivers on
startup. The resulting connect notifications are forwarded to the
existing child devices, whose drivers then reconfigure them.

Reproduced with an MX Master 3 on a Unifying receiver (046d:c52b)
behind a USB KVM switch: suspend, switch the KVM away and back, move
the mouse while the host is still suspended, then resume. Without this
change the wheel stays in low-res mode with the hi-res multiplier
applied; with it, hidpp re-enables hi-res scrolling after resume.

Fixes: 534a7b8e10ec ("HID: Add full support for Logitech Unifying receivers")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203421
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/528
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Mark Pariente <markpariente@gmail.com>
---
Tested on Fedora's 7.2.11 kernel, with this change applied to the v7.2
driver and loaded as an out-of-tree module. Only tested with a Unifying
receiver (046d:c52b) and an MX Master 3; Lightspeed, Nano and 27 MHz
receivers were not tested. Investigation, patch and changelog were
drafted with an LLM coding assistant, then reviewed and tested by me.

 drivers/hid/hid-logitech-dj.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 6e8db01d27ec..cdb20fdc7b21 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -2010,6 +2010,16 @@ static int logi_dj_reset_resume(struct hid_device *hdev)
 		return 0;
 
 	logi_dj_recv_switch_to_dj_mode(djrcv_dev, 0);
+
+	/*
+	 * Paired devices may have reconnected and lost their configuration
+	 * (e.g. hi-res scrolling) while the receiver was unpowered or switched
+	 * away by a KVM. Have the receiver re-announce connected devices so
+	 * the child drivers run their connect handling again.
+	 */
+	if (djrcv_dev->dj_mode && logi_dj_recv_query_hidpp_devices(djrcv_dev))
+		hid_err(hdev, "%s: failed to query connected devices\n", __func__);
+
 	return 0;
 }
 

base-commit: ae6927c533a4454570950125ca8ba909c45f20f9
-- 
2.56.0

Re: [PATCH] HID: logitech-dj: Re-announce connected devices on reset-resume

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] HID: logitech-dj: broken Unifying device enumeration in logi_dj_reset_resume()
--

commit 00da9ba908cab58b8ccc5713c8e413562664314d
Author: Mark Pariente <markpariente@gmail.com>

HID: logitech-dj: Re-announce connected devices on reset-resume

This commit sends a HID++ fake device arrival request in
logi_dj_reset_resume() after switching the receiver back to DJ mode so
that connected devices are re-announced and reconfigured by their child
drivers after a USB reset on resume.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=203421
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/528

> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 6e8db01d27ec0..cdb20fdc7b21e 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -2010,6 +2010,16 @@ static int logi_dj_reset_resume(struct hid_device *hdev)
>  		return 0;
>  
>  	logi_dj_recv_switch_to_dj_mode(djrcv_dev, 0);
> +
> +	/*
> +	 * Paired devices may have reconnected and lost their configuration
> +	 * (e.g. hi-res scrolling) while the receiver was unpowered or switched
> +	 * away by a KVM. Have the receiver re-announce connected devices so
> +	 * the child drivers run their connect handling again.
> +	 */
> +	if (djrcv_dev->dj_mode && logi_dj_recv_query_hidpp_devices(djrcv_dev))
> +		hid_err(hdev, "%s: failed to query connected devices\n", __func__);

[Severity: Medium]
Can calling logi_dj_recv_query_hidpp_devices() unconditionally here break
Unifying (recvr_type_dj) device enumeration when a slot in
djrcv_dev->paired_dj_devices[] is still NULL during logi_dj_reset_resume()?

For example, if logi_dj_probe() ran while a KVM switch was focused on
another host (where commit 36dcfa46852533 leaves dj_mode false and
paired_dj_devices[] unpopulated), or if a new device was paired while
switched away during suspend, paired_dj_devices[device_index] is NULL when
logi_dj_reset_resume() runs.

Normally, logi_dj_recv_query_paired_devices() enumerates recvr_type_dj
receivers using REPORT_TYPE_CMD_GET_PAIRED_DEVICES so that devices are
created from DJ REPORT_TYPE_NOTIF_DEVICE_PAIRED notifications containing
the full 32-bit reports_supported bitmask:

drivers/hid/hid-logitech-dj.c:logi_dj_recv_query_paired_devices() {
	if (djrcv_dev->type != recvr_type_dj) {
		retval = logi_dj_recv_query_hidpp_devices(djrcv_dev);
		goto out;
	}

	dj_report = kzalloc_obj(struct dj_report);
	if (!dj_report)
		return -ENOMEM;
	dj_report->report_id = REPORT_ID_DJ_SHORT;
	dj_report->device_index = HIDPP_RECEIVER_INDEX;
	dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
	...
}

When logi_dj_recv_query_hidpp_devices() sends HIDPP_FAKE_DEVICE_ARRIVAL to
a Unifying receiver instead, the receiver replies with a HID++
REPORT_TYPE_NOTIF_DEVICE_CONNECTED (0x41) notification with protocol type
0x04 (eQUAD step 4 DJ). Because dj_dev is NULL, logi_dj_hidpp_event()
routes this to logi_hidpp_recv_queue_notif() rather than queuing unknown
work to run logi_dj_recv_query_paired_devices():

drivers/hid/hid-logitech-dj.c:logi_dj_hidpp_event() {
	if (dj_dev) {
		logi_dj_recv_forward_report(dj_dev, data, size);
	} else {
		if (hidpp_report->sub_id == REPORT_TYPE_NOTIF_DEVICE_CONNECTED)
			logi_hidpp_recv_queue_notif(hdev, hidpp_report);
		else
			logi_dj_recv_queue_unknown_work(djrcv_dev);
	}
}

That schedules delayedwork_callback() -> logi_hidpp_dev_conn_notif_equad()
-> logi_dj_recv_add_djhid_device():

drivers/hid/hid-logitech-dj.c:logi_hidpp_dev_conn_notif_equad() {
	workitem->type = WORKITEM_TYPE_PAIRED;
	workitem->device_type = hidpp_report->params[HIDPP_PARAM_DEVICE_INFO] &
				HIDPP_DEVICE_TYPE_MASK;
	...
	switch (workitem->device_type) {
	case REPORT_TYPE_KEYBOARD:
		workitem->reports_supported |= STD_KEYBOARD | MULTIMEDIA |
					       POWER_KEYS | MEDIA_CENTER |
					       HIDPP;
		...
		break;
	case REPORT_TYPE_MOUSE:
		workitem->reports_supported |= STD_MOUSE | HIDPP | MULTIMEDIA;
		break;
	}
}

Because logi_hidpp_dev_conn_notif_equad() only populates reports_supported
for REPORT_TYPE_KEYBOARD and REPORT_TYPE_MOUSE, Unifying Trackballs,
Touchpads, Numpads, Presenters, and Remote Controls end up with
reports_supported == 0, causing logi_dj_ll_parse() to pass a 0-byte report
descriptor that hid_parse_collections() rejects with -EINVAL, while
Unifying keyboard+touchpad combos such as the K400 lose STD_MOUSE and
KBD_LEDS.

Furthermore, because paired_dj_devices[device_index] is then populated,
logi_dj_recv_add_djhid_device() will ignore any subsequent DJ
REPORT_TYPE_NOTIF_DEVICE_PAIRED notification for that slot until the
receiver is unplugged:

drivers/hid/hid-logitech-dj.c:logi_dj_recv_add_djhid_device() {
	if (djrcv_dev->paired_dj_devices[device_index]) {
		/* The device is already known. No need to reallocate it. */
		dbg_hid("%s: device is already known\n", __func__);
		return;
	}
	...
}

> +
>  	return 0;
>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261018224627.60328-1-markpariente@gmail.com?part=1

Re: [PATCH] HID: logitech-dj: Re-announce connected devices on reset-resume

[Mark R. Pariente]

> Can calling logi_dj_recv_query_hidpp_devices() unconditionally here break
> Unifying (recvr_type_dj) device enumeration when a slot in
> djrcv_dev->paired_dj_devices[] is still NULL during logi_dj_reset_resume()?

Yes, thanks. For a slot without a known device, logi_dj_hidpp_event()
passes the HID++ 0x41 notification to logi_hidpp_recv_queue_notif(),
which adds the device with reports guessed from the device type, and
the correct DJ pairing notification is then ignored.

This predates this patch: since commit 74808f9115ce ("HID: logitech-dj:
add support for non unifying receivers") the same happens on Unifying
receivers whenever a 0x41 arrives for an unknown slot, e.g. when Solaar
sends the same fake-arrival request on startup or when a device
reconnects. v2 adds a separate patch so that on Unifying receivers such
notifications queue the unknown-device work instead, which enumerates
the devices through DJ notifications, and makes this patch depend on it:

https://lore.kernel.org/linux-input/20261018232654.70571-1-markpariente@gmail.com/T/#u

[PATCH v2 0/2] HID: logitech-dj: Restore device configuration after reset-resume

[Mark Pariente]

When a Unifying receiver is reset on resume, for example because a USB
KVM switch moved it to another host while the system was suspended,
devices that reconnected in the meantime lose their configuration. The
most visible case is HID++ hi-res scrolling, which leaves the wheel
about 15x slower. Patch 2 has the receiver re-announce its connected
devices on reset-resume so that hidpp reconfigures them.

Sashiko pointed out that on Unifying receivers the re-announce can also
hit slots without a known device, and that HID++ connect notifications
then add those devices with an incomplete report descriptor. That can
already happen today, e.g. when Solaar sends the same request on
startup, so patch 1 fixes it separately: on Unifying receivers, unknown
slots are enumerated through DJ notifications instead.

Changes in v2:
- New patch 1/2: don't add devices from HID++ connect notifications on
  Unifying receivers (reported by Sashiko).
- Patch 2/2: code unchanged; the commit message notes the dependency
  on 1/2.
- v1: https://lore.kernel.org/linux-input/20261018224627.60328-1-markpariente@gmail.com/

Testing:
- Both patches applied to the v7.2 driver and loaded as an out-of-tree
  module on Fedora's 7.2.11 kernel, with an MX Master 3 on a Unifying
  receiver (046d:c52b) behind a USB KVM switch. Devices enumerate
  normally, and hi-res scrolling is restored after the reset-resume
  reproducer described in patch 2.
- The unknown-slot case fixed by patch 1 could not be reproduced here,
  because this KVM switch fully disconnects the receiver, so it was
  verified by code inspection only.
- Lightspeed, Nano and 27 MHz receivers were not tested; patch 1 does
  not change their behaviour, and patch 2 sends them the request
  logi_dj_recv_query_paired_devices() already uses for them.
- The investigation, patches and changelogs were drafted with an LLM
  coding assistant, then reviewed and tested by me.

Mark Pariente (2):
  HID: logitech-dj: Don't add Unifying devices from HID++ notifications
  HID: logitech-dj: Re-announce connected devices on reset-resume

 drivers/hid/hid-logitech-dj.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)


base-commit: ae6927c533a4454570950125ca8ba909c45f20f9
-- 
2.56.0

[PATCH v2 1/2] HID: logitech-dj: Don't add Unifying devices from HID++ notifications

[Mark Pariente]

Unifying receivers (recvr_type_dj) announce paired devices through DJ
"device paired" notifications, which carry the full bitmask of reports
the device supports. Before commit 74808f9115ce ("HID: logitech-dj: add
support for non unifying receivers"), HID++ reports for a slot without
a known device were dropped. That commit made HID++ 0x41 "device
connected" notifications for such slots create the device instead, so
that non-DJ receivers, which do not send DJ pairing notifications, can
be supported. This also applies to Unifying receivers.

For Unifying receivers this produces a broken device. The HID++
notification only identifies the device type, and
logi_hidpp_dev_conn_notif_equad() only sets reports for keyboards and
mice. Unifying trackballs, touchpads, numpads and presenters get an
empty report descriptor, so no driver can bind to them, and keyboards
with a built-in touchpad such as the K400 lose their mouse reports.
Since the slot is then populated, the correct DJ pairing notification
for it is ignored until the receiver is unplugged.

This happens whenever such a notification arrives for a slot the driver
does not know about yet, for example after the receiver was probed
while a KVM switch had focus on another host, or after a device was
paired while the receiver was switched away. HID++ connect
notifications are sent when a device reconnects, and when userspace
(e.g. Solaar on startup) asks the receiver to re-announce its devices.

On Unifying receivers, queue the unknown-device work instead, which
enumerates the paired devices through DJ notifications.

Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Mark Pariente <markpariente@gmail.com>
---
 drivers/hid/hid-logitech-dj.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 6e8db01d27ec..383c762c503f 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1766,7 +1766,13 @@ static int logi_dj_hidpp_event(struct hid_device *hdev,
 	if (dj_dev) {
 		logi_dj_recv_forward_report(dj_dev, data, size);
 	} else {
-		if (hidpp_report->sub_id == REPORT_TYPE_NOTIF_DEVICE_CONNECTED)
+		/*
+		 * DJ receivers announce devices through DJ pairing
+		 * notifications, which carry the full list of supported
+		 * reports, so query those instead.
+		 */
+		if (djrcv_dev->type != recvr_type_dj &&
+		    hidpp_report->sub_id == REPORT_TYPE_NOTIF_DEVICE_CONNECTED)
 			logi_hidpp_recv_queue_notif(hdev, hidpp_report);
 		else
 			logi_dj_recv_queue_unknown_work(djrcv_dev);
-- 
2.56.0

[PATCH v2 2/2] HID: logitech-dj: Re-announce connected devices on reset-resume

[Mark Pariente]

If a receiver is reset on resume, for example because a USB KVM switch
moved it to another host while the system was suspended, its paired
devices may have reconnected to it while the host was not listening.
The connection notification the receiver queued for the host is lost
in the USB reset, so hid-logitech-hidpp never re-runs its connect
handling for the device.

Devices drop host-configured state when they reconnect, so whatever
hidpp configured on connect is silently lost. The most visible case is
HID++ 2.0 hi-res scrolling: the mouse reverts to low-resolution wheel
reports while hidpp keeps scaling them by the hi-res multiplier, so
scrolling becomes extremely slow (1/15 of the normal speed on an MX
Master 3) until the receiver is replugged or the mouse power cycled.

logi_dj_reset_resume() only switches the receiver back to DJ mode. Also
ask the receiver to re-announce its connected devices with the HID++
"fake device arrival" request, which is already used to query paired
devices on non-DJ receivers, and which Solaar sends to all receivers on
startup. The resulting connect notifications are forwarded to the
existing child devices, whose drivers then reconfigure them.

On Unifying receivers, slots without a known device are then
enumerated through DJ notifications; this depends on the previous
patch, which stops HID++ connect notifications from adding them.

Reproduced with an MX Master 3 on a Unifying receiver (046d:c52b)
behind a USB KVM switch: suspend, switch the KVM away and back, move
the mouse while the host is still suspended, then resume. Without this
change the wheel stays in low-res mode with the hi-res multiplier
applied; with it, hidpp re-enables hi-res scrolling after resume.

Fixes: 534a7b8e10ec ("HID: Add full support for Logitech Unifying receivers")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203421
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/528
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Mark Pariente <markpariente@gmail.com>
---
 drivers/hid/hid-logitech-dj.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 383c762c503f..4230c47713ee 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -2016,6 +2016,16 @@ static int logi_dj_reset_resume(struct hid_device *hdev)
 		return 0;
 
 	logi_dj_recv_switch_to_dj_mode(djrcv_dev, 0);
+
+	/*
+	 * Paired devices may have reconnected and lost their configuration
+	 * (e.g. hi-res scrolling) while the receiver was unpowered or switched
+	 * away by a KVM. Have the receiver re-announce connected devices so
+	 * the child drivers run their connect handling again.
+	 */
+	if (djrcv_dev->dj_mode && logi_dj_recv_query_hidpp_devices(djrcv_dev))
+		hid_err(hdev, "%s: failed to query connected devices\n", __func__);
+
 	return 0;
 }
 
-- 
2.56.0