-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing key with german keyboard on MacBook Pro M2 using Apple Virtualization framework #5037
Comments
I use UTM with DEBIAN 11 (LDXE) on a Macbook M1 with german Keyboard and 16GB memory I wish the following command would be incorporated in the Config GUI (or I didn't find it) and/or be part of the installation procedure. login as root: The "^" key - I have to press the key twice |
unfortunately the above setting does not provide for |
I modified the configuration (in english now)
"hidden" characters |
@ferdiga The behaviour is actually the same with different keyboard-configurations. I don't think it's a guest problem, as xev does not even show a keycode for the "^°" key. |
I would suggest to display the current keyboard mapping in the UTM-Help Menu - if this possible at all |
This is a bug in Apple's virtualization framework (probably in virtio keyboard device) affecting Macs (with Apple Silicon chips but probably also MacIntel machines) with a physical keyboard that have an ISO mapping (like French Azerty keyboard , German keyboard, Danish keyboard, etc.). The framework bug transforms the ISO mapping into ANSI mapping (that of American Qwerty keyboards) with these problems of keys missing or not in their place : For example (for French Azerty Keyboard), the code for the @ key on an 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). The problem concerns both MacOS VMs and Linux VMs and the integrated keyboards of MacBook (Pro) as well as separate keyboards (like Apple Magic Keyboard, etc.). It concerns all software that uses this framework, UTM included. The ideal is that Apple fixes this bug. |
well it would already be helpful if during the installation the command |
The Here is a sample how it can look: {
"description": "'^' <-> '<', nodeadkeys @ QEMU",
"manipulators": [
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.utmapp\\.UTM$",
"^com\\.electron\\.nativefier\\.proxmox-"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "non_us_backslash",
"modifiers": {
"optional": [
"left_shift",
"right_shift",
"caps_lock"
]
}
},
"to": [
{
"key_code": "grave_accent_and_tilde"
},
{
"key_code": "spacebar"
}
],
"type": "basic"
},
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.utmapp\\.UTM$",
"^com\\.electron\\.nativefier\\.proxmox-"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "grave_accent_and_tilde",
"modifiers": {
"optional": [
"left_shift",
"right_shift",
"caps_lock"
]
}
},
"to": [
{
"key_code": "non_us_backslash"
}
],
"type": "basic"
},
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.utmapp\\.UTM$",
"^com\\.electron\\.nativefier\\.proxmox-"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "equal_sign"
},
"to": [
{
"key_code": "equal_sign"
},
{
"key_code": "spacebar"
}
],
"type": "basic"
},
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.utmapp\\.UTM$",
"^com\\.electron\\.nativefier\\.proxmox-"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "equal_sign",
"modifiers": {
"mandatory": [
"shift"
]
}
},
"to": [
{
"key_code": "equal_sign",
"modifiers": "left_shift"
},
{
"key_code": "spacebar"
}
],
"type": "basic"
},
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.apple\\.terminal$",
"^com\\.googlecode\\.iterm2$",
"^com\\.google\\.android\\.studio$"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "n",
"modifiers": {
"mandatory": [
"option"
]
}
},
"to": [
{
"key_code": "n",
"modifiers": "left_option"
},
{
"key_code": "spacebar"
}
],
"type": "basic"
}
]
}, To get the other stuff that I expect from a Mac keyboard in Windows, I install I guess the very right move would be to do it like Parallels with a kbdEdit keyboard layout for Mac keyboards, but my method is also portable, since PowerToys supports to export/import settings. Couldn't find the kbdEdit image from a trustworthy source and I needed something quick. Hope this helps. |
Among the new features of apple's virtualization framework for MacOS Sonoma, I see that a new class has appeared: Perhaps a solution to our ISO keyboard problems and better management of Mac keyboards? |
The problem ultimately remains with Sonoma (Beta 2). 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. |
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/ |
For people using French Azerty Keyboards in macOS VMs, here is the rule I am using in Karabiner (add it to the "rules" section of your "karabiner.json" file):
|
Having a french keyboard I also stumbled on this problem when trying out UTM instead of Parallels (I want to see if I can build my QT app on windows x86 from my new M3 macbook and sell my old intel macbook). From the Howard Oakley article, I see that the simplest solution instead of remapping a certain combination to those characters, is to use the standard, preexisting, obscure combination for those @ and # symbols, instead of installing a separate app within the VM, understanding how to set it up, and choosing my own key combination which I didn't manage to do easily :
|
Quelle galère ce clavier AZERTY |
Amazing ! There is news. Installing the final version of macOS Sonoma 14.5 seems to have partly resolved this bug, at least with the Azerty keyboard (Apple magic keyboard for example). Keyboard mapping is good now. The test was carried out with macOS 14.5, UTM 4.5.2 and a virtual machine updated to macOS 14.5. On the other hand, on a Linux VM (Ubuntu 24.04) using Apple's virtualization framework, the bug is still present, but with improvement: there is only an inversion of the mapping of characters between the @ keys and < . The rest of the keyboard is now OK. |
I am convinced, this is not a guest linux keymap problem
Describe the issue
Configuration
Debug log
How to activate for Apple Virtualization?
Screenshots
![photo_keyboard](https://user-images.githubusercontent.com/368751/219852494-0fbc6798-f390-44c3-b58e-f73c1320e008.jpg)
The text was updated successfully, but these errors were encountered: