Emoji 😀 support for a different layer?

Hey all,

I bought the keyboard based on Simon’s video here (Referencing emojis)

I tried myself to add emojis to the keyboard but couldn’t do it on the Mac UHK Agent.

Am I missing something? I see he’s doing it on a windows client. Did anybody encode emoji’s on the keyboard on a mac?

Does this help? How to Enter a Unicode Character on a Mac - La De Du

This is from a long time ago, but I had the same question just now and ended up on this answerless page, so, here’s the (an?) answer.

If you want a macro to produce :grinning: then you have at least a couple of options that I’ve worked out. Both of them use the UHK macro </> Command action and both require that you turn on Apple’s Unicode Hex Input.

To turn on Unicode Hex Input:

  1. Open System Preference
  2. Select Keyboard
  3. Select the Input Sources tab
  4. Click the + button that’s underneath the left pane
  5. Scroll to the very bottom of the list of languages and click on Others (you can’t type that in the search box)
  6. Click on Unicode Hex Input on the right and then Add

Once that’s enabled, you’ll be able to press and hold the left-option (or Alt) key and type letters/numbers to have them interpreted as a UTF-16 encoded character.

If you need to use a different input source by default (e.g. you type in German or French or some other language that has a different keyboard layout then there’s a shortcut key that you can set and then use in your macro. To enable the shortcut key (and change it if you wish, because by default it clashes with Spotlight):

  1. Open System Preference
  2. Select Keyboard
  3. Select the Shortcuts tab
  4. Select Input Sources from the left pane
  5. Enable and modify the two input source selectors

OK, finally, you can set up your macro! As stated, you have at least two options:

  1. Three lines, but easier to copy/paste unicode strings into:

    holdKey sLA
    write "D83DDE00"
    releaseKey LA

    This uses holdKey to press and hold the Left Alt (or “Option” on the Mac) key. Note the prepended s, that sets the “sticky modifier” which means that this modifier applies to the subsequent key press events.

    write will type the provided string (I guess it’s probably the equivalent of press/release for each key).

    releaseKey does the obvious.

  2. Single line, but you’ll have to space out the Unicode:
    tapKeySeq sLA D 8 3 D D E 0 0

    tapKeySeq does the same thing as option 1, but requires you to type out each character of the D83DDE00 string space-separated, so the macro knows which individual keys to “press”. I’m not sure if you need to reset the sticky modifier anywhere but my reading of firmware/doc-dev/reference-manual.md at master · UltimateHackingKeyboard/firmware · GitHub makes me suspect not (next keypress should cancel it).

One important note! The string I’m using is D83DDE00 which is the UTF-16 encoding for :grinning: - see the page at https://www.compart.com/en/unicode/U+1F600 for an example of the various different ways that these characters can be encoded.

The UTF-32 Encoding is often the default on various websites but macOS expects UTF-16 for historical reasons so you need to use that version. You’ll see these numbers presented like 0x0001F600 (UTF-32) and 0xD83D 0xDE00 (UTF-16). The 0x is just a convention to indicate that the following number is hexadecimal, and you don’t need to include it when sending key presses for Unicode-interpretation.

Happy typing :slightly_smiling_face:


sLA … I’m not sure if you need to reset the sticky modifier anywhere

I don’t see any reason for using the sticky option at all. It should work just fine just with LA.

In any case you don’t need to reset it. It only prolongs the alt until the next key is pressed or until current layer is released.

Also, thanks for detailed guide!

Interesting! I don’t know if it’s a bug, or Operating System variance (I’m running macOS 12.7.5) or if I just don’t understand how things are working but, for what it’s worth, without that s this macro doesn’t work for me.

With the following macro I get 🙂:

holdKey sLA
write "D83DDE42"
releaseKey LA

With this one I get D83DDE42:

holdKey LA
write "D83DDE42"
releaseKey LA

Also, I’ve expanded the macro to automatically toggle to the Unicode mode (because I need to be able to use a different input mode normally). I have set the keyboard shortcut Ctrl+⌘+Alt+i to Select next source in Input menu and I have two input sources now so adding a leading and trailing tapKey LCLALG-i to the macro toggles the mode as part of the macro now.

For completeness, the current macro now looks like:

tapKey LCLALG-i
holdKey sLA
write "D83DDE42"
releaseKey LA
tapKey LCLALG-i

You don’t need the L for each of the control keys, CAG-i will work just the same, but they were the ones I pressed to create the shortcut, so I just ran with it.

Hmpf. Allright, in that case macOS apparently requires prolonged press of the alt. That could also be done by inserting a delay (like delayUntil 200 just before the releaseKey LA) instead. But I can see that sLA is more convenient :person_shrugging:.

Nope, I tried removing the s and adding delayUntil 200 as the fourth line (between the write and the releaseKey) and it didn’t work. I also tried extending the delay, just in case that helped but 2000 and then 20000 made no difference (and I’m sure it’s running, because with the longer delay I can visually watch the input source icon changing).

I’ll have access to an alternate macOS machine with a different OS next week. I’ll try it out there and see if the same thing happens.

If you have time, I’d be interested in understanding what the s actually does and how it compares (in theory) to the delayuntil. I’m not sure I really understand the Reference Manual because my reading of that is that the D that the write sends should “release” the sticky modifier, although perhaps it actually holds until the 2, because the write acts as an atomic action?

I see. You are totally right.

I have forgotten that in the same macro those pressKey and write use the same usb report buffer, so the write clears the modifier masks.

Anyway… In practice, sticky modifier mask doesn’t get cleared because it is processed differenty - it is stored in an independent global variable. It is then cleared once next key is physically pressed.

As for the purpose of sticky modifiers, assume standard Windows Alt+Tab behavior. Now map UHK so that mod+tab produces (sticky) alt+tab (sLA-tab in macro notation). The point of the sticky modifier mode is to make uhk keep alt pressed between the tab taps in mod+tab+tab, which is needed for proper window switching function. (So the fact that it doesn’t get cleared by write is correct, although it was not designed to be used the way you did.) Formally sticky modifier is active until next key action is activated (by a physical key press) or until the layer it was issued from is released.

You have read the Reference Manual wrong because the manual ambiguously states “until next key press”, without clarifying that the author (me) meant next physical key press rather than next produced scancode. I will fix the documentation shortly.

Now, the use of the sticky mask sLA is a nonconventional solution - it was not meant to be used this way. Proper-by-design solution is to use tapKeySeq pLA D 8 3 D D E 0 0 rLA, which however is bugged (:person_facepalming:). I will fix this shortly too, although it may take some time till it makes the release → Fix press modmask modifier. by kareltucek · Pull Request #777 · UltimateHackingKeyboard/firmware · GitHub .

Not sure if I have answered all the confusion, please do ask if anything remains unclear. And thanks for pointing me to the bug with tapKeySeq!