keylayout file, scan code to unicode

[Jason Addison]

How can I map an arbitrary "scan code" to an arbitrary unicode character in a Mac keylayout file?

(I don't really know enough to know if this is even possible or if I'm even asking the right questions.)

Details:

I have an external Atreus keyboard that has Chrysalis software to configure it.

You can, if understand correctly, have a key send an arbitrary "scan code", like 65534.

So then, I'm guessing, on the os (Mac) side I need to map that scan code to a character.

I see in the keylayout file that a "key code" is mapped to an "output".

I tried to enter something like this, but it didn't work (see the last few lines with "key code" like 65531, 65532, 65533, 65534):

...
<keyMapSet id="16c">
    <keyMap index="0">
        <key code="0" action="a14"/>
        <key code="1" output="s"/>
        <key code="2" output="d"/>
        <key code="3" output="f"/>
...
        <key code="125" output="&#x001F;"/>
        <key code="126" output="&#x001E;"/>
        <key code="65534" output="◊"/>
        <key code="65533" output="√"/>
        <key code="65532" output="÷"/>
        <key code="65531" output="≥"/>
    </keyMap>
...

[Gé van Gasteren]

I’m tempted to ask: What’s the real question?

Because how in the world are you going to generate those scancodes / key codes?

"Key codes are integers between 0 and 511, although the usual range is from 0 to 127."

They are hard-wired into the hardware keyboard.

Ukelele allows you to check directly which key code is generated by a certain key: Click on the (i) icon to bring up the Inspector window, then click on tab "State".

And the keyboard layouts Ukelele can edit are basically "translation files" that determine which character is displayed when a certain scancode (plus a certain combination of modifier keys) is received by the OS.

There might be some possibilities however, if you realize that the single-byte scancodes could be used in pairs, to produce a 16-bit number.

But all depends on the question whether you can influence how the OS reacts to those scancodes.

What did you expect to happen after you activated a custom layout with definitions like "<key code="65534" output="◊"/>" ?

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/167a6948-427f-490c-86f3-f17136779968n%40googlegroups.com.

[Jason Addison]

What did I expect to happen with "<key code="65534" output="◊"/>"?

In the Chrysalis software for the keyboard, I configured a key, the "B" key (in the 3rd layer), to send a "Custom key code" of 65534, at least that is what I think I've done. (From what I can tell, the Atreus keyboard is essentially an Arduino computer, that can be configured to do just about anything.)

Then I put those lines, manually, in a keylayout file.

That freaked out System Preferences, nearly crashed it, as far as I can tell.

I would have been surprised if it worked, but I as hoping I would get a "◊" when I pressed the "B" key after activating the 3rd layer on the keyboard.

[Aside: I have my keyboard configured to activate the 3rd layer by holding the Fn key, pressing the Esc key, then hitting the Fn key again. Hitting the Esc key returns to the keyboard to the base, 0 layer. I'm sure this works, though there is probably a much better way to set this sort of thing up.]

The real question?

What I'm ultimately hoping to accomplish is to be able to enter glyphs for APL and BQN computer languages quickly and efficiently from my Atreus keyboard. The BQN project has a keylayout file that looks like it was generated by Ukelele, which is how I found out about Ukelele, and layout files. I think the BQN-provided file is intended for a traditional keyboard that will be used in gui editor. I mostly work in a terminal and disable the Apple configured fancy keyboard stuff in order to have access to things like the Meta (Alt) key for emacs and readline.

As a little test, I set layer-3 keys: A, S, D to X, Y, Z, and B to "Custom key code" 65534. Using Ukelele info, A, S, D worked as expected, giving X, Y, Z, but B didn't register anything (the "Key Code" utility reported the same results). I also tried setting B to send 511, but that had the same behavior as with 65534. Maybe that is because I don't have anything entered in a keylayout file?

[Gé van Gasteren]

In the Chrysalis software for the keyboard, I configured a key, the "B" key (in the 3rd layer), to send a "Custom key code" of 65534, at least that is what I think I've done. (From what I can tell, the Atreus keyboard is essentially an Arduino computer, that can be configured to do just about anything.)

Then I put those lines, manually, in a keylayout file.

What I'm ultimately hoping to accomplish is to be able to enter glyphs for APL and BQN computer languages quickly and efficiently from my Atreus keyboard.

 

[Aside: I have my keyboard configured to activate the 3rd layer by holding the Fn key, pressing the Esc key, then hitting the Fn key again. Hitting the Esc key returns to the keyboard to the base, 0 layer. I'm sure this works, though there is probably a much better way to set this sort of thing up.]

All right, that shows me where some light is needed ;-)

1.

You are familiar with different layers like Shift + key and Option + key. The vital point here is that the key code sent by the keyboard remains the same, whether Shift, Control, or any other "modifier key" is held down. This means that there is no need for more key codes than there are keys on the hardware, because macOS differentiates, say, key code 5 and Option + key code 5.

So I encourage you to leave the key codes alone, except if you really need to do something fancy like changing the F5 key into "cursor key up" (keycode 126).

As long as you stick to redefining the output of "character keys", Ukelele is the tool you want.

2. Now to those extra layers.

a) You could define so-called dead keys to add complete extra layers, but they work only for one keystroke, then fall back to the "base layer".

For example: You type an ' then an E and what is produced is é. So it modifies the output of the E key for one keystroke. The next time you type E you just get e.

So that may not be what you’d want ideally.

You can check how that works by looking at the built-in layout "ABC Extended": With Option held down, about half the keys function as dead keys, giving access to a great number of special characters.

b) The Caps Lock key can double the number of available layers – if you don’t mind that that costs you the possibility of typing in ALL CAPS :

key ("base layer"; all modifier keys up)

Shift + key

Option + key

Shift + Option + key

Caps Lock + key

Shift + Caps Lock + key

Option + Caps Lock + key

Shift + Option + Caps Lock + key

I haven’t listed combinations with the Control or Command key, to be on the safe side as to the functioning.

To use the Caps Lock key like that, you may have to unlink the layer from the base layer ("Unlink Modifier Set…")

If you have based your custom layout on an existing one, chances are your every change at the Caps Lock level produces a parallel change at the base level.

c) You could activate "Sticky Keys". This is a System Preferences / Accessibility setting, useful for people typing with one hand, or having trouble holding down one key while typing another. But it also makes it possible to switch the complete layout assignment by typing one key, and switching back to the previous environment by typing that key again.

I hope that helps …

[Jason Addison]

Very helpful ... Thanks! I'm starting to figure this stuff out, though slowly.

It's too bad that keyboards don't/can't send simple codes with limitless configuration. I guess when they were developed that sort of technology wasn't really an option.

[Gé van Gasteren]

On Thu, Oct 21, 2021 at 1:07 AM Jason Addison <jrad...@gmail.com> wrote:

Very helpful ... Thanks! I'm starting to figure this stuff out, though slowly.

It's too bad that keyboards don't/can't send simple codes with limitless configuration. I guess when they were developed that sort of technology wasn't really an option.

Maybe you haven’t discovered Ukelele’s PDF Manual yet?

It’s on the Help menu …

Re. keyboard technology: Here’s the old way (Wikipedia):

Computer keyboards include control circuitry to convert key presses into key codes^[42] (usually scancodes) that the computer's electronics can understand. The key switches are connected via the printed circuit board in an electrical X-Y matrix where a voltage is provided sequentially to the Y lines and, when a key is depressed, detected sequentially by scanning the X lines.

Maybe modern keyboards use different technology, but I guess the scancode output hasn’t changed, for compatibility reasons. Yours is a notable exception …