SicVolo
-
Posts
9 -
Joined
Content Type
Forums
Gallery
Release Notes
Corsair Blog
Store
Profiles
Posts posted by SicVolo
-
-
I am seeing one small quirk, most likely my fault, with the 'windows lock' key (upper right corner of the strafe rgb). At one time it illuminated but now does not. Window lock functionality is correct. With lock 'on', Gnome will to 'overview' / 'pilot' view as it should. Suggestions?
Just fixed that, along with the corsair logo backlight on Strafe in my testing branch and got the pull request going. Should show up in the main repo soon.
As a side note. We should probably package CKB into debs as well, and get a ppa going. Any takers?
-
Hi, I just got a notification from CUE in windows that 1.33fw is out. Has anyone tried 1.33 with ckb. Does it still work well or should I wait for a ckb update to switch 1.33.
Changing the firmware would break ckb only if it also breaks CUE, which ckb emulates at the USB level. Does one need a new version of CUE to go with the new fw?
What's fixed in 1.33?
-
Hey guys, I was just wondering... Will the rgb Strafe will be supported with this?
Yes, it is supported. I added the Strafe RGB support, and tested along with a couple of other folks. It's in the testing branch and will be official in the upcoming release of ckb from ccMSC.
Please report any bugs/feature requests for Strafe on the GitHub.
-
I've been fiddling around with compiling the app from the source as the binary would not seem to be recognizing my board.
The code I wrote for the Strafe RGB is in the testing branch of MSC's repo - beta-v0.2.1+t06. You need to get that branch and compile manually. I've not tried compiling it on OS X, but someone else did - https://github.com/ccMSC/ckb/issues/138.
Note the small fix you need to do before it compiles.
-
Anyone know how I can completely remove any trace of these drivers? It's completely screwed up everything and Linux ignores half of the input from the keyboard.
Read the README.md on github. If that did not help, your problem is not the drivers but something else on your system.
-
I would blame the USB interrupt polling for that. The window update/redraw should not happen more frequently than the screen refresh rate.
The window is updated on timer, every 1/60 of a second, which then sends the LED codes to the driver. The driver is very gentle on the USB communication when no lights are being updated. However if you have an animation running the worst case is 4*60 USB packet writes a second and 60 packet reads. Yes, a ton of wakeups.
-
I've extended the driver to support the new Strafe RGB. You can test it from the testing branch of my repo for now (https://github.com/SicVolo/ckb/tree/testing) or from the MSC's repo after the pull request is merged.
-
07/10/15 11:02:49,000 kernel[0]: process ckb-daemon[20542] caught causing excessive wakeups. Observed wakeups rate (per sec): 552; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45462
I am not surprised - ckb spams /dev/input/ckb[12]/cmd like crazy, posting the full LED map with colors every time the main window gets a re-draw/update even if no LED's changed. The daemon wakes up to process it every time. It then drops it silently because nothing changes.
@MSC, I suggest frameUpdate in kblight.cpp is made smarter to check if anything has changed before posting the cmd. Kind of like updatergb does it in led_keyboard.c, when determining if it needs to post to usb.
It would save CPU, heat, battery, electiricy, and eventually the world ;)
(Unofficial) Linux / OSX Driver
in Keyboards and Mice
Posted
@Frickler:
Good writeup - should probably go into the main docs. One comment - your fixes were pulled into the main branch. Any particular reason your documentation tells people to check out the newfx branch instead?