Running Omarchy in VMware Workstation and Fusion

VMware is one of the rougher places to run Omarchy 4.x. The desktop boots, and then you sit on a flat grey rectangle with a mouse cursor. That is not a broken install. It is a real bug in how the VMware graphics driver hands buffers to Hyprland, and it has a workaround that takes about five minutes.

This page was checked against Omarchy 4.0.4. The official manual lists VMware under Omarchy on…, but it points at discussion #572 from August 2025, which is 3.x era advice written before Quattro replaced the whole desktop shell. Every confirmed report below is VMware Workstation, nearly all on a Windows host; the reporter in issue #7835 saw the same black screen from an Ubuntu host too. Fusion on an Intel Mac uses the same vmwgfx driver and should behave the same, but there is no Omarchy-specific Fusion report to cite. The closest is a comment in Hyprland discussion #12966 reporting the same vmwgfx failure, and the same patch, on Fusion. Fusion on Apple Silicon is out: Broadcom’s documentation says it runs Arm guests only, and Omarchy is x86_64.

VM settings before you install

• Firmware: UEFI.
• Display: turn Accelerate 3D graphics on. dsuarezv’s write-up in issue #8113 reports that with it off, Hyprland never got a renderer up and the display stayed blank, and issue #8943 saw the session die after unlock with it off. One reporter in #7918 did reach a desktop without acceleration, so it is not absolute, but every working recipe in the tracker has it on. Counter-intuitive, given that the fix below is partly software rendering, but the compositor still wants a working GL stack.
• The one report that lists VM sizing (issue #8943) used 4 vCPUs and 8 GB of RAM. Software-rendered surfaces cost CPU, so do not go smaller than that without a reason.
• Get the ISO from omarchy.org and check it against the verification page before you boot it.

The fix

The live ISO is usually fine. The problems start on the installed system. If you are already stuck on the grey screen, switch to a TTY with Ctrl + Alt + F2 and log in there.

1. Stop the shell crash loop. Add this at the bottom of ~/.config/hypr/hyprland.lua:

hl.env("QT_QUICK_BACKEND", "software")
hl.env("XWAYLAND_NO_GLAMOR", "1")

The first line makes Qt Quick render the Omarchy shell into a shared-memory buffer instead of a GPU dmabuf, so the buffer Hyprland rejects is never created. The second stops XWayland apps from taking the session down the same way.

2. Install the VMware guest tools and turn them on:

omarchy pkg add open-vm-tools gtkmm3 libxtst
sudo systemctl enable --now vmtoolsd.service vmware-vmblock-fuse.service

3. The desktop-side agent does not start on its own under Omarchy’s uwsm session. Add it to ~/.config/hypr/autostart.lua:

o.launch_on_start("vmtoolsd -n vmusr")

That agent is what carries the shared clipboard and drag and drop between host and guest.

4. Make the guest follow the VMware window size. On a Wayland-only install there is no xf86-video-vmware, so open-vm-tools does not enable its KMS resolution plugin by itself:

sudo install -d /etc/vmware-tools
printf '%s\n' '[resolutionKMS]' 'enable=true' | sudo tee /etc/vmware-tools/tools.conf
sudo systemctl restart vmtoolsd

5. Make the mouse pointer visible. vmwgfx never commits the hardware cursor plane, so add this to ~/.config/hypr/looknfeel.lua:

hl.config({
  cursor = {
    no_hardware_cursors = true,
  },
})

6. Fix the scale. Omarchy ships GDK_SCALE=2 for retina-class panels, which on a 1280x800 virtual display gives you an effective 640x400 desktop. Open ~/.config/hypr/monitors.lua and set both values to 1:

local omarchy_gdk_scale = 1
local omarchy_monitor_scale = 1

7. Reboot, or log out and back in. GDK_SCALE and the hl.env lines only reach processes started after the session begins.

Verify it worked

journalctl -b -t omarchy-shell | grep -c 'exited with status'
hyprctl getoption cursor:no_hardware_cursors
pgrep -a -f vmtoolsd
head -n1 /sys/class/drm/card0-Virtual-1/modes

The first should print 0. Omarchy’s shell launcher gives up after five relaunches inside a minute and logs each one, so any non-zero count means the shell is still dying. The second should show the option switched on; issue #7918 reports set: true in its output once the block is loaded. The third should show both /usr/bin/vmtoolsd and a vmtoolsd -n vmusr process. The fourth should change when you resize the VMware window, which tells you resolutionKMS is live.

Why it happens

Mesa’s svga driver advertises no dmabuf render modifiers for the scanout formats, while the vmwgfx kernel driver advertises only LINEAR. Hyprland’s compositor side survives that, falling back to implicit modifiers, but GPU-accelerated Wayland clients do not. Quickshell’s surface gets rejected at wl_surface.attach with invalid arguments, which is a fatal Wayland protocol error, and Qt leaves through _exit() without raising a signal. Omarchy’s bin/omarchy-launch-shell supervises exactly that kind of silent death, retries five times, then gives up. With no bar and no wallpaper you are left looking at Hyprland’s background fill, which is why it reads as a black or grey screen rather than a crash.

There is a second half to the same mess. Pascal-0x90 traced it in Hyprland discussion #12966 and kevincasier filed it as Hyprland #16175: when vmwgfx imports a surface-backed dmabuf it hands back a TTM surface handle, not a GEM handle, so the drmCloseBufferHandle() call Hyprland makes afterwards returns EINVAL and the log fills up. That issue carries a tested patch, but it was auto-closed as not planned by the Hyprland bot, which no longer accepts user-filed issues. The live discussion is Hyprland #12966, and the aquamarine side is #360, open since 2026-08-20. Nothing has shipped upstream as of 2026-09-16.

On the Omarchy side, grep over the 4.0.4 tree finds no VMware detection at all. What the tree does have is install/user/hardware/fix-nouveau-cursor.sh, which appends the same no_hardware_cursors block when it sees nouveau. Issue #7918 asks for the identical treatment for vmwgfx and issue #10620 asks the installer to install open-vm-tools when systemd-detect-virt reports vmware. Both were open on 2026-09-16.

If that did not work

The shell comes up but text appears only when you move the mouse. Damage-driven page flips get missed on this driver. dsuarezv’s fix is to make Hyprland repaint continuously, in ~/.config/hypr/looknfeel.lua:

hl.config({
  debug = {
    vfr = false,
  },
})

Apply with hyprctl reload and confirm with hyprctl getoption debug:vfr. It costs some idle CPU.

QT_QUICK_BACKEND=software is not enough. The bigger hammer is hl.env("LIBGL_ALWAYS_SOFTWARE", "1"), which pushes the whole session onto llvmpipe. nenad82 measured roughly 12 percent idle Hyprland CPU that way against about 4 percent with the narrower setting, so try the narrow one first. Note that hl.env does not reach the SDDM greeter, which runs its own Hyprland; for that you need the variable in /etc/environment instead, as suggested in #10620.

Advice from a 3.x guide does nothing. Omarchy 4 moved Hyprland config to Lua. Editing ~/.config/hypr/envs.conf has no effect, and #7918 found that Hyprland skips a cursor { } block in a leftover hyprland.conf once hyprland.lua is present. See Hyprland conf to Lua migration.

Screenshots lose the pointer. Issue #8240 reports that omarchy-capture-screenshot forces hardware cursors back on for the duration of the region picker, which makes the pointer vanish on exactly the drivers that needed software cursors. Open on 2026-09-16, no workaround beyond picking blind.

The whole guest hard-hangs at random. Issue #8943 reports that on Workstation 17.6.4, with acceleration on or off, and notes the installed kernel was an Apple T2 build. I checked: install/hardware/apple/fix-t2.sh only installs linux-t2 when lspci finds Apple PCI IDs 106b:1801 or 106b:1802, so that path should not run on an ordinary VMware guest. Why that reporter ended up on a T2 kernel is unexplained. Check uname -r before assuming the same cause.

Autofit still does nothing after step 4. Hyprland reads the connector’s preferred mode at startup and does not react to the vmwgfx hotplug update, so hyprctl monitors keeps reporting the old size even though /sys shows the new one. You can apply it by hand:

hyprctl eval 'hl.monitor({ output = "Virtual-1", mode = "1600x900@60", position = "auto", scale = 1 })'

dsuarezv published a polling helper in #8113 that does this automatically and rounds the requested size so fractional scales survive.

What to watch for on newer versions

The current development branch snapshot still contains no VMware or vmwgfx handling. The only match in that tree is the same manual paragraph as in 4.0.4. So the real fix has to come from Hyprland or aquamarine, and neither has merged one. Watch aquamarine #360 rather than the Omarchy tracker. Until then, treat every item above as something you apply yourself after each fresh install.