Can't get it to work with Hermes-KMS on Cachyos GNOME

[Cryborg12]

I have followed the instructions to setup hermes (built with the cuda flag off), hermes-kms, and evdi. Every setting is at default.
With evdi, I can get my Artemis client (on xiaomi pad 8) to work as intended.
But, when I select hermes-kms, the client displays a black screen with no video output. I can control the mouse pointer of the host via the client's touchscreen, but no video.
I really can't makeout what is going wrong. Please help.

My setup: Ryzen 5700 x3D, Radeon 7800 XT, Cachyos GNOME with secure boot enabled.

Logs: pastebin.com/SM4SYnHY

[MrOz59]

Thanks for the detailed report and logs.

I had a look through the log, and the good news is that most of the Hermes-KMS pipeline appears to be working correctly. Hermes is able to create the "HERMES-1 / Virtual-1" output, initialize the zero-copy capture path, and start VAAPI encoding on your RX 7800 XT.

The suspicious part is that GNOME/Mutter does not appear to actually activate the "Virtual-1" output. Hermes then continues capturing it anyway, which would explain the black screen: the stream and input are alive, but Mutter is not rendering a desktop onto that display.

Could you please try the following while the Artemis client is connected and showing the black screen?

First, open GNOME's display settings:

gnome-control-center display

Check whether a second display such as "Virtual-1" or "HERMES-1" appears there. If it appears but is disabled, try enabling it manually and applying the configuration. Please let me know if video immediately starts working in Artemis after doing that.

Also, please run:

gdbus call
--session
--dest org.gnome.Mutter.DisplayConfig
--object-path /org/gnome/Mutter/DisplayConfig
--method org.gnome.Mutter.DisplayConfig.GetCurrentState

and send me the output.

Finally, please send the output of:

udevadm info --query=property --name=/dev/dri/card0

and:

loginctl seat-status seat0

According to your log, "/dev/dri/card0" is the Hermes-KMS device in this session.

At the moment, my main suspicion is that this is a GNOME/Mutter-specific issue rather than a problem with Artemis, VAAPI, Secure Boot, or the Hermes-KMS capture path itself. Hermes currently handles display activation better on KDE/KScreen, and GNOME may require explicit configuration through Mutter's "org.gnome.Mutter.DisplayConfig" interface.

If manually enabling the display in GNOME Settings fixes the stream, that will pretty much confirm the cause and give me a clear path for implementing proper automatic Mutter support in Hermes.

Thanks for reporting this — this may have uncovered a real gap in the current GNOME support.

[Cryborg12]

Hi, thank you for the prompt response.

In GNOME's display settings, the client's display (HRM) was enabled by default with black screen output. Here is the screenshot: postimg.cc/qhCMcpfh

Output for the gdbus... : pastebin.com/MvCypcEt

Output for the udevadm... : pastebin.com/7ezZ0B1a

Output for the loginctl... : pastebin.com/53TXHwVJ

Let me know if you need anything else from me.

[MrOz59]

Thanks — your output was decisive, and it disproved what I suspected in my previous comment.

I guessed Mutter was not activating Virtual-1. Your screenshot and GetCurrentState show the opposite: Mutter had adopted it and was driving it. The bug is on our side, and there are two of them.

What actually happens

1. Hermes asks Mutter too early.

From your log:

12:15:24.927  Connected HERMES-1 ... connector=Virtual-1 ... requested=1600x1068@90
12:15:24.933  Warning: GNOME/Mutter ... has not adopted Virtual-1
12:15:24.933  Error: The compositor did not activate the Hermes-KMS output.

Six milliseconds. Hermes issued a single GetCurrentState call right after connecting the output and gave up when the connector was not in the reply yet. Mutter adopts a hotplugged connector asynchronously, so that answer was always going to be "no" — which is why the log claims the compositor refused an output that your own GetCurrentState proves it accepted.

2. Mutter drives the output at the wrong mode — this is the black screen.

Your GetCurrentState shows Virtual-1 advertising the mode we asked for:

'1600x1068@89.991', 1600, 1068, 89.99, ... {}
'1920x1080@60.000', 1920, 1080, 60.0,  ... {'is-current': <true>, 'is-preferred': <true>}

The requested mode is there, but Mutter picked its own preferred 1920x1080@60. Meanwhile Hermes set capture up at the size it requested:

Hermes-KMS zero-copy capture ready: 1600x1068

So the compositor was rendering your desktop at 1920x1080 while the encoder captured and sent 1600x1068. The stream, the input and the audio were all healthy — the encoder was simply publishing frames that Mutter never rendered into that region. That is exactly the "everything works except video" behaviour you described.

Checking that the output was merely present was never enough. Hermes has to tell Mutter which mode to use.

Fixed in ceca6268 on main

Hermes now waits for Mutter to probe the connector (polling up to four seconds instead of asking once), then pushes the requested geometry through ApplyMonitorsConfig rather than hoping the compositor picked it. It selects the advertised mode matching the requested resolution with the closest refresh rate, and leaves every other monitor exactly as Mutter has it.

Two safeguards, since ApplyMonitorsConfig is all-or-nothing:

• every config is submitted to Mutter's own VERIFY method first, so a config that would disturb your ViewSonic is abandoned instead of applied;
• it is applied as temporary, so your saved layout in ~/.config/monitors.xml is never rewritten.

Only Hermes needs rebuilding — the driver is unchanged for this:

git clone https://github.com/MrOz59/Hermes.git && cd Hermes && makepkg -sf

The nightly prerelease also refreshes on every push to main, if you prefer to wait for it.

Please read this before testing

This fix is real but it is not the end of the story, and I would rather set expectations than have you chase a partial result.

1. I validated against mutter 50.4 running headless, not against your session. I confirmed that a payload of this exact shape is accepted, that a deliberately malformed one is rejected by VERIFY, and that a temporary config is not silently reverted (checked at 3 s, 30 s and 60 s). What I could not test is your actual GNOME session on real hardware. That is what your test would tell us.

2. If VERIFY rejects the config on your machine, Hermes logs it and leaves your layout alone. You would still get a black screen, but nothing else breaks. The log line to look for starts with [VDISPLAY/Mutter].

3. The four-second wait is a guess. If Mutter takes longer on your setup, you will see never appeared in Mutter's monitor state and the same failure. Tell me and I will raise it.

4. A client asking for a resolution the connector does not advertise will still fail, with does not advertise in the log. Your 1600x1068 is advertised, so this should not affect you.

5. Anything that rewrites the display configuration mid-stream — you opening Display Settings, GNOME reacting to another hotplug — can override the temporary config we applied.

Separately, I pushed a change to Hermes-KMS (6f94cae) about a stale /etc/modprobe.d/hermes-kms.conf masking the packaged default. It is unrelated to your problem, so do not read it as part of this fix.

What would help most

After rebuilding and starting a stream:

• does video appear?
• the Hermes log lines matching Mutter (grep -i mutter over the log)
• GetCurrentState again while streaming — I want to see is-current on 1600x1068@89.991 instead of 1920x1080@60.000

If video still does not appear but is-current is now the requested mode, then the mode mismatch was not the whole story and the next suspect is the capture path itself. Either way, the log will tell us which.

Thanks for the patience and for the quality of the data — the 6 ms gap and the is-current flag are what made this findable at all.

[Cryborg12]

Thank you for the update.

After rebuilding and installing Hermes, the black screen issue is not resolved.

Logs from Hermes web UI: pastebin.com/DNjesbA5
Lines from the log matching Mutter:

[2026-08-16 16:02:35.565]: Info: [VDISPLAY/Mutter] Driving Virtual-1 at 1600x1068@90000 for this session.
[2026-08-16 16:02:35.578]: Info: [VDISPLAY] Mutter is driving virtual output Virtual-1 at 1600x1068@90000; capturing it directly.

Output for the gdbus... : pastebin.com/mR0uy5zJ

I think, now the client's resolution and refresh rate are being recognized : postimg.cc/gwKvF9ND

[MrOz59]

Thanks — that is exactly the data I needed, and it moves things forward even though the screen is still black.

The mode problem is fixed

Your GetCurrentState now shows:

'1600x1068@89.991', 1600, 1068, ... {'is-current': <true>}

It was 1920x1080@60 before. Mutter is adopting the connector and driving it at the geometry your client negotiated, and the log confirms the new path ran:

[VDISPLAY/Mutter] Driving Virtual-1 at 1600x1068 ...
[VDISPLAY] Mutter is driving virtual output Virtual-1 ...; capturing it directly.

So that half is closed. What is left is a different failure that the mode bug was hiding — the session never got this far before, so this is not a regression from the fix.

Where it fails now

Error: Couldn't import RGB Image: 00003003
Error: Could not convert image

0x3003 is EGL_BAD_ALLOC. Hermes acquires the frame from the driver fine, but eglCreateImage(EGL_LINUX_DMA_BUF_EXT) refuses to import that DMA-BUF into the GPU, so there is nothing to hand the encoder. Same black screen, different cause: previously the compositor never drew the right thing, now it draws it and we cannot pick it up.

I checked two obvious candidates and ruled both out in our code:

• Modifier handling — Hermes already omits the modifier attributes when the framebuffer carries no modifier, and the driver initialises its plane with no modifier list, so nothing bogus is being passed.
• Pitch — the driver aligns to 256 bytes, and 1600 × 4 = 6400 is already a multiple of 256, so there is no padding to get wrong.

I do not yet know why your stack rejects the import, and I would rather measure than guess.

What I need

The Hermes log does not carry the framebuffer's format, modifier or pitch — the kernel driver logs those. Two options, either is fine.

Option A — the import checker (most direct). It prints the exact frame description and then reports each stage of the import chain, so it tells us the buffer's shape and where it breaks in one run:

git clone https://github.com/MrOz59/Hermes-KMS.git && cd Hermes-KMS
make tools
# start a stream from Artemis so a frame exists, then, while it is connected:
./tools/hermes-egl-import-check/hermes-egl-import-check --no-cuda

Its first line looks like frame: 1600x1068 format=... modifier=... planes=1 pitch0=..., followed by PASS/FAIL per stage. That first line plus the stage summary is what I am after.

One heads-up so it does not confuse you: I found today that this tool can crash with a bus error at its last stage, after the import has already been reported. If it dies at the end, the lines it printed before dying are still valid and still useful — please paste them.

Option B — the kernel log. DRM debug is off by default; you can turn it on at runtime and off again without rebooting:

sudo sh -c 'echo 0x04 > /sys/module/drm/parameters/debug'
# start the stream, let it fail
sudo dmesg | grep -i hermes | tail -40
sudo sh -c 'echo 0 > /sys/module/drm/parameters/debug'

Also useful either way: your Mesa version (pacman -Q mesa) and kernel (uname -r), so I can line your stack up against what I test on.

One more thing I corrected

Your log line read Driving Virtual-1 at 1600x1068@90000 — Hermes carries refresh rates in mHz internally and the Mutter path was comparing that against Mutter's Hz. On your machine it still picked the right mode, because only one mode matches 1600x1068 and there was nothing to choose wrongly between. It would have picked wrong on a connector advertising the same resolution at several refresh rates, so it is fixed.

This does not change your black screen — I am mentioning it so you are not left wondering what the @90000 was, not offering it as a fix. No need to rebuild for it before collecting the data above.

[Cryborg12]

Import checker output:

frame: 1600x1068 format=0x34325258 ('XR24') modifier=0x0000000000000000 planes=1 pitch0=6400
plane 0 dma-buf: 6836224 bytes; pitch x height = 6835200; spare = 1024 bytes (0.2 rows)
PASS: frame fence signalled (producer finished writing)

pacman -Q mesa: mesa 3:26.1.6-1

uname -r: 7.1.8-1-cachyos

[MrOz59]

That output is more useful than it looks, including where it stops.

Your buffer is identical to mine

Lining your first two lines up against the same measurement on my machine:

	yours	mine
geometry	1600x1068	1600x1068
format	XR24	AR24
modifier	0x0 (linear)	0x0 (linear)
pitch	6400	6400
dma-buf size	6836224	6836224
vs pitch x height	+1024	+1024

Byte for byte the same, down to the spare bytes. The only difference is XRGB vs ARGB, which is just Mutter and KWin choosing differently and is not something an importer should care about. So whatever is wrong, it is not the buffer's geometry, stride or size — I had a theory along those lines and your numbers kill it.

Your run stopped where the tool can die silently

Your paste ends right after PASS: frame fence signalled, with no CPU-reference line, no EGL stages and no summary. That is the shape of the process being killed rather than finishing: the very next thing the tool does is mmap the DMA-BUF and read eight rows, and until an hour ago that read was unguarded, so a buffer whose pages cannot be faulted in would kill it exactly there and take the rest of the output with it.

I have pushed a guard for that stage, so it now reports the fault instead of dying. Could you rebuild just the tools and run it once more?

cd Hermes-KMS && git pull && make tools
# with a stream connected:
./tools/hermes-egl-import-check/hermes-egl-import-check --no-cuda

If it was dying there, you will now get a line saying so plus the full stage summary. If instead it prints PASS: CPU mmap of plane 0 and continues, then the earlier run was cut short some other way and the EGL stages are what I need to see.

Either answer narrows this a lot, because on my machine that CPU stage passes and the failure happens later, so knowing which stage breaks first on yours is the fork in the road.

One thing I forgot to ask

./tools/hermes-kmsctl/hermes-kmsctl version

I have your Mesa (26.1.6) and kernel (7.1.8) — thank you — but not which hermes-kms driver you are running. The EDID the connector publishes and the refresh limits it advertises changed between 0.3.0 and 0.3.1, so it matters for reproducing your side accurately.

For reference, so you can see what I am comparing against: I am on Mesa 26.1.0, kernel 7.0.9-cachyos, RX 6700 XT, driver 0.3.0. I am not assuming any of those differences is the cause — I am listing them so we both know what is not held constant.

[Cryborg12]

Import checker output:

frame: 1600x1068 format=0x34325258 ('XR24') modifier=0x0000000000000000 planes=1 pitch0=6400
plane 0 dma-buf: 6836224 bytes; pitch x height = 6835200; spare = 1024 bytes (0.2 rows)
PASS: frame fence signalled (producer finished writing)

After the above output, the display freezes after a few seconds on my host's display, only the mouse pointer is responsive (same behavior as before). No more lines appear after the PASS line.

./tools/hermes-kmsctl/hermes-kmsctl version

driver=hermes-kms
uapi_version=9
driver_version=0.3.1

[MrOz59]

First: sorry. I asked you to run something that froze your desktop, twice. That is on me — please do not run the checker again until you have pulled the fix below.

Your run changes the diagnosis

I had assumed the tool was dying. It was not: the signal guard I added would have caught a crash and printed a summary, and it never fired. It blocked, and took your compositor with it. That is a completely different failure from the one I was chasing, and much more interesting.

Between the last line you got and the next one the tool would print, there is exactly one thing: the CPU reference read. It maps the DMA-BUF and takes CPU access on it with DMA_BUF_IOCTL_SYNC. Doing that to a buffer the compositor is still scanning out can block forever — and on your machine it evidently wedges more than the caller.

The detail I want to make sure I did not gloss over: you wrote that the freeze is the same behaviour as before. If your host desktop also freezes during a normal stream attempt, that is a bigger symptom than the black client image, and it may well be the primary one — the black screen could be a consequence of the host GPU or compositor being stuck, not a separate problem. Please confirm whether that is what you have been seeing, because if so I have been investigating the smaller half of this.

Fixed, and a way past it

Pushed to Hermes-KMS main: the CPU reference read now polls the DMA-BUF with a 2 second deadline and gives up instead of blocking, and there is a new --no-cpu-ref flag to skip that stage entirely.

That stage only produces a reference CRC to compare the GPU readback against. Hermes never does it. Skipping it costs nothing and gets us to the stage that actually matters and that no run has reached yet — eglCreateImage, the one failing inside Hermes with EGL_BAD_ALLOC.

cd Hermes-KMS && git pull && make tools
# with a stream connected:
./tools/hermes-egl-import-check/hermes-egl-import-check --no-cuda --no-cpu-ref

If your desktop still freezes with --no-cpu-ref, stop there and tell me — that would mean the hang is not in that stage at all and I need to think again rather than send you another patch to try.

Where this leaves things

Thanks for the driver version — 0.3.1. That was worth having: I tested 0.3.0 against 0.3.1 in a VM and they produce a byte-identical buffer, so it is ruled out. Along with everything else I have been able to vary:

Variable	Result
Hermes-KMS 0.3.0 vs 0.3.1	identical buffer, same CRC
Kernel 7.0.9 vs 7.1.8	identical buffer, CPU mapping fine on both
Mesa 26.1.0 vs 26.1.6	both import successfully on RDNA2
Buffer geometry	byte-identical to yours, including the spare 1024 bytes

Your XR24 versus my AR24 is just Mutter and KWin choosing differently; I reproduced XR24 locally and it imports fine.

What I cannot test is your GPU. I have an RX 6700 XT (RDNA2); you have an RX 7800 XT (RDNA3), and that is now the only variable left standing. I have opened #23 asking anyone with an RDNA3 card to run the same check, precisely so we can find out whether this is your machine or the generation — I am not assuming it is the latter on one report.

I have also written up the state of this in docs/compatibility.md, as an open question rather than a conclusion.

Thanks for the patience, and again, sorry about the desktop.