Chrome Remote Desktop and Wayland

Fri Apr 17 07:59:04 UTC 2020

Hi,

On 4/16/20 8:45 PM, Ray Strode wrote:
> Hey,
> 
> On Wed, Apr 8, 2020 at 12:04 AM Erik Jensen <rkjnsn at google.com> wrote:
>> Chrome Remote Desktop currently works on Linux by spinning up its own
>> Xvfb server and running a graphical session in that. However, as more
>> and more parts of the stack assume that a user will have at most one
>> graphical session, this is leading to more breakage more often. E.g.,
>> several distros have switched DBUS to using a single session bus per
>> user, which only supports one graphical session, and recent versions
>> of GDM will fail to log a user in locally at all if a Chrome Remote
>> Desktop session is running due to
>> https://gitlab.gnome.org/GNOME/gdm/-/issues/580. Given that Chrome
>> Remote Desktop starts at boot, the latter means that even just setting
>> it up and rebooting is enough to break local logins for the user,
>> which is obviously less than ideal.
> Right, and as mentioned in the bug, GNOME doesn't really support
> logging in more than once with the same user from a data reliability
> point of view anyway.  I mean the settings database doesn't work well
> if more than one thing is writing to it at the same time (which is one
> of the reasons writes for all apps are funneled through a daemon).
> 
>> We have the following constraints for our use case:
>>   * Chrome Remote Desktop must be usable after boot without the user
>> needing to log in locally, first.
> makes sense.
> 
>>   * It must be possible to "curtain" the session, meaning that, when a
>> user is connected, their session is not displayed on the local
>> monitor. (Imagine a user working from home and connecting to their
>> workstation in a shared office space.)
> Yea this is something we've wanted in GNOME for a long.  See for
> instance this bug from 2005:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=311780
> 
> Back then we didn't even have compositing window
> managers so it wasn't something we could practically implement.
> Today's a different story!  This is something mutter/gnome-shell can
> reasonably implement with some effort.
> 

I really like the idea of curtaining the session.
However, i am wondering if logind couldn't serve there as sort of 
gatekeeper, this idea is not new, i was thinking about that already a 
few years ago.
The idea is that a session in logind can be locked or unlocked. In case 
it is locked, logind would spin up a "micro" session with a process that 
renders something to login.
A successful login there would unlock the other session. This 
microsession can be displayed on *some* output which depends on the 
implementation of this process allowing to login.
The login session can also give hints to what sort of session this is 
now transformed (pipewire or real, from your proposal below). This is 
useful for apps/libs like spotify/pulseaudio as they can check if they 
should output music on physical devices for example or not. GNOME would 
then be told by logind when it needs to transform to a different sort of 
session.

I think this is useful to have in logind instead of gdm / gnome itself, 
because the process of login in / bringing up a session is more 
unified.There is no need to differentiate between login from something 
like chrome or the physical appearance of a person in front of a screen.
Additionally, it seems to me that this is more crash proof, if the 
session crashes because of something, a user would just be thrown back 
to the micro session, hopefully leaving him to login back.

Greetings,
    bu5hm4n

>>   * It's okay to require X11 today, but there should be a reasonable
>> path forward as more distributions switch to Wayland.
> I think it's more likely for mutter, that this would land in the
> native display server (wayland) side first.
> 
>> Possible idea brainstorming:
>> I'm hoping for feedback for the feasibility of these, given I don't
>> have a lot of experience with Wayland or the modern graphical session
>> architecture. All of these have gaps which make them likely not usable
>> *right now*, so the question is probably which approach would be the
>> most likely to be accepted by the relevant projects, and potentially
>> which would be the quickest to design and get working.
>>
>> There's likely other possibilities that I haven't thought of.
> [snip]
>> ~Add curtaining support to session compositors~
> This seem like the most plausible way forward.
> 
> So the original idea with having a user bus instead of a session bus
> was that e.g., gnome-shell would handle all sessions, not just one
> session.  So rather than a gnome-shell per session, there would be
> just the one for the user, started by systemd and running in its own
> cgroup.  (Likewise, dconfd would handle setting writes for all sessions,
> and then no worries about the settings database getting corrupted.)
> 
> The idea is, that if gnome-session is started in the mode that tells
> it to use systemd, rather than starting gnome-shell and the rest of
> the required components of the session itself, it instead defers to
> the user's systemd instance to reach a specific target. That target
> has various session services as dependencies including gnome-shell.
> 
> Crucially, if one gnome-session instance starts gnome-shell via a
> systemd user service (say via chrome remote desktop), and another
> gnome-session instance gets started in a new session (say via the
> local gdm login screen), and also tries to set a systemd --user
> target that brings in gnome-shell, systemd won't start gnome-shell
> twice.  gnome-shell is instead a sort of factory process that starts
> when the first session logs in and lasts until the last session logs
> out.
> 
> But if gnome-shell is a factory process that may be around before a
> session is started, how can it know when that new session comes
> around so it can "adopt" or service it?
> 
> Sessions are registered with logind (usually via pam_systemd, but
> there's an underlying D-Bus api too).
> 
> gnome-shell can easily ask logind to enumerate all the sessions that
> belong to a user (see sd_uid_get_sessions), and can also easily
> detect when a new session comes or goes (see sd_login_monitor).
> It can also detect when a session is active or inactive via logind.
> 
> We don't really do a lot of this today, but one vision for the future is
> something like this:
> 
> - User logs into their workstation at work and hacks away for a while
> before needing to leave.
> 
> - Before going the user enables remote desktop, which leads to the
> new session getting registered with logind .
> 
> - This, in turn, tells systemd --user to reach a particular target that
>   pulls in gnome-shell, other gnome bits, and maybe some
> chrome-remote-desktop agent-y thing? Probably we would provide
> a gnome-session-pipewire at .target that ISVs could depend on, I guess.
> 
> - Since gnome-shell is already started, systemd doesn't start it again
> when reaching the new target.
> 
> - The already running gnome-shell instance notices the new session
> show up and stages a virtual output for it (that feeds to pipewire).
>   No windows are placed on this output, and it's locked, with the
> shell shield dropped.
> 
> - When the user connects with their remote viewer from their laptop,
> logind on the workstation reports the new session as "active" instead
> of just "online" (see sd_session_get_state ()).  This triggers the
> shield to raise, and the unlock screen to be presented.
> 
> - If the user then types their password, the session is unlocked and the
> windows are redirected to the virtual output.  At the same time, the shield
> on the workstation drops, and the seat there is locked.
> 
> - If the user goes back to their workstation and unlocks it the shield
> would drop over the remote desktop session, and the windows would
> get redirected back to the local seat.
> 
> So that's the vision.  Where do we stand?
> 
> Today, mutter doesn't have full support for virtual outputs to redirect
> windows, too, but it's something Jonas has mentioned he wants to work
> on for a variety of reasons (including this use case).
> 
> Today, gnome-shell doesn't try to listen for sessions coming and going,
> and it doesn't try to manage more than one session.  It also, doesn't notice,
> when some other session for the user starts, and so it doesn't let that new
> session preempt the currently active session.
> 
> Today, logind supports registering session for type "x11" and type "wayland".
> It doesn't support a type of "pipewire" which would be more appropriate for
> this remote desktop kind of session. Remember, in this vision, gnome-shell
> is listening for the new session to get registered with logind.  it needs to
> know the type of the session so it knows to enable pipewire and the
> virtual output.
> 
> Today, logind always forces the sessions that aren't running on a physical
> seat to have the state of "active".  At the moment "online" is mainly used for
> "running on inactive VT on the primary seat", and not so much in other contexts.
> We may need to enhance logind to support setting the state for these kinds
> of seat-less sessions.  Alternatively, we could potentially go off the
> "LockedHint"
> for the session, but it's not quite as good of a fit conceptually as the session
> state.
> 
> So there's a bit of work to do, mostly on the shell/mutter side, and some on the
> logind side, before there's a good story, but it should happen
> eventually. In the
> mean time, Benjamin is going to land a fix for your more immediate GDM
> problem soon:
> 
> https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/90
> 
> --Ray
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 