Perhaps I should write a bit more explanation about the coding?
I think I can do programming self-test of my russian "keyboard layout" by this way:
It's much more work.
Suppose you write this program in Arduino:
Code:
void setup() {
}
void loop() {
delay(5000);
Keyboard.println("Russian, Русский")
}
Every 5 seconds, Teensy will attempt to type that string. You didn't mention if you're using Teensy 2.0 or 3.0, so I'm going to assume 3.0 and talk about the code in hardware/teensy/cores/teensy3. The println() code is in Print.h, where an inline function will replace this with write(str, strlen(str)), which then calls the single-byte write() function, defined in usb_keyboard.h, which is inline translated to usb_keyboard_write().
So the interesting code is usb_keyboard_write() in usb_keyboard.c. If you read that code, you'll see it's a UTF-8 parser. The strings are UTF8 encoded. Those latin characters are a single byte. The cyrillic characters are 2 bytes. The UTF8 parser calls usb_keyboard_write_unicode() with the 16 bit unicode for each actual character.
The first step within usb_keyboard_write_unicode() is turning the unicode number into a "keycode", by calling unicode_to_keycode(). A "keycode" is a number that contains information about the specific key sequences needed for the keyboard to type that unicode character. The exact definition of the keycode differs depending on the selected language.
Some languages use "dead keys". If such a language is selected, the keycode is checked if a deadkey press is needed for this character, and if so, the specific dead key is looked up and the keyboard action is taken by calling write_key(). Then the keycode is used with write_key().
The write_key() function separates the keycode into the actual key to be pressed, plus any of the modifiers (shift, control, alt-gr), and then it calls usb_keyboard_press() to actually transmit a pair of USB packets to press and release the key.
As you can see, this process is quite complex, to translate any string with any UTF8 encoded international characters into the sequence of USB packets to "type" each character.
To support Russian, first the mechanism to select latin vs cyrillic needs to be implemented. I do not know how that works on Russian keyboards. It is the same as the Alt-gr and deadkeys mechanisms used on European keyboards, then the existing code can work. The correct deadkey and alt-gr definitions only need to be created in keylayouts.h.
But if Russian uses some different mechanism to select between latin and cyrillic, obviously the code in usb_keyboard_write_unicode() would need to be updated to implement that mechanism.
Another challenge in the code is unicode_to_keycode(). If you look at that code, you'll see if supports only up to 10 non-latin (greater than U+00FF) conversions from unicode to keycodes. So that function will need to be expanded to support all the necessary cryillic characters. Simply replicating the code probably isn't a good plan. The fixed 10 checks probably needs to be changed to some more memory-efficient approach, like an array of unicode-keycode pairs to be searched?
Then, of course Russian needs to be added in keylayouts.h, and boards.txt. If an array is used for beyond U+00FF, code to generate that array needs to be written in keylayouts.c.
Hopefully this lengthy message helps explain the massive work needed in the software. I am actually interested in doing much of this work. There are 2 main reasons I have never attempted to implement non-latin keyboards. #1: I do not know how they work (exactly what key presses are used to select latin vs cryillic), and #2: I need someone like you to help test and verify if the code actually works on real computers in Russia....