Jump to content

MSC

Members
  • Posts

    246
  • Joined

Reputation

10 Good

About MSC

  • Birthday 06/29/1993
  1. Check the Performance tab to see what the indicators are set to. They might be turned off. If you'd be willing to compile Fedora packages I'll definitely put them up with the project :) The current version in the testing branch allows you to disable the scroll acceleration and set a fixed scrolling speed instead. Try that out and see if it works for you. Not yet. It's planned soon though. If you uninstall ckb, do the lights still turn on when you plug in the keyboard? It should load the static profile as long as the driver's not running. If the backlighting isn't coming on at all, the keyboard might not be getting enough power.
  2. There's Sabre support in the testing branch. I think it works, but I haven't heard back from a previous tester yet, so I'm not certain. Let me know if you get it working. On the "Settings" tab in the GUI, there's a checkbox that says "Check for new firmware automatically". Turn that off and it won't bother you anymore. A number of people have reported issues getting the keyboard to work at boot and/or in their BIOS. Usually it can be fixed by 1) moving to a different USB port, 2) updating BIOS, or 3) applying the HID quirks mentioned in the readme. You may need to connect the keyboard to a Windows computer first in order to do a firmware update. Other than that I'm not aware of any major problems.
  3. Hey everyone, I've tested the latest firmwares and they seem to be working fine, no ckb upgrade needed. I've updated the database for ckb so you should be able to download/install them now, or just use CUE. Which desktop environment are you using? Most of them will provide an option to run it in a terminal if you double-click on the script. If that's not working, open the directory in a terminal and then type "./quickinstall" and hit enter.
  4. Hey everyone, sorry it's been so long in coming, but v0.2.2 is finally released tonight! Adds support for the Strafe and Strafe RGB as well as the new Scimitar mouse. It also fixes the bug with launching programs on Linux, which has been around since v0.2.1. Let me know if you find any new issues with it.
  5. Re-launching the program will open the UI again. It should show up in your applications menu.
  6. Yeah, this is planned for some point in the future. Can't give a timeline yet as it's pretty far down the backlog. Interesting, thanks for that. I'll add a note in the Troubleshooting section. Have you tried updating your BIOS or moving the keyboard to a different USB port? It seems like some motherboards have this problem and, as far as I know, there's no consistent solution for it. Sorry :/
  7. A bit of both. The keys do have X/Y coordinates, which are sent to the animations when they start up. However, the color values are sent by name. What the built-in animations do is store the position map, then figure out what color to assign to each key based on its position.
  8. Possibly a Qt bug or a problem caused by using an older SDK. Should be fixed when I update the binary for v0.2.2. I assume you have one of the non-RGB versions? Unfortunately they're not supported at the moment. The side buttons don't really work with OSX even with the RGB version, however. (A handful of apps recognize the back/forward actions, but most don't) No, but that's a pretty cool idea :) The animations are all C programs, it's a relatively straightforward API. Basically you just have to tell ckb which color to assign to each of the keys.
  9. Project files should be fixed now. I'm not actually sure why QMAKE_MAC_SDK is in there, I think it was a workaround for some issue earlier on. Seems to work just fine with those lines removed. See #133 - I've made an update to the testing version, it should work again now. Let me know if you're still having trouble. There's a system file named /Library/LaunchDaemons/com.ckb.daemon.plist. Edit it to this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.ckb.daemon</string> <key>ProgramArguments</key> <array> <string>/Applications/ckb.app/Contents/Resources/ckb-daemon</string> <string>--nomouseaccel</string> </array> <key>KeepAlive</key> <true/> <key>ProcessType</key> <string>Interactive</string> <key>LegacyTimers</key> <true/> </dict> </plist> Then restart your computer and that should do the trick. One caveat, this does also disable scroll wheel acceleration. I'll work on implementing finer control over it, as well as a GUI option to disable acceleration, in a future version.
  10. Yeah, this is definitely planned. There's an issue thread with some discussion about it: https://github.com/ccMSC/ckb/issues/67 I haven't done anything yet because I don't have much time for the project and so far the people who complain about performance have been fewer than the people who ask for new features :P But I'll definitely get around to optimizing it soon-ish. I think you're right. OSX isn't very friendly to user-space drivers, and writing a kernel driver requires shelling out $100/yr for an apple developer program, which I'm not willing to do. It's possible there are some optimizations I'm missing, but if it's causing the CPU to heat up even when the GUI isn't active then I'm not sure there's anything I can do. Merged in the ckb testing repo now! If anyone else has one of these and can test it before it gets back to the master branch, would be much appreciated :) I'm also going to try to add support for the Strafe non-RGB, Sabre RGB, and Scimitar RGB in the next few weeks. If you have one of those and haven't already contacted me about it, feel free to leave a PM or comment.
  11. Uhm, if ckb-daemon is attempting to connect to the internet then you should rebuild it from source and/or check your computer for viruses, because the version you downloaded has been tampered with. I could give you GPG signatures for the source code if you need them. ckb-daemon doesn't contain networking code at all. It's possible that GitHub is tampering with the binaries somehow (I hope not...) so I'll look into that. I'd like to get this sorted out before investigating what's going on with the power states. Did it work correctly in a previous version? The driver itself doesn't care, but a lot of motherboards have problems using the keyboard with USB 3.0. The simplest way to turn mouse acceleration off is to use this: https://apple.stackexchange.com/questions/151539/how-to-disable-mouse-acceleration-in-yosemite This *should* disable acceleration both with and without ckb running. If it's still accelerating, ckb-daemon has a command line option named "--nomouseaccel" to turn it off.
  12. Oh wow, it actually just works? That's great news! Guess I won't need those captures after all then. I'd like to clean a few things up and get it added back into the main branch - I'll post here again when they're finished. Thanks for testing it out. How bad is it? Anywhere up to 10% or so is normal, just from handling animations. If you're seeing CPU spikes of 50% or more it may be something that I need to look into.
  13. Hey everyone, sorry I haven't had time for this project in the past week...life's been busy, haven't gotten many chances to work on it. Anyway, I've started up work again, planning to have v0.2.2 released soon with a few new settings and some bug fixes. Thanks! I made a new branch to test it: https://github.com/ccMSC/ckb/tree/sabretest It should treat it as an M65. What I think will happen is that the mouse will work, but only three of the lighting zones will be customizable. Let me know what happens when you run it and we'll go from there. Check your keyboard layout on the settings screen. Hard to tell what's going on but the protocol looks completely different from the keyboards I've encountered so far. I can try to add support anyway but it could be very difficult. As clement said, please provide captures for simple actions (i.e. turning on CUE after the keyboard is plugged in, changing the color of one key at a time, etc) with detailed descriptions of what you did. Also, if you could open an issue ticket on the GitHub page, that would probably be a lot easier than trying to go through everything here on the forums.
  14. Frankly I don't know - it seems like a design flaw on Corsair's part. The OS doesn't read the reports at all. If I try to capture them in Wireshark, they simply don't appear without ckb running. For some reason this causes the keyboard to hard-lock (I assume it's waiting for the USB transfer to be acknowledged by the OS, which doesn't happen). It doesn't have this problem in Windows or OSX because they actually do read the reports, but don't do anything with them. It can be fixed with the ALWAYS_POLL HID quirk, which causes the Linux kernel to behave in the same way. Awesome! Can you post the output of the following terminal command: lsusb -d 1b1c:
  15. No. The report doesn't conform to any HID standard that I'm aware of. In fact sending it to the kernel driver will cause the keyboard to go into a hard lock because the driver doesn't read it. The report is actually a bitfield of all keys currently pressed, including the G keys (in this way it's similar to the N-key rollover switch, which is how the keyboard communicates with the stock driver). However, the keys don't appear in the same order.
×
×
  • Create New...