HID: logitech-hidpp: G920 FF init fails with -110 since "move FF initialization to .input_configured()"

HID: logitech-hidpp: G920 FF init fails with -110 since "move FF initialization to .input_configured()"

[Gideon Heinz]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

On 7.3.1 the Logitech G920 (Xbox One/PC version, 046d:c262) loses all
force feedback except autocenter. dmesg:

  logitech-hidpp-device 0003:046D:C262.0002: Unable to initialize
  force feedback support, errno -110

The error appears before "HID++ 4.2 device connected". fftest shows no
FF capabilities and every effect upload fails with ENOSYS.

Works:
  - stock Arch 7.2.11-arch1-1
  - linux-cachyos-lts 6.18.55-2
  dmesg: "Force feedback support loaded (firmware release 4)" about
  5 ms after "HID++ 4.2 device connected". fftest lists all effect
  types.

Fails:
  - linux-cachyos 7.3.1-1
  Reproducible on cold boot, on replug and on module reload, with no
  other software touching the device.

I captured usbmon traffic for both cases (bus 3, captures attached).
The wheel behaves the same in both. The request 11ff0001 8123 and the
reply 12ff0001 0b are byte-identical and answered in 3-4 ms. The
difference is on the host side:

  working: the 0x8123 lookup is sent once, after the protocol ping and
           the earlier feature lookups. The driver then talks to
           feature index 0x0b (get info, reset all, get aperture, get
           global gains, download effect) and FF initializes.
  broken:  the 0x8123 lookup is sent before the protocol ping and
           retried 3 times about 5.1 s apart. The driver never sends
           anything to index 0x0b. The ping and the rest of the init
           only run afterwards.

This looks like a regression from commit
544315e401727364f7ce3ba771a36f7dc24ba6c4 ("HID:
logitech-hidpp: move FF initialization to .input_configured()",
2026-08-14). It moves g920_get_config()/hidpp_ff_init() from
hidpp_probe(), where they ran after schedule_work()/flush_work() of the
connect event, into hidpp_input_configured(), which is called from
hid_hw_start() before that work runs. That matches the capture: the
wheel answers the 0x8123 lookup normally, the driver doesn't act on the
reply and gives up after 3 tries with -ETIMEDOUT. I haven't tested a
revert. Happy to test patches.

[-- Attachment #2: FFB_G920_WORKING.pcapng --]
[-- Type: application/x-pcapng, Size: 30296 bytes --]

[-- Attachment #3: FFB_G920_BROKEN.pcapng --]
[-- Type: application/x-pcapng, Size: 29248 bytes --]

Re: HID: logitech-hidpp: G920 FF init fails with -110 since "move FF initialization to .input_configured()"

[Dmitry Torokhov]

Hi Gideon,

On Mon, Nov 02, 2026 at 02:23:18PM +0100, Gideon Heinz wrote:
> This looks like a regression from commit
> 544315e401727364f7ce3ba771a36f7dc24ba6c4 ("HID:
> logitech-hidpp: move FF initialization to .input_configured()",
> 2026-08-14). It moves g920_get_config()/hidpp_ff_init() from
> hidpp_probe(), where they ran after schedule_work()/flush_work() of the
> connect event, into hidpp_input_configured(), which is called from
> hid_hw_start() before that work runs. That matches the capture: the
> wheel answers the 0x8123 lookup normally, the driver doesn't act on the
> reply and gives up after 3 tries with -ETIMEDOUT. I haven't tested a
> revert. Happy to test patches.

Thank you for the report and the usbmon captures.

The issue is that hidpp_probe() calls hid_device_io_stop() right before
hid_connect(), so incoming HID reports are dropped with -EBUSY while
hidpp_input_configured() runs g920_get_config(). Re-enabling I/O around
g920_get_config() (matching what hid-pidff and hid-haptic do during
hid_connect()) should fix it.

Could you please give the patch below a try and let me know if it
resolves the issue?

Thanks.

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 9646380febac..6b1f55483385 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4098,7 +4098,9 @@ static int hidpp_input_configured(struct hid_device *hdev, struct hid_input *hid
 		if (!list_is_first(&hidinput->list, &hdev->inputs))
 			return 0;
 
+		hid_device_io_start(hdev);
 		ret = g920_get_config(hidpp, &data);
+		hid_device_io_stop(hdev);
 		if (!ret)
 			ret = hidpp_ff_init(hidpp, &data);
 

-- 
Dmitry

Re: HID: logitech-hidpp: G920 FF init fails with -110 since "move FF initialization to .input_configured()"

[Dmitry Torokhov]

Hi Gideon,

On Wed, Nov 04, 2026 at 09:32:04PM +0100, Gideon Heinz wrote:
> The init failure is fixed:
>
>   logitech-hidpp-device 0003:046D:C262.000B: Force feedback support
>   loaded (firmware release 4).
>   logitech-hidpp-device 0003:046D:C262.000B: HID++ 4.2 device connected.
>
> No -110 anymore, and fftest lists all effect types with uploads OK.
>
> One separate observation: when I play the constant effect in fftest,
> dmesg shows "Force feedback command queue contains 20 commands, causing
> substantial delays!" followed by "Failed to send command to device!".
> This doesn't happen on stock Arch 7.2.11 (no patch, old init order).
> I haven't determined whether it's related to the patch, to other 7.3
> changes, or specific to the CachyOS kernel build. I can capture usbmon
> of it if that helps.

Thank you for testing!

Yes, a usbmon capture along with matching dmesg output would be very
helpful. Also, when you played the constant effect, did the wheel
actually produce any force (perhaps after a delay), or was force feedback
completely unresponsive?

Note that hid-logitech-hidpp queues all FF commands (gain, effect
uploads, playback, erase-on-close, and sysfs "range" writes) onto an
asynchronous workqueue, so fftest prints "OK" on upload even if the
worker thread is stalled. If anything queues a command while the input
device is closed and the interrupt IN URB is not running (for instance
cleanup commands from closing an earlier fftest run within ~15 seconds,
or a udev rule writing to the "range" sysfs attribute after probe), the
worker gets stuck waiting 3 x 5s for a reply and later commands pile up
behind it. On the other hand, if commands are timing out while fftest is
the first user and keeping the device open, the inverted init order
(hidpp_connect_event() now running after g920_get_config()) or another
7.3 change may be upsetting the device or endpoint.

If you can start usbmon before loading the patched module (or plugging
the wheel in), wait ~20 seconds after probe settles, and then run fftest
once to trigger the constant effect before exiting, that should tell us
immediately which case it is.

Thanks.

-- 
Dmitry

Re: HID: logitech-hidpp: G920 FF init fails with -110 since "move FF initialization to .input_configured()"

[Dmitry Torokhov]

Hi Gideon,

On Fri, Nov 06, 2026 at 07:24:03AM +0100, Gideon Heinz wrote:
> Short version: your patch
> fixes the 7.3.1 init failure, and the runtime errors I saw afterwards are
> unrelated to it.
>
> To your question: the constant effect did produce force, a slow pull to
> the left for several seconds, then it stopped.
[...]
> So this is your first case (commands queued after the input device was
> closed), not the init order. Everything while fftest held the device open
> was answered normally. The init order is inverted as you expected (the
> ping comes after FF init), but it caused no problem here.
>
> I then repeated the same fftest run (play constant, exit) on stock Arch
> 7.2.11-arch1-1 with the unpatched driver, with usbmon this time (capture
> attached, wheel is dev 7 on bus 3). The same thing happens.
[...]
> So the exit-time behaviour predates
> 7.3 and isn't caused by your patch. The init order on 7.2.11 is the old
> one (ping before FF init), so the capture pair also shows the inversion.
>
> Tested-by: Gideon Heinz <gideonheinz02@gmail.com>

Thank you very much for collecting both captures and comparing against
7.2.11! That confirms both that querying G920 FF ahead of the protocol
ping during probe works cleanly on the wheel, and that the exit-time
errors are the pre-existing race where closing the evdev descriptor
stops the USB interrupt IN URB while the async FF workqueue is still
draining stop/erase commands (with each command retrying 3 x 5 seconds
while nobody is listening for replies).

While looking through hid-logitech-hidpp I ran into a handful of other
bugs and lifetime issues around G920 force feedback and device teardown,
so I am about to send out an 18-patch series with you on the To: list.
It starts with fixes marked for 7.3 and stable (including the minimal
init fix carrying your Tested-by, draining the FF workqueue before
closing the HID transport on normal input close, switching FF work item
allocation to GFP_ATOMIC, and fixing an off-by-one on hardware slot 64),
followed by the probe-time G920 FF initialization rework,
disconnect/unbind teardown fixes, and general driver cleanups.

Not everything is fixed in this first batch yet - normal fftest exit
should drain cleanly now before the IN URB is stopped, but stalls on
close or teardown can still happen when device I/O is already inactive
(for instance on driver unbind with loaded effects, or writing the range
sysfs attribute while the input device is closed) because the 3 x 5s
retry loop on timeouts and synchronous FF upload/erase handling still
need follow-up work.

When you have a chance, could you please give the series a spin on your
G920, and if anything misbehaves or regresses, ideally bisect within the
series to pinpoint which patch broke it?

Thanks.

-- 
Dmitry