chmod222
Handshake fails for MasterKeys MK750 US Layout
The current version of libcmmk fails to communicate with the MK750 (US) for both the cmmk-test and cmmk-debug test utilities.
The output of cmmk-debug is as follows:
Attaching to 2516:0067...
Layout detected as: 2
Firmware version:
test_handshake1(): send failed...?
test_handshake1(): send failed...?
I will be personally looking into the cause in the meantime.
It is possible that the change to hidapi caused some trouble if you had it running with the previous libusb before. Maybe running rmmod usbhid && modprobe usbhid to reset it provides some remedy?
rmmod usbhid && modprobe usbhid does not seem to do anything to change the debug info.
I am currently using hidapi 0.9.0-1 when compiling.
I will note that the last time I built the library, and it worked, the source was using libusb.
Update: cloned the git repo for when I confirmed that the MK750 was supported. Using it didn't work, and the same debug information was given upon running the utility. I now suspect it has something to do with the new version of libusb.
This is weird, I made it use hidapi-hidraw especially to get around libusb, so the libusb version shouldn't be the issue anymore
Update: Tested the latest libcmmk on Ubuntu 18.04 -- originally tested on Manjaro 20.0.3.
Handshakes now appear to work, but the detected layout is wrong, and cmmk-test does not seem to be able to set keyboard effects.
The output of cmmk-debug is as follows:
Attaching to 2516:0067 alias "Cooler Master Masterkeys MK750"...
Layout detected as: 6 alias "EU"
Firmware version:
Hexdump of handshake #1:
0 1 2 3 4 5 6 7 8 9 A B C D E F
000000: ff aa 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................
000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0 1 2 3 4 5 6 7 8 9 A B C D E F
Hexdump of handshake #2:
0 1 2 3 4 5 6 7 8 9 A B C D E F
000000: ff aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0 1 2 3 4 5 6 7 8 9 A B C D E F
I've only seen ff aa responses as part of error messages, and I distinctly recall a contributor getting such an error after updating the firmware on their device.
Did you update the device sometime between it working and not working?
This is weird, I made it use hidapi-hidraw especially to get around libusb, so the libusb version shouldn't be the issue anymore
I was referring to my repo that is still at my old commit (27 commits ago) for when libusb was still being used. I remember that it worked on my system, which is why I tried using the source from there, but it didn't end up working.
I've only seen ff aa responses as part of error messages, and I distinctly recall a contributor getting such an error after updating the firmware on their device.
Did you update the device sometime between it working and not working?
I don't think I updated the firmware any time after it was confirmed to be working. I remember using the related cmmk_ctrl application to successfully apply effects to my MK750 directly after the last time I updated the firmware for the device.
That being said, I could still be wrong.
I will probably be recording USB captures for investigation into this issue.
I have taken captures of the cmmk_debug utility with hexdumps on:
https://gist.github.com/JonOcto/71d8b22ea065d932cee50d7bdd3c5255
Wireshark capture data: https://files.catbox.moe/jnqo25.pcapng
It appears that keyboard is refusing to accept the handshake data, giving -ENOSPC in the replies.
At this point, I am considering upgrading the firmware anyway, so that I can capture and map out the keyboard's new protocol.
It doesn't seem likely that work on this issue will progress until we are able to see what CM's official control app is doing.