Compose key(s) in firmware

Programming
1

One of the things I want most from the Model 01 is a compose key for entering various non-ASCII characters. I’m still hoping that I’ll be able to plug my keyboard into a new computer, put it into the mode that matches the host OS (linux/macos/windows), and have the compose key work without needing to do any further configuration on the host. It would be a small nuisance to have to tell the host what kind of keyboard I’m using explicitly, but I consider it a much bigger nuisance to go much further than that (i.e. if I have to tell it to consider my keyboard to be a pc-105-key keyboard, that’s okay, but if I have to download anything or do extensive reconfiguration on the host to make it work, such as the hoops that need jumping to get a compose key on a Mac, I’ll probably just give up and have a less-functional keyboard than I want). I also want the compose key table to be configurable and to be consistent regardless of which host OS it’s connected to.

I can’t tell yet if this is possible to do in the firmware, both because there may not be sufficient storage for the whole compose tree or because the default keyboards just aren’t capable of generating all the characters I might want. Can anyone fill me in on the practicality of setting something like this up?

Also, is anyone else on this forum interested in setting up a compose key on their Model 01 as a means of typing occasional non-ASCII characters?

4 Likes
2

I’m raising a hand here, as I want to implement a Compose key on my Model 01. It’s non-trivial to do it without OS-side help, and in some cases, even impossible. To input symbols that are not on the OS keymap (not even with AltGr), you need some kind of OS support: either a compose key, unicode input, and so on.

Explaining how it all works is… rough, and I lack the time to do so, but thankfully there are a lot of people here who know a whole lot more about languages and various input methods than I do. So, for now, I just signalled my interest in a Compose key that works - in my case - on Linux, with GNOME, and an US-QWERTY layout on the host. I’ll need Hungarian and German symbols at least.

1 Like
3

Can you give me a pointer to a description of a standard keymap with AltGr that shows what characters can be entered that way?

And do you know if your unicode input trick could work, or would it use up too much memory on the controller storing the compose table and mapping those sequences to unicode?

1 Like
4

QWERTZ - Wikipedia has a bunch, for example the Hungarian one:

800px-KB_Hungary.svg.png800×267 30.6 KB

The blue labels are the symbols you can input with AltGr.

It works, I’m using unicode input for plenty of stuff on my ErgoDox EZ, which has similar constraints as the Model 01. You can’t have everything in the firmware, but a subset - sure. At the moment, the Unicode input stuff uses about 8-10 bytes / symbol, and that counts towards code, not the tiny 2k memory. So it’s not too bad.

Mind you, the thing I use at the moment does not operate with a compose table. But adding that should fit within the constraints too, I believe. Depends on what other things you want to cram into the keyboard firmware, too.

1 Like
5

Just adding my +1 for a working compose key. Very much mirroring @merlin’s wishes. It would be wonderful if it would work on any machine the keyboard plugs into, without configuration.

My compose map in Linux is all the defaults, of which I use quite a lot, but with some changes. For example, I’ve added a bunch of emojis to it. Compose ^ _ ^ for :blush: for example. I’d love these to be built in to my keyboard!

I was thinking the “any” key was a good target for my compose key.

1 Like
6

Also definitely interested. I don’t currently dual boot but if I do in the future it’d be nice if compose Just Worked. Even on Linux there’s inconsistency between applications on how the Compose key works, and I can’t figure out the input method mess between Qt and GTK+ enough to fix it.

+1 to Unicode input, sounds like the least fragile and most extensible way to do it, even if it requires a custom driver.

7

That’s exactly where I’m going to try it.

After doing some investigating, MacOS seems particularly awful for setting up a working Compose key, but it’s pretty simple to enable Unicode Hex Input, which seems like the way to go. I don’t think any custom drivers will be necessary. I think the big question is how much space the table of Compose rules will take up in the firmware. If it’s too big, maybe the best thing would be to have a smaller table for a limited set of unicode input sequences, and use the host OS to produce characters beyond that set.

1 Like
8

I spoke too soon. For mysterious reasons, Unicode Hex Input completely fails for Emacs (and Aquamacs) on MacOS. I guess it only works for apps that use the Cocoa text input system, which is far less universal than I want.

9

My experience is that while Unicode input works, it is far from the most reliable, or fastest thing. OS-assisted Compose is considerably faster, and more reliable, as far as I see. I mean, Unicode input is usable, especially on a Mac, but on Windows, its awkward at best, I was told: the built-in unicode input works in everything but Office apps, those need a different method. So most people I saw using QMK’s unicode input with Windows, ended up installing additional software (usually WinCompose, which is pretty much needed for proper Compose key behaviour too).

Just saying its not a silver bullet, and has considerable downsides too. Still useful, still better than nothing, but not a silver bullet.

…and yeah, this too. Same thing on Windows and Linux too.

Unless you fill your firmware with useless junk, it will fit. Assuming that a rule is just a sequence, an average composed input is about 3-4 keys, thus 6-8 bytes. Add some overhead for some meta-data, and we are looking at something like 10-16 bytes / rule. Since the rules are immutable once compiled, meaning we do not want to change them at run-time, they can be put into the code segment, and won’t eat into the tiny 2k memory, and there’s plenty of space in the code area. (My current firmware, which has a lot more bells and whistles than the default one, still has about 4k free, which is plenty.)

So, as I said before, compose tables aren’t an issue, unless you want to cram the entire unicode table, or all possible compose sequences into the firmware. That will never work. That’s where language pack plugins may be of great help.

1 Like
10

…yeah, thinking about it most input APIs don’t understand Unicode. Nevermind >.>

11

Don’t get me wrong, it is still useful, just not universally. I work in a Linux + Emacs + GTK environment exclusively, and unicode input works there just fine. A bit slower than normal typing, so if I used that to input Hungarian, my speed would drop noticeably, but for the occasional Unicode symbol, it’s fine. ¯_(ツ)_/¯

:coffee:

1 Like
12

I think I’ll just give up tilting at this particular windmill, and rely on host-specific compose key setups. I know Linux will work, and I’m pretty sure I can get the Mac to do what I want (set up my compose key with Karabiner to get converted to F13, and configure Emacs to turn that into C-x 8). And on machines that I haven’t set up, I can make do without being able to type those characters.

13

Just wondering if there are any new developments in the last year and a half on this front. I’d still love this feature.

14

I don’t think this will ever be practical on an ATmega32u4 (i.e. Model01) because it just doesn’t have enough memory. On an ARM MCU, it might be.

15

Would a smaller list be doable? I could pare down the default linux compose list to the stuff I have actually used or could see myself wanting, and it’d be quite a difference I’m sure…

16

A small list should be possible, but even then it would require some configuration on the host to make sure it works properly.

17

It would all be so much simpler if the keyboard could just send characters to the host instead of keycodes…

18

Can it detect the host OS and make a best guess? Like if it’s windows, to insert a smiley face it’ll hold alt and type some keypad numbers; if it’s OSX it’ll do something else; if it’s Linux it’ll do something else?

1 Like
19

Not reliably, no. There’s the FingerprintUSBHost library that HostOS used to use, but it was more trouble than worth. With a small helper tool, that tells the keyboard what the OS is, this would be much simpler.

1 Like