OmacVM 3.1.31

Trackpad gestures work again after the Mac sleeps. The VM's Display panel gets a brightness slider and, on an XDR display, the Extra brightness switch, which now also works with HDR and keeps your setting.

There is no 3.1.30: it was built but not released. Everything it had is in 3.1.31, so this is what changed since 3.1.29.

Fixed

• Trackpad gestures after sleep (#497). After the Mac woke from a longer sleep (Power Nap's short wakes too), three- and four-finger swipes and scroll momentum's two-finger scrolling no longer reached the VM until OmacVM Gestures was started again. macOS makes the trackpad's device anew at such a wake, and Gestures kept the old one. It now takes the new one about a second after the wake (a Magic Mouse's too). A Magic Trackpad touched last before the sleep stays the one in use. Gestures also logs a VM connection that ended, and says so when macOS does not start a trackpad.

New

• Brightness and Extra brightness in the VM's Display panel (#494). Omarchy's brightness slider in the bar's Display panel (the monitor icon) now also sets the MacBook's own display, as the brightness keys do; the keys and the slider stay in step. On a Mac with an XDR display, an Omarchy-style Extra brightness switch sits right under it, with the same use-with-care (i) as the app's row. It is the app's setting, so the window's row and the panel always agree, and it switches only while that VM's window is in front. In the VM's terminal: omacvm extra-brightness [on|off]. A Mac without an XDR display (a MacBook Air, most external monitors) shows the slider but not the switch.
• Extra brightness works with HDR (#493). With "HDR and 10-bit colour" on, Extra brightness now wins while it is on: the VM's picture gets up to 2x brighter, HDR highlights do not go above that. Turned off, HDR is back at once, in a running VM. Before, it stayed off over HDR ("not with HDR yet").
• Extra brightness keeps your setting (#496). On or off, it stays as you last set it in the app or the VM's Display panel: through a restart of the VM or the Mac, Update VM and app updates, HDR or GPU safe mode switched, and a start on a display without it. Its (i) says so now.
• Chromium (WebGPU) at the display's scale (#487). The "Chromium (WebGPU)" menu entry runs Chromium on X11, which does not see Omarchy's display scale: on a Retina display its pages and menus came out at half size. It now opens at the scale of the display it starts on (a scale you set yourself, on its command line or in chromium-flags.conf, still wins).

Tested

Tested on a Mac mini M4 (macOS 27.0) with the release build as a test copy, and on a MacBook Pro M4 Max (macOS 27.0.1).

• Trackpad gestures: the Gestures helper's own tests (588 checks; among them a made-up wake where the trackpad's device is made anew: the new one is taken, the old one let go, and frames reach the VM again). On the MacBook Pro's real trackpad the release's helper code takes the trackpad, keeps it over several looks, lets go and takes it again. The OmacVM Gestures in the release zip has the fix; 3.1.29's has not.
• Update VM on a VM folder as if copied from another Mac set up and started the new OmacVM Gestures and the Bridge, the VM's gestures connected, and the next start asked nothing.
• The app updated itself from 3.1.29, and from the 3.1.29.1 test version, to 3.1.31 through its own updater and kept its settings. A VM made by 3.1.29: Update VM, then omacvm check fine and the home in the VM still yours. A new VM made by 3.1.31 from the ready-made image: Vulkan (KosmicKrisp), OpenCL and WebGPU set up, and the "Chromium (WebGPU)" entry opens at the display's scale.
• The brightness slider and Extra brightness were tested with the 3.1.29.1 test version: the slider on screen on a MacBook Air and the mini (it sets the display, no popup), the Display panel's switch, over HDR too, on the MacBook Pro M4 Max (XDR, without a window), and Extra brightness over HDR by hand on a MacBook Pro M1 Max. That code has not changed since; Extra brightness keeping its setting was tested on the mini and the MacBook Pro before it was merged.
• Not tested: a real sleep and wake with the fixed helper (no Mac with a trackpad could be put to sleep for the test). Not run on this build: the on-screen test's window, switch, full-screen and pointer rows (someone was using the mini; 3.1.28 passed them), a Mac with a notch, macOS 15 and 26, a VM built from scratch, UTM, VMware Fusion and Parallels VMs; their offline tests pass in CI.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. The gesture fix is in OmacVM Gestures, which Update VM installs; the app update alone keeps the old one running. Other routes: omacvm update (it updates the Mac's helpers too).

Or download OmacVM-3.1.31.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.29

On a MacBook Pro's XDR display the VM's window can now be up to twice as bright, for bright light.

New

• Extra brightness (experimental, off by default) (#486). On a MacBook Pro's XDR display (or another display with more than 2x headroom), the VM window's Display settings have a switch that makes the VM's window up to twice as bright as the Mac's normal white. It works at once in a running VM and ends by itself when the VM stops, its window is hidden or you turn it off. Only the VM's window gets brighter; the rest of the screen stays as it is. Use it with care: it can use more battery and make the Mac warmer; its (i) says so. Not with HDR yet (it stays off while the VM shows HDR). A display without the headroom (a MacBook Air, most external monitors) does not show the switch. omacvm check has a line for it.
  On XDR displays: the window goes to exactly 2x (white 2.00 of the Mac's white, a 50 % grey 0.43), never more; macOS asks the panel for 2x only. Power: about +1.2 W at brightness 0.5 (one rough reading), no measurable difference at brightness 0.1 (3.28 W against 3.22 W for the whole Mac, within the noise). 30 minutes on without an error. At the lowest brightness macOS gives no extra brightness.

Tested

This release was tested on a Mac mini M4 (macOS 27.0, LG UltraFine without extra brightness) and a MacBook Pro (macOS 27.0.1, XDR), with the release build as a test copy.

• Extra brightness on a MacBook XDR display, at the lowest brightness that allows it (0.1): the switch and its (i) are in the window's Display settings, the (i) says to use it with care. On: the VM's window at 2x and the display's headroom at 2.00, never more (24 readings in 6 s). Off: the window back to normal at once (0.02 s); macOS lets the panel's headroom down by itself about 17 seconds later. On again, then the VM shut down: the window and its 2x gone, the panel back to normal 16 seconds later.
• On the mini's LG monitor (no extra brightness): the switch is not offered, and turned on by hand it stays off; the app, QEMU's log and omacvm check say why ("the VM window's display has no extra brightness").
• The app updated itself from 3.1.28 to 3.1.29 through its own updater and kept its settings. A VM that 3.1.28 made from the ready-made image: Update VM in its window, then omacvm check fine, the home in the VM still yours (src/tests/home-links.sh).
• A VM folder as if copied from another Mac: OmacVM asked once, Update VM in that question set up OmacVM Gestures and the Bridge, and the VM started with gestures connected, on screen with the question's real button and once more without a window; the next start asked nothing.
• A new VM made by 3.1.29 from the same image: Vulkan (KosmicKrisp), OpenCL and WebGPU set up; Update VM, start and shutdown from the on-screen test. Full screen including notch off and on (this Mac has no notch). HDR on and off as in 3.1.28 (Chrome's white at the Mac's white, 10-bit; off: 8 bits).
• Not run: the on-screen test's window size, switch, full-screen and pointer rows on this release (someone was at the mini; 3.1.28 passed them and nothing there changed), a Mac with a notch, macOS 15 and 26, a VM built from scratch, UTM, VMware Fusion and Parallels VMs (no Parallels licence); their offline tests pass in CI.

Update

OmacVM › Check for Updates…. Other routes: omacvm update.

Or download OmacVM-3.1.29.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.28

A VM folder copied to another Mac now says when that Mac is not set up for it, and Update VM sets it up.

Changed

• A VM from another Mac says what it needs (#485). OmacVM Gestures and the Bridge, the small Mac helpers behind trackpad gestures, scroll momentum, the escape combo, media keys, Wi-Fi names, Bluetooth and the control centre, are set up on a Mac by Update VM, a new VM or omacvm apply. A VM folder copied to a new Mac ran without them, and nothing said so: gestures just didn't work and macOS never asked for the permissions. Now OmacVM asks before the start and shows a notice in the VM's window, with an Update VM button. Update VM sets the helpers up and they ask macOS for their permissions themselves; then the VM starts. A helper that is not allowed yet, or switched off in Login Items, gets a button to the right System Settings page instead. Nothing is installed without you, and Later starts the VM as it is. omacvm check has the same answer in its new "Mac setup" line.

Tested

This release was tested on a Mac mini M4 with macOS 27.0, with the release build as a test copy.

• The app updated itself from 3.1.27 to 3.1.28 through its own updater and kept its settings.
• A VM that 3.1.27 made from the ready-made image: Update VM in its window finished in 21 seconds; omacvm check fine, the home in the VM still yours (src/tests/home-links.sh 18 of 18).
• A VM folder as if copied from another Mac (made by 3.1.27 without this Mac's helpers, with another Mac's Bridge token): before the start OmacVM said that OmacVM Gestures and OmacVM Bridge aren't set up for it on this Mac yet. Update VM in that question set them up, they had their permissions, and the VM started with gestures connected, the right Bridge token and omacvm check's "Mac setup" line ok, all in that first start. This ran on screen with the question's real Update VM button, and once more from a start without a window. The next start asked nothing.
• A new VM made by 3.1.28 from the same image: Vulkan (KosmicKrisp), OpenCL and WebGPU set up. The whole on-screen test passed on the mini: the app's window size, Update VM from the window, a switch with the VM stopped, the VM window's size around full screen, no Mac cursor over the VM (with and without QEMU's lock), and nothing left running after shutdown, closing the window and quitting.
• Full screen including notch off and on (this Mac has no notch): off, nothing of FullPanel runs; on, the VM starts with the normal full screen and says why.
• HDR on: Chrome's white page is 201 nits on the VM's output, as in 3.1.27. Off: 8 bits, sRGB, nothing of the HDR rule left.
• Not run: a Mac with a notch (nothing about the notch changed), macOS 15 and 26, key to screen latency, a VM built from scratch (omacvm build --build), UTM, VMware Fusion and Parallels VMs (no Parallels licence); their offline tests pass in CI.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.28.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.27

FullPanel (full screen including the notch) is rewritten with one small hook by @brianmerchant, and the experimental Vendor HID devices switch is removed at the request of its author, @fbalazsy.

Changed

• Full screen including notch: FullPanel rewritten with one small hook instead of many (@brianmerchant, #480). macOS now lays the VM's window out over the whole display itself (FullPanel answers its question whether a full-screen window keeps room for the menu bar), and the menu bar's reveal is seen through AppKit's titlebar window instead of hooks on a private AppKit class. Nothing changes in how it looks or how you set it. With external displays on, omacvm check no longer warns about their windows' normal full screen. Versions 3.0.16 to 3.1.26 adapted code from UTM (Apache-2.0); this version has no code from UTM, and UTM is now credited in the notices for the approach (ADR 0044).
• Vendor HID devices is gone (@fbalazsy, #476). The experimental switch under USB devices (3.1.14, #424) is removed at its author's request. USB devices work as before; a vendor HID board stays with the Mac again, also one remembered as Connect. The USB Devices list then shows it as plugged in and kept by macOS, and the VM's log says why it did not connect. A VM folder's old usb-vendor-hid file is no longer read.

Tested

This release was tested on macOS 27, on a Mac mini M4 and a MacBook Pro M4 Max with the notch.

• Mac mini M4 (macOS 27.0), the release build as a test copy (the Mac's screen was locked):
  • The app updated itself from 3.1.26 to 3.1.27 through its own updater and kept its settings.
  • A VM that 3.1.26 made from the ready-made image: Update VM finished in 20 seconds; omacvm check fine, the home in the VM still yours (src/tests/home-links.sh 18 of 18). With an old usb-vendor-hid file set to on in its folder, the VM starts with plain USB; QEMU no longer has the vendor HID device at all.
  • A new VM made by 3.1.27 from the same image in 7 minutes: Vulkan (KosmicKrisp), OpenCL and WebGPU set up, graphics without QEMU's lock and Vulkan windows without a copy.
  • Full screen including notch off and on (this Mac has no notch): off, nothing of FullPanel runs; on, the VM starts with the normal full screen and says why, and omacvm check and omacvm fullscreen say the same.
  • HDR on: Chrome's white page is 201 nits on the VM's output, as in 3.1.26. Off: 8 bits, sRGB, nothing of the HDR rule left.
• MacBook Pro M4 Max, 16-inch with the notch (macOS 27.0.1), the release build as a test copy: the whole on-screen test passed: the app's window size, Update VM from the window on a VM made by 3.1.26, a switch with the VM stopped, the VM window's size around full screen, no Mac cursor over the VM (with and without QEMU's lock), and nothing left running after shutdown, closing the window and quitting.
• The new FullPanel, on the same MacBook Pro before it was merged (the same code as this release): the strip beside the notch covered with Keep the Dock away on and off, the menu bar coming down at the top edge and going again, back from Mission Control and from another Space, a display mode change, full screen out and in 5 times, Split View, Stage Manager, the "Always show the menu bar" fallback, display sleep and lock; the menu bar and the Dock normal after quitting.
• The private AppKit and SkyLight parts FullPanel needs are there on macOS 15.7 and 26.6 (checked on GitHub's Macs); FullPanel did not run on screen there.
• Not run: key to screen latency, a VM built from scratch (omacvm build --build), UTM, VMware Fusion and Parallels VMs (no Parallels licence); their offline tests pass in CI. No real vendor HID board was free; the USB tests with a fake device pass.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.27.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.26

Graphics now run without QEMU's lock and Vulkan windows without a copy by default, Chrome no longer looks gray with the HDR switch on, and OmacVM writes your home in the VM as you everywhere.

Changed

• Graphics without QEMU's lock and Vulkan windows without a copy are on by default. Both switches in the VM window's General section were off and marked experimental (since 3.1.18 and 3.1.24). With them on, graphics work that only touches the GPU runs without QEMU's lock, so the VM's CPUs wait less for it (Mac mini, new Chromium windows: longest stop 107 ms -> 1 ms), and on macOS 26 and newer Vulkan apps' frames reach the screen without a copy. With MoltenVK (macOS 15) Vulkan windows are copied as before: the switch says so there, and omacvm check no longer warns about it. 10- and 25-minute runs with both on, on a Mac mini M4 and a MacBook Air M2 with macOS 27: no GPU restart, no crash, no memory growth. A switch you set in the VM window stays as you set it. If you went back in 3.1.18 with defaults delete, switch it off in the window. GPU safe mode still turns both off.

Fixed

• Chrome no longer looks gray with HDR on. With the experimental HDR switch on, Chrome and Chromium draw their whole window as HDR, and the VM dimmed all of it to fit, so pages and white looked gray. Their normal content now looks exactly like any other app's, and HDR video still goes brighter than white as far as the display can show.
• OmacVM writes your home in the VM as you, everywhere. After ~/.ssh in 3.1.25, the rest of the VM side does the same: omacvm apply wrote Hyprland's config, the Bridge's token, the bar's plugin folders and its own markers in your home as root, following links there, so a program running as you could point one at a system file and get root at the next apply. All of that is now written as you, and root reads your files only as you. The Mac folder is mounted at ~/Mac only when that is a real folder, never through a link.
• Update VM's SSH messages name the right key. They say "this VM folder's key" (it said "this Mac's key"), and a VM that has the key but still turns OmacVM away says so. The command for the VM's terminal also goes into the update's log, so Show Log still has it after Back. A VM folder whose ssh-key.pub went missing gets it back from its ssh-key instead of a new key the VM does not know. Without a guest agent, a feature switched while the VM was stopped gives up after about 10 minutes again (up to 20 with the SSH repair before it).

Tested

This release was tested on macOS 27 only, on a Mac mini M4 (macOS 27.0): no other test Mac was free. The new graphics defaults were not soaked on macOS 15 (with MoltenVK, Vulkan windows are copied there as before).

• Mac mini M4 (macOS 27.0), the release build as a test copy:
  • The app updated itself from 3.1.25 to 3.1.26 through its own updater and kept its settings.
  • A VM that 3.1.25 made from the ready-made image: Update VM (the window's path) finished in 18 seconds. After it, ~/.ssh and every file in your home in the VM belong to you, and the test that points the home's folders at root's files (src/tests/home-links.sh, run as root in that VM) passed 18 of 18. omacvm check: 52 ok, nothing wrong; Graphics without QEMU's lock and Vulkan windows without a copy on, with no setting changed.
  • A new VM made by 3.1.26 from the same image in 4 minutes: Vulkan (KosmicKrisp), OpenCL and WebGPU set up, omacvm check 52 ok and nothing wrong, and QEMU's log says "virgl runs without the BQL" and "Vulkan windows are IOSurfaces".
  • HDR on: Chrome's white page is 201 nits on the VM's output (SDR white is 203; about 105 in 3.1.25), its greys as an SDR app's. The Mac's screen was locked, so QEMU held back its display layout; the layout it sends for an HDR display was given to the VM by hand. With the switch off: 8 bits, sRGB, nothing of the HDR rule left.
  • The on-screen test: Update VM, and nothing left running after shutdown and quit, passed. Not run: its window, switch, full-screen and pointer rows, as the Mac's screen was locked.
• Not run: key to screen latency (it needs the screen). This release does not change how keys reach the VM.
• Not run: a VM built from scratch (omacvm build --build), macOS 15 and 26, UTM, VMware Fusion and Parallels VMs (no Parallels licence). Their offline tests pass in CI.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.26.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.25

New VMs from the ready-made image get Vulkan, WebGPU and GPU compute again on macOS 26 and later, the Mac's arrow no longer shows up over the VM, and Update VM gets back into a VM that only knew another Mac's SSH key.

Fixed

• New VMs from the ready-made image get Vulkan, WebGPU and GPU compute again. On macOS 26 and later, a VM made from the ready-made image quietly ended up with OpenGL only. The image's package list is as old as the image (11 days), and Arch Linux ARM's mirrors keep only the newest version of each package, so setup could not install the Vulkan driver's build tools or OpenCL ("package list older than the mirrors"); switching WebGPU and GPU compute on failed the same way. Setup now brings the VM's system up to date first, once, with Omarchy's own update, and restarts the VM when that brought a new kernel. Setup takes a few minutes longer for it. A VM made from the image before this release keeps OpenGL after Update VM (its package list is still the old one); omacvm check now says so and what to do: omarchy update in the VM, then omacvm apply.
• The update in the VM is no longer cut off half way. OmacVM's system update (Graphics -> Vulkan, and now the setup of a VM from the image) took it for the end of the update when systemd restarted itself during it, and stopped pacman in the middle of its run.
• A feature that did not switch on says why. After a failed switch, the window and the log said only "rolled back ... (what failed is above)". That line now names it, for example "WebGPU and GPU compute was not set up: Omarchy's package list is older than the mirrors". omacvm check shows a FAIL line for WebGPU and GPU compute when it is on but its packages are missing.
• No second pointer over the VM. The Mac's arrow could show up next to Omarchy's pointer and stay until you switched out of the VM and back. The app hid the Mac's cursor once when the VM took the pointer, but other programs and macOS can show it again (OmacVM Gestures did, over full-screen VMs). While the VM has the pointer, the Mac's cursor is now also an empty picture, so nothing shows when something else shows it, and OmacVM Gestures leaves the app's VMs alone (Parallels, UTM and VMware Fusion as before). This also holds while the pointer rests, for example while you type: the app looks twice a second while it hides the cursor. Ctrl+Option+G, leaving the VM and switching apps bring the arrow back as before; on Omanotch's strip beside the notch the strip's own pointer stays.
• Update VM lets a VM in again that knows only another Mac's SSH key. A VM set up on another Mac (or before 3.0.12) let only that Mac in over SSH: Update VM waited 5 minutes and then said the VM "did not come up", and switches failed. The app now adds the VM folder's own key through the VM's guest agent, without SSH: quietly at each start, and in Update VM within seconds of the first refusal, after which the update goes on. When the guest agent does not answer either, Update VM stops with a Copy Command button (and an (i) that says what the command does) to paste into a terminal in the VM.
• omacvm apply writes your ~/.ssh in the VM as you. It added the VM folder's key to your ~/.ssh/authorized_keys in the VM as root, following links there. That step now runs as your user; root's own key file is written as before.
• Deleted files give their space back sooner. What you delete in the VM goes back to the Mac within about two minutes (disk.img gets smaller, and still grows up to the size you set). Files deleted outside your home folder stayed as long as one of omarchy-mac's update snapshots held them, and it keeps 5, one per omarchy update. VMs now keep the last 2: the older ones go once the next Update VM has updated the VM (a failed one leaves them), and the disk is trimmed then. A number you set yourself stays. On a test VM with 5 update snapshots, this step followed at once by a shutdown, as Update VM does it, gave back 1.9 GiB on the Mac. Each update after it gives back what its oldest snapshot held (before: nothing). omacvm check shows a "freeing disk space" line.
• The app's window opens at most 800 points tall, centred. On a large display it opened as tall as the screen; you can still make it taller.
• mpv keeps playing in UTM VMs too. UTM's VMs draw OpenGL with virgl as well, so mpv's default output kept one open file per frame there too and stopped drawing after about 17 seconds of 60 fps video (fixed for app VMs in 3.1.24). UTM VMs now get the same vo=gpu line at their next omacvm apply; a vo line in your own ~/.config/mpv/mpv.conf still wins.
• Screenshots no longer crash the desktop. In app VMs, each screenshot left about 180 MB (on a 5K display) in a small memory folder of the VM, /run/user/1000. After a handful it was full, and Hyprland and apps such as Electron apps crashed (SIGBUS), and Hyprland came back in safe mode. OmacVM's own build of hyprpicker, which freezes the screen for screenshots, did not delete its files when it stopped. It does now, and Update VM removes what was left. omacvm check warns when that folder is over 80 % full.

Faster

• WebGPU and GPU compute in the VM, on macOS 26 and newer. KosmicKrisp, the Vulkan driver the app uses there, kept a compute shader's shared memory in a byte array, and Metal's compiler made every access to it slow. It is now 16-byte aligned: a WebGPU matrix multiply in a VM on a MacBook Air M2 went from about 256 to about 757 GFLOPS (MoltenVK: about 895). Vulkan's conformance tests for compute (50,788 cases) give the same results as before.

New

• HDR and 10-bit colour (experimental, off). A new switch in the app's Display settings, shown on Macs with an HDR display. With it the VM's main window runs at 10 bits: smoother gradients (about twice the levels on screen), and HDR highlights from Linux apps that send HDR. White stays the Mac's white; brighter parts go as far as the display can show at its current brightness (the VM tone-maps, and macOS no longer does it a second time). The VM loads its 10-bit driver only for a start with the switch on; Update VM builds it. Few Linux apps send HDR yet (GStreamer does; mpv and Chromium show HDR video as SDR). HDR highlights are not yet checked on a real HDR screen: our test MacBook Pro gave no HDR headroom during the tests.

Tested

This release was tested on macOS 27 only: today there is no test Mac on macOS 15 or 26. Earlier today the same on-screen test ran on a MacBook Pro with macOS 15.7.4 on 3.1.24 with this release's pointer fix: the pointer, Update VM and switch rows passed there (the window was still too tall then; that fix, #458, is in this release).

• MacBook Air M2 (macOS 27.0.1), the release build as a test copy:
  • The app updated itself from 3.1.24 to 3.1.25 through its own updater and kept its settings.
  • A VM that 3.1.24 made from the ready-made image today: setup ended at "OpenGL until the VM has its Vulkan driver", the bug above. With root in that VM knowing only another Mac's SSH key, Update VM in the window said "SSH works again" and finished in 37 seconds.
  • A new VM made by 3.1.25 from the same image: Vulkan (KosmicKrisp), OpenCL and WebGPU all set up, omacvm check 53 ok and nothing wrong, setup 11 minutes including the system update.
  • The on-screen test on that VM, every row passed: the app's window 800 x 800 points, centred, still 800 wide after the green button; Update VM from the window (22 s); WebGPU and GPU compute switched off and on with the VM stopped, applied at the next start; the VM's window kept its size over two full screens; no Mac arrow over the VM, with Graphics without QEMU's lock off and on; nothing left running after shutdown, close and quit.
• Not run this time: key to screen latency. The only Mac where that test can run today is in use (it needs the screen, and screen recording, which macOS does not allow over SSH). This release does not change how keys reach the VM.
• Not run: a VM built from scratch (omacvm build --build). That path has no changes in this release; the setup steps it shares with the ready-made image ran in the new VM above.
• Parallels: no licence here, so no Parallels VM ran. The changes that touch Parallels VMs were reviewed and its offline tests (with a stand-in for prlctl) pass.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.25.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.24

The VM window keeps its size after full screen, mpv plays long videos cleanly again, and Vulkan windows run at the display's rate.

Fixed

• mpv keeps playing after 17 seconds. In app VMs, mpv's default video output (gpu-next) kept one open file per frame: after about 17 seconds of 60 fps video it hit its limit of 1024, and every frame after that failed ("expect bad rendering" in its log). The leak is mpv's: it never hands its frames back to libplacebo's OpenGL swapchain, which frees each frame's fence only there, and on the VM's OpenGL (virgl) every fence is a file. The VM's system-wide mpv.conf now has vo=gpu, which frees them (5 minutes of 1080p60: 28 open files throughout). A vo line in your own ~/.config/mpv/mpv.conf still wins. A VM gets it at its next Update VM; omacvm check's mpv line now shows in every app VM.
• The VM window keeps its size after full screen. Leaving full screen gave the window back smaller, again with every full screen (1280 x 720 became 1140 x 700, then 1120 x 700): macOS put the old size back while the window still had the full-screen display's shape, and the window's 20-point steps rounded that down. The window now drops that shape before macOS puts its size back.
• The app's window stays 800 points wide. A double-click on its title bar (macOS's Fill) or window tiling made it as wide as the screen while its content stayed 800 points. It now goes back to 800 points at once, around the same middle; only its height changes, as intended.
• Vulkan windows run at the display's rate. A Vulkan app that waits for the display (vkcube, most games) ran at 45-50 frames a second on a 60 Hz display, while OpenGL apps ran at 60. Mesa gave each frame a target time from the last frame's presentation, and Hyprland held the frame until then; the VM's frame clock runs a few milliseconds late, so frames often waited one refresh more. VMs with Vulkan now leave that timing out (MESA_VK_WSI_DEBUG=nowlts; a value you set yourself wins). It counts from the next login after Update VM; omacvm check has a line for it.

New

• Vulkan windows without a copy (experimental, off). A new switch in the VM window's General section, next to "Graphics without QEMU's lock". QEMU copied every frame of a Vulkan window on its main loop: 2.5 ms a frame for a 1816 x 870 window on a Mac mini, while the VM's CPUs waited. With the switch on (macOS 26 and newer), the Vulkan driver writes each frame into memory the Mac's OpenGL can read, and the GPU puts it in place: 0.3 ms. Frame rates and pictures stay the same. omacvm check says which way the VM's Vulkan windows go. It stays off by default until it shows a difference people notice.

Tested

• Mac mini (macOS 27) with the release build: a VM made by the published 3.1.23 from the ready-made image. The app updated itself to 3.1.24 and kept its settings; Update VM took 23 seconds; omacvm check showed no problems, with the new mpv line. Key to screen, median of 30 keys per run: 27.9 / 28.2 ms with 3.1.24, 27.7 / 29.7 ms with 3.1.23 (same VM, same conditions).
• A new VM built here from scratch with 3.1.24 (omacvm build), Vulkan on the Mac's GPU (KosmicKrisp): vkcube in a window, started from the desktop session, ran at 59.9 and 60.4 frames a second on the 60 Hz display (started from an SSH shell, without the new setting, 45.8). With Vulkan windows without a copy on: omacvm check and the VM's log say the windows are IOSurfaces, vkcube 59.5. The VM window's settings show the new switch.
• The VM window's size: 1140 x 672 points before full screen, and the same after each of two full screens.
• MacBook Pro (macOS 15.7): 3.1.24 made a VM from the ready-made image in 7 minutes (OpenGL, as on macOS 15); it ran, shut down and started again, with no problems in omacvm check.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.24.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.23

Keyboard sharing apps has a switch in the VM's settings, and OpenCL is right from the first login after a switch to Vulkan.

Fixed

• OpenCL is right from the first login after a switch to Vulkan. The check whether the Mac's Vulkan driver gives OpenCL a GPU (it does not on macOS 15) ran 90 seconds after the desktop came up, so the first session after switching Graphics to Vulkan could offer OpenCL without a device until the next login, and apps fell back to the CPU. It now also runs before the desktop session starts.

New

• Keyboard sharing apps has a switch. The setting for Synergy, Deskflow, Barrier and Input Leap (3.0.18, #350) was only a Terminal command. It is now a switch in the VM window's settings, under Input, with an (i) that says what it does. It counts from the VM's next start.
• Modifier keys in the input debug log. With OMACVM_IME_DEBUG=1, each Shift, Control, Option or Command press and release now shows in the log with what the Mac's input method did with it. This is to find why a Shift tap does not always switch between Chinese and English (#357, thanks @Vocllum).

Tested

• Mac mini (macOS 27) with the release build: a VM made by the published 3.1.22 from the ready-made image. The app updated itself to 3.1.23 and kept its settings; Update VM took 25 seconds, and omacvm check showed no problems in the VM. The VM window's settings show the Keyboard sharing apps switch. Key to screen, median of 30 keys per run: 25.2 / 21.1 ms with 3.1.23, 26.7 / 26.5 ms with 3.1.22 (same VM, same conditions).
• A new VM built here from scratch with 3.1.23 (omacvm build): Vulkan on the Mac's GPU (KosmicKrisp) and OpenCL on; the new OpenCL check took under a second and was done before the desktop session could start. omacvm check showed no problems.
• MacBook Pro (macOS 15.7): 3.1.23 made a VM from the ready-made image in 8 minutes (OpenGL, as on macOS 15); it ran, shut down and started again, with no problems in omacvm check.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.23.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.22

New VMs build again on your Mac, and omarchy update works again in your VMs.

Fixed

• New VMs build again, and omarchy update works again. Since 18 October, Omarchy's package server has no ARM builds of two Hyprland parts (hyprtoolkit and hyprland-guiutils), but omarchy-mac still asks that server for them by name. So building a new VM here stopped while Omarchy installed, and omarchy update in a VM stopped with "target not found" (omacom/omarchy-mac#741). OmacVM now leaves those two out while Omarchy's server does not have them, and the VM takes Arch Linux ARM's builds of them, which fit Omarchy's Hyprland. When the server has them again, nothing changes from how Omarchy does it. A VM gets this at its next Update VM; new VMs have it from the start. The ready-made VM download was not affected.
• The control centre's Omarchy update (and Graphics -> Vulkan on an older ready-made VM) now runs the same Omarchy as omarchy update in the terminal, not the copy the installer left behind.

Tested

• Mac mini (macOS 27) with the release build: a VM made by the published 3.1.21 from the ready-made image (a new build fails there today). The app updated itself to 3.1.22 and kept its settings; Update VM took 23 seconds. After it, omarchy update in the VM ran through (165 packages; on 3.1.21 it stopped with "target not found"): Hyprland 0.56.2-7 from Omarchy with Arch Linux ARM's hyprtoolkit 0.6.0 and hyprland-guiutils 0.2.2. After a restart Hyprland ran, no library was missing, no service failed, and omacvm check showed no problems in the VM.
• A new VM built here from scratch with 3.1.22 (omacvm build, the path that broke): done in 7 minutes, with the same packages and the same clean checks.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.22.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash

OmacVM 3.1.21

mpv shows video again in VMs with Vulkan, and the swipe out to macOS goes the right way on macOS 26 and older.

Fixed

• mpv shows video with Vulkan. With Graphics on Vulkan (Automatic on macOS 26 and newer), mpv picked Vulkan by itself and showed no picture at all: on Venus it stops after its first frame on Wayland (on X11 it plays). Now the VM's system-wide mpv.conf has mpv draw with OpenGL, which plays it. A gpu-api line in your own ~/.config/mpv/mpv.conf still wins; Graphics OpenGL takes the line out again. A VM gets it at its next Update VM; omacvm check has an mpv line.
• Swipe out to macOS goes the right way on macOS 26 and older. On a MacBook Pro on macOS 15.7 the Space first moved the wrong way (or bounced), then the swipe out took one step after all, and after two such swipes it stopped following the fingers. macOS before 27 reads the swipe's direction from fields it does not document; the direction the escape combo learned on that Mac now counts for the swipe out too, and a swipe that lands on the other side, or bounces, teaches it once. macOS 27 is unchanged. Covered by the Gestures tests (test-escape.c); our test Mac runs macOS 27, which takes the other path, so macOS 15 users get the fix as tested there, not yet on a Mac with macOS 15.

Tested

• Mac mini (macOS 27, KosmicKrisp) with the release build: a VM made by the published 3.1.20; the app updated itself to 3.1.21 and kept its settings; Update VM took 28 seconds, without a kernel question.
• On screen, Graphics Automatic (Vulkan): mpv played a 4K60 clip in its window (60 frames a second, the picture moving); the same check on 3.1.20 stayed on its first frame. Graphics OpenGL and back to Automatic: the VM started each way and mpv played both times; omacvm check showed the mpv line.
• Not worse: QEMU at an idle desktop 7.5 % CPU, 55 mW (3.1.20: 7.7 %, 54 mW); a key to the screen in half the cases within 30.4-30.7 ms (3.1.20: 30.4 ms, same conditions).
• Vsync: on an unlocked Mac, a client that waits for the display (glmark2 with FIFO) runs at the display's 60 frames a second with 3.1.16 and 3.1.20 alike; the 25-37 seen earlier came from the Mac's screen being locked.

Update

OmacVM › Check for Updates…, then Update VM in the VM's window. Other routes: omacvm update.

Or download OmacVM-3.1.21.zip below.

New to OmacVM?

curl -fsSL https://raw.githubusercontent.com/gillesgoetsch/omacvm/main/install.sh | bash