-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyboard Language/Layout Support #177
Comments
The way I've approached this problem is distinguishing between "physical keys" (what gets sent via HID) and "virtual keys" (what is getting typed). Suppose I want to type F. Normally you can just send KC_F if user is using QWERTY. However if user has Colemak, you need to send KC_E to get F. One can define a VirtualF key that looks at whether the device is configured for QWERTY/Colemak/etc and decide what to send. I think some sort of "virtual key" mechanism is also useful for macros, where you have a virtual key that corresponds to a series of other virtual keys, at the lowest layer corresponding to a physical key that gets sent. This can also be useful for making non-ASCII characters easy to define.
Similarly you can have VirtualUnicode or that Ctrl-Shift-U-[codepoint] on Linux (which by the way, probably needs to be Ctrl-Shift-I on Linux with Colemak) and adjust the sequence based on the OS (or do nothing if not supported). You can then have VirtualString that calls a series of VirtualUnicode keys. https://github.com/ergoblue/src-adafruit/blob/master/control/keymap.go is an example implementation of my proposal (in Go). |
@xudongzheng, as I've worked through #21, I've come to the same conclusion from a different angle: functional keys such as
For the reasons you outlined, as well as my own, I'm also leaning towards the need for virtual key codes. Moreover, as we venture beyond standard keyboard codes (i.e. consumer controls, mouse buttons, axes, etc.), we may want to consider calling them intents. However, it wouldn't be trivial to achieve, because an implementation needs to:
I suspect that points (4) and (6) will be sticking points for virtual keys or intents. Any thoughts? |
A short discussion between @petejohanson and I following my comment above is relevant to this issue in the short-term: Suffice to say, host layout support is a consideration for the longer-term which needs to be explored. In the short-term we're going to use workarounds for functional keys by leveraging OS-specific layers. |
First it would be nice to implement something like qmk, that doesn't recognizes the host keyboard layout necessarily, just create aliases for the keycodes in the different layout. Just implementing the basic would be sufficient for most people (I think). I just use the abnt2 layout because I need to have access to ç and accented keys, so in my keyboard running qmk I just need to import the abnt2 keycodes and use it instead of the default KC_ keycodes, for most keys, most modifiers and function keys are unchanged. This and macros are the only things stopping me from running zmk, it would be nice to have something like that implemented. Thanks for the awesome work! |
as @toniz4 said about, ignoring the layout on the host. IMO it will be best thing. I was on qmk and thought zmk will also do the same and used my keyboard on other machine just to realize it will understand my keys. This also limit me from using custom layout. correct me if I am wrong about custom layout |
this is something that in my opinion keeps zmk from expanding outside us/ansi world. @urob has a solution that an be simply upstreamed and simplified. |
When I saw this post, I felt discouraged about ZMK, but then after quite a bit of reading through the documentation I set up my layout which is Colemak-DH angle mode with a few of Slovenian letters (č, š, ž...). My host (PC) layout is Slovenian so I needed to change quite a number of characters, but you can copy keymaps for different host layouts from QMK repo (like I did for Slovenian host layout). My steps were to copy keymap_slovenian.h (other layouts) to my ZMK config folder (keys_si.h). With something like keys_si.h you can include it into your |
@bzgec I've used your solution too for the German layout. |
I didn't know you could do that, thanks for the info! Now I feel comfortable with trying out zmk.
I could try to do something like that, probably an awk script would suffice that, if there is not many edge cases. In 2 months or so i will receive the components for my new keyboard, so by then I probably will get something made. |
This is brilliant, thanks a lot. I followed your steps to make a french zmk keymap, it works perfectly well. |
Worth noting the ZMK locale generator project, which generates locale headers suitable for use with ZMK: https://github.com/joelspadin/zmk-locale-generator If it is confirmed working for various locales by users, the generated headers could be incorporated into ZMK, or linked to in the documentation as an official approach. |
@MajykOyster I looked at your solution and I was wondering how you figured out how to compose the characters in your french_unicode.dtsi file? |
Thank you very much! |
Lol what a timing, just seaching for a DK layout, my {} ends up being ¶≠ with these. do you happen to know what i do wrong? |
You didn't make a mistake - I did, and defined the brackets twice and one of these wrong, this should work :) Nick from keymap editor proposed of doing it this way though, if you like having a GUI for editing. |
This topic was recently raised by xudongz and is increasingly on my mind as I revisit key names/codes.
How should ZMK support or facilitate this use case?
Suggestions so far:
The text was updated successfully, but these errors were encountered: