flozz / rivalcfg

CLI tool and Python library to configure SteelSeries gaming mice
https://flozz.github.io/rivalcfg/
Do What The F*ck You Want To Public License
801 stars 66 forks source link

"An error occured when updating mouse settings!" on Windows #114

Open lf- opened 4 years ago

lf- commented 4 years ago

Hi! After considering whether it was a good idea to install a 150MB mouse driver to disable a distracting lighting effect and deciding "probably not", I installed rivalcfg. It appears to be detecting my Rival 300 mouse correctly on my Windows 10 2004 computer with Python 3.7, but when I try to update the colour with rivalcfg.exe -c d11bd6 -C d11bd6 , I get "An error occured when updating mouse settings!".

How can I get more details than this error gives so I can understand what the issue might be?

lf- commented 4 years ago

I have just plugged it into my Linux computer and rivalcfg changed the settings perfectly, so this is evidently a platform-specific problem. I have also tried in a console as administrator on my Windows computer to no avail.

flozz commented 4 years ago

Hello,

Are you using an administrator account or a standard user account on your Windows? I will try to reproduce the issue :)

lf- commented 4 years ago

I am using an administrator account and UAC is on. But I was running it from an administrator prompt to no avail.

flozz commented 4 years ago

I tried to reproduce your issue:

Each time I installed rivalcfg in a Python Virtualenv with pip.

I Do not know what happen on your machine :(


Also, I saw that you used this command:

rivalcfg.exe -c d11bd6 -C d11bd6

How did you obtained this .exe? How did you installed rivalcfg?

lf- commented 4 years ago

It's a pip .exe. I can try running with python -m rivalcfg in combination with a virtualenv.

On Sat., May 23, 2020, 5:05 a.m. Fabien LOISON, notifications@github.com wrote:

I tried to reproduce your issue:

  • on a Windows VM: it worked
  • on an other VM with a fresh Windows install: it also worked
  • on a non-administrator account on a fresh Windows install: it worked again.

Each time I installed rivalcfg in a Python Virtualenv with pip.

I Do not know what happen on your machine :(

Also, I saw that you used this command:

rivalcfg.exe -c d11bd6 -C d11bd6

How did you obtained this .exe? How did you installed rivalcfg?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/flozz/rivalcfg/issues/114#issuecomment-633038356, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSYHKC6SGAQT6YFY42BL5LRS63W5ANCNFSM4NID7U4A .

flozz commented 4 years ago

Rivalcfg 4.0 was now released. Can you retry with this new version?

lf- commented 4 years ago

I regret to report that while the error message has been resolved, the tool is still not setting the colour successfully or reporting any error. This is on a fresh Windows install this time ;-)

flozz commented 4 years ago

That's annoying :(

I am not able to reproduce, at least with my Rival 100 in a VM:

Capture d’écran de 2020-08-25 13-41-42

I do not know what can causes your issue.

lf- commented 4 years ago

SteelSeries engine not installed unless Windows did it on its own.

Yeah I can capture some packets, how do I do that on Windows?

lf- commented 4 years ago

I have attempted to capture packets using USBPcap but Wireshark is basically just giving me a bunch of hex for the packets, not even decoding them as HID or anything. So I have 3MB of what appears to be completely opaque hex captured over a couple of seconds, with also opaque device names. I feel like I'm probably doing some part of this wrong.

lf- commented 4 years ago

image

I got a quieter capture. Start capture; [alt-tab] [enter] on rivalcfg -c black -C black [alt-tab] [C-c]. (my keyboard is on the same hub). Should be possible to open it in Wireshark.

I got it down to 7kb (gzipped because github sucks): z.pcap.gz

Let me know if this is usable.

flozz commented 4 years ago

Oh I see you have a Rival 310 not a Rival 300 :)

The strange thing is that there seems to be no color packet at all in the capture, BUT there is the save command that is sent at the end:

Capture d’écran de 2020-08-26 13-33-56

The difference between "color" and "save" commands on this mouse is that the "color" command uses a FEATURE_REPORT whereas the "save" command uses a simple OUTPUT_REPORT... Maybe we found a bug here!

Can you try to change the DPI setting (that use an OUTPUT_REPORT, like the "save" command) to see if it work?

Anyway, I do not have any mouse that use FEATURE_REPORT yet, but by chance SteelSeries will send me a Sensei 310 soon, so I will be able to test! :D

flozz commented 4 years ago

Ok, confirmed! Now I have a Sensei 310, I am able to reproduce the bug.

Every commands works but colors. They are not sent on the USB bus at all. No idea why nor how to fix it, but at least, I can investigate! :)

virrim commented 4 years ago

Having this issue as well with my Rival 310 on Win10. Glad to see I'm not the only one but annoying nonetheless. Hope it's an easy fix!

flozz commented 4 years ago

Sadly, it will not be easy to fix...

I do not understand why hid.dll (the Windows backend used by hidapi) returns an error when we try to send feature reports to the devices :(

Maybe we will have to implement the libusb backend on Windows to make it work :/

FHeilmann commented 4 years ago

@flozz any update on this? I'm struggling with the same issue on Windows 10 with my sensei 310.

flozz commented 4 years ago

Hello,

I made a pause on this project by the end of September, but I am back on it since this week.

I will try to fix this but it will not be easy, I am not able to figure out what is the problem with hid.dll :(

FHeilmann commented 4 years ago

I'm currently battling a similar issue over at the OpenRGB project trying to control my steelseries apex M750. SteelSeries Engine can control the keyboard just fine, but anything I try to send from OpenRGB just disappears into the aether. Maybe the two issues are connected somehow.

edit: as it so happens that issue was just "solved". I was talking to the wrong interface (2 is the correct one instead of 0). Maybe that's the issue here too? All other mice (which are supported both by rivalcfg and openrgb) use interface 0 (which is probably the default)