Collaboration on newer CKB

[mattanger]

Hello to anyone interested, I'm, slowly, working on a CKB fork that hopefully will have some improvements. I think this is an awesome project, but as everyone has noticed.. it's maintainer @ccMSC doesn't seem to be able to support it.

CKB in it's current state is basically stable for me, K70 RGB on Arch Linux. But, I've noticed some UI issues that I've been wanting to fix, and that's what I'm somewhat focused on now. I'm also cleaning up the codebase a bit and converting it to a CMake project. I won't be able to dedicate much time to fixing anything for the next two months, but towards January 2017 I'll have more time to work on this project.

If there are any other developers who want to collaborate on supporting and/or fixing this project up let me know!

[mattanger]

Perhaps I should have noted that I only have limited access to OSX.

[fleischie]

This seems like a good idea and I'm willing to help.

I also have a K70 RGB on Arch. Let me know if I can help somehow. 😊

I'm also willing to help.

I have an Corsair STRAFE RGB on Linux Mint.

[mattanger]

Thanks for the replies! I'm not sure what exactly will be need off the bat, but all help is welcome!

[stephenhouser]

There have been other forks you should look at that have been active more recently than the original branch. In #437 we were working on adding better macro handling.

[fleischie]

@stephenhouser Would you suggest creating a fork, that merges all currently un-merged forks/branches and starting from there?

@mattanger What is your general outline how and what to address? How do you want to address the issues with the driver?

[mattanger]

@fleischie I don't have much of an outline yet. I haven't been able to dedicate enough time to really figure out any sort of concrete plan. I've been working on some UI improvements to make CKB more usable on a high dpi display.

I'm open to all suggestions on where to go with it. As a starting point, I think getting all the un-merged forks and branches merged and going from there is a great idea.

edit: @stephenhouser Do you know if anyone has started looking into merging any pull requests into a new fork?

[webdev23]

Hi everyone. I am currrently making a controller for the ckb-daemon.
I am using electron with html javascript that talk to a php file served in localhost.
The web audio api is used to get system audio datas.
Here is a preview: https://www.youtube.com/watch?v=H7mKN2PASGM
The interface is currently fully remade and some more effects are on the way.
Preparing instructions and codes! i want to keep it simple, my goal is to make a js plugin to pass web events to the keyboard.
See a basic php/html setup, a rainbow running in daemon: https://github.com/webdev23/phpCorsair

I got my hands on a Scimitar Mouse for testing

[tatokis]

K70 RGB on Ubuntu here. Willing to help whenever I have time.

It would be appreciated if anyone could give some insight on what Apple changed on Sierra to break CKB.

Also, we should have a single fork, deprecating all of the existing ones (the WIP ones should become branches on the new fork), possibly rename the repo to something along the lines of "ckb-next", or "ckb-revived" so that people won't get confused.

@mattanger if you don't mind, give write access to the people interested in here on your fork, and we can start merging existing PRs that have been waiting for a long time, and then go from there.

[fleischie]

I suspect the new TouchBar might have something to do with how the Keyboard System is structured in the newer MacOS Version. Although of course I am no expert and have no previous experience writing device drivers in MacOS.

I will take a look tomorrow, whether I find something insightful but I doubt this will be perfectly easy to find out.

[mattanger]

@tatokis That sounds good to me. I'd planned on starting merging the PRs first and doing what you suggested. Soon as I get time, I'll grant some access to start merging in some PRs. For the next week I'm busy as hell, but, if you're looking to get started immediately, would you like to take lead on getting those PRs merged? Or anyone else who wants to get started lemme know, and I'll set up access so those PRs can get merged into my fork. Otherwise, I'll get started on it sometime next week.

Also, it would be real nice if we could find a developer running OSX. I know little about how OSX handles keyboards, or what kind of funny stuff it does.

@webdev23 that sounds like a neat project. One thing I would like to add is an easy way to define effects and create effects without running a binary.

[mattanger]

@fleischie Good luck on figuring out the MacOS subtleties. I suppose keep us updated on anything you figure out, and maybe we'll be able to do something about Sierra...

[fleischie]

@mattanger thankfully @ccMSC documented the OS_MAC portions of the device driver daemon, so that I can get a somewhat clear understanding, of the quirks inside the source code.

On the other hand most of the workarounds are due to the very non-standard behaviour of many things (e.g. mouse-acceleration, keyboard-layout, time-management, etc.)

I will try to make time to research some more of the Apple-specific documentation regarding device-drivers etc. but also to figuring out, why this project writes a device-driver at all (I suppose it may be because of more previous versions of Mac OS). Regarding the issues it seems the devices work more well-rounded without ckb, the lighting and macro-ing is implemented in userspace (as far as I can tell but may be wrong). BUT maybe I am missing the bigger picture, yet.

As I said before, I will try to make time as well to research more into this and try to understand the ifs-buts-and-whys on the sourcecode.

💪

[tatokis]

I am free to get work done this week, I'd just like to ask you to get your fork up to date/even with the main repo, as that's the only thing I am not sure how to do. Also, regarding Sierra, I've been looking at how Karabiner is dealing with it. Turns out, the dev started working on Karabiner Elements, which is a rewrite for Sierra, so that probably means quite a few things need to be changed in ckb. Maybe there is an official doc that explains what needs to be changed, but I doubt it. So, as a short term roadmap: -> merge existing PRs -> get in contact with people who have forks in development, and see if they are interested in helping out. -> figure out what exactly is broken on Mac and find a solution -> make a list of new devices that will have to be supported in the future, and see which ones we can get away with by just adding their USB ids. -> go through existing bugs and filter out the ones that along the lines of "plz help". Feel free to suggest more, to add them to the new readme as a reference point.