Support non-US keyboard layouts

[hanshuebner]

If I'm reading the code correctly, there currently is no support for non-US keyboard layouts. Do you have any hints as to how that could be implemented, or do you have plans to do so yourself? I'm guessing that different SelBindings would be required for each national variant. Would it be best to have a complete table for each layout or instead have a list of patches describing the differences to the US layout?

[delan]

to support non-us keyboard layouts in the sun keyboard protocol, we’ll need a setting that configures what type 4 layout code we send (sparc keyboard spec § 3.7). this can tell the software how to interpret our key codes, if it supports non-us layouts (e.g. openbsd sunkbdmap.c line 1045).

my understanding is that, to some extent, both usb and sun keyboards send the same key codes at any given location in all layouts. for example, a german usb keyboard would send Keyboard y and Y (1Ch) when you press Z¹, which we can still translate to 49. Y (3Bh), because the software will interpret 3Bh as Z when using a german layout (e.g. illumos type_4/germany line 46, openbsd sunkbdmap.c line 479).

we’ll need to fix the binding for Keyboard Non-US \ and | (64h) to send the <>| key (7Ch) instead of the \| key (58h), but beyond that i can’t say how our system needs to change without more research. maybe we need separate bindings for each national variant, maybe we only need separate bindings for type 5 layouts, maybe something else?

examples of differences between type 4 and type 5 layouts:

• on a german keyboard, #' is Keyboard Non-US # and ~ (32h)
  • → 75. ` ~ (2Ah) for the german type 4 #^
  • → 13. \ | (58h) for the german type 5 #'
• on a japanese keyboard, ]} is Keyboard Non-US # and ~ (32h)
  • → 75. ` ~ (2Ah) for the japanese type 4 ]}
  • → 13. \ | (58h) for the japanese type 5 ]}

examples of keys that didn’t exist on type 4 layouts:

• on a german keyboard, ^° is Keyboard Grave Accent and Tilde (35h)
  • → no idea what this should be for german type 4
  • → 75. ` ~ (2Ah) for the german type 5 ^°
• on a japanese keyboard, ¥| is Keyboard International3 (89h)
  • → no idea what this should be for japanese type 4
  • → 75. ` ~ (2Ah) for the japanese type 5 ¥|

we would definitely need separate bindings if you want to emulate a different layout to the usb keyboard you have, e.g. you want to send the \| key (58h) when you press Keyboard Non-US \ and | (64h), but i think that will make things very complicated, so let’s leave that out of scope for now.

¹ hid usage tables § 10:

Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate other languages.

[delan]

it’s hard to know how to solve this “perfectly” for all non-US layouts, but maybe we can focus on adding one layout at a time. do you have a specific layout in mind? (e.g. you want to use a german usb keyboard as a german sun keyboard)

[hanshuebner]

I personally don't care about non-US layouts, but a friend asked me whether usb3sun would support a German keyboard. I would be interested in helping with this.

For starters, I have changed the code so that it sends 5 as the keyboard layout code. It did what you indicated: Many keys (like z, y and the diacritical characters) changed their function to correspond to the german variant. This is already good, but then there are a couple of keys that are either incorrectly mapped (i.e. caps lock becomes control), that are unmapped (i.e. control does nothing now) or that are partially mapped incorrectly (i.e. Alt-8 should be [, but sends a backquote instead).

I think what is needed is a way to set the keyboard variant in the menu. The selection should switch between the available bindings (i.e. one of multiple UsbkToSunk instances).

I have to study the code more, but would there already be a way to define different Sun make/break codes for a key based on modifiers that are pressed, or does the code currently assume that the USB keyboard symbol combinations per key match that of the Sun keyboard?

[delan]

This is already good, but then there are a couple of keys that are either incorrectly mapped (i.e. caps lock becomes control), that are unmapped (i.e. control does nothing now) or that are partially mapped incorrectly (i.e. Alt-8 should be [, but sends a backquote instead).

i’m not sure about the control and caps lock problems, but while AltGr+8 is [ on a german type 5, it is ` on a german type 4. we currently emulate a type 4 keyboard, except for the power key. does AltGr+8 work the way you expect if you change this 0x04 to 0x05? (changing this may break other keys)

I think what is needed is a way to set the keyboard variant in the menu. The selection should switch between the available bindings (i.e. one of multiple UsbkToSunk instances).

good idea! do either of you have a real german sun keyboard? if not, we may need to determine the sun keycodes experimentally, because i think there are more keys on the german type 4 than listed in the sparc keyboard spec.

I have to study the code more, but would there already be a way to define different Sun make/break codes for a key based on modifiers that are pressed, or does the code currently assume that the USB keyboard symbol combinations per key match that of the Sun keyboard?

special bindings can do this, but they currently support right Ctrl only. for other modifiers, we would need to extend this into something more general.

[delan]

my understanding is that, to some extent, both usb and sun keyboards send the same key codes at any given location in all layouts. for example, a german usb keyboard would send Keyboard y and Y (1Ch) when you press Z¹, which we can still translate to 49. Y (3Bh), because the software will interpret 3Bh as Z when using a german layout (e.g. illumos type_4/germany line 46, openbsd sunkbdmap.c line 479).

i think the next step is to experiment with changing our response to the Layout Command (0Fh), which corresponds to the dip switches on a real sun keyboard. i suspect that will get us 80% of the way there, and if we’re lucky it may even be all we need for some layouts?

[hanshuebner]

I have a Type 4 keyboard and it has internal DIP switches. I can do some experiments to figure out the Layout Command responses. Do you happen to know how I can send commands to the keyboard and display the results, maybe from OpenFirmware or SunOS?

[delan]

i’m not sure, i would have to do some research, though for type 4 keyboards the response octet comes directly from the switches in msb-first order. see §§ 3.2.2 and 3.7 of the sparc keyboard spec (below), and see this file for a bigger list including type 5 layouts.