Re: Chrome Remote Desktop and Wayland
Hi, On Thu, Apr 23, 2020 at 2:27 AM Jonas Ådahl wrote: > Can't the remote login session still be "wayland", but without being > able to be drm master? So I think you're saying: "Clients still speak the wayland protocol when talking to the display server even if they're getting displayed via pipewire, so they should still have a wayland session type." It's a valid point that the possible session types are named after display server protocols, not display server outputs. i.e., we have "x11" and "wayland" not "x11-over-kms" and "wayland-over-kms". Although it all gets muddy when you consider mir supports wayland protocols, and even wayland supports x11 protocols with Xwayland, etc. > We still need API to manage the pipewire streams > (add/remove/change virtual outputs, So in my proposal, I said a virtual output can be automatically created when the logind session is registered, and all windows can be moved to that output when the session switches from "online" to "active" state (and we'd add some way for logind to be able to be told to move from "online" to "active" in this new session type when a user connects) > inject input, So this point here is a strong reason not to have a session type named "pipewire". And it's not something I'd considered before. I mean input isn't going through pipewire. And, of course, even getting the pipewire stream needs to go through mutter. I guess pipewire isn't really first class, or distinguishing here. So you've convinced me. > would adding a new session type bring us anything useful? Well, it would be useful if we had some logind level bookkeeping that distinguish e.g., vnc sessions from drm ones. but I guess session type isn't going to work out for that purpose. Maybe, sd_session_get_service is good enough for that purpose, then. logind sessions are generally registered with pam_systemd anyway, so there's going to be an associated pam service file. If we decide it's not good enough, we could always try to add a sd_session_get_output_target (render_platform/medium/whatever) > We wouldn't just implicitly spit out a > pipewire stream for some made up output, I assume we still want it to be > managed some how by the remote desktop service. Okay, so let's do another iteration, and talk this through this updated vision a little deeper but from the gnome-remote-desktop point of view. I assume chrome-remote-desktop would be similar but let's start with g-r-d. If this is TL;DR territory let me know and I'll throw it on the GNOME wiki instead. Here's how I believe gnome-remote-desktop works *today* with a shared local session instead of a curtained local session: 0. User logs in from the GDM login screen on VT 1. This opens a pam session, registers a logind session, and runs gnome-session 1. gnome-session starts the session off by doing: $ systemctl --user start gnome-session-wayland@gnome.target where "wayland" is the session type (the @gnome part isn't important for this discussion, but it could also be "@gnome-classic" for classic mode or "@gnome-login" for the login screen). 2. This target pulls in gnome-shell-wayland.service which starts gnome-shell. 3. Gnome-shell initializes its "native" backend where it sets up kernel modesetting. It uses the graphics hardware attached to seat0. If the oldest graphical session isn't attached to seat0, gnome-shell will fail to initialize. This logic will obviously need to be improved. 4. The gnome-session-wayland target also pulls in gsd-sharing.service which starts the daemon that starts gnome-remote-desktop. This is guaranteed to be started after gnome-shell is started. 5. gnome-remote-desktop tells mutter it's going to be doing input remotely by calling org.gnome.Mutter.RemoteDesktop.CreateSession. This makes mutter set up virtual input devices, and provides access to those input devices via a unique identifier. 6. gnome-remote-desktop tells mutter it's going to be doing output remotely by calling org.gnome.Mutter.ScreenCast.CreateSession. It links that output to the previously set up virtual input devices by passing the unique identifier generated in step 5 to this call. 7. gnome-remote-desktop tells mutter to send the primary monitor of the already running session to the newly created screencast session by calling org.gnome.Mutter.ScreenCast.Session.RecordMonitor. This call returns a pipewire stream, with one end hooked up to the primary monitor of the already running session. 8. gnome-remote-desktop acts as a VNC server and forwards all input from VNC clients to mutter via the virtual input devices created in step 5. It pushes video from the pipewire stream created in step 7 to VNC clients. I think I got those steps right, but tell me if you spot anything I got wrong. :-). Now how would gnome-remote-desktop go from here to a world with curtaining? 0. We're no longer going to have one session that gets shared, so we need two distinct sessions registered. One session is still the user logging in fro
Re: Chrome Remote Desktop and Wayland
Hi, On Tue, Apr 21, 2020 at 8:21 AM Benjamin Berg wrote: > Yes, I agree that "user" is very similar. However, it cannot currently > convey any information about whether a graphical session is already > running or whether it is capable of spanning multiple logind sessions. why does that information need to be conveyed? who would consume it? > > I don't think gnome-session needs to do much beyond what it's already > > doing. It just needs to make sure systemd is told what services to > > start, if they aren't already started (which target to reach) > Well, you need some mechanism to attach the new session/seat to the > running graphical session and then watch for it to be released again > And yes, the session leader process could be the one taking care of > that. So to be clear, I've been advocating for mutter/gnome-shell to do the attaching *themselves*. We don't need any new api for them to do that. If mutter is already running, it just needs to set up a sd_login_monitor to detect when a new session for the user show up. As soon as a new session is registered with logind, that new session is announced. mutter can then check the session type of the newly registered session and see if it needs to add a new output (to e.g. pipewire or to kms). This can be done using api that exists today (well we need a new session type, right now there's only tty, x11, wayland, mir, unspecified, we need pipewire too) > But, the other part of this is that the situation is confusing. Right > now we assign "user" processes to one of the logind sessions by doing a > best guess. That works great as long as the user has one graphical > logind session. But, if this graphical session starts spanning multiple > logind sessions, then the choice becomes more relevant as each of the > sessions might for example have a different "Active" state. Right, mutter shouldn't be guessing which session to use. it should use all of them! it may use some logic to figure out where window go (e.g, last that went active wins), but all active sessions should get chrome. > So, having something that represents the combination of all of them > could bypass that problem in an elegant way. We would never need to > "guess" the session, we would just always return the combined "user" > session. This user session would for example be considered "Active" as > lone as any of the underlying logind sessions are active. Totally agree with these words, but I also think that's precisely what a "user" is in logind. i don't see any advantage to having something between user and session that's basically the same as user. > Sorry, I meant the desktop here. ah okay. > So if KDE and GNOME have incompatible > implementation then we may run into odd error scenarios should the user > try to change the session type while they are logged in already. You're saying a user wants to log into KDE on X11 and GNOME on wayland at the same time, and both use systemd --user? First, I think that's a fairly niche use case that cause problems for the user (e.g., what if they try to run firefox in both?) But I don't think there's anything that would prevent it from working. logind lets a display server query whether or not a session is KDE or GNOME. See sd_session_get_desktop . Each display server, should clearly only manage sessions registered for their own desktop. > > > 3. we would likely get different implementations with varying degree > > > of brokenness. > > Not sure what you're saying here, can you reiterate? > I think the above captures it well enough. I still don't understand. Is this in the context of KDE and GNOME ? --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi, On Fri, Apr 17, 2020 at 11:25 AM Benjamin Berg wrote: > > If so, I agree it's better if we don't have the user entering their > > password in their > > own session. In an ideal world we'd have a "secure attention" key or key > > sequence on the keyboard that users hit when it's time to type their > > password. > Yup. So I'll just add one other note... People expect to be able to blindly type their passwords to the lock screen and hit enter to get back to their session. I know from experience users get very upset if this feature is broken! If we add a SAK key they definitely wouldn't be able to do that anymore, but if we don't have a SAK key, there isn't really trusted path. Anyway doing unlock from tty1 is a good idea for other reasons (like systemd-homed), so it makes sense whether or not we pursue trusted path. --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi, On Fri, Apr 17, 2020 at 9:58 AM Benjamin Berg wrote: > I do however think there is value in supporting such delegation from > the logind side. A primary motivator for me here is systemd-homed, as > it may freeze the user session, making it impossible to re-authenticate > from within. So my plan for systemd-homed was going to be to just make the GDM session worker jump to VT1. Today, if we jump to VT1 a login screen will materialize and all should just work. We could add some mechanism to logind to register where a login screen will go and provide a way for logind to jump to that login screen instead, sure. > And really, it would be better if we don't let the user ever see their own > password. not sure what you mean by this. are you talking about ensuring trusted path? If so, I agree it's better if we don't have the user entering their password in their own session. In an ideal world we'd have a "secure attention" key or key sequence on the keyboard that users hit when it's time to type their password. > But, it should be as simple as logind forcing a VT switch to the > correct greeter UI/session. Plus a little bit more magic to maybe spin > up the UI in the background before suspending and pre-selecting the > user to make the experience smoother. Right, I'm definitely not opposed to api getting added to logind for this, but I also don't think it's strictly necessary. We can do it all from GDM pretty easily. Probably when I play with systemd-homed I'll prototype things out on the GDM side first. But, I also think this is an orthogonal discussion to remote desktop support. (maybe one better for the systemd list?) --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi,
On Fri, Apr 17, 2020 at 8:45 AM Benjamin Berg wrote:
> I feel that this means that we conceptually have a "composite" session
> that consists of multiple "normal" logind sessions. And I wonder if we
> could make this singleton "composite" session an explicit concept
> rather than something that purely exists implicitly.
This concept of a "composite session" you speak of already exists in
logind. In logind nomenclature it's called a "user".
> In the "simple" implementation, we could expect each desktop
> environment to handle all this themselves. i.e. gnome-session would
> launch, see there is already an existing one, and then do an
> appropriate call to "attach" the new seat and remain dormant until it
> should/needs to be detached again.
I don't think gnome-session needs to do much beyond what it's already
doing. It just needs to make sure systemd is told what services to
start, if they aren't already started (which target to reach)
> While possible, I see the disadvantages that,
> 1. GDM/the greeter cannot know whether attaching is possible,
GDM certainly can (and already does) know if the user already has a
running session.
> 2. the user could try launching a different session type
Launching different session types should be supported. I mean, if the
user is already running a local kms ("wayland") session, and then
starts a "pipewire", mutter should detect and handle that.
I think it would even be possible in theory (though maybe hard in
practice with mutter, and of dubious value) to support "x11" and
"wayland" at the same time.
> 3. we would likely get different implementations with varying degree
> of brokenness.
Not sure what you're saying here, can you reiterate?
> Right now to login/create a session we do:
> * GDM starts helper process
right, we call that a "session worker"
> * Helper does pam authentication and creates pam session,
right.
> * pam_logind moves helper into scope and attaches an FD for watching
pam_systemd, but yea it should have been called pam_logind :-)
Right, and to be clear, this is where session registration happens.
pam_systemd use's logind's dbus api to say "Here's a new
wayland session" or "here's a new Xorg session".
> * Helper effectively launches the user's session processes
Yup, the session worker forks off the session from here, and sticks
around to tell PAM when the session is over, too.
> What if, instead, the user can only have one "composite" graphical
> session from GDMs point of view (which may not support multiple "real"
> sessions, e.g. in the case of X11).
>
> We can have calls in logind to manage such a composite session, i.e.:
> * attach a new "real" logind session
> * detach a "real" logind session
> * create a new "composite" session with an existing "real" session
So I don't understand why attaching a session would be a separate step
from creating the session. logind automatically attaches all new sessions
to the user ("composite session" in your nomenclature). why wouldn't
you want it to continue to do that?
Is the point that you want to support multiple concurrent composite sessions
for a user? If so, what if those concurrent sessions share services? All of
a sudden those services need to not only see what sessions they're in, but
also need to see what composite sessions they're in?
> Session creation itself could be delegated to systemd-logind. The funny
> thing is, that then GDM may never need to launch user processes. It
> would go through PAM for authentication, and then from there just call
> the "attach" or "create" method.
So historically, the reason things have been done the way they are, is
because PAM has these notions of credentials and environment that
PAM modules can influence. The simplest example is
environment variables, which can be fairly easily transferred out from
the session worker, but there's also, for example, creating a session
specific kernel keyring, assigning supplementary groups, instituting
ulimits, etc. Basically the PAM modules can do blackbox things to the
the process running the pam conversation and expect those "things" to
get passed on to the children of that process, to the session getting
opened.
Btw, PAM also expects, in some cases to be able to update those "things"
at unlock time. A canonical example would be a kerberos ticket put on
the session keyring. The ticket gets assigned at login, and renewed when
the user types their password at the unlock screen. In order to make that
sort of thing work, GDM jumps through some contortions to make the
session worker used for unlocking be forked from the session worker
used for login. (Though these days kerberos tickets aren't put on the
session keyring).
Now in a world where most of the session is running from a user context
anyway, obviously the users session, today, isn't picking up all those things.
This has created some problems, for instance,
https://bugzilla.gnome.org/show_bug.cgi?id=780622
But, that just means we need
Re: Chrome Remote Desktop and Wayland
Hi, On Fri, Apr 17, 2020 at 3:59 AM Marcel Hollerbach wrote: > I really like the idea of curtaining the session. > However, i am wondering if logind couldn't serve there as sort of > gatekeeper [...] > 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. So you're saying logind would take on the function of e.g. GDM? I think logind is intentionally primarily about bookkeeping and resource passing. The individual desktops want to be able to design the user experience for their unlock screens. Also, in the olden days GDM used to have a separate "micro" session, itself. It had a perennial problem that things from a real session needed to be reimplemented in it. Things like keyboard layout choosing, accessibility features, system trays, etc. And so there was duplicated code, that had duplicate bugs, and the login screen UI provided a different experience than the logged in UI, which was suboptimal for the user. So that's why we changed GDM to actually run a "normal" session instead of a "micro" one. I mean we still obviously turn a lot of knobs off for the login screen, but we're running the same implementation inside the session as out, and we give the user a consistent experience and don't have to implement everything twice. > 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. So logind already tells a session whether or not it is active, and already handles giving and taking away devices from a session. These are things parts of the session can and do listen to today. --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hey, On Wed, Apr 8, 2020 at 12:04 AM Erik Jensen 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. > * 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, ot
Re: [PATCH wayland] Revert "client: require WAYLAND_DISPLAY to be set"
Hi, > All of these arguments makes sense, so I guess I agree with reverting this > change. Great. pq are going to push before the beta? --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Revert "client: require WAYLAND_DISPLAY to be set"
Hi, > This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d. thanks, you've got my vote. Acked-by: Ray Strode --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
Hi, > thanks, and sorry I didn't see your reply before I pushed. :-D So this commit totally broke gtk+. Thread 1 (Thread 0x7f3813651980 (LWP 537)): #0 g_logv (log_domain=0x7f38128b01ce "Gdk", log_level=G_LOG_LEVEL_ERROR, format=, args=) at ../../glib/gmessages.c:1078 #1 0x7f380edd30cd in wl_log (fmt=fmt@entry=0x7f380edd31b8 "error: WAYLAND_DISPLAY not set in the environment.\n") at ../src/wayland-util.c:385 #2 0x7f380edd0115 in connect_to_socket (name=0x0) at ../src/wayland-client.c:768 #3 wl_display_connect (name=name@entry=0x0) at ../src/wayland-client.c:899 #4 0x7f38128a5f7e in _gdk_wayland_display_open (display_name=0x0) at ../../../gdk/wayland/gdkdisplay-wayland.c:443 #5 0x7f381285b357 in gdk_display_manager_open_display (manager=, name=0x0) at ../../gdk/gdkdisplaymanager.c:463 #6 0x7f3812d24c10 in gtk_init_check (argc=, argv=) at ../../gtk/gtkmain.c:1011 #7 0x7f3812d24c49 in gtk_init (argc=, argv=) at ../../gtk/gtkmain.c:1068 #8 0x00400e11 in main (argc=0, argv=0x0) at ../../tools/gnome-session-check-accelerated.c:121 gtk+ treats wl_log messages as fatal errors. See this commit from krh: https://git.gnome.org/browse/gtk+/commit/?id=4252ac6d6ce2a02efa0991fc0723f9522aff7a0f Gtk+ also uses its wayland backend by default, so after this change, it now dies instead of falings back to the x11 backend on non-wayland sessions. I've filed https://bugzilla.gnome.org/show_bug.cgi?id=753635 to change gtk+'s default behavior to treat wayland errors as debug messages now. Still, I think this change is wrong headed. We've been trying to cleave ourselves from environment variables for years in the default case. Having to set this seems like a step backward. This means having to jump through additional hoops when using systemd --user sessions, it means having to jump through an additional hoop when running a program from a VT, and it means having to jump through an additional hoop when ssh'ing in to debug something. if a user runs a program it should show up on the default display in a clean environment. save the environment variables for fringe cases like nested compositors. The problem purportedly getting fixed gives this as a rationale: > Now suppose you launch Weston while running the Gnome session. Suddenly, all > of the Gtk+ apps > launched from Gnome will show up inside Weston instead. That's unexpected. > There's also no good > way to prevent that from happening (other than perhaps setting > WAYLAND_DISPLAY to an invalid value > when launching an app). It's wrong to say there's no good way to prevent programs from launching on weston. This corner case, can be covered by setting the GDK_BACKEND environment variable. edge cases should use environment variables not the default case. Furthermore, the commit says it's trying to fix a scenario where the user is logged into X, but the commit actually breaks X logins (because of the above log handler issue)! That means it wasn't tested. I don't think the commit is good idea at all, can we revert it ? XDG_RUNTIME_DIR is supposed to free us from other environment variables. --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
