SUMMARY When Wayland compositors start, they are supposed to limit themselves to only the hardware which is attached to the seat on which the compositor is running loginctl can split the outputs of a single graphics card into multiple seats; these split outputs count as primary devices for seats, allowing them to start up. kwin breaks in 2 ways when trying this. STEPS TO REPRODUCE 1. Set up kwin wayland, with logind or elogind 2. With a multi-output GPU, assign one port to seat1 3. Ask startplasma-wayland to start on seat0; note failure mode 1 4. Ask startplasma-wayland to start on seat1; note failure mode 2 OBSERVED RESULT In the seat0 case, kwin_wayland fails to start. It doesn't matter if there is a monitor attached to the output in question, or which output gets moved to seat1, it fails to start. In the seat1 case, it starts, and grabs all connected screens, regardless of which seat they are assigned. Seat1 doesn't own the tty, so you actually get the mouse cursor *over* the text of the tty, with various repaints fighting back and forth between kwin and the tty shell. EXPECTED RESULT In the worst case, a clear error message that split-gpu multiseat is not supported on KDE. In the ideal case, it should be possible to run a multi-seat setup with a single GPU the same as you can with multiple GPUs. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo 17.0, Linux 5.3.9 (available in About System) KDE Plasma Version: 5.17.4 KDE Frameworks Version: 19.08.3 Qt Version: 5.12.5 ADDITIONAL INFORMATION
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.