[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: APIs for persistent remote access and headless/hybrid sessions
From:       Erik Jensen <rkjnsn () google ! com>
Date:       2024-03-16 2:51:24
Message-ID: CAN=K5G8NvfJewY=-h=McKptEcQUCVSCkoJ7EybjBjTQkynz1RA () mail ! gmail ! com
[Download RAW message or body]

Thinking about this more, I'm not really sure extending the existing
Portal API makes sense.

Given that remote assistance (well served by the existing API) wants

* Explicit user consent to share
* To allow the local user to select what to share
* To mirror the selected existing displays / windows

while remote assistance wants

* Persistent access
* To ensure the session is curtained or headless to prevent
observation and interaction from the local console
* Full control over the virtual monitor layout and the ability to
capture all of it

It seems like a unified API would have enough special cases depending
on which access mode is in use that it wouldn't really be worth it,
especially given that the actual capture (PipeWire) and input
injection (libei) would be the same either way. E.g., even with
persistent permission tokens, the existing ScreenCast portal doesn't
really fit the remote access use case, and a separate API to control
the layout and get the resulting PipeWire streams without user monitor
selection likely makes more sense.

> I suspect we might need Plasma Login Manager to exist first before
> we can achieve this, though. The kind of integration that GDM and
> GNOME Shell have allowed them to pull off what they did there, I'm
> not sure how to do it without that integration.

Ideally, I'd like to have a standard protocol that is both lightweight
and flexible enough that it wouldn't require any deep integration
between the login manager and desktop environment, but could be
implemented by even lightweight login managers.
[prev in list] [next in list] [prev in thread] [next in thread]