Bad keyboard mapping in Linux with macOS virtualization

[M-Rick]

When creating a new Linux VM using the built-in Apple virtualization, the keyboard mapping is incorrect.

I use an Apple French mapping keyboard. And UTM will map the #/@ key to the </> key located next to the left SHIFT. The top key #/@ under ESC is unrecognized. No problem in other virtualization like Parallels, VMware or in UTM using QEMU instead of the Apple virtualization.

On the screenshot below, the mapping is correct, but doesn't match to the real behavior.

Configuration

• Until UTM Version: 4.2.5
• macOS Version: from macOS 11 to macOS 13
• Mac Chip (Intel, M1, ...): Intel

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Backend</key>
    <string>Apple</string>
    <key>ConfigurationVersion</key>
    <integer>4</integer>
    <key>Display</key>
    <array>
        <dict>
            <key>HeightPixels</key>
            <integer>1200</integer>
            <key>PixelsPerInch</key>
            <integer>80</integer>
            <key>WidthPixels</key>
            <integer>1920</integer>
        </dict>
    </array>
    <key>Drive</key>
    <array>
        <dict>
            <key>Identifier</key>
            <string>039CA56B-8098-4D17-A649-C35F8D3037C7</string>
            <key>ImageName</key>
            <string>039CA56B-8098-4D17-A649-C35F8D3037C7.img</string>
            <key>ReadOnly</key>
            <false/>
        </dict>
    </array>
    <key>Information</key>
    <dict>
        <key>Icon</key>
        <string>linux</string>
        <key>IconCustom</key>
        <false/>
        <key>Name</key>
        <string>Ubuntu Jammy Jellyfish</string>
        <key>UUID</key>
        <string>1E7D631B-24C7-438A-8D49-BEB2F061A675</string>
    </dict>
    <key>Network</key>
    <array>
        <dict>
            <key>MacAddress</key>
            <string>e2:6d:cc:32:01:fb</string>
            <key>Mode</key>
            <string>Shared</string>
        </dict>
    </array>
    <key>Serial</key>
    <array/>
    <key>System</key>
    <dict>
        <key>Architecture</key>
        <string>x86_64</string>
        <key>Boot</key>
        <dict>
            <key>EfiVariableStoragePath</key>
            <string>efi_vars.fd</string>
            <key>OperatingSystem</key>
            <string>Linux</string>
            <key>UEFIBoot</key>
            <true/>
        </dict>
        <key>CPUCount</key>
        <integer>0</integer>
        <key>MemorySize</key>
        <integer>4096</integer>
    </dict>
    <key>Virtualization</key>
    <dict>
        <key>Audio</key>
        <true/>
        <key>Balloon</key>
        <true/>
        <key>ClipboardSharing</key>
        <true/>
        <key>Entropy</key>
        <true/>
        <key>Keyboard</key>
        <true/>
        <key>Pointer</key>
        <true/>
        <key>Rosetta</key>
        <false/>
    </dict>
</dict>
</plist>

[naga-re]

It's a bug in Apple's virtualization framework. See #5037 and #4041 for example.

Also report on Apple's Feedback Assistant; there are already several on this bug : FB11898180, FB11489872, etc.

[naga-re]

Among the new features of apple's virtualization framework for MacOS Sonoma, I see that a new class has appeared:

VZMacKeyboardConfiguration

Perhaps a solution to our ISO keyboard problems and better management of Mac keyboards? Even if it's too early (we're only in the first beta of Sonoma), are the UTM teams planning to integrate these new features in a future version of UTM?

[naga-re]

The problem ultimately remains with Sonoma (Beta 2). If the support of the function keys and controls of the Mac are appreciable (globe key, sound, multimedia, etc.), the bug of the bad mapping of the ISO keyboards (French, Danish, German, etc.) is unfortunately not always not corrected, while the keyboard works perfectly on the beta directly installed on a Mac, without going through a VM.

Explanation and solution of this bug:

The code for the @ key on a French ISO keyboard is 0Ah, but the code for this key on an ANSI keyboard is 32h (which is the code for the extra key < in ISO). That explains why I don't see the @. It's on the code key 0Ah which does not exist.

The virtualization framework does, for some reason that I cannot explain, this code replacement for the keys, taking into account neither the settings of the keyboard of the host machine, nor the settings of the keyboard of the virtual machine.

[naga-re]

Howard Oakley, from the excellent site The Eclecticlight Company has just published a post on this problem and made a bug report to Apple:

https://eclecticlight.co/2023/06/27/keyboard-layouts-in-lightweight-virtualisation/