Hi! Wanted to gauge interest before opening anything large.
Background: I've been running an EVDI-capable Apollo build on RTX 4070 / KDE Plasma Wayland for the past week (couch game streaming via Moonlight fork). The current Apollo virtual-display path here SIGSEGVs inside mesa's gbm_create_device when handed an EVDI card — display_ram_t::init → driCreateNewScreen3 crash — because EVDI has no render node.
@Sgtmetalmex's fork (Apollo-CachyOS) solves this with a parallel capture backend (display_evdi_t) that reads BGRA pixels from libevdi's CPU buffer instead of going through the GBM/EGL chain. It's a series of focused patches against your master tip; full architectural writeup is in their 0007 commit message.
I think this could close several of your open issues:
Validation across two independent encoder backends:
| Rig |
GPU |
Encoder |
Result |
| Sgtmetalmex |
RX 9070 XT, Mesa 26.1 |
VAAPI |
Steam Deck client, working |
| Me |
RTX 4070, NVIDIA proprietary |
hevc_nvenc |
4K120 SDR capture; 1080p120 stream locked, 0 dropped frames, ~3ms encode |
What I'd like to propose, if you're interested:
One focused PR for the EVDI capture core (~7 patches, 0001–0008+0018) plus the minimum PKGBUILD changes to apply them. Out of scope for this PR: gamescope helper, AMD-only VAAPI tuning, CachyOS-flavored README, Steam-Deck-specific EDID. Those stay in the CachyOS fork.
Authorship would be preserved via git cherry-pick so @Sgtmetalmex remains the Author: on every commit.
Is this something you'd want as a PR? And if so, any preference on scope — all-at-once vs. patch-by-patch? Happy to follow whatever rhythm works for you.
Disclosure: I'm a first-time PR submitter on this repo, and both @Sgtmetalmex's original development and my coordination work involved AI coding assistance (Claude). The patches were end-to-end tested on real hardware before landing in the fork, and I've validated the streaming result on my own rig over a week of daily use.
Hi! Wanted to gauge interest before opening anything large.
Background: I've been running an EVDI-capable Apollo build on RTX 4070 / KDE Plasma Wayland for the past week (couch game streaming via Moonlight fork). The current Apollo virtual-display path here SIGSEGVs inside mesa's
gbm_create_devicewhen handed an EVDI card —display_ram_t::init→driCreateNewScreen3crash — because EVDI has no render node.@Sgtmetalmex's fork (Apollo-CachyOS) solves this with a parallel capture backend (
display_evdi_t) that reads BGRA pixels from libevdi's CPU buffer instead of going through the GBM/EGL chain. It's a series of focused patches against your master tip; full architectural writeup is in their 0007 commit message.I think this could close several of your open issues:
Validation across two independent encoder backends:
hevc_nvencWhat I'd like to propose, if you're interested:
One focused PR for the EVDI capture core (~7 patches, 0001–0008+0018) plus the minimum PKGBUILD changes to apply them. Out of scope for this PR: gamescope helper, AMD-only VAAPI tuning, CachyOS-flavored README, Steam-Deck-specific EDID. Those stay in the CachyOS fork.
Authorship would be preserved via
git cherry-pickso @Sgtmetalmex remains theAuthor:on every commit.Is this something you'd want as a PR? And if so, any preference on scope — all-at-once vs. patch-by-patch? Happy to follow whatever rhythm works for you.
Disclosure: I'm a first-time PR submitter on this repo, and both @Sgtmetalmex's original development and my coordination work involved AI coding assistance (Claude). The patches were end-to-end tested on real hardware before landing in the fork, and I've validated the streaming result on my own rig over a week of daily use.