Some K95 Non-RGB feedback

[hecal3]

Hey, I just tried the k95 non-RGB on Archlinux. k95test branch.

First of all, the GUI does not work: At the first run:

libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Scanning  "[home]/ckb/bin/ckb-animations/ckb-gradient"
Scanning  "[home]/ckb/bin/ckb-animations/ckb-pinwheel"
Scanning  "[home]/ckb/bin/ckb-animations/ckb-rain"
Scanning  "[home]/ckb/bin/ckb-animations/ckb-random"
Scanning  "[home]/ckb/bin/ckb-animations/ckb-ripple"
Scanning  "[home]/ckb/bin/ckb-animations/ckb-wave"
Starting  "[home]/ckb/bin/ckb-animations/ckb-wave"
QThread: Destroyed while thread is still running

When I tried starting it again the window did appear. It was unresponsive however, with the following error being spammed:

Starting "[home]/ckb/bin/ckb-animation/ckb-wave"
QThread: Destroyed while thread is still running

The daemon itself seems to be working mostly:

• bind and macro for normal keys
• ion, ioff, iauto
• get name, profileid, layout, etc...

What did not work:

• rgb on/off
• any of the hw- commands (get :hwid, hwload, hwsave, etc...)

I was also unable to bind and macro the G-Keys, when there is a profile stored on the keyboard itself. Only when I reset the keyboard storage with a empty default profle on a widows machine, the G-Keys started working.

I am not sure what the mode switch command is supposed to do. I played around with it for a while but it didn't make any kind of difference as fas as I can tell.

If there is anything else you would like me to try please let me know.

[ccMSC]

It makes sense that the RGB and HW commands wouldn't work, since those are for the RGB boards only. The mode command accomplishes the same thing as M1-M3 on the keyboard.

I think I fixed the GUI being non-responsive. Check out the latest commit and see if it's working now.

Question: would you be willing to run Windows in a virtual machine and provide me with USB data captures for the keyboard? The RGB K95 can't store bindings on hardware at all, so I have no idea how to save/load macros from the board, or how to talk it out of hardware playback so that the keys are recognized properly.

[hecal3]

The new commit fixed the GUI.

I just spend some time piecing together this virtual machine setup. For now I can give you this:

I briefly tried saving macros to the keyboard as well. Naturally the messages are a bit more voluminous. I have found no GUI option to load from the keyboard. It might not even be possible. I will look into more detail tomorrow. Do you have anything you'd like to see in particular?

[ccMSC]

Wouldn't surprise me too much if there's no hardware load. I guess you could try moving/deleting the application data and see if it tries to pull it from the keyboard.

The latest k95test commit should disable hardware playback. Is "hardware playback off" identical to "switch to profile 1" or are the other parameters different? could you send me the data for profiles 2 and 3 as well?

[hecal3]

Yes, hardware playback and switch profile are the same. Whenever you switch the profile in Windows software, it will send the current state of hardware playback to the keyboard.

The new commit works fine. It will disable hardware playback on start, and reanable it when it's closed.

Saving full profiles on the board seems a bit more complicated unfortunatly. I have uploaded some commented Wireshark logs: https://drive.google.com/folderview?id=0B5ZVI5rrUZK1UUx5M3Nab09ROHM&usp=sharing

The overall process is always the following:

- Send hardware playback on
- send some control package
- send the layout for M1
- send the actual keys for M1
- send delimiter
- layout M2
- keys M2
- delimiter
- layout M3
- keys M3
- delimiter
- control package
- hardware playback off

The delimiter and the control package are always the same, the actual data is obviously not. So far I have figured out how to store individual keybinds to the G-Keys. I've outlined it briefly in the layoutkeys file above.

[ccMSC]

So it has to send two separate messages, one just to tell it that the G keys are being reprogrammed and then another to set the actual key codes? o_O corsair wat

k95test_7 should now set the M1-M3 lights when you switch modes via software. Am I correct in thinking that the Windows software doesn't allow you to create more than 3 modes? Right now I just made the lights wrap around, so mode 4 -> M1, mode 5 -> M2, mode 6 -> M3, mode 7 -> M1 again, etc. If there's a way to turn them all off that would be preferable.

The standard key bindings look pretty straightforward to implement. Let me know if you make any progress on decoding the macro format. I can give you some suggestions for what to put in them if it would help.