-
-
Notifications
You must be signed in to change notification settings - Fork 28
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
Support non-US keyboards #8
Comments
I can try to help with testing this, but will in turn need help setting up a test environment. I have not yet built a RIA or VGA image myself. /Ulf |
To do something useful i made a german keymap. But only ASCII chars.
To use this map, copy this define into RIA's hid.h and change line 41 in RIA's hid.c from: I will make a HID to unicode for german keyboards soon. I hope this is helpful for someone. :P |
German keymap with UNICODE\UTF8 chars. But it does not work.
|
@Technikfreak2002, I can use this to build out the next layer. Isn't GR typically used for Greece? I thought Germany was DE (Deutschland). |
I depends. When you talk about the locale, it is DE. But when you set the layout, it is GR. Like "keyb gr" from old MS-DOS. Don't know why. |
Also, what about the AltGr key? Don't you need that for full ASCII (like @)? |
Yes this key is also needed. |
I added a column for AltGr and send everything through the unicode translation. It looks like dead keys are needed too. I don't know what else is needed and don't have time to do the research. If someone wants to work on this to completion, build it around a #define and I'll add a setting for it. |
I added a CMakeLists.txt option to help collect the basic unicode tables. Once we have the full requirements, a config format should emerge. |
I experimented with the Swedish keyboard and made a kbd_sv,h file. The issue that I see is that while keyboard mappings work for character values below 128, everything between 128 and 255 (or -127 to -1) does not print. I noticed several places in kbd.c were a char type is used and I suspected that unsigned char would be needed. But even after changing those that I found, it still did not work. The problem might be higher up the stack in the typedef struct stdio_driver stdio_driver_t , but I might also be barking up the entirely wrong tree. |
Ö is unicode 0x00D6 but you have 0x0099 which is Ö in cp850. |
I was thinking some more about ISO 3166 (country codes) and came across ISO 639 (language codes) which makes more sense for keyboards. In that case SV means swedish/svenska (not Sweden/Sverige). The thing about standards is that there so many to choose from. https://xkcd.com/927/ |
I was feeling 30 years out-of-date after your first message for not keeping up with ISO standards and for not fully grasping unicode. After your 2nd message I can focus on catching up on unicode :-) and remain lost in the ISO standards for now. The cartoon summed it up nicely! |
Thanks to your help, I am getting close to a working Swedish keyboard now. åÅäÄöÖ and most other keys are working. The supposedly silent keys are of course not so silent and are printing without waiting for the next char, i.e.: é'eë are printed directly without waiting for the 'e' (which I guess is known), but otherwise it seems OK. On the other hand, strings in the code when printed, for instance: "These are the special Swedish characters: åÅ, äÄ, öÖ" do not come out right on VGA, only on minicom. I guess we still need to fix unicode for the VGA display I changed the file name to kbd_swe.h in accordance with 639-2, but have made the defines to accept both 'swe' and 'se' as keyboard settings since 639-2 mentions that 639-1 and 639-2 should be considered synonyms. |
not 'se' - I meant 'sv' |
6502 applications and the terminal use the code page. Unicode is too much for 8-bit 64k systems. The idea is an app checks codepage() and faults if an unsupported one is selected. Or an app can do it all itself with direct keyboard and character graphics. Dead keys (silent?) aren't yet implemented. We don't have those here. I have to research its nuances unless someone does it. It's checked in. Simply change RP6502_KEYBOARD in CMakeLists.txt until we have a complete solution. |
Here's a list of what Windows uses: https://ss64.com/locale.html |
The very simple HID_KEYCODE_TO_ASCII table from TinyUSB is currently used. We can do better.
One approach is to create HID_KEYCODE_TO_UNICODE_(LOCALE) tables. Then use FatFs ff_uni2oem() to convert unicode to the current code page.
The text was updated successfully, but these errors were encountered: