rnayabed / rangoli

Free, Open Source, Lightweight, Cross-platform Software for Royal Kludge Keyboards
https://rnayabed.github.io/rangoli_website
GNU General Public License v3.0
272 stars 14 forks source link

FN key issues #118

Open i0nC4nn0n opened 2 months ago

i0nC4nn0n commented 2 months ago

I apologize for the wall of text in advance. Over time I amassed quite a few Royal Kludge keyboards. Two RK61s in white, a black RK68 and a white RK84. Regarding price/performance ratio they are so good i might buy more. There is an issue that makes using the smaller ones a bit of a pain for me though. Namely the implementation of the multiple layers and their access to them. I am talking about any kind of key combinations where the FN key is involved. The RK61 and RK68 are 60% and 65% keyboards respectively, both of them have a total of 3 (maybe more) layers, accessible via the FN key. I will get to them shortly but for my problems description let us focus only on the RK84 first, since that one is less complex. It has only 2 layers, the main one and the one accessible via the FN. Furthermore all the FN layer keys on the RK84 are "momentary press" only, none of them are "sticky", meaning the moment I depress the FN key every key returns back to "normal" (to the main layer). There are two type of keys on the second layer. Ones that send a scan code to the OS. For example FN+F10 sends 0xE020 which is "multimedia mute". Other function keys invoked with the FN key do other stuff, like FN+F12 is the "multimedia volume up", FN+F11 is the "multimedia volume down", FN+F4 starts a calculator, etc. The other type of second layer keys don't send scan codes to the OS at all, but instead manipulate some aspect of the keyboard, mostly RGB related stuff. For example FN+Home cycles through the RGB modes, FN+Up and FN+Down increas or decrease the LEDs brightness, etc. I am fully aware that the second type (the not sending scan codes type) of keys probably can never be affected, but it would be nice if we could manipulate the ones that do send scan codes. From my understanding not even that is feasible since Rangoli (nice name, btw) under the hood uses the same commands that the official RK Keyboard app uses to modify the keyboards behavior. Although not for USB traffic I have used Wireshark myself to intercept packets, analyze them and basically reverse engineer a protocol. Even if I am not familiar with the development workflow I know one thing: Rangoli will only have features that the official RK Keyboard app supports, since they need to exist there first, to be intercepted and to be implemented in Rangoli. I know for sure that the latest RK Keyboard app doesn't support what I'm asking for at all. Still, since the developer looks like to care about RK Keyboards enough, and I feel like I am between like minded people, maybe we could raise a petition and email RK directly asking for a simple thing, like the ability to remap the MUTE from F10 to F1 for example in their app and if they implement it we could intercept that and remap everything. TL;DR multi layer implementation of RK Keyboards is a mess, there's probably nothing that can be done, but it's still sad and we should do something about it