Significant regression with Corsair k100

[D3SL]

Expected Behaviour

Aurora should start with windows, a longstanding bug causes the K100 to go blank, and when the device is restarted in Aurora's "Device Manager" tab everything with pretty much immediately begin working.

Actual Behaviour

When the device is restarted in Aurora's "Device Manager" the app sometimes hangs for several seconds, sometimes saying there's an error with the device and other times starting. Once started lighting profiles are unreliable and incomplete, the K100's peripheral LEDs don't work anymore, things such as an overlay when CTRL is pressed may get "stuck" fairly frequently with no discernible pattern, and randomly the lighting goes completely haywire.

example: My default desktop profile has the classic slow RGB rainbow. It's working right now as I type this in github, but the moment I click on Aurora's window all lighting breaks. The macro keys remain frozen in whatever color they had last, the media and extra keys/lights like the wheel and WIN-lock go blank, and the stock QWERTY/F1-12/Numpad keys begin strobing random colors at high speed with no pattern.

Reproduction steps

Update to V168 or higher (currently using v169).
2023-08-08 10.22.39.log

Frequency

All the time

Aurora Version:

V169

Previously an Issue?

V168

[Aytackydln]

Does this only happen if Corsair device is enabled at launch?

Can you try disabling it and enabling after launch?

[D3SL]

Didn't seem to make a difference either way, I had to disable and re-enable it just to get it to work briefly in the first place and then it quickly went to the strobe glitch.

[Aytackydln]

Logs are filled with OpenRGB connection errors. Can you try disabling it if you're not using it?

[D3SL]

You removed the working corsair device in V168. If I disable the OpenRGB device there won't be any errors, but there also won't be any lighting at all for the K100 anymore either.

[Aytackydln]

It was unnecessary because the current rgb.net implementation uses the same sdk as the regular one before.

About OpenRGB... I thought that wasn't installed. I think the problem is two controllers are trying to control the device.

What if you only used OpenRGB?

[D3SL]

I had a dyslexic moment and got OpenRGB and RGB.net mixed up. I don't use OpenRGB for anything, the program's never even running so it couldn't be what's affecting anything. It also doesn't cause any problems in V166.

[Aytackydln]

can you check latest version?

https://github.com/Aurora-RGB/Aurora/releases

[D3SL]

It works without needing to force-restart the device and doesn't break my mouse, but it still has the issue that none of the outer rim lights on my keyboard work even though they show up on the simulator.

[Aytackydln]

Alright, for now you can remap them in the settings.

Also, can you tell me led names and their locations there? I will change default layout so it won't need remapping

[D3SL]

Finally had a chance to get to this. The key IDs are wrong and skip from LedStripe19 straight to LedStripe21, so at the moment 1-11 are the left-bottom to left-top, 12-34 are the top-left to top-right, 35-45 are the right-top to right-bottom. It should be 1-11 on the left, 12-33 on the top, 34-44 on the right.

I also found the wheel is mismapped. The wheel is numbered Wheel1-8 starting at 12:00 going clockwise, and in Aurora those are Key IDs Custom5-12. Currently a few are mapped out of order and the wheel's center doesn't appear to have a Key ID to map to at all.

Semi-related it'd be a really nice QOL feature if mousing over things popped up the name of the light and what (if anything) it was currently mapped to.

[D3SL]

Slight bump for the edge lighting, and a note that in V194 there's still semi-regular issues with this keyboard reporting a failure involving the device. Particularly when waking the computer up.