<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Feature request: support multiseat for a single multi-headed graphics card" href="https://bugs.freedesktop.org/show_bug.cgi?id=66501#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Feature request: support multiseat for a single multi-headed graphics card" href="https://bugs.freedesktop.org/show_bug.cgi?id=66501">bug 66501</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>AFAIU, if you do not want a system compositor spanning everything input and output, and then have session compositors for each seat, we would need the DRM KMS device split in the kernel. What that means is, that the DRM infrastructure would expose several KMS nodes for a single piece of hardware. How the hardware resources (CRTCs, connectors) are split among the KMS nodes is configured by user space during boot. Then each seat would have its own DRM KMS device node (systemd-logind could open those for the compositors, doesn't matter) that is restricted to the monitors intended for that seat. After that, the modifications necessary to compositors would be minimal. I think Dave Airlie would know more about that device node splitting, IIRC it was being planned some time in the past, but I have no idea what the idea is nowadays or if anyone is working on it. You might be better asking on dri-devel mailing list. The KMS nodes would be somewhat alike render nodes, except instead of exposing just GPU computing resources, each node would have a dedicated set of display hardware resources. In any case, this has nothing to with Wayland, and only a little to do with compositors.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>