Open msander opened 1 year ago
I use UTM with DEBIAN 11 (LDXE) on a Macbook M1 with german Keyboard and 16GB memory I have to confirm various reports - extremely fast and low memory consumption.
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:
dpkg-reconfigure keyboard-configuration
I choose
Apple-Laptop
Deutsch-Macintosh
kein AltGr
keine Compose
Strg-Alt-Zurück - Nein
The "^" key - I have to press the key twice The "<>" key - work
unfortunately the above setting does not provide for @ and ~
any ideas?
I modified the configuration (in english now)
dpkg-reconfigure keyboard-configuration
I choose
Apple
German
right AltGr
no compose key
Strg-Alt-Zurück - No
"hidden" characters @ Option right + q ~ Option right + (+*) key
@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.
This is the keyboard layout for the above configuration
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. This bug has existed since the first Beta of Ventura. I reported this bug to Apple as early as August 2022. Apple asked me for clarification in early January 2023 to learn more and reproduce it. I haven't had any news since (Apple Feedback number : 11489872)
The ideal is that Apple fixes this bug. This bug can be temporarily fixed with Karabiner app by remapping the affected keys. In the worst case, UTM would have to patch this by offering key remapping when an ISO keyboard is used.
well it would already be helpful if during the installation the command
dpkg-reconfigure keyboard-configuration
would be executed or a hint would be given.
The ^
/<
swap is a common problem with German keyboards when being in QEMU with a MacOS host and it affects T2 Intel Macs as well. It's not just a problem of UTM, also when remote controlling VMs/LXCs in proxmox. I use Karabiner to swap those events and turn my deadkeylocks into nodeadkeys, so when I press ^
in any Terminals (incl. QEMU sessions) I will not have to press space afterwards to trigger it (nice for vim).
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 Microsoft.PowerToys
via winget and setup the keyboard manager to re-map all my stuff properly, so I get the most important mappings like []{}@~|\
like I'm used to.
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? 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?
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.
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):
{
"description": "Remap '@' to 'alt-`' in UTM",
"manipulators": [
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.utmapp\\.UTM$"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "non_us_backslash",
"modifiers": {
"optional": [
"left_shift",
"right_shift",
"caps_lock"
]
}
},
"to": [
{
"key_code": "non_us_pound",
"modifiers": "left_option"
}
],
"type": "basic"
}
]
}
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 :
# : [option (⌥)] + [pound/back quote (£ `)]
@ : [option (⌥)] + [shift] + [pound/back quote (£ `)]
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. However, there remains a cosmetic bug in the keyboard viewer, which continues to display a bad key layout (mixing between ISO keys on an ANSI keyboard).
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.
@naga-re I'm on Sonoma 14.5 but still get incorrect keys on the macbokPro M1 builtin keyboard, in the console (not GUI) Specifically:
Any suggestions ?
@fgm Pas d"idée précise sur votre souci, encore moins de solution, mais peut-être une piste…
No specific idea.
On the integrated azerty keyboard of my MacBook Air M2 (but this is also the case with my desktop Mac and an Apple keyboard), under Sonoma 14.5, I've now the right keys in any application, terminal included. There is just the keyboard viewer application which always displays a wrong keyboard layout). And it still doesn't work with virtualized Linux (Debian, Ubuntu, etc.)
I don't use console, but since "square 2" replaces the @ key, I'd say it looks like a PC keyboard layout.
I remember that when I used, a few years ago now, remote access software to a system on another machine, like Microsoft RDP or Apple Remote Desktop for example, I could have this problem of "square 2" key and that there was an option in the settings of this app to allow you to manage the correct keyboard layout. It was necessary to specify that the local machine to access it used a keyboard format other than that expected (in summary here a Mac keyboard), or something like that…
As I don't really use this kind of solution anymore, I don't know if UTM manages this kind of thing or if it's still a concern on the side of Apple and its virtualization framework.
If people with more knowledge than me on this subject have a better answer...
Thanks for your answer. The thing is, I tried multiple variants with dpkg-reconfigure keyboard-configuration, and it changes absolutely nothing. It looks like this is not used by the console at all.
I am convinced, this is not a guest linux keymap problem
Describe the issue
Configuration
Debug log
How to activate for Apple Virtualization?
Screenshots