Mac keycodes for Option and Command keys appear swapped

[RonaldPR]

I am working with a BasiliskII for Linux user to edit the keycodes file to add SDL2 scancode to Mac keycode translations for SDL2 builds of BasiliskII and SheepShaver for Linux. He compiled BasiliskII from this source on 16 June 2021.

We found that the Mac keycodes for Option and Command keys are swapped.

The Mac keycode for Option is 58 and the Mac keycode for Command is 55, not only in BasiliskII and SheepShaver. However, now keycode 55 in the keycodes file activates the Option key and keycode 58 activates the Command key in BasiliskII and SheepShaver.

I checked other builds. Recent Windows builds appear to be affected the same way, macOS builds are not affected. But also Windows builds from last year are not affected. Those older builds were used while editing the keycodes file to add SDL2 scancode to Mac keycode translations for SDL2 builds of BasiliskII and SheepShaver for Windows.

The key swapping is apparently caused by the 7 February 2021 commit "fixed swapping opt and cmd key if keycode file is used": fbddf06

I do not know what the issue was that led to this "fix". Was it with Windows or with Linux? Which keycodes file was used? Which keyboard (ISO, ANSI, other) was used?

In my opinion this commit should not have been added. If Command or Option keys do not work as expected, or not to the user's liking, or not all, this should be corrected in the keycodes file, not in BasiliskII source.

The result of this fix can again be fixed in the keycodes file by using 58 for Command and 55 for Option, but that is not how it should be.

The original keycodes file cannot be used with SDL2 builds. With a keyboard layout that differs much from a US English layout, it would be impossible to even type a simple text.

I first added the SDL2 to Mac translations to the keycodes file for macOS, and later also for Windows. These keycodes files are distributed with builds for Windows and macOS on Emaculation.com.

Basically, and unlike before, the SDL2 to Mac translations are identical for macOS, Windows, and Linux. However, Windows and Linux hosts highjack some keys for their own use, keys that could otherwise be used for Mac modifier keys in BasiliskII and SheepShaver.

In Windows the (Windows) Logo keys are highjacked and cannot not be used. And in Windows on a ISO keyboard the Alt Gr (Alt Right) key equals Control-Alt on a ANSI keyboard. The SDL2 scancode for the Alt Gr key is 224 + 230 (Control Left + Alt Right). So the Left Control and the Right Alt key must be used for the same Mac key.

After some trials we decided to this solution for Windows in the keycodes file:

224	58	# Ctrl Left (--> Option)
# 227		# Logo Left
226	55	# Alt Left (--> Command)
44	49	# Space
230	58	# Alt Right (--> Option)
# 231		# Logo Right
101	50	# Menu (--> International)
228	54	# Ctrl Right

This key mapping is explained in a ReadMe that is included with the SheepShaver and BasiliskII builds for Windows.

But in recent builds (after 7 February) the keys are swapped.

Ctrl Left --> Mac Command

Alt Left --> Mac Option

Alt Right --> Mac Command

Ctrl Right --> Mac Control

In my opinion the 7 February key swapping fix should be reversed. If a different key mapping for the modifier keys is desired, the change should instead be made in the keycodes file. The Mac keycodes can then be used correctly.

The keycodes files that are currently used for BasiliskII and SheepShaver downloads on Emaculation.com can be found here:
http://ronaldpr.home.xs4all.nl/basiliskiiforum/BasiliskII_keycodes.zip
http://ronaldpr.home.xs4all.nl/sheepshaverforum/keycodes.zip
The files are identical, only the file names differ.

These files contain SDL2 scancode to Mac keycode translations for macOS and Windows, not yet for Linux.

[kanjitalk755]

Use prefs item swap_opt_cmd.
See #79.

It does work, but only when keycodes is not used.

I fixed it based on pointed out.
See #59 for more details.

[RonaldPR]

That is not a good solution. These settings must be added or changed manually in the prefs file. The average user cannot be expected to do that. The default behaviour should be correct for most users. I have no time now to sort out exactly where and when the undesirable key swapping happens. I will come back later.

[RonaldPR]

I will try again, hopefully I can explain the issue more clearly now.

Some time ago I saw the Option-Command swap feature come by. It had little impact on macOS builds and I did not give it much thought. Apparently, for whatever reason, some want the keys swapped.

But now, while trying to edit the keycodes files for Linux builds, I realised that this key-swapping interferes with the use of keycodes files in Windows and Linux builds.

Apparently swap_opt_cmd true is the default now for Windows and Linux builds.

(The swap_opt_cmd item appears in prefs files with a new or changed setup, but in some cases users can upgrade to a newer BII/SS build without the swap_opt_cmd item appearing in the prefs file.)

The order of the keys is different on Mac and Windows keyboards. That order is determined in the keyboard, not in the OS.

Windows keyboard:	Control 224 - Logo 227 - Alt 226 	Alt 230 - Logo 231 - Control 228
Mac keyboard:		Control 224 - Alt 226 - Logo 227	Logo 231 - Alt 230 - Control 228

The numbers are the SDL2 scancodes
The Mac Alt key is called the "Option" key
The Windows Logo key is called the "Windows" key
The Mac Logo key is called the "Command" key (used to be the "Apple" key)

Without a compatible keycodes file it may indeed be useful to swap Option and Command keys for Windows and Linux builds, assuming that probably all Windows users and most Linux users will use a Windows keyboard.

The old keycodes files cannot be used for the SDL2 builds. I have been editing the keycodes files by adding the SDL2 scancode to Mac keycode translations. For all keys on all three platforms the translations are identical, except for the modifier keys. I will only show the translations for these keys here.

Mac keycode for Option is 58
Mac keycode for Command is 55

I started with the translations for macOS. Pretty straightforward:

224	54	# Ctrl Left
226	58	# Option Left
227	55	# Command Left
44	49	# Space
231	55	# Command Right
230	58	# Option Right
228	54	# Ctrl Right

Last year I proceeded by adding the translations for Windows:

224	54	# Ctrl Left
227	58	# Logo Left (--> Option)
226	55	# Alt Left (--> Command)
44	49	# Space
230	55	# Alt Right (--> Command)
231	58	# Logo Right (--> Option)
228	54	# Ctrl Right

But it appeared that the Windows keys could not be used as these were highjacked by Windows (Start menu).
That left BII/SS without Option key. So I made the left Control key to work as Option key:

224	58	# Ctrl Left (--> Option)
# 227		# Logo Left
226	55	# Alt Left (--> Command)
44	49	# Space
230	55	# Alt Right (--> Command)
# 231		# Logo Right
228	54	# Ctrl Right

(On ISO keyboards the Alt Right key is the Alt Gr key. Alt Gr functions the way Control-Alt would on a ANSI keyboard, scancodes 224 + 230. Alt Gr will thus translate to Option-Command.)

This worked fine last year, but it does not work as intended in recent builds, apparently as a result of the key swapping.

I encountered the same issue while trying to add the translations for Linux.

When a compatible keycodes file is used (keycodes true) the behaviour in BasiliskII and SheepShaver should be without Option-Command swap.

Possible solutions:
1. Maybe it can be made such in Windows and Linux that setting keycodes true will also set swap_opt_cmd false.

2. Alternatively I could switch the Mac keycodes 55 and 58 in the keycodes files, use 55 for Option and 58 for Command. It is possible, but it does not feel right. Everywhere in the keycodes files keycode 55 is Command and keycode 58 is Option. Also used in AppleScript: https://eastmanreference.com/complete-list-of-applescript-key-codes

Note:
I hope to be able to have the keycodes file edited to be compatible with Linux soon. That will be a keycodes file for Linux with a Windows keyboard. It is not possible to have the keycodes file be compatible with Linux with both Windows and Mac keyboards. If Linux does not have keys that cannot be used, the Option-Command swapping could be useful here.

[kanjitalk755]

Reverted before fbddf06.
This means that swap_opt_cmd is forced to false if the keycodes file is valid.

[RonaldPR]

In what way is decided if the keycodes file is "valid".

Edit: I mean: when is the keycodes file "valid"?

[kanjitalk755]

"valid" means:
keycodes is true and
keycodefile is readable and
the video driver name (e.g. sdl x11) is found

[RonaldPR]

Thank you.

(In the currently provided keycodes files the driver sdl x11 is still at the top of the SDL1 translations. As soon as SDL2 translations for Linux are sufficiently tested, new keycodes file will be made available.)