On Thu, 9 Apr 2020 12:05:57 -0700 Erik Jensen <rkj...@google.com> said:
> On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl <jad...@gmail.com> wrote: > [snip] > > DRM master and input device revocation should be handled more or less > > already by most if not all compositors, by closing devices, by then > > going dorment until access is returned to the compositor. I don't know > > if there is any compositor that can already handle continuing it's > > session headless with an active PipeWire stream. > > Ideally, (though not a strict requirement for us), there'd also be a > way to specify the resolution of the offscreen virtual display (to > match the resolution of the client) without modifying the modes used > locally once the session is switched back to the local display(s). > > [snip] > > More or less, yes. Launching sessions without DRM master and going > > headless is probably things we can add capability fields for in the > > session .desktop files, and show dialogs like "Wait" or "Terminate > > session" if a conflict appears (as mentioned in the linked GDM bug). All > > of this would also not need be specific to a certain windowing system, > > so that you we can use the same APIs for handling both Wayland sessions, > > X11 sessions, and whatever more types that may eventually appear. > > You mentioned that integration with session management makes sense to > discuss with display manager folks. Where would be the best place to > discuss other such potential cross-windowing system remote-desktop > APIs like .desktop fields or headless startup? my take is this should be a daemon like a hybrid login manager/sshd, but instead of a text login shell, it authenticates then launches a "virtual fb" parent compositor that sets up a wayland compositor "rendering to ram" and then launches the actual user session as a wayland client. this will require compositors that are compatible need to support targeting both drm/kms directly in the tty AND as a wayland client of this compositor. this compositor would probably use something like the wayland fullscreen shell. it would be this compositor that encodes and transmits the compositing results over the network as well as reading in input from the remote system. the dbus session problem just need working around probably with another dbus session bus launched for this session and if apps have a problem with being run multiple times with different dbus sessions on the same system/homedir.. well.. there is nothing to be done - it's a problem with that app. it only matters if the user is logged in on the console and remotely and uses one of these types of apps. they can opt to not use them or do that, or these apps get fixed. if they want to "take over their existing console login session" the same idea applies but this remote compositor is actually a full system-wide fullscreen compositor and can auth some user then redirect their on screen session to be remote (and issue appropriate monitor reconfiguring when this happens) and replace their on-console session with a picture of a horses behind until the remote session ends... the same daemon can do both just with the option of it being a system-wide console compositor as opposed to "virtual, only for remote clients" most of the code is the same/shared. then they will bypass the above singleton problem apps by having only a single login (gui one) and single dbus session. the takeaway from this is more that the ecosystem at large needs to support compositors running as wayland clients with a system compositor using a fullscreen shell with all the appropriate logic to handle real local screens and expose them and let the client compositor configure them, as well as doing the "virtual rendering to memory and fake a virtual screen and modify that one (or ones if you want multiple screens) by unplugging/plugging it with new resolution options etc. if this system compositor is fairly lean and efficient and essentially doesn't get in the way of real desktop compositors, then it probably will be supported by most major compositors eventually. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel