K100 RGB Optical-Mechanical Gaming Keyboard - 1b7c

[cajuncooks]

Corsair's new shiny object.

Here's the log generated by ckb-next-dev-detect: ckb-next-dev-detect-report.gz

If there's anything I can do to help, let me know; I'm a vaguely competent developer sometimes.

[tatokis]

Can you please install wireshark with usbcap (when prompted during the installation) on windows, and capture the keyboard being plugged in with CUE running?

Alternatively, if you want to do usb passthrough, you can use usbmon+wireshark on linux and pass the device through to a vm.

[cajuncooks]

I will do that on my Windows desktop this afternoon, sure.

[cajuncooks]

usbpcap_corsair_k100.pcapng.gz

[Ravenslofty]

It's Bragi, ugh. That's gonna be fun.

[tatokis]

Can someone try the code from the k95-xt branch and change the usb device id in usb.h for the k95 platinum xt to the one for the k100?

It's possible that input will break, so make sure you have a backup keyboard.
The GUI won't recognise it, but the daemon should. Check if you can type with it.
After that, try echo active > /dev/input/ckb1/cmd afterwards and check if you can type again.

Also send the log from the daemon

[bjowi]

Changed as follows:

-#define P_K95_PLATINUM_XT 0x1b89 // Don't think this needs to be in the macro
+#define P_K95_PLATINUM_XT 0x1b7c // Don't think this needs to be in the macro

After daemon restart tried to push enter, and it looked like that enter was repeated multiple times in the terminal, but it came in spurts, not evenly. Also all keys were blinking. No possibility to do the echo active thing.

Log is attached.
log.txt

[mcrapet]

Thanks to KitsuWhooa (irc) for help. This is a quick & dirty hack.

Use new-devices-redux branch (commit 142621f).
Apply patch: https://gist.github.com/mcrapet/40f8000b59a0a6b720c6c0e947012bf2

Compile:

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_GUI=OFF -DDEBUG_USB_SEND=ON -DDEBUG_USB_RECV=ON -DDEBUG_USB_INPUT=ON ..
make

Launch (as root):

./bin/ckb-next-daemon

daemon seems to launch correctly. However at each keystroke I got:

[W] handle_nkro_key_input (keymap.c:661): Got unknown NKRO key press 112
[I] ckb1 Input Recv: 01 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00

[mcrapet]

Keyboard is available in two flavors:

• Cherry MX Speed
• Corsair OPX

Have no idea if this makes a difference for software.

[MasterRoCcO]

Once you start using your git, the mouse stops working. Keyboard cannot be customized. But it is recognized in the software

[freetz-ng-mod]

Keyboard is now recognized, but not all colors are displayed correctly. And besides, the number 7 no longer works with number pads

[LakesideMiners]

any updates on this?
I tried installing @mcrapet 's commit
I assume it worked, like I have installed the main branch, and I assume I did not need to do anything special for this one aside from the different repo.
Device is not detected.

EDIT:
Turns out I did it wrong, I forgot to checkout the right branch.
Colors are wrong tho.vvdfdf

EDIT 2:

So, I set the keyboard to fully black

The keys that are still on are

0)

and

Del

I noticed that where the FN key would be in the gui, its labeled as "Right Windows"
this is the FN key.

I need to test something here so I will update more after I restart this

EDIT 3:
Okay, so, the left windows/super key does NOT open up the Cinnamon menu if ckb-next is not running, if it is running, then it does. the FN key does nothing regardless of if ckb-next is open or not.

Also, the Keyboard viewer tool for my system doesn't show the left super being seen as pressed regardless of ckb-next

Id be willing to bet that the FN key is fully controlled by the keyboard itself. As, I remember weird stuff with it when I used to use Windows.,

Also the keyboard viewer shows this extra key, that dose not exist on my keyboard at all. I don't know if this is relevant at all but, I'm just documenting what I see..

[tatokis]

Can someone test the code from the k100 branch?
Input might be broken, so keep a spare keyboard handy.

RGB probably won't work correctly. For that I need wireshark packet captures while setting the keyboard to static plain red, then plain green, then plain blue.

[LakesideMiners]

I will test it when I get home,(about 4-5 hours) I use a laptop so broken input should not be an issue. I can provide any needed captures as well. Just tell me what you need and I’ll grab them.

…

Sent from my iPhone

On Oct 25, 2021, at 9:37 AM, Tasos Sahanidis ***@***.***> wrote:  Can someone test the code from the k100 branch? Input might be broken, so keep a spare keyboard handy. RGB probably won't work correctly. For that I need wireshark packet captures while setting the keyboard to static plain red, then plain green, then plain blue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[stefanorossiti]

Can someone test the code from the k100 branch? Input might be broken, so keep a spare keyboard handy.

RGB probably won't work correctly. For that I need wireshark packet captures while setting the keyboard to static plain red, then plain green, then plain blue.

I am using now the k100 branch on Pop OS 21.04, input actually works great.
I tried to do some binding, and it seems also to work for all keys, but it doesn't work for the G1 to G6 keys.

Normally the keyboard's RGB is in breathing mode. Starting ckb all RGB just turn off completely and setting some color or mode doesn't anything. Quitting ckb returns the keyboard in breathing mode.

Also, here is the capture:
https://gofile.io/d/WffyAT
I started the capture, plugged in the keyboard (Packet No.513), then for all keys together I sent a blue color command, then green and finally red.
For the rgb packets im not sure but i think are those filtered with with: "frame.len>72"

[MasterRoCcO]

git clone -b k100 https://github.com/ckb-next/ckb-next.git ckb-next_100

sudo apt install build-essential cmake libudev-dev qtbase5-dev zlib1g-dev libpulse-dev libquazip5-dev libqt5x11extras5-dev libxcb-screensaver0-dev libxcb-ewmh-dev libxcb1-dev qttools5-dev git libdbusmenu-qt5-dev
cd ckb-next_100
./quickinstall

[tatokis]

I have pushed code to the k100-v2 branch, which should have all the lights fully functioning.
The zones on the light wheel are a bit broken at the moment, in the sense that the only way to select them is to click and drag the cursor in their general direction. The animations also render diagonally on them instead of vertically.
I'll try to fix them whenever I have time.

In addition, adding the extra wheel lights has increased the cpu usage while the preview is on.

I will also need someone to enable logging in the daemon (cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_USB_INPUT=1) and then with the GUI running and brightness set to 0, move the control wheel while noting down the packets logged by the daemon so that I can implement support for it.

[T99Rots]

@tatokis

I just installed the branch and made a debug build for the logging

aug 13 12:33:05 tim-workstation ckb-next-daemon[81124]: [I] ckb1 Input: (83) 00 05 60 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
aug 13 12:33:10 tim-workstation ckb-next-daemon[81124]: [I] ckb1 Input: (83) 00 05 60 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The first one is rotating clockwise, 2nd one is counterclockwise

[tatokis]

@T99Rots Thank you and apologies for the late reply. If you move the wheel as quickly as you can, do you get anything other than 01/ffffffff ?

[T99Rots]

@tatokis I've tried spinning it as fast as i could and found out it's a great way to slice open your finger somehow, other than that i can confirm the values i stated before are the only values no matter the spinning speed.