CKB - New Feature Requests

[mattanger]

For anyone who wants to suggest new features for the ckb driver. Please leave a reasonably detailed description of your idea and reasoning as to why it should be added. Thanks!

[frickler24]

Hi @mattanger, today I read that you have opened that clone. Thank you for that!
My recent development on the ckb were the macro definitions in the client and server.
They are integrated in your version, because they had been promoted to the testing-stage in the ccMSC-branches.
In combination with an other programmer, who added variable delays between keystrokes in the daemon (as I see now, you integrated it as ccMSC/ckb#437), I implemented a GUI for that. My pull-request was too late - ccMSC was offline at the time.

Here is a screen shot, the difference is just the green radio-buttons letf hand.
When recording a G-Key-macro, the delay between keystrokes while typing is stored.
You have three choices afterwards: Replaying the macro as typed with the delays recorded,
playing the macro without any delay or playing the macro with default-delays as you can select in your current implementation.

So my two questions: Are you interested in that development?
If yes, can you give me a hint how to deal this with git, because the PullReq was relative to the git-history from ccMSC?

Another point: I'm german speaker (so my bad english). Are you interested in a german version of the GUI and the README.md?

best regards, Lutz

[mattanger]

Hi @frickler24, thanks for getting in touch. I think that this improvement is definitely something that we'd like to see in this version. My keyboard doesn't have G-Keys, and I, personally, haven't run any to any issues in regards to macro's. I do remember seeing that thread where some of the issues related to this were discussed, and I see how why it may be needed.

I could be missing something, I also haven't really looked either, but are these GUI changes in ccMSC/ckb#437? Because we haven't merged that PR in yet. Otherwise, the best thing to do is to get your repo up to date with ours, and then submit a PR for your GUI changes.

As to German translations, I'm not opposed to making ckb-next as accessible as possible if you'd like to make a translation.

[tatokis]

Regarding the best thing to do is to get your repo up to date with ours, I would like to add that you should base it on our master, and not the testing branch, as that is currently being left behind until we can get to a stable state.

[randominternetuser]

Hello,

I'd also like to see support for Corsair Void headsets, they have lighting and several buttons I would like to work under linux. Currently there is very limited support for these headsets under Linux.

Thanks.

[batchpert]

Hi regarding the macros with delays between them. I really like that as for certain games if you have text within your macro then it doesn't normally pick up all the text before it registers the enter key. I don't have windows but I'm guessing that this feature is available in that and i know that it is available for logitech keyboards. So it would be great if at some point this could be added!!!

[batchpert]

Also a new feature that i was a thinking about was like a sort of snake (sorry was the best way i could think of describing it). But as in you set like a pattern say going around the letter keys and then it follows it at a constant speed. I know this is quite similar to the pin wheel but that doesn't go at a constant speed and wouldn't be able to follow something that doesn't just go in a circle/oval shape without lighting up more than one key.

[Camoleopard]

Hi,
I would love to see support for newer devices such as the Corsair Harpoon RGB Mouse, the void headsets, and any other devices not currently supported.

[SyntaxualSugar]

I would love to be able to use a combination of mouse buttons for a command. For instance: One the m65 pro we have a "sniping" button the side. I would like to use that and the two top buttons to change dpi. That, combined with having the "sniping" button set to its default function, and the top buttons set to window spread and workspace spread would be a wet dream.

[frickler24]

@FlutterFox That's quite difficult.
First we need some more coding for macro handling. I tried to use a M65 with its buttons to send keyboard-macros, but I could not find a clean way to implement it because of the internal structure of the client software (device handling).
But I still think about it...

[slugger7]

Hi
First of all thank you for forking and continuing with this amazing project that personally works better than the Windows version provided by Corsair.
Something that v2 of CUE has is that you can layer your effects to apply the effects to certain buttons but not others. Almost like CSS (for clarification Cascading Style Sheets) where changes where there is a rule for a style on an object but it can later be override with another CSS file.
So in the Animation section: the order in which the animations appear matter. (Top layer will override all other layers when active (type lighting over a rainbow pattern for instance currently does not work or I am not using it correctly)

[slugger7]

@FlutterFox I did something similar to that using a different function that basically creates a macro that is then mapped as a bash script to that button. I think the program that i used was xdotool just go have a read on what that does. Best of luck if you still battle then give me a PM and ill give you a more in depth guide once I figure out what i did way back when.

[tatokis]

If I understood correctly, I think what you're looking for is the different blending modes.

[tatokis]

Forgot to add, you can select which keys an animation applies to, by selecting the keys from the keyboard displayed in the UI.

[slugger7]

@tatokis I think I have figured it out thank you

[slugger7]

This might not be possible because of hardware support across Mac and Linux but it could be cool to have a sound layer that changes the colour of the keys based on the sound being played from your speakers. I think this is possible on the windows software and I have heard of people adding this mod on CKB for their machines only but just thought it could be cool if it was possible

[ghost]

I bought a K70 RapidFire (non-RGB) and after fidgeting around with things to actually get it to detect the keyboard, I found this software to be much nicer than even the official utility from Corsair on Windows. It took a little getting used to, but once I had the hang of it I was able to get my keyboard to behave EXACTLY the way I wanted it too, which is more than I can say for Corsair's utility, which got me close, but not quite where I wanted to be.

So, my question is, are there any chances of efforts to port this to Windows so we can use it instead of Corsair's utility?

[ghost]

@ColtonDRG thanks for the question.

I don't think it will be ever ported on Windows because:

• It's already hard to maintain the support for both Linux & Mac. These systems have less in common than you might think, especially in userspace. We are now considering a big refactoring to address this problem. There are a lot of *_linux* and *_mac* files in the source tree that do roughly the same but are still very different. And we want it to be more cross-platform and are looking for the solution. However, the chances are we won't find such.
• This project was created as a fork of ckb, and ckb was created as a software that tries to address some of the CUE's features on other platforms, so there's neither strong argument as for why should this appear on Windows, nor it is logical.
• There could be a conflict of interests between Corsair and us on Windows. In theory they could shut down this repository and the project at any time if they would want to. But unless we're trying to do something that they do (read: providing Windows support), we should be fine. They do not support any software features neither on Linux nor on Mac, just a basic hardware one. But we didn't get any bad message from them either regarding this project. So, at least Corsair doesn't get in the way of ckb-next.
• And, last but not least, currently none of the devs can just sit down and write Windows-related code because of the lack of knowledge on Windows API (excuse me, the dev, if you really do, these are just my considerations).

[ghost]

I understand. It's a shame because Corsair's own software is mediocre at best. I found the various options in this implementation to be much more complete and useful than their CUE counterparts.

By the way, I returned my K70 RapidFire (the actuation on the Speed switches was far too high for my liking and the lack of resistance made typing a long paragraph a real chore) and bought a K70 LUX RGB (with Brown keyswitches). I've been having lots of fun twiddling the various knobs and playing with the RGB backlights. Thanks again for the cool software, when I first bought the Corsair keyboard I must admit that Linux support was one of my main concerns, and you guys have made it even better than on Windows! :)

[ghost]

Oh! I did have one other suggestion. I noticed that the keyboard uses the hardware profile after a reboot. Obviously the hardware profile can't store anything complex, just the most basic settings possible. Would there be any way to have the driver daemon that runs at boot remember the user's profiles so that they would start working at the login screen? It's really a minor nitpick but I think it would be a cool feature.

[tatokis]

@ColtonDRG if I understood this correctly, you want the profiles stored in the GUI (not hardware), to work with just the daemon running.

Unfortunately this is not possible, as the daemon only just acts as a way for the GUI to talk to the keyboard, by itself it can't do anything. You can get more information about it in the DAEMON.md file.

Additionally, the GUI profiles are different for each user (as they are stored in ~/.config), so it wouldn't be a good practice for the daemon, running as root, to access them, and even then, it wouldn't know which ones to use.

[ghost]

That makes sense. I suspected that was the case. Thanks anyway.

I also noticed that the keyboard was not actually able to make any inputs to the operating system until about a minute after the login screen showed up. This happens on Windows too. Could it be a problem with my USB controller or motherboard or is this somewhat common behaviour? It does work OK in the UEFI before the kernel boots, fwiw.

An option to start at login like what many other common gui-based applications that are expected to be running all the time or at least an option to not open the GUI unless the application is already running (so I could add the executable to my autostart and not have the GUI come up at boot) would be fantastic. Nevermind, ckb -b is what I was looking for.

[ghost]

@ColtonDRG please keep this thread sane and related to feature requests only. If you experience any problems, please open an issue or find a similar one and we can discuss everything there.

[tajnymag]

How about some sort of API? As CueSDK is available only for Windows, you are basically our only hope for integrating Corsair devices into our Linux projects.

EDIT: Never mind, I've just found the Daemon.md file :)

[Vorathe]

Macro Wait States and Toggle (On/Off or Start/Stop)

Use case:
In a game where auto-run isn't a feature, you could use this to simulate the same functionality.

Flow:

1. User records macro sequence +lshift,+w,+time,+-lshift,-w
2. User selects control in ckb-next ui to set as toggle

Usage:

1. Press keybind with recorded macro
2. Macro plays
3. Press keybind with recorded macro again
4. Macro play terminates, releasing any key presses, clearing any wait time

[k80w]

It'd be nice if I could get a little more information about devices through the daemon. For example, an leds file that listed the names and positions of LEDs so I don't have to rely on the source files too much.

[frickler24]

@Vorathe Sorry I didn't see your mail until now. I've been offline for a long time.
I don't understand your approach yet. Have you tried the possibilities for delays between keystrokes (press and release)?
You can define per key,

• whether the delays should be used in the way they were created during input,
• the standard delays are to be used permanently
• or no delay is to be used.
  

You can also change the delays in the left window - e. g. if you only want to have a delay between two keys. By the way, this is easier with drag & drop from or to a text editor than in the small window of the ckb-next GUI.

When you then switch between the modes, the driver remembers the delays you have saved - so you can toggle between 0-delay and original delay.