Ckb-next: Windows Support/Release

[ghost]

• Read the wiki.
• Search in open and closed Issues.

---

Feature request

What would you like it to do instead?

I would love for ckb-next to have a release for Windows aswell. While that might seem redundant, having an open source lightweight alternative to the rather heavy/buggy proprietary CUE-software would be an awesome thing.
I am not sure how difficult it would be to make a Windows version (toolkit compatability etc.), so hope me asking doesn't seem too rude.
Has this been on the radar of anyone?

Any other notes & comments?

Thank you so much for the great work you all do on this project!

[OvermindDL1]

Making USB drivers in Windows is a whole unique world of pain that the devs here I highly doubt would want to touch. Though if PR's were submitted, who knows?

[tatokis]

I am not sure how difficult it would be to make a Windows version (toolkit compatability etc.), so hope me asking doesn't seem too rude.

Depends on how you see it. Some parts are easy, others are pretty painful.

Making USB drivers in Windows is a whole unique world of pain that the devs here I highly doubt would want to touch.

You'd be correct. That said, I felt like trying to see how difficult it would be to port it.

I'll eventually put up a branch with the work, as I don't see myself ever finishing it, or getting it to a working state. So if anyone ever wants to pick up, they will be able to do so.

Don't expect anything to come out of this, as it requires rewrite of some major parts of the daemon, such as the way it communicates with the GUI.
We also need a kernel input driver (maybe UMDF?).

Might be worth trying to see if we can get this to compile
https://github.com/Microsoft/Windows-driver-samples/tree/master/hid/vhidmini2

We can use zadig/zadic with libusb to get exclusive raw access to the devices, so at least we won't have the same headaches as we do on macOS.

[tatokis]

This was probably not closed intentionally, but I should make a quick update on this.

I haven't worked on it for a bit, but it reached the point where the daemon can run, the GUI can send RGB data to it, talk to usb devices (through libusbk), and send mouse movements to the OS through vmulti.

Code is in the windows branch and can be compiled with qt-creator installed under mingw-w64 with msys2.

[DewmBot]

Sorry for the bump, but even if this can work on a basic level I'd be more than happy. Having the option to simply just change the color of my keyboard without running iCue would be a godsend.

As of right now; anything that polls for input devices either freezes and locks up or crashes immediately when iCue is open. Nothing seems to fix it and it seems to be a consistent issue that never gets fixed. (even the old CUE had such an issue)

[tatokis]

Don't worry about it. I'll see if I can get keyboard input working relatively easily, because at the moment you can only change the lighting without any input, and that makes the keyboard pretty useless.
I haven't touched this in a while, so it probably needs some fixes due to changes done in 0.4.0.