-
-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metaissue: Devices responding with an unknown serial number (UNKWN*) or 0% battery #2122
Comments
I can confirm same behavior on Orochi V2: |
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 |
@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. |
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:
So it seems the daemon does see the serial. Subsequent (frequent) battery notifications display Plugging in only wired or only wireless dongle results in the single device successfully reporting a serial correctly. |
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. |
Linking related PR: #2248 |
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 as0%
. This might be random or consistent.Command timed out
appears in the kernel log:Symptoms
Workaround
razer.conf
if the device is capable of retaining settings across power cycles and you don't dual boot.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
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
.Affected Devices
Related Issues
The text was updated successfully, but these errors were encountered: