Open TheManFromEarth1 opened 3 years ago
Is there a way track any logs to find something out?
You can use wireshark to capture the USB communication from the official software and rgb_keyboard for options that don't work. This would allow a direct comparison of the relevant packets, thus giving the best chance to fix these problems.
Here is a brief explanation of the process, here are more detailed guides: https://bytepunk.wordpress.com/2017/03/25/reverse-engineering-a-usb-mouse/ https://github.com/pez2001/razer_chroma_drivers/wiki/Reverse-Engineering-USB-Protocol Feel free to ask if there is anything else.
Interestingly, my Redragon K552RGB-1 reports the following under lsusb
:
0c45:5004 Microdia Redragon Mitra RGB Keyboard
@darrynjordan The keyboard is identified by its vendor and product id (0c45 and 5004), the name is taken from the udev hardware database. Multiple keyboards have the same ids, but only one is entered into the hardware database, therefore you see the wrong name.
The hwdb(7) manpage has the details if you are interested, or you can edit the entry at https://usb-ids.gowdy.us/.
Interesting! Thanks @dokutan. I didn't know about this database.
Please note that I have found the following erroneous mappings from label to physical key:
Label | Physical Key |
---|---|
Tilde | Apostrophe |
Bracket_l | Bracket_r |
Bracket_r | None |
Backslash | None |
Semicolon | Slash |
Apostrophe | Tilde |
Slash | None |
For testing I use rgb_keyboard -Y brazil -P example.conf
.
I'll be happy to capture the output of the Redragon software using wireshark for these keys.
@darrynjordan Did this affect remapping of the keys or or custom led patterns?
Instead of directly using wireshark, it might be easier for you to simply edit the labels or remove entries in one of the keycodes_*
(leds) or _keymap_offsets_*
(key mapping) maps in https://github.com/dokutan/rgb_keyboard/blob/master/include/data.cpp. Only if you lack information e.g. the code for a specific key, wireshark would be necessary.
If you attach the fixed map or usb captures i would add a new layout for the K552 (of course you are welcome to do it yourself if you want).
@dokutan I have not tried any remapping, this was simply for custom led patterns.
Thanks, that was a great suggestion. I managed to find the required hex values by running through all of the ANSI keycodes.
Making the following changes has fixed my issues for the K552RGB-1
:
// keycodes for custom led patterns (brazilian layout)
const std::map<std::string, std::array<uint8_t, 3>> rgb_keyboard::keyboard::keycodes_brazil = {
...
{"Apostrophe", { 0x32, 0xde, 0x00 }},
...
{"Bracket_l", { 0xf3, 0x9f, 0x00 }},
{"Bracket_r", { 0xf6, 0xa2, 0x00 }},
...
{"Semicolon", { 0x2f, 0xdb, 0x00 }},
...
{"Backslash", { 0xf9, 0xa5, 0x00 }},
...
{"Slash", { 0x72, 0x1d, 0x01 }},
...
{"Tilde", { 0x93, 0x3f, 0x00 }},
...
};
It would be great to know if the required values are different for the K552RGB
and K552RGB-2
?
Are you happy for me to make a pull request with the changes applied?
@darrynjordan Thanks for figuring out the correct values, i have added a new layout brazil_k552rgb1
in 7cbf3b274a6e7fcf20934f879730f92962c3fe0d instead of merging your update to the brazil
layout, i hope this acceptable to you. This is to avoid any accidental regressions for other keyboards. Please let me know if this works for you.
Yep, that works for me @dokutan. Thanks.
Tested on: Kubuntu 20.10
1. Set active profile 1, 2 or 3
As long as you set profile once and leave it at that, these work fine, great job!
I can set modify them from the original software on Windows and they persist as they are stored on the keyboard.
2. Manual options, e.g.
rgb_keyboard --color 00ff00
It doesn't take any new color.
3. Freeze/Crash
What happens every 3rd or 4th command is it freezes keyboard, which makes the keyboard not work until restart (with only half of the lights on). The last time it also somehow changed the color to green after restart.
Is there a way track any logs to find something out?