Re: Multi seat with nested servers?
On Thu, 08 Dec 2022 11:47:45 -0500 Phillip Susi wrote: > Only one Wayland server can control a given GPU, but if you have two > monitors on one GPU, isn't it possible to run a root server that > displays two nested servers each on their own monitor to get a multi > seat setup? Sure. > Has anyone done this? What would a good server be to use for the root? I don't know. There are two different approaches: - nested compositor presents to the root compositor which presents to KMS - nested compositor uses KMS leasing offered by the root compositor, and presents to KMS directly In the leasing case, the root compositor may not need to be even a Wayland server nor a compositor. It could be a system daemon like seatd or logind, if they offered the API for it. > Could you have the nested servers directly bind to their keyboard/mouse > or would the root server also have to multiplex those out to the nested > servers? In the root compositor case, the root server would indeed need to proxy the input as well. That would maintain security. OTOH, in the leasing case, if the lease daemon is also leasing out input devices (like seatd and logind already do today), input would not need to be proxied. Thanks, pq pgp0_XWuxGLpM.pgp Description: OpenPGP digital signature
[ANNOUNCE] libei 0.4.1
libei 0.4.1 is now available. This time with the tag pointing to the right commit. See below for the 0.4 announcement below which has all the interesting bits. On Fri, Dec 09, 2022 at 03:15:30PM +1000, Peter Hutterer wrote: > libei 0.4 is now available. libei is a library to send > Emulated Input (EI) to a matching Emulated Input Server (EIS) which can > receive those events with libeis, also part of this project. > > libei uses GitLab releases, for tarballs please see: > https://gitlab.freedesktop.org/libinput/libei/-/releases/0.4.1 > > Notable changes since 0.3: > - ei_setup_backend_portal() was removed. The portal it connected to never > really existed and all the efforts since have gone into supporting libei > connections through the RemoteDesktop and the InputCapture portals. Note > that these changes are not yet merged into upstream xdg-desktop-portal. > - a new library "liboeffis" takes the place of the above. It is a helper > library to connect to the RemoteDesktop portal via DBus with a minimal API > and retrieve the EIS socket. > This library is intended to be used by tools that cannot easily talk DBus > themselves (this includes Xwayland). > - the libei/libeis log handlers have a new API which makes handling log > messages a bit simpler. > - version exchange between client/server make it possible (in the future) to > have multiple supported protocol versions. > > This is a development snapshot and neither API nor ABI should be considered > stable. Anyone using libei or libeis must keep both in sync, there are no > accommodations made for libei/libeis from different versions and the wire > protocol may break at any time. > > Please see the API documentation here: > https://libinput.pages.freedesktop.org/libei/ > > The git shortlog is below: > > Olivier Fourdan (7): > README: Xwayland is a Wayland client > Fix absolute events filtering > util: Add block/release signals API > util: Protect system calls against signals > util: Add a wrapper for dup() and pipe2() > ei: Use the signal protected wrappers > liboeffis: protect from interrupted system calls > > Peter Hutterer (44): > Add a comment that reserved properties cannot be set by the API > reis: fix return code handling in allow_capabilities > reis: drop unnecessary variable rc > proto: reformat according to the Google Style Guide > proto: specify that Configure messages must be sent before connection > eis: capabilities can only be reduced > proto: document ConfigureCapabilities > proto: split the Configure messages out a bit > proto: document that only one ConfigureName is possible > Remove a double semicolon > util: only do flag_* operations if the bit fits > test: rename the ei AUTOCONNECT behavior to HANDLE_CONNECT > test: set up libreis support in eierpecken > eis: send out the list of existing properties on connect > eis: add eis_client_has_capability > test: add a few tests for reis > eis: default the client to only the capabilities we know about > tools/demo-client: stop means stop sending events > tools/demo-client: keep a ref to the ptr/kbd/abs devices > tools: print property values in the demo client and server > proto: split the client's SetProperty from the server event > log: allocate the log message on demand > log: enforce single logical messages only > Drop the trailing newline from the log messages > log: abstract the auxiliary information into a log message context > tools: drop help for obsolete --sender option from the eis-demo-server > Add a version macro for grepable version numbers > proto: add a version exchange prior to connect > proto: allow the client to set the protocol version > proto: add versioned Configure transactions > Fix some logging linebreak issues > proto: separate pre-connection properties into ConfigureProperty > doc: fix two references to function calls > doc: fix a doxygen warning about a wrong parameter name > doc: fix a comment in util-mem.h > meson.build: fix an indentation issue > CI: purge all references to the master branch > CI: bump to Fedora 37 > CI: bump to latest ci-templates > README: swap to RemoteDesktop over the nonexistent EmulatedInput portal > Purge the portal code > liboeffis is a wrapper library for the RemoteDesktop communication > util: change the signal handler to a context-manager like macro > libei 0.4 > > signature.asc Description: PGP signature
Re: Multi seat with nested servers?
Pekka Paalanen writes: > There are two different approaches: > - nested compositor presents to the root compositor which presents to KMS > - nested compositor uses KMS leasing offered by the root compositor, > and presents to KMS directly > > In the leasing case, the root compositor may not need to be even a > Wayland server nor a compositor. It could be a system daemon like > seatd or logind, if they offered the API for it. How does this leasing work? Does it lease the entire GPU or can it lease only one display? I would imagine it would be the entire GPU, in which case you couldn't lease it to both servers. > In the root compositor case, the root server would indeed need to proxy > the input as well. That would maintain security. Why do you say that? > OTOH, in the leasing case, if the lease daemon is also leasing out > input devices (like seatd and logind already do today), input would not > need to be proxied. What is this leasing you speak of? AFAIUI, logind just maintains a database of what input devices belong to what seats so that the display server can query it and find out which devices it should open.
Re: Multi seat with nested servers?
On Fri Dec 9, 2022 at 10:09 AM EST, Phillip Susi wrote: > How does this leasing work? Does it lease the entire GPU or can it > lease only one display? I would imagine it would be the entire GPU, in > which case you couldn't lease it to both servers. Using the drm-lease-v1 [1] protocol you can lease a connector, that would fit perfectly for your use case. > > > In the root compositor case, the root server would indeed need to proxy > > the input as well. That would maintain security. > > Why do you say that? I believe its to prevent both compositor to handle both input device. Similar to what the drm-lease-v1 does. The compositor asks for an input device and become the owner of it. Other compositors could not listen to their events. > > OTOH, in the leasing case, if the lease daemon is also leasing out > > input devices (like seatd and logind already do today), input would not > > need to be proxied. > > What is this leasing you speak of? AFAIUI, logind just maintains a > database of what input devices belong to what seats so that the display > server can query it and find out which devices it should open. Maybe it's an opportunity to draft a new protocol? Simon [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/drm-lease/drm-lease-v1.xml
