Error on first connection after boot

[yursan9]

I have MX Master 3, whenever I connect the device after boot it always output the following message in systemctl status logid:

Error adding device /dev/hidraw2: Invalid function ID

So I try to run logid outside of systemd service, and I see that logid report wrong device name on first connection after reboot:

[INFO] Device Wireless Mouse MWireless M not configured, using default config.
[INFO] Device found: Wireless Mouse MWireless M on /dev/hidraw2:255
[INFO] Device Wireless Mouse MWireless M not configured, using default config.
[INFO] Device found: Wireless Mouse MWireless M on /dev/hidraw2:255
[DEBUG] /dev/hidraw2:255 remappable buttons:
[DEBUG] CID  | reprog? | fn key? | mouse key? | gesture support?
[DEBUG] 0x00 |         |         |            | 
[DEBUG] /dev/hidraw2:255 remappable buttons:
[DEBUG] CID  | reprog? | fn key? | mouse key? | gesture support?
[DEBUG] 0x00 |         |         |            | 
[WARN] Error adding device /dev/hidraw2: Invalid function ID
[WARN] Error adding device /dev/hidraw2: Invalid function ID

To reproduce you need to run logid before connecting (moving) the mouse. If I exit logid, and rerun the program, it will report the correct device name.

I already tried using the latest commit from master, but the problem still persist.

[giorgioskij]

I had the same problem, together with a lot of other people from previous issues apparently. The behaviour I encountered was that after boot sometimes it worked fine, sometimes I had the same error you have, and sometimes I had Error adding device /dev/hidrawX: Invalid argument .

I believe this is an issue in the actual code, as no proposed solution seems to fix it (changing the wants and WantedBy parameters in the systemd unit for example did nothing).

I managed to fix it (apparently, but since it is a random behaviour I can't be 100% sure about it) with a very ugly hack, but I didn't have time to reverse engineer the code any further to find a cleaner solution. It consists in making the action of adding a new device synchronous instead of asynchronous on a separate thread.

For anyone who's comfortable with editing cpp code and recompiling, you can go in the file DeviceMonitor.cpp and do the following:

• After if (action == "add") in line 102 add an open curly brace {
• Comment line 103: task::spawn([this, name=devnode]() {
• Comment lines 113,114,115,116 (this block of code):

}, [name=devnode](std::exception& e){
    logPrintf(WARN, "Error adding device %s: %s",
            name.c_str(), e.what());
});

• Add a closed curly brace } in a new line before or after this last comment

This is not pretty at all and may generate errors, but since systemd automatically handles crashes and restarts the service if it stops, in this case having the program crash if unable to add the device is much better than having it handle the error and continue the execution without adding the device. This way, if unable to add the device, the program crashes and gets restarted by systemd instead of hanging around without having added the device and needing to be restarted manually.

[araujorm]

To me this seems to be 100% reproducible at each reboot. Any more info needed to fix it? Or is there any feasible workaround?

[araujorm]

I decided to compare the modules that are present before and after I turn on the mouse. I found out that (at least on kernel 5.15.12) hid_logitech_hidpp is loaded. I then ensured that hid_logitech_hidpp was always loaded before logid, and that seems to workaround the issue.

For now one can do that via a conf file in /etc/modules-load.d or (as I do at the moment) with a systemd override (sudo systemctl edit logid.service) such as:

[Service]
ExecStartPre=/usr/sbin/modprobe hid_logitech_hidpp || :

Can anyone with the issue try it?

Anyway, this is just a workaround, the issue should be tackled by logid. My guess is that logid starts trying to do certain stuff that depend on that module as soon as it detects de device, and sometimes that happens before the module has had time to fully load (or even while it's still loading). That's why it only happens at boot, and it doesn't always happen (to me it seems to happen mostly when using my laptop on battery, when it is slower, for example)

@PixlOne , could there be anything that could be probed before trying to act on the device, to ensure this does not happen?

[yursan9]

I have my own workaround. I use udev rule to restart logid on udev BIND event. But I can try your solution @araujorm

[Chr1s70ph]

For now one can do that via a conf file in /etc/modules-load.d or (as I do at the moment) with a systemd override (sudo systemctl edit logid.service) such as:

[Service]
ExecStartPre=/usr/sbin/modprobe hid_logitech_hidpp || :

Can anyone with the issue try it?

Editing the override file with sudo systemctl edit logid.service only causes errors (at least for me). I have edited the service file from hand now. I have not yet tested it with a restart, but do people even still run in this issue, or is it just me?

Update (April 4th): This seems to work without any issues now.

[lazarosgogos]

I decided to compare the modules that are present before and after I turn on the mouse. I found out that (at least on kernel 5.15.12) hid_logitech_hidpp is loaded. I then ensured that hid_logitech_hidpp was always loaded before logid, and that seems to workaround the issue.

For now one can do that via a conf file in /etc/modules-load.d or (as I do at the moment) with a systemd override (sudo systemctl edit logid.service) such as:

[Service]
ExecStartPre=/usr/sbin/modprobe hid_logitech_hidpp || :

Can anyone with the issue try it?

Anyway, this is just a workaround, the issue should be tackled by logid. My guess is that logid starts trying to do certain stuff that depend on that module as soon as it detects de device, and sometimes that happens before the module has had time to fully load (or even while it's still loading). That's why it only happens at boot, and it doesn't always happen (to me it seems to happen mostly when using my laptop on battery, when it is slower, for example)

@PixlOne , could there be anything that could be probed before trying to act on the device, to ensure this does not happen?

This fix worked for me! Thanks!!