TeensyKeyboard support complete? (Alternatively: Unicode support?)

[nariox]

Hi,
I'm trying to write a keyboard program to send unicode characters (I've built a 4x4 macro keyboard, but only ended up using about half of the keys, then I realized I could use it to send emoticons like this ¯_(ツ)_/¯, but haven't been able to yet)

I'm trying to use the TeensyKeyboard, since the improved and boot keyboards don't seem to have support for it (or am I mistaken?). But when I try to compile my sketch (even the TeensyKeyboard example sketch), I get "'TeensyKeyboard' was not declared in this scope". Looking into the source, it seems like the USE_TEENSY_KEYBOARD variable is not hooked up to any part of the code.

So, my question is, is the TeensyKeyboard support complete/dropped? And also, is it possible to print Unicode keys with it (or without it for that matter)?

Thanks

[NicoHood]

No its not and I have no idea how to implement this. Also Paul does not want that I copy his keyboard layout code. And I personally do not need unicode and dont have time to implement this for fun.

Duplicate of #22

[nariox]

Thanks for the quick reply. Apparently adding 16-bit characters is not part of the HID specification anyways, so a software solution is probably the way to go or a workaround using the alt method is best as suggested in #22 . If I find out any "cross-platform" way, I'll sure let you know. Thanks again.

[NicoHood]

That has nothing to do with the HID specs. It depends on your keyboard layout and the teensy will send the keys that are required to give a special character. That might depend on the keyboard setting. So on an english keyboard you would never have a chance to get the german "umlaute" öäü for example. Correct me if I am wrong.

You can use the raw keyboard to add your very own, custom pressed. You can build another layer around that and even provide a library for that if you are doing it good. That'd be the best idea anyways if you ask me.

[nariox]

Yes, what I mean is that the implementation of HID simply sends Keycodes and Modifiers, it's up to the OS to map them into characters. Regardless of whether I'm allowed to type ä or if the OS will simply type "a instead. I mean, if I set my layout to be AZERTY, if I type "Q, I'll get ä. So there needs to be support on the OS/Driver to map keystrokes into actual letters. I can't just send a (unicode) character directly through the keyboard (I just read this thread, seems relevant: kiibohd/KiiConf#30 (comment))

Since I'm not planning to mass-produce this, I guess it's fine if I just hard-code the Alt method to compose the keys I want.

Anyway, thanks for the help. (;

[donid]

Hi, I receive the same error in the TeensyKeyboard-example as described above and this discussion hasn't described a way to solve this yet, has it? My guess would be that TeensyKeyboard has been renamed to TeensyKeyboardAPI, right? But where/how do I include TeensyKeyboardAPI.h and where do I define LAYOUT_GERMAN? My goal is to send the '<' and '>' keys with a german keyboard layout.
Could you fix the example and modify it to show how to use a different (e.g. german) keyboard layout?

[NicoHood]

Oh. I need to delete the example. Its just not supported and from an old dev try.

[donid]

So, HID-Project doesn't support different language layouts? Or is there another way to achieve the described goal?

[NiKiZe]

@donid just send the keyboard scancode, in http://www.usb.org/developers/hidpage/Hut1_12v2.pdf at page 53 you can see the HID spec for this. The <>| key is scancode 0x56 Which is HID code 0x64 The above PDF was not clear on this, but below pdfs note was more helpfull: http://www.siongboon.com/projects/2007-12-08_ascii_code/HID%20keyboard%20code.pdf

so for < send 0x64 and to send > just combine 0x64 with the Shift key press

[NicoHood]

Its not implemented yet and I will not do it. You can use the codes as suggested above and create a wrapper library. Feel free to implement this and let us know in #22

[donid]

As far as I understand the existing code, I would only have to modify ImprovedKeylayouts.h like this:

#if !defined(LAYOUT_US_ENGLISH) && !defined(LAYOUT_GERMAN)
#error This API does only support US english and german layouts.
#endif



#ifdef LAYOUT_US_ENGLISH
static const uint8_t _asciimap[] PROGMEM =
{
//currently used values
}
#endif


#ifdef LAYOUT_GERMAN
static const uint8_t _asciimap[] PROGMEM =
{
//modified values for german layout
}
#endif

Or am I missing something?

[donid]

@NiKiZe Thanks for that info - I had found the same HID-code just before I saw your comment with the method described here (german blog post).

[NicoHood]

No you cannot modify this array. Create a wrapper and do not touch the library at all. This is the way to go!

The reason why you cannot modify the code is that on a german layout alt gr and other modifiers are required to reach some keys. And this will not work with this array, at leats not fully.

A wrapper would me much nicer and could also help other people.

[donid]

Please see my comment in issue 22

[heangfat]

Hi @nariox , I am not sure whether you can directly use Unicode Page 0x10 as introduced in Page 108 of HID Usage Tables.

I will start to make a big keyboard with about 500 to 600 keys with Unicode characters. I want to make my keyboard boot compatible (meaning all keys can work in BIOS and DOS before Windows/Linux/Macintosh is loaded).

[nariox]

Hi @heangfat, Not sure if the latest specifications allow it, but this one you've linked limits it to a two octet unicode character (16-bit), so you'd only be able to reach 0x0~0xFFFF. If you want to reach unicodes greater than these, you'd probably have better luck using the compose-keys, but as far as I know, these are not OS-agnostic.

[szabi]

While the specification (stemming from the 90s) says "UCS-2", interpreting the stream as UTF-16 would actually allow you to cover all of Unicode.

Given that the codepoints for the surrogate pairs are defined in Unicode and reserved codepoints, even if old devices would use page 0x10 they would not be allowed to send those in UCS-2, so interpreting UCS-2 as UTF-16 would not break existing devices (of which we know, btw, not any to exist).

[szabi]

To back up what I said (UTF-16 and UCS-2 being virtually interchangably usable):

The IBM® i operating system supports CCSID 13488, defined as UCS-2, and CCSID 1200, defined as UTF-16. The system treats both CCSID 13488 and CCSID 1200 as UTF-16 encodings.

Using either scheme, you will have the same results for almost all system operations. However, certain SQL functions that operate on a character boundary defined by the SQL standard can produce different results. For instance, the SQL functions of CHARACTER, LENGTH, POSITION, and SUBSTRING distinguish UTF-16 and UCS-2, and therefore you get different results. See the SQL reference for more information about these functions.

IMB.com: UCS-2 and its relationship to Unicode (UTF-16)

This last example of SQL can be disregarded, as it is the driver alone that would interpret the stream as UTF-16 enabling all planes of Unicode.