| Summary: | Multiseat with single GPU fails | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | logan |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | luke-jr+kdebugs, xaver.hugl |
| Priority: | NOR | ||
| Version: | 5.17.4 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
logan
2020-01-25 03:28:19 UTC
Sorry but this can't really be done. Managing output devices requires access and control to global resources of the GPU. On the kms/drm level that's also reflected by there only being one drm master per GPU - I'm surprised you could make KWin run while a tty was active at all, it definitely doesn't work with multiple compositors. If you want multiple seats on a single GPU then you need a compositor that manages that explicitly. In terms of running multiple compositors at once that could be done by running them nested in a special compositor. AFAIK compositors allowing such things don't really exist yet though X11 could do it, so is Wayland a big step backward? It's not about Wayland, it's about hardware and kernel API restrictions. From what I could find out multi seat on Xorg worked exactly like what I'm describing would be needed for Wayland, too: one instance ("normal" Xorg) runs on the hardware, multiple other instances (Xephyr) run nested on the outputs.
Admittedly, it hasn't worked since systemd invaded, but it used to be possible to just run two Xorg servers, each controlling a monitor. Possibly pre-compositing (but many of us still don't use compositors even today) (In reply to Zamundaaa from comment #1) > Sorry but this can't really be done. Managing output devices requires access > and control to global resources of the GPU. On the kms/drm level that's also > reflected by there only being one drm master per GPU - I'm surprised you > could make KWin run while a tty was active at all, it definitely doesn't > work with multiple compositors. > If you want multiple seats on a single GPU then you need a compositor that > manages that explicitly. In terms of running multiple compositors at once > that could be done by running them nested in a special compositor. AFAIK > compositors allowing such things don't really exist yet though I was under the impression that the login1 provider handled the kernel/drm level resource allocation, so handing the per-screen render plane to the compositor should be possible, but it might have poor security implications if the kernel-level (or hardware level) isolation aren't what they'd need to be. Given that a major goal of wayland is to resolve the security concerns that existed under X11, it's probably not worth pursuing further. That said, the poor behavior exhibited is not ideal, a clear error message that split-card-multiseat is unsupported by kwin shouldn't be too difficult to add, and would avoid the silent breakage / corrupted output. |