Every line of Polyseat was written on one Arch host with an RTX 4080. The AMD path was written on that same machine, which is to say it was reasoned about rather than run. It has never encoded a frame.
That is not a gap in the code. The AMD path is finished, and on paper it is the simpler of the two: no injected driver, no repair step, Mesa arrives in the seat as an ordinary package, and a host driver update cannot leave a seat behind. docs/amd.md records what was verified without a card, which is more than nothing: the detection is checked against sysfs trees built by hand for six machines this one is not, every one of those checks was deliberately broken once to confirm it fails, the package set resolves to 491 packages in a fresh container and pulls no NVIDIA package, and the order that makes that work was measured rather than assumed.
What none of that can answer is whether the card encodes.
What is unknown
- Whether it encodes in hardware at all. The one that matters.
- Whether wlroots renders headless on
amdgpu inside a container.
- Whether Sunshine's wlr capture hands its frames to VA-API without a copy through system memory. If it copies it still works, and is slower.
- Whether 32 bit games find the GPU.
- Which codecs come out. AV1 wants RDNA 3 or newer, HEVC most things since Polaris.
- Anything about a specific card.
What it takes to find out
An Arch based host with a Radeon in it, amdgpu bound, one wired interface, and about an hour. The installer works out the card itself and says AMD in its first step.
git clone --branch v0.3.1 https://github.com/superuser404notfound/Polyseat.git
cd Polyseat
sudo host/install.sh
sudo systemctl enable --now polyseatd
Then add a seat, provision it, and read the encoder line on the seat's card in the web interface. vaapi means the hardware path came up. libx264 means it did not, and that is the bug this issue is about.
sudo host/install.sh --uninstall takes it all out again and leaves the containers alone.
What to report
Open a hardware report and paste sudo polyseatd -report. Read it before pasting: it carries your host name, your seat names and their private addresses, and no password or key.
The encoder line is the single most useful thing in it. After that, these two:
sudo incus exec <seat> -- vainfo --display drm --device /dev/dri/renderD128
sudo incus exec <seat> -- sudo -u player env XDG_RUNTIME_DIR=/run/user/1000 eglinfo -B
A report that says it simply worked is worth exactly as much as one that says it did not. Right now neither answer exists. A partial one is welcome too: if you get as far as the provisioning log and no further, that log is still more than this project has.
Card, kernel and Mesa version in the report are what turn one data point into a range, so please leave them in.
Every line of Polyseat was written on one Arch host with an RTX 4080. The AMD path was written on that same machine, which is to say it was reasoned about rather than run. It has never encoded a frame.
That is not a gap in the code. The AMD path is finished, and on paper it is the simpler of the two: no injected driver, no repair step, Mesa arrives in the seat as an ordinary package, and a host driver update cannot leave a seat behind.
docs/amd.mdrecords what was verified without a card, which is more than nothing: the detection is checked against sysfs trees built by hand for six machines this one is not, every one of those checks was deliberately broken once to confirm it fails, the package set resolves to 491 packages in a fresh container and pulls no NVIDIA package, and the order that makes that work was measured rather than assumed.What none of that can answer is whether the card encodes.
What is unknown
amdgpuinside a container.What it takes to find out
An Arch based host with a Radeon in it,
amdgpubound, one wired interface, and about an hour. The installer works out the card itself and says AMD in its first step.Then add a seat, provision it, and read the encoder line on the seat's card in the web interface.
vaapimeans the hardware path came up.libx264means it did not, and that is the bug this issue is about.sudo host/install.sh --uninstalltakes it all out again and leaves the containers alone.What to report
Open a hardware report and paste
sudo polyseatd -report. Read it before pasting: it carries your host name, your seat names and their private addresses, and no password or key.The encoder line is the single most useful thing in it. After that, these two:
A report that says it simply worked is worth exactly as much as one that says it did not. Right now neither answer exists. A partial one is welcome too: if you get as far as the provisioning log and no further, that log is still more than this project has.
Card, kernel and Mesa version in the report are what turn one data point into a range, so please leave them in.