sway: Unable to start sway on Arch Linux running in VMWare Fusion

Please fill out the following:

Sway Version: 1.5.1
Debug Log: https://paste.sr.ht/~gpanders/64de4204fcd197701c1750ffcd02cf2397b37e37
Configuration File: Default sway config file
Description: This is a fresh install of Arch Linux on VMWare Fusion. I’m running sway from the command line and then the screen goes black and unresponsive. The only way for me to kill it is to switch to another tty using Ctrl+Alt+F3 and running killall sway.

These are the errors I see in the log file:

00:00:00.178 [ERROR] [backend/drm/atomic.c:36] Virtual-1: Atomic commit failed (pageflip): Invalid argument
00:00:00.190 [ERROR] [backend/drm/renderer.c:381] Tried to acquire an FB with a NULL BO
00:00:00.190 [ERROR] [backend/drm/atomic.c:164] Failed to set plane 35 properties
00:00:00.190 [ERROR] [backend/drm/renderer.c:381] Tried to acquire an FB with a NULL BO
00:00:00.190 [ERROR] [backend/drm/atomic.c:164] Failed to set plane 35 properties
00:00:00.192 [ERROR] [backend/drm/renderer.c:381] Tried to acquire an FB with a NULL BO
00:00:00.192 [ERROR] [backend/drm/atomic.c:164] Failed to set plane 35 properties
00:00:00.207 [ERROR] [backend/drm/renderer.c:381] Tried to acquire an FB with a NULL BO
00:00:00.207 [ERROR] [backend/drm/atomic.c:164] Failed to set plane 35 properties
00:00:01.196 [ERROR] [backend/drm/renderer.c:381] Tried to acquire an FB with a NULL BO
00:00:01.196 [ERROR] [backend/drm/atomic.c:164] Failed to set plane 35 properties
00:00:02.200 [ERROR] [backend/drm/renderer.c:381] Tried to acquire an FB with a NULL BO
00:00:02.200 [ERROR] [backend/drm/atomic.c:164] Failed to set plane 35 properties
00:00:12.225 [ERROR] [backend/drm/atomic.c:36] Virtual-1: Atomic commit failed (modeset): Permission denied

I’ve tried with and without VMWare’s “Accelerate 3D Graphics” option. It doesn’t seem to make a difference.

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 9
Comments: 33 (9 by maintainers)

Most upvoted comments

WLR_NO_HARDWARE_CURSORS=1 sway is a workaround for me.

+15

hedgepigdaniel on Dec 1, 2020

Sway works perfectly for me when setting WLR_NO_HARDWARE_CURSORS=1 and ensuring Accelerate 3D Graphics in the guest VM’s display preferences is enabled.

If the former is not set you will get a black screen. If the latter is not set you will get a Could not connect to socket error.

asininemonkey on Sep 13, 2021

Something fishy is definitely going on with wlroots and virtualised drm drivers (such as virtio-gpu, vmwgfx, etc.). On all virtual machines (tried Parallels Desktop, VMware Fusion, but above there are reports re: Virtualbox too) any wlroots-based compositor can’t produce a hardware cursor (either it is not visible or results in a console lockup). At the same time, Weston happily works with all these drm drivers and enables hardware cursor. JFYI.

galaxy4public on Nov 14, 2022

You’re also getting this:

00:00:00.221 [ERROR] [backend/drm/atomic.c:36] Virtual-1: Atomic commit failed (pageflip): Invalid argument

emersion on Dec 24, 2020

I am having the same issue on a fresh install of ubuntu in vmware. Same symptoms (black screen, starting from already running gnome session opens sway correctly in window).

WLR_NO_HARDWARE_CURSORS=1 sway is a workaround for me.

Works for me too. I have to disable the graphical login manager with sudo systemctl set-default multi-user and start it with the workaround from the terminal.

ClaCodes on Nov 14, 2022

hey bros doesnt anybody know how to make WLR_NO_HARDWARE_CURSORS=1 sway this work with sddm? because if i try to input it into the .desktop file it doenst work

pls halp.

fislysandi on Dec 1, 2022

Mesa call, if that helps: https://gitlab.freedesktop.org/mesa/mesa/-/blob/dc3505f87ed69ac843cd4ce7d269b2ab01a32ff7/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c#L187

emersion on Dec 17, 2020

The snooper image is created in these conditions:

	if (metadata->scanout &&
	    metadata->num_sizes == 1 &&
	    metadata->sizes[0].width == 64 &&
	    metadata->sizes[0].height == 64 &&
	    metadata->format == SVGA3D_A8R8G8B8) {

		srf->snooper.image = kzalloc(64 * 64 * 4, GFP_KERNEL);
		if (!srf->snooper.image) {
			DRM_ERROR("Failed to allocate cursor_image\n");
			ret = -ENOMEM;
			goto out_no_copy;
		}
	} else {
		srf->snooper.image = NULL;
	}

We need to figure out which one of these conditions fail.

Preliminary findings to be confirmed: None of this code runs at all. I put a DRM_ERROR in the else block and didn’t see any log messages.

Next step is to put more of them at all the early returns earlier in that function and see of one of them is the culprit.

hedgepigdaniel on Dec 16, 2020

It sounds like this check fails in the driver:

	if (surface && !surface->snooper.image) {
		DRM_ERROR("surface not suitable for cursor\n");
		ret = -EINVAL;
	}

The snooper image is created in these conditions:

	if (metadata->scanout &&
	    metadata->num_sizes == 1 &&
	    metadata->sizes[0].width == 64 &&
	    metadata->sizes[0].height == 64 &&
	    metadata->format == SVGA3D_A8R8G8B8) {

		srf->snooper.image = kzalloc(64 * 64 * 4, GFP_KERNEL);
		if (!srf->snooper.image) {
			DRM_ERROR("Failed to allocate cursor_image\n");
			ret = -ENOMEM;
			goto out_no_copy;
		}
	} else {
		srf->snooper.image = NULL;
	}

We need to figure out which one of these conditions fail.

Can you provide a drm_info log?

emersion on Dec 1, 2020