Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery

[lah7]

There are few identical issues popping up with the same root problem. This issue will link them.

Cause

The daemon responds with a serial number like UNKWN00000000XXXX or battery status as 0%. This might be random or consistent.

Command timed out appears in the kernel log:

dmesg | grep razer

Symptoms

• After reboot, persistent settings are not applied - like poll rate, brightness or effect.
• Battery notification incorrectly says the device reached 0% battery.
• Battery % is incorrect in applications.
• Rarely, some items (e.g. DPI) reports the wrong value.

Workaround

1. Write a script that runs at logon to apply your desired settings.
2. Turn off persistence in razer.conf if the device is capable of retaining settings across power cycles and you don't dual boot.
3. Restart openrazer-daemon and any open applications connected to the daemon.

Solution

This happens because the device didn't send a valid response, so the driver generates a dummy serial to prevent applications and scripts from crashing. It's theortically possible that a handful of devices are incapable of reading their serial number, or are unreadable under certain connections (e.g. wired vs wireless)

In future, the driver will introduce a retry mechanism to send the request again.

To check

cat /sys/bus/hid/drivers/razer*/*1532*/device_serial

Serials should not start with UNKWN. If you're affected, please let us know which devices are intermittent or always wrong - just in case there is a problem with that device's implementation.

There is one Razer device with a serial that literally said As printed in the D cover.

• Handle "Default string" serial number (Razer Blade) #192

Affected Devices

• DeathAdder V2 X Hyperspeed
  • Settings won't apply correctly after reboot #2048
• Viper Ultimate
  • saving issue #2076
• Naga Pro
  • Razer Naga Pro (Wired) shows up twice #2101
  • Device battery reported as 0% (Naga Pro, DSV2PTKL, Pro Click) #2109
• Viper V2 Pro
  • Viper V2 Pro Polling rate reverting on reboot polychromatic/polychromatic#493
• Orochi V2
• DeathAdder V3 Pro

Related Issues

• Persistence issue: Devices spontaneously reset to Spectrum if serial is incomplete #1367

[h0x32]

I can confirm same behavior on Orochi V2:
1532:0094 Razer USA, Ltd Orochi V2

[Adam-Englebright]

I had this issue using the DeathAdder V3 Pro (Wireless). However, for me the issue only occurs if I don't touch my mouse during boot up (so it is sleeping), then move the mouse once I am at the desktop. If I continually move my mouse during boot up, so that it tries to connect to the USB dongle as soon as possible, I seem to avoid this issue.

Debian Bookworm using the openrazer-meta package from the stable repo, version 3.5.1+dfsg-2.

[z3ntu]

@Adam-Englebright That's some interesting info, I wonder if we can somehow check if the device is responding during init (or asleep) and delay initialization until we have connection.

[pdf]

Device: 0003:1532 RazerViperUltimateWireless / RazerViperUltimateWired

When both the wireless dongle and the wired cable are connected (e.g. when charging), only one of the devices reports a serial number via sysfs, the other is blank.

When plugging in the second device, the daemon throws an exception:

openrazer-daemon[1423]: Exception in thread Thread-14 (_collecting_udev_method):
openrazer-daemon[1423]: Traceback (most recent call last):
openrazer-daemon[1423]:   File "/usr/lib/python3.11/threading.py", line 1045, in _bootstrap_inner
openrazer-daemon[1423]:     self.run()
openrazer-daemon[1423]:   File "/usr/lib/python3.11/threading.py", line 982, in run
openrazer-daemon[1423]:     self._target(*self._args, **self._kwargs)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/daemon.py", line 605, in _collecting_udev_method
openrazer-daemon[1423]:     self._add_device(d)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/daemon.py", line 530, in _add_device
openrazer-daemon[1423]:     razer_device = device_class(device_path=sys_path, device_number=device_number, config=self._config,
openrazer-daemon[1423]:                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/hardware/device_base.py", line 136, in __init__
openrazer-daemon[1423]:     super().__init__(object_path)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/openrazer_daemon/dbus_services/service.py", line 57, in __init__
openrazer-daemon[1423]:     self.add_to_connection(bus, object_path)
openrazer-daemon[1423]:   File "/usr/lib/python3.11/site-packages/dbus/service.py", line 579, in add_to_connection
openrazer-daemon[1423]:     connection._register_object_path(path, self._message_cb,
openrazer-daemon[1423]: KeyError: "Can't register the object-path handler for '/org/razer/device/PM1234H12345678': there is already a handler"

So it seems the daemon does see the serial.

Subsequent (frequent) battery notifications display 0% , with timeouts in dmesg.

Plugging in only wired or only wireless dongle results in the single device successfully reporting a serial correctly.

[z3ntu]

openrazer-daemon[1423]: KeyError: "Can't register the object-path handler for '/org/razer/device/PM1234H12345678': there is already a handler"

We don't support connecting a device two times, as you can see it breaks some assumptions OpenRazer has. We probably need to fix this in the future but it's not a simple fix as everything relies on the serial number being unique.

[NeilGirdhar]

Linking related PR: #2248