Call for testers 📣

[joske]

Hi All,

I only have a limited amount of hardware and I mostly test on Arch linux. I need more test reports, both good and bad. Run it as described in the README, on a TTY preferrably, and report your findings. Create an Issue, attach logs.

I'm not going to be able to close the long tail of perf/rendering issues without your help.

Thank you 🙏 !

[BergmannAtmet]

First Try

• rust-toolchain.toml without a specific version selected is largely useless. It's an annoyance because it force-downloads the latest stable chain, even if you have a perfectly capable beta and/or nightly one(s) already installed, while not actually serving the purpose of providing precise tool chain version requirement. You can of course just delete the file, which is what I did. But It has always been a pet peeve of mine, especially the part where the downloading can be triggered merely by cargo shell completions.

• I noticed mcookie executed in the Justfile. mcookie is a part of util-linux which may not be installed in all systems, so that's worth a mention.

• I got permission errors in the log for /dev/input/even<N>, because my user wasn't part of the input group.

• After fixing that, yserver still failed to load. Why? because your logic here is insufficient:

yserver/crates/yserver/src/lib.rs

Lines 583 to 600 in 8c9bf61

	let mut entries: Vec<PathBuf> = match fs::read_dir("/dev/dri") {
	Ok(it) => it
	.filter_map(Result::ok)
	.map(|e| e.path())
	.filter(|p| {
	p.file_name()
	.and_then(|n| n.to_str())
	.is_some_and(|n| n.starts_with("card"))
	})
	.collect(),
	Err(err) => {
	return Err(io::Error::new(
	err.kind(),
	format!("read_dir(/dev/dri): {err}"),
	));
	}
	};
	entries.sort();

I have card1 (Intel iGPU) with no connected conntectors, and card2 (Radeon dGPU) which is the one connected to a monitor and used for running Xorg sessions.

% ls -1d /sys/class/drm/card1-*
/sys/class/drm/card1-DP-1
/sys/class/drm/card1-HDMI-A-1
/sys/class/drm/card1-HDMI-A-2
/sys/class/drm/card1-HDMI-A-3

% cat /sys/class/drm/card1-*/status
disconnected
disconnected
disconnected
disconnected

% ls -1d /sys/class/drm/card2-*
/sys/class/drm/card2-DP-2
/sys/class/drm/card2-DP-3
/sys/class/drm/card2-DP-4
/sys/class/drm/card2-DVI-D-1
/sys/class/drm/card2-HDMI-A-4

% cat /sys/class/drm/card2-*/status
disconnected
disconnected
disconnected
disconnected
connected

What you should be doing is using the DRM API where you check for this, instead of just raw-enumerating the GPU list.

Ironically, I had an issue with Firefox last year that had a similar cause, and ended up providing the fix for it. It's funny how I had that iGPU turned off for years, and once I turned it on, these issues started to pop up.

For now, I just reversed the entries vec and moved on 😉.

• Now that we have yserver running, first impressions is that it seems very laggy in response to keyboard input. Both GPU and CPU load appear to be low, so the issue is not processing resource exhaustion. There is also at times a visible "leak" between the tiled windows in Awesome (the background showing, although it's narrow, so not easy to guess it's the background).

• As for running picom in yserver, while it tries to work, it seems rather buggy (starting with missing up already open windows). If you want to quick test, just use this trivial non-chroma-preserving inverter:

#version 330
in vec2 texcoord;
uniform sampler2D tex;

vec4 window_shader() {
  vec2 texsize = textureSize(tex, 0);
  vec4 c = texture2D(tex, texcoord / texsize, 0);
  c = vec4(
      1.0 - c.r,
      1.0 - c.b,
      1.0 - c.g,
      c.a);
  return c;
}

and

picom --config /dev/null --backend glx --window-shader-fg-rule "/path/to/trivial_invert.glsl:class_i *= '*'" --xrender-sync-fence

Extra Notes

• Logs have this line:

[2026-06-26T17:35:03Z WARN  yserver::drm::device] failed to release DRM master on /dev/dri/card2: Permission denied (os error 13) (file close will still drop the fd)

This also showed up when yserver was trying to use card1, which was accidentally helpful 🙂.

• My dGPU doesn't support VK_EXT_image_drm_format_modifier

[2026-06-26T16:49:22Z WARN  yserver::kms::vk::device] vulkan: physical device lacks VK_EXT_image_drm_format_modifier — Vulkan-fed scanout will not work

But at the same time, log lines like this one appear:

[2026-06-26T17:22:37Z WARN  yserver::kms::vk::scanout] ScanoutBo disarmed (atomic disable_output failed); leaking FB/GEM/Vk to be reaped by DRM-fd close

• And finally, more permission-related log lines:

[2026-06-26T17:12:01Z WARN  yserver::kms::v2::platform] v2 cursor rebind: show on crtc::Handle(61) failed: Permission denied (os error 13)
[2026-06-26T17:12:01Z WARN  yserver::kms::v2::scene] v2 scene: atomic commit failed for output 0 (bo 1): io: Permission denied (os error 13); BO invalidated
[2026-06-26T17:12:01Z WARN  yserver::kms::v2::scene] v2 scene tick: output 0 compose failed: compositor present failed: io: Permission denied (os error 13); continuing

(Some of those may have appeared while testing picom)

[joske]

• rust-toolchain: fair, and putting a version isn't really any better, as it would STILL force a download if you don't have that exact version. Maybe we should delete, I'll have to check the MSRV of the main crates
• mcookie: util-linux is probably available everywhere, but OK, can be added to the README
• GPU choice: created GPU selection picks first KMS-capable card, ignores which GPU has a connected display #62 for this, please test it out from fix(drm): prefer GPU with a connected display when selecting card #63
• input: this IS in the README 😁 but we should probably refuse to start if we can't open input Refuse to start (with actionable error) when no input devices can be opened #64 fix(input): refuse to start when no input device can be opened #66 Can you test this one too? I can't reproduce.

[joske]

awesome seems to work fine, but I have no real good way to test as I'm not familiar with how it's supposed to work. Picom is still quite problematic, I'm continuing to work on it.

[joske]

@BergmannAtmet can you please test the 2 PRs ⬆️ 🙏

meanwhile I've almost fixed the picom issues (see #67)

[joske]

both PRs are merged, and picom is fixed too. I even tested your custom shader, and that works too (had to fix the syntax of the argument though)

[joske]

@BergmannAtmet can you test on current master?

[joske]

and CPU usage in mpv is basically zero, yserver AND mpv process

[BergmannAtmet]

and CPU usage in mpv is basically zero, yserver AND mpv process

GPU, not CPU.

[joske]

reproduced. let's see what we can do

[BergmannAtmet]

I've been keeping an eye and occasionally testing the issues I encountered initially. And yserver GPU load when mpv is playing got worse, not better, after the all the latest changes, I think.

[joske]

@BergmannAtmet can you try again?