Display Management / Login Screen
One important question toward integrating wayland into the desktop stack is what role GDM should play. GDM currently provides a few main functions:
- Starting and managing X servers (display management)
- Running gnome-shell in a special "GDM"-mode to present a login screen to the user
- Being a liason between the GDM-mode gnome-shell and the underlying authentication backend (PAM)
- Starting the user's session after authentication succeeds.
A first step toward wayland integration is getting GDM to manage wayland based user sessions in addition to the existing X based user sessions it already supports. For simplicitly, GDM should be changed to support this before the login screen itself is re-engineered to run a wayland compositor.
Typically, after a user has typed their username and password successfully, GDM kills the GDM-mode gnome-shell from the currently running X server, and then starts the user session on the same X server. In a model where the user's session is wayland based, we don't need to transition the X server over from the login screen program to the user sesssion. Instead of killing the login screen, we can reset it so it's available for user switching later. Alternatively we could kill the login screen and the X server, but doing that has the potential to disrupt the login process.
The login screen presents a list of sessions (e.g., GNOME, GNOME Classic) the user can log in with at login time. GDM needs to tag whether or not each of these sessions in the list are wayland sessions or X sessions, so that it knows whether or not to reuse the X server for the user session. These sessions are currently generated from a collection of keyfiles in /usr/share/xsessions. The file format is based on the .desktop file spec, but it's not really a desktop entry (since it describes sessions, not applications). An example file may look like:
[Desktop Entry] Encoding=UTF-8 Name=GNOME Exec=gnome-session
We can extend the file format to tag what kind of session it is, by adding a new line, prefixed with X-GDM-, e.g.,
X-GDM-Session-Type=wayland
GDM already has code for handling reseting the login screen and keeping the X server alive. It uses this code when a user performs user-switching to an already started session. We should be able to make use of or at least look at this code for inspiration:
Once GDM knows that it's going to start a user session that uses a wayland based compositor, it needs to pass that information on to PAM, before calling pam_open_session. Right now, GDM sets the PAM_XAUTHDATA and PAM_XDISPLAY items, before opening the session. pam_systemd uses these two items when registering the user session with logind. These items make no sense if the session isn't running on an X server. Some comparable mechanism will need to crafted to register "wayland" sessions (as opposed to "x11" sessions returned from sd_session_get_type). Session registration is currently done by the pam_systemd PAM module by calling CreateSession:
Some new parallel API will need to get added that's wayland aware.
logind currently handles setting up device acls on the dri devices. We should make sure all device acl management is consolidated in one place logind.
IRC Log
Thu 21 Mar 2013 03:51:57 PM EDT Mar 21 15:51:57 --- Users on #gnome-os: jjardon damien_l poettering jadahl stefw mdhill joss @ebassi|afk kklimonda @Services sri robtaylor fredp rtcm zeenix ivan moonlite Jasper hergertme
Thu 21 Mar 2013 03:52:01 PM EDT Mar 21 15:52:01 --> krh (~krh@c-67-186-132-98.hsd1.ma.comcast.net) has joined #gnome-os
Thu 21 Mar 2013 03:52:21 PM EDT Mar 21 15:52:21 <krh> hey halfline
Thu 21 Mar 2013 03:52:28 PM EDT Mar 21 15:52:28 --> rib (~bob@cpc3-heme9-2-0-cust169.9-1.cable.virginmedia.com) has joined #gnome-os
Thu 21 Mar 2013 03:52:33 PM EDT Mar 21 15:52:33 <halfline> hey
Thu 21 Mar 2013 03:53:15 PM EDT Mar 21 15:53:15 <krh> rib and I were talking about what to do about gdm and wayland and weston-launch in the near term
Thu 21 Mar 2013 03:53:21 PM EDT Mar 21 15:53:21 <rib> hey, yeah I was just starting to adapt something like weston-launch for mutter/gnome-shell and wondering about the interaction with pam and gdm
Thu 21 Mar 2013 03:53:52 PM EDT Mar 21 15:53:52 <halfline> so the way gdm works now is ...
Thu 21 Mar 2013 03:54:03 PM EDT Mar 21 15:54:03 <halfline> there's process called the "slave" that runs as root
Thu 21 Mar 2013 03:54:07 PM EDT Mar 21 15:54:07 <halfline> it starts an X server
Thu 21 Mar 2013 03:54:18 PM EDT Mar 21 15:54:18 <halfline> and it starts another process called the "worker" that also runs as root
Thu 21 Mar 2013 03:54:29 PM EDT Mar 21 15:54:29 <halfline> the worker is what does the PAM conversation
Thu 21 Mar 2013 03:54:44 PM EDT Mar 21 15:54:44 <halfline> so it calls pam_authenticate
Thu 21 Mar 2013 03:54:49 PM EDT Mar 21 15:54:49 <halfline> which runs through the auth stack
Thu 21 Mar 2013 03:55:11 PM EDT Mar 21 15:55:11 <halfline> and any time there are messages they get forwarded up to gnome-shell which is running in gdm mode
Thu 21 Mar 2013 03:55:16 PM EDT Mar 21 15:55:16 <halfline> (the login screen)
Thu 21 Mar 2013 03:55:31 PM EDT Mar 21 15:55:31 <halfline> any time the user answers a message, it gets sent back to the worker that feeds it into pam
Thu 21 Mar 2013 03:55:57 PM EDT Mar 21 15:55:57 <halfline> eventually the worker calls pam_open_session after working through the auth and account stacks
Thu 21 Mar 2013 03:56:13 PM EDT Mar 21 15:56:13 <halfline> this pam_open_session call registers the session with logind
Thu 21 Mar 2013 03:56:22 PM EDT Mar 21 15:56:22 <halfline> and then the worker forks() and setuid() to the user
Thu 21 Mar 2013 03:56:29 PM EDT Mar 21 15:56:29 <halfline> and execve()'s gnome-session
Thu 21 Mar 2013 03:56:47 PM EDT Mar 21 15:56:47 <halfline> after the fork, the worker sits around and waits for the session to end
Thu 21 Mar 2013 03:56:57 PM EDT Mar 21 15:56:57 <halfline> and then calls pam_close_session()
Thu 21 Mar 2013 03:57:33 PM EDT Mar 21 15:57:33 <halfline> does all that writing make sense ?
Thu 21 Mar 2013 03:57:42 PM EDT Mar 21 15:57:42 <rib> okey that makes some sense to me yeah
Thu 21 Mar 2013 03:57:52 PM EDT Mar 21 15:57:52 <krh> yup - who starts gnome-shell greeter mode? slave or worker?
Thu 21 Mar 2013 03:58:13 PM EDT Mar 21 15:58:13 <halfline> the slave starts a worker specifically for the greeter user
Thu 21 Mar 2013 03:58:30 PM EDT Mar 21 15:58:30 <halfline> that worker uses a minimal pam stack
Thu 21 Mar 2013 03:58:43 PM EDT Mar 21 15:58:43 <halfline> (called /etc/pam.d/gdm-launch-environmont )
Thu 21 Mar 2013 03:58:55 PM EDT Mar 21 15:58:55 <krh> ok
Thu 21 Mar 2013 03:59:25 PM EDT Mar 21 15:59:25 <krh> so it sounds like the worker process is very similar to weston-launch
Thu 21 Mar 2013 03:59:31 PM EDT Mar 21 15:59:31 <halfline> s/greeter user/gdm user (uid 42 on fedora)/
Thu 21 Mar 2013 03:59:48 PM EDT Mar 21 15:59:48 <halfline> yea i briefly looked at weston-launch of a couple of days ago
Thu 21 Mar 2013 04:00:03 PM EDT Mar 21 16:00:03 <halfline> it runs a subset of the pam stuff
Thu 21 Mar 2013 04:00:08 PM EDT Mar 21 16:00:08 <halfline> (basically just the session stack)
Thu 21 Mar 2013 04:00:24 PM EDT Mar 21 16:00:24 <halfline> and uses the /etc/pam.d/login service file normally used by /bin/login
Thu 21 Mar 2013 04:00:27 PM EDT Mar 21 16:00:27 <krh> yeah, we just run enough to get a valid session and get the right facls on device nodes
Thu 21 Mar 2013 04:00:29 PM EDT Mar 21 16:00:29 <halfline> but conceptually they seem similar
Thu 21 Mar 2013 04:00:55 PM EDT Mar 21 16:00:55 <halfline> in a wayland world, things are little inside out compared to an X world
Thu 21 Mar 2013 04:01:15 PM EDT Mar 21 16:01:15 <halfline> i wouldn't make sense for the slave to start a wayland server for instance
Thu 21 Mar 2013 04:01:18 PM EDT Mar 21 16:01:18 <halfline> in the way it starts an X server
Thu 21 Mar 2013 04:01:20 PM EDT Mar 21 16:01:20 <krh> what weston-launch does in addtion is to keep a socket connection to weston, and helps weston open input devices and do drop/set master on the drm device
Thu 21 Mar 2013 04:01:33 PM EDT Mar 21 16:01:33 <halfline> it would just start the greeter's gnome-shell which would be the wayland display server
Thu 21 Mar 2013 04:02:06 PM EDT Mar 21 16:02:06 <krh> right, there are two issues here: how do we make gdm work as a wayland server and how do we start wayland sessiosn
Thu 21 Mar 2013 04:02:31 PM EDT Mar 21 16:02:31 <halfline> well the thing to remember is in the X model
Thu 21 Mar 2013 04:02:39 PM EDT Mar 21 16:02:39 <halfline> the login screen runs on the some display server as the user session
Thu 21 Mar 2013 04:02:57 PM EDT Mar 21 16:02:57 <halfline> once the user types in the right credentials, the greeter's gnome-shell dies off
Thu 21 Mar 2013 04:03:14 PM EDT Mar 21 16:03:14 <halfline> and the display is handed over to the user's gnome-session / gnome-shell
Thu 21 Mar 2013 04:03:14 PM EDT Mar 21 16:03:14 <krh> yup
Thu 21 Mar 2013 04:03:56 PM EDT Mar 21 16:03:56 <krh> once gdm runs as a wayland server, it won't do that
Thu 21 Mar 2013 04:04:21 PM EDT Mar 21 16:04:21 <rib> initially I'm not sure we need to adapt gdm to work as a wayland server since in the first phase of wayland support for gnome we can still run the login screen like today with an xserver
Thu 21 Mar 2013 04:04:39 PM EDT Mar 21 16:04:39 <halfline> well gdm doesn't do any of the "front end" stuff
Thu 21 Mar 2013 04:04:45 PM EDT Mar 21 16:04:45 <halfline> so i'm not sure it should ever be a wayland server
Thu 21 Mar 2013 04:04:47 PM EDT Mar 21 16:04:47 <halfline> gdm just runs gnome-shell
Thu 21 Mar 2013 04:05:06 PM EDT Mar 21 16:05:06 <halfline> for the user session gnome-shell is going to provide the wayland server right?
Thu 21 Mar 2013 04:05:13 PM EDT Mar 21 16:05:13 <krh> it doesn't run any clients at all?
Thu 21 Mar 2013 04:05:20 PM EDT Mar 21 16:05:20 <halfline> no
Thu 21 Mar 2013 04:05:26 PM EDT Mar 21 16:05:26 <krh> ok
Thu 21 Mar 2013 04:05:29 PM EDT Mar 21 16:05:29 <halfline> i mean it XOpenDisplay and moves the mouse cursor
Thu 21 Mar 2013 04:05:39 PM EDT Mar 21 16:05:39 <krh> well I guess gnome-shell could support running in a mode with no wayland server support
Thu 21 Mar 2013 04:05:47 PM EDT Mar 21 16:05:47 <krh> and just come up on kms and prompt for password
Thu 21 Mar 2013 04:06:20 PM EDT Mar 21 16:06:20 <krh> but that's mostly a detail for the purpose of this discussion
Thu 21 Mar 2013 04:07:00 PM EDT Mar 21 16:07:00 <halfline> well gnome-shell depends on gnome-settings-daemon and the like to be running, even in the login screen
Thu 21 Mar 2013 04:07:14 PM EDT Mar 21 16:07:14 <krh> and anyway, I think it's probably a good idea to focus on just the how-to-launch-a-wayland-session aspect for now
Thu 21 Mar 2013 04:07:59 PM EDT Mar 21 16:07:59 <rib> so initially I would image we leave the slave aspect unchanged, running gnome-shell in gdm mode against a regular x server. but the stuff I wonder about is the differences with starting a new gnome-session with a new xserver vs a weston-launch like thing
Thu 21 Mar 2013 04:08:16 PM EDT Mar 21 16:08:16 <krh> yea
Thu 21 Mar 2013 04:08:54 PM EDT Mar 21 16:08:54 <krh> I imagine that we can extend the worker process to do what weston-launch doesn in case of a wayland session
Thu 21 Mar 2013 04:09:02 PM EDT Mar 21 16:09:02 <rib> it sort of sounds like gdm can deal with creating the pam session for us, which is one thing that weston-launch currently does
Thu 21 Mar 2013 04:09:10 PM EDT Mar 21 16:09:10 <halfline> yea, i agree
Thu 21 Mar 2013 04:09:13 PM EDT Mar 21 16:09:13 <krh> vt switching and the setuid helper parts
Thu 21 Mar 2013 04:09:26 PM EDT Mar 21 16:09:26 <halfline> it would make sense to just put the relevant parts of weston-launch in gdm-session-worker
Thu 21 Mar 2013 04:09:27 PM EDT Mar 21 16:09:27 <rib> right vt switching is the next bit I'm wonderng about
Thu 21 Mar 2013 04:09:36 PM EDT Mar 21 16:09:36 <krh> since the worker stays around for the duration of the session anyway
Thu 21 Mar 2013 04:10:21 PM EDT Mar 21 16:10:21 <krh> rib: oh yeah, you had a good point about putting some of the vt init/restore code in weston-launch to have better error recovery
Thu 21 Mar 2013 04:10:21 PM EDT Mar 21 16:10:21 <halfline> so if we vt switch we're going to flicker and not get a smooth transition
Thu 21 Mar 2013 04:10:37 PM EDT Mar 21 16:10:37 <krh> halfline: no, vt switch doesn't flickr if you do it right
Thu 21 Mar 2013 04:10:50 PM EDT Mar 21 16:10:50 <krh> in KD_GRAPHCIS mode, nothing happens on the display when you switch vt
Thu 21 Mar 2013 04:10:58 PM EDT Mar 21 16:10:58 <-- c-a_ has quit (Ex-Chat)
Thu 21 Mar 2013 04:11:13 PM EDT Mar 21 16:11:13 <krh> the process running the the vt you switch to is responsible for updating the output
Thu 21 Mar 2013 04:11:36 PM EDT Mar 21 16:11:36 <krh> kms wont change at all when you switch vt
Thu 21 Mar 2013 04:11:58 PM EDT Mar 21 16:11:58 <halfline> okay if we can avoid the flicker, that's fine
Thu 21 Mar 2013 04:12:05 PM EDT Mar 21 16:12:05 <krh> the flicker you see when you swtich in and out of an X server is X exposing all windows on vt enter
Thu 21 Mar 2013 04:12:10 PM EDT Mar 21 16:12:10 <krh> to make sure it all gets repainted
Thu 21 Mar 2013 04:12:42 PM EDT Mar 21 16:12:42 <halfline> we will need to make sure that the old vt and the new vt are showing the same frame during the transition
Thu 21 Mar 2013 04:13:12 PM EDT Mar 21 16:13:12 <halfline> fwiw, GDM used to have a mode called "factory" mode
Thu 21 Mar 2013 04:13:16 PM EDT Mar 21 16:13:16 <krh> the new vt will show the same fb until it pageflips away
Thu 21 Mar 2013 04:13:19 PM EDT Mar 21 16:13:19 <halfline> where it would keep the login screen always running on one VT
Thu 21 Mar 2013 04:13:26 PM EDT Mar 21 16:13:26 <halfline> and would farm out all user sessions to separate VTs
Thu 21 Mar 2013 04:13:29 PM EDT Mar 21 16:13:29 <-- tacg has quit (Ping timeout: 600 seconds)
Thu 21 Mar 2013 04:13:48 PM EDT Mar 21 16:13:48 <krh> yeah, we'll be a lot closer to that mode of operation
Thu 21 Mar 2013 04:14:39 PM EDT Mar 21 16:14:39 <mccann> hmm anyone know what this is? http://paste.fedoraproject.org/5757/36389657/
Thu 21 Mar 2013 04:14:40 PM EDT Mar 21 16:14:40 --- stefw is now known as stefw_afk
Thu 21 Mar 2013 04:14:42 PM EDT Mar 21 16:14:42 <krh> anyway, it seems like there's an idea here
Thu 21 Mar 2013 04:15:09 PM EDT Mar 21 16:15:09 <krh> we pull the bits of weston-launch in to the gdm worker
Thu 21 Mar 2013 04:15:19 PM EDT Mar 21 16:15:19 <halfline> well maybe some of the bits should be in logind
Thu 21 Mar 2013 04:15:30 PM EDT Mar 21 16:15:30 <krh> I don't know how the worker will know whether to launch a wayland session or an X sessiosn
Thu 21 Mar 2013 04:15:32 PM EDT Mar 21 16:15:32 <halfline> i think logind is what handles facls on /dev/dri/card0 atm
Thu 21 Mar 2013 04:16:28 PM EDT Mar 21 16:16:28 <krh> we can even use weston for prototyping the gdm-worker part
Thu 21 Mar 2013 04:16:52 PM EDT Mar 21 16:16:52 <halfline> krh: well, the bulk of the work for launching the wayland session happens from just starting the compositor right?
Thu 21 Mar 2013 04:17:08 PM EDT Mar 21 16:17:08 <krh> halfline: yea
Thu 21 Mar 2013 04:17:09 PM EDT Mar 21 16:17:09 <halfline> i mean at the end of the day (modulo a few small details) the worker is just going to be launching a process
Thu 21 Mar 2013 04:17:23 PM EDT Mar 21 16:17:23 <krh> starting weston is the weston "session"
Thu 21 Mar 2013 04:17:37 PM EDT Mar 21 16:17:37 <krh> weston forks all the helpers for the panel and such
Thu 21 Mar 2013 04:18:12 PM EDT Mar 21 16:18:12 <halfline> right, so whether that process is something runs on the login screen's X server or that process starts doing wayland stuff on another vt, that's not something the worker has to be too concerned with
Thu 21 Mar 2013 04:18:36 PM EDT Mar 21 16:18:36 <krh> halfline: oh it is
Thu 21 Mar 2013 04:18:49 PM EDT Mar 21 16:18:49 <krh> weston-launch is also a setuid helper for weston
Thu 21 Mar 2013 04:19:03 PM EDT Mar 21 16:19:03 <krh> it stays around and opens input devices when they're hotplugged
Thu 21 Mar 2013 04:19:19 PM EDT Mar 21 16:19:19 <krh> and it doesn drmSet/DropMaster (which requires root) when switching vt
Thu 21 Mar 2013 04:19:45 PM EDT Mar 21 16:19:45 <rib> I'm not quite sure we want to pull bits of weston launch into the gdm worker do we; even though we want to put vt handling into the wayland launcher its effectively equivalent to starting a new xserver that would handle its own vt switching so gdm doesn't need to deal with it
Thu 21 Mar 2013 04:19:52 PM EDT Mar 21 16:19:52 <halfline> so some of that seems like it should be in logind
Thu 21 Mar 2013 04:20:19 PM EDT Mar 21 16:20:19 <halfline> well you definitely want the PAM bits in one place
Thu 21 Mar 2013 04:20:20 PM EDT Mar 21 16:20:20 <halfline> in gdm
Thu 21 Mar 2013 04:20:46 PM EDT Mar 21 16:20:46 <rib> yeah we can scrap the pam bits in the wayland launcher I think
Thu 21 Mar 2013 04:21:25 PM EDT Mar 21 16:21:25 <krh> I'd like to keep them there, but have a mode where it's bypassed
Thu 21 Mar 2013 04:21:28 PM EDT Mar 21 16:21:28 <krh> for use with gdm
Thu 21 Mar 2013 04:21:44 PM EDT Mar 21 16:21:44 <drago01> does that mean we can launch it in a window inside X like weston?
Thu 21 Mar 2013 04:22:01 PM EDT Mar 21 16:22:01 <krh> so in that case weston-launch will just do vt switching, input hotplug and the drm master stuff
Thu 21 Mar 2013 04:22:28 PM EDT Mar 21 16:22:28 <krh> drago01: that should be possible
Thu 21 Mar 2013 04:22:44 PM EDT Mar 21 16:22:44 <drago01> krh: nice, makes for a good Xephr replacement
Thu 21 Mar 2013 04:22:48 PM EDT Mar 21 16:22:48 <rib> yup, the main thing I still wonder about is how to enable users to choose to run a wayland session vs a xsession
Thu 21 Mar 2013 04:22:51 PM EDT Mar 21 16:22:51 --> jrb (~jrb@static-71-174-236-21.bstnma.fios.verizon.net) has joined #gnome-os
Thu 21 Mar 2013 04:22:59 PM EDT Mar 21 16:22:59 --> c-a (~c-a@195.176.94.251) has joined #gnome-os
Thu 21 Mar 2013 04:23:00 PM EDT Mar 21 16:23:00 <-- KaL has quit (Bye)
Thu 21 Mar 2013 04:23:33 PM EDT Mar 21 16:23:33 <halfline> rib: right not gdm has a session list in it's UI that's populated by files in /usr/share/xsessions
Thu 21 Mar 2013 04:23:43 PM EDT Mar 21 16:23:43 <halfline> they're little key files that say what to run
Thu 21 Mar 2013 04:23:48 PM EDT Mar 21 16:23:48 <krh> drago01: most of the work there should be take care of by clutters different backends, but there may be some fudging require to get input working right
Thu 21 Mar 2013 04:23:57 PM EDT Mar 21 16:23:57 <halfline> Presumably there would be a weston.desktop for weston
Thu 21 Mar 2013 04:24:06 PM EDT Mar 21 16:24:06 <-- API_afk has quit (Remote closed the connection)
Thu 21 Mar 2013 04:25:05 PM EDT Mar 21 16:25:05 <krh> ok, that sounds good
Thu 21 Mar 2013 04:25:06 PM EDT Mar 21 16:25:06 <rib> halfline: so gdm doesn't assume that it needs to run an xserver + some user session thing, the session even controls running the xserver too?
Thu 21 Mar 2013 04:25:36 PM EDT Mar 21 16:25:36 <halfline> rib: no, like i said earlier the way it works today is the session uses the already running xserver
Thu 21 Mar 2013 04:25:49 PM EDT Mar 21 16:25:49 <halfline> the one the login screen was using
Thu 21 Mar 2013 04:26:08 PM EDT Mar 21 16:26:08 <halfline> so in the X case, the server is already there and we just run the program
Thu 21 Mar 2013 04:26:19 PM EDT Mar 21 16:26:19 <halfline> in the wayland case, the program will make sure the display server is started
Thu 21 Mar 2013 04:26:42 PM EDT Mar 21 16:26:42 --> mccann_ (~mccann@c-76-118-180-63.hsd1.ma.comcast.net) has joined #gnome-os
Thu 21 Mar 2013 04:26:43 PM EDT Mar 21 16:26:43 --- Services gives channel operator status to mccann_
Thu 21 Mar 2013 04:26:49 PM EDT Mar 21 16:26:49 <halfline> but either way, the worker isn't starting the display server
Thu 21 Mar 2013 04:27:14 PM EDT Mar 21 16:27:14 <halfline> it's either already running, or will get created on-demand by the session getting executed
Thu 21 Mar 2013 04:27:32 PM EDT Mar 21 16:27:32 <-- fmuellner has quit (Geronimo!)
Thu 21 Mar 2013 04:27:37 PM EDT Mar 21 16:27:37 <halfline> now there's some question on what to do on the X server that's left behind in the weston case
Thu 21 Mar 2013 04:27:49 PM EDT Mar 21 16:27:49 <krh> right
Thu 21 Mar 2013 04:28:01 PM EDT Mar 21 16:28:01 <krh> we're leaking an xserver
Thu 21 Mar 2013 04:28:08 PM EDT Mar 21 16:28:08 <rib> yup :-)
Thu 21 Mar 2013 04:28:13 PM EDT Mar 21 16:28:13 <halfline> we just need to tell the shell to reset
Thu 21 Mar 2013 04:28:18 PM EDT Mar 21 16:28:18 <halfline> and show the user list again
Thu 21 Mar 2013 04:28:33 PM EDT Mar 21 16:28:33 <halfline> we already have code do this for fast user switching purposes
Thu 21 Mar 2013 04:28:55 PM EDT Mar 21 16:28:55 <halfline> if the user chvt's back to the vt, the login screen will be sitting there ready to go
Thu 21 Mar 2013 04:29:55 PM EDT Mar 21 16:29:55 <halfline> for fast user switching the slave handles this
Thu 21 Mar 2013 04:30:35 PM EDT Mar 21 16:30:35 <halfline> it checks if there's a session already running on a different vt for that user
Thu 21 Mar 2013 04:30:44 PM EDT Mar 21 16:30:44 <halfline> if so it jumps to that vt and resets the login screen vt
Thu 21 Mar 2013 04:31:07 PM EDT Mar 21 16:31:07 <halfline> so we'd need to augment that check for "already running on another vt" to "about to be running on another vt" I guess
Thu 21 Mar 2013 04:31:10 PM EDT Mar 21 16:31:10 <krh> what would trigger the reset in this case?
Thu 21 Mar 2013 04:31:13 PM EDT Mar 21 16:31:13 <rib> it might also be nice to support the non-factory like model too though, where we don't keep the login screen running once we've logged in
Thu 21 Mar 2013 04:31:25 PM EDT Mar 21 16:31:25 <halfline> krh: it asks logind if there's already a session registered
Thu 21 Mar 2013 04:31:52 PM EDT Mar 21 16:31:52 <halfline> krh: so i guess that's the trick to make this just work. ensure that pam_systemd registers the weston session during pam_open_session
Thu 21 Mar 2013 04:31:57 PM EDT Mar 21 16:31:57 <krh> halfline: yeah, but for the case where it's a new login?
Thu 21 Mar 2013 04:32:18 PM EDT Mar 21 16:32:18 <halfline> krh: if it's new login, today we don't reset
Thu 21 Mar 2013 04:32:24 PM EDT Mar 21 16:32:24 <halfline> we kill the the login screen
Thu 21 Mar 2013 04:32:29 PM EDT Mar 21 16:32:29 <krh> exactly
Thu 21 Mar 2013 04:32:33 PM EDT Mar 21 16:32:33 <halfline> and steal its X server
Thu 21 Mar 2013 04:32:45 PM EDT Mar 21 16:32:45 <krh> oh, so the kill should be a test instead
Thu 21 Mar 2013 04:33:12 PM EDT Mar 21 16:33:12 <-- elima has quit (Read error: 148 (No route to host))
Thu 21 Mar 2013 04:33:33 PM EDT Mar 21 16:33:33 <halfline> a test for what?
Thu 21 Mar 2013 04:33:53 PM EDT Mar 21 16:33:53 <krh> instead of killing the login screen there we see if the session is running on a different vt - if it is, reset, else kill
Thu 21 Mar 2013 04:34:43 PM EDT Mar 21 16:34:43 <halfline> yea that logic already exists
Thu 21 Mar 2013 04:34:46 PM EDT Mar 21 16:34:46 <halfline> for fast user switching
Thu 21 Mar 2013 04:34:50 PM EDT Mar 21 16:34:50 <krh> ok
Thu 21 Mar 2013 04:35:01 PM EDT Mar 21 16:35:01 <halfline> so we just have to make sure the session is registered properly by pam_systemd
Thu 21 Mar 2013 04:35:03 PM EDT Mar 21 16:35:03 <krh> right ok
Thu 21 Mar 2013 04:35:05 PM EDT Mar 21 16:35:05 <krh> yes
Thu 21 Mar 2013 04:35:08 PM EDT Mar 21 16:35:08 <krh> I get it now
Thu 21 Mar 2013 04:35:22 PM EDT Mar 21 16:35:22 <halfline> but if we want to support what rib is asking for
Thu 21 Mar 2013 04:35:25 PM EDT Mar 21 16:35:25 <halfline> that's a little harder
Thu 21 Mar 2013 04:35:38 PM EDT Mar 21 16:35:38 <halfline> if we want to kill instead of reset i mean
Thu 21 Mar 2013 04:35:51 PM EDT Mar 21 16:35:51 <-- mccann has quit (Ping timeout: 600 seconds)
Thu 21 Mar 2013 04:35:51 PM EDT Mar 21 16:35:51 <krh> yea
Thu 21 Mar 2013 04:36:09 PM EDT Mar 21 16:36:09 <halfline> because then we have to know to start things back up again when weston exits
Thu 21 Mar 2013 04:36:14 PM EDT Mar 21 16:36:14 <-- calvaris has quit (Ex-Chat)
Thu 21 Mar 2013 04:36:21 PM EDT Mar 21 16:36:21 <halfline> and of course that will be flickery
Thu 21 Mar 2013 04:36:39 PM EDT Mar 21 16:36:39 <halfline> but logout today is flickery anyway, so no regression
Thu 21 Mar 2013 04:36:53 PM EDT Mar 21 16:36:53 <halfline> but reusing the fast user switching login will get rid of a lot of the flicker
Thu 21 Mar 2013 04:37:06 PM EDT Mar 21 16:37:06 <krh> but the transition from login gnome-shell to session is hard if you want to kill the login screen
Thu 21 Mar 2013 04:37:10 PM EDT Mar 21 16:37:10 <halfline> just a quick full screen expose of the login screen, so a small flikcer
Thu 21 Mar 2013 04:37:22 PM EDT Mar 21 16:37:22 <halfline> yea it really is
Thu 21 Mar 2013 04:37:28 PM EDT Mar 21 16:37:28 <halfline> since X wants to be in the forground when it dies
Thu 21 Mar 2013 04:37:36 PM EDT Mar 21 16:37:36 <halfline> and it will switch vts to the vt it was started from
Thu 21 Mar 2013 04:37:38 PM EDT Mar 21 16:37:38 <krh> though, I guess you could just start up the session and once its vt is active, just kill the greeter
Thu 21 Mar 2013 04:38:05 PM EDT Mar 21 16:38:05 <halfline> so i'd say for a first cut
Thu 21 Mar 2013 04:38:06 PM EDT Mar 21 16:38:06 <krh> well, greeter on wayland will fix that then :)
Thu 21 Mar 2013 04:38:15 PM EDT Mar 21 16:38:15 <halfline> we should avoid killing the login screen
Thu 21 Mar 2013 04:38:21 PM EDT Mar 21 16:38:21 <krh> yes
Thu 21 Mar 2013 04:38:21 PM EDT Mar 21 16:38:21 <halfline> we'll keep it waiting patiently in the background
Thu 21 Mar 2013 04:38:26 PM EDT Mar 21 16:38:26 <halfline> and reuse all the logic we already have
Thu 21 Mar 2013 04:38:45 PM EDT Mar 21 16:38:45 <halfline> now the pam_systemd<=>logind communication is going to need to be augmented
Thu 21 Mar 2013 04:38:47 PM EDT Mar 21 16:38:47 <krh> right
Thu 21 Mar 2013 04:38:52 PM EDT Mar 21 16:38:52 <halfline> it currently only supports x11 and tty sessions
Thu 21 Mar 2013 04:39:06 PM EDT Mar 21 16:39:06 <halfline> it will need new method calls for handling wayland sessions
Thu 21 Mar 2013 04:39:36 PM EDT Mar 21 16:39:36 <krh> yea, lennart didn't have a problem with that last I talked to him
Thu 21 Mar 2013 04:39:46 PM EDT Mar 21 16:39:46 <halfline> so if you do e.g. loginctl show-session N inside the wayland session
Thu 21 Mar 2013 04:39:58 PM EDT Mar 21 16:39:58 <halfline> it will have Type=wayland or Type=weston
Thu 21 Mar 2013 04:40:07 PM EDT Mar 21 16:40:07 <halfline> or something
Thu 21 Mar 2013 04:40:25 PM EDT Mar 21 16:40:25 <krh> wayland I'd say
Thu 21 Mar 2013 04:40:26 PM EDT Mar 21 16:40:26 <krh> but yea
Thu 21 Mar 2013 04:40:29 PM EDT Mar 21 16:40:29 <halfline> sure
Thu 21 Mar 2013 04:40:49 PM EDT Mar 21 16:40:49 <halfline> then logind can be modified to do some of the weston-launch acl management
Thu 21 Mar 2013 04:41:04 PM EDT Mar 21 16:41:04 <halfline> when a session gets registered that's type wayland, it can do special stuff
Thu 21 Mar 2013 04:41:28 PM EDT Mar 21 16:41:28 <halfline> or for now, we could just leave those bits in weston-launch
Thu 21 Mar 2013 04:41:44 PM EDT Mar 21 16:41:44 --> tacg (~tiago@bl16-106-68.dsl.telepac.pt) has joined #gnome-os
Thu 21 Mar 2013 04:42:11 PM EDT Mar 21 16:42:11 <halfline> but logind already applies acls so it seems like a more suitable "home"
Thu 21 Mar 2013 04:42:22 PM EDT Mar 21 16:42:22 <halfline> not sure about dropMaster on vt out
Thu 21 Mar 2013 04:43:44 PM EDT Mar 21 16:43:44 rib rishi Robot101 robtaylor rtcm russo79
Thu 21 Mar 2013 04:43:49 PM EDT Mar 21 16:43:49 <halfline> rib: you still there?
Thu 21 Mar 2013 04:43:51 PM EDT Mar 21 16:43:51 <krh> halfline: it's not just about changing evdev device permissions
Thu 21 Mar 2013 04:44:04 PM EDT Mar 21 16:44:04 <krh> weston-launch opens them and passes the fd to weston
Thu 21 Mar 2013 04:44:05 PM EDT Mar 21 16:44:05 <halfline> it's passing the device fd's along ?
Thu 21 Mar 2013 04:44:08 PM EDT Mar 21 16:44:08 <halfline> okay
Thu 21 Mar 2013 04:44:57 PM EDT Mar 21 16:44:57 <rib> halfline: yeah, still here, I was just reading a bit of the scroll back to get what you were saying a bit clearer in my head
Thu 21 Mar 2013 04:45:27 PM EDT Mar 21 16:45:27 <rib> (sorry I've only just started scratching the surface of this stuff, so not entirely familiar with all the details yet)
Thu 21 Mar 2013 04:45:56 PM EDT Mar 21 16:45:56 <halfline> no worries, it's all pretty complicated and we probably won't get the details right exactly the first time around anyway
Thu 21 Mar 2013 04:46:12 PM EDT Mar 21 16:46:12 <krh> halfline: and the set/drop drm master isn't something you do once for all
Thu 21 Mar 2013 04:46:24 PM EDT Mar 21 16:46:24 <krh> it has to happen whenever you switch in and out of the vt
Thu 21 Mar 2013 04:46:38 PM EDT Mar 21 16:46:38 <halfline> right, i said "not sure about dropMaster on vt out" above
Thu 21 Mar 2013 04:46:45 PM EDT Mar 21 16:46:45 <krh> oh ok
Thu 21 Mar 2013 04:47:00 PM EDT Mar 21 16:47:00 <halfline> so it does feel like weston-launch is going to have a place going forward
Thu 21 Mar 2013 04:47:32 PM EDT Mar 21 16:47:32 <krh> yeah
Thu 21 Mar 2013 04:47:41 PM EDT Mar 21 16:47:41 <halfline> though longer term, we should get into a place where all this stuff is activated i think
Thu 21 Mar 2013 04:47:58 PM EDT Mar 21 16:47:58 <krh> well until we can build a better redirection mechanism for input and kms in the kernel, anyway
Thu 21 Mar 2013 04:48:19 PM EDT Mar 21 16:48:19 <krh> activated is a buzzword :-P
Thu 21 Mar 2013 04:48:45 PM EDT Mar 21 16:48:45 <halfline> well i don't care for the buzz. i'm just saying if you run something needs X, a rootless X server should get started
Thu 21 Mar 2013 04:49:10 PM EDT Mar 21 16:49:10 <halfline> if you run something that needs a particular wayland server then that wayland server should get started
Thu 21 Mar 2013 04:49:28 PM EDT Mar 21 16:49:28 <halfline> ultimately i think we should do it inside out from how we do it now
Thu 21 Mar 2013 04:49:53 PM EDT Mar 21 16:49:53 <halfline> but one step at a time, i guess
Thu 21 Mar 2013 04:50:26 PM EDT Mar 21 16:50:26 <halfline> the way we've mapped forward here, should require very little changes to GDM, so it's a good step toward wayland domination
Thu 21 Mar 2013 04:52:58 PM EDT Mar 21 16:52:58 <krh> halfline: the problem with activation for wayland is that the thing that's going to need the display server *is* the display server
Thu 21 Mar 2013 04:53:13 PM EDT Mar 21 16:53:13 <krh> you want to run gnome-shell, that's your end-point
Thu 21 Mar 2013 04:53:25 PM EDT Mar 21 16:53:25 --- ebassi|afk is now known as ebassi
Thu 21 Mar 2013 04:53:32 PM EDT Mar 21 16:53:32 <krh> and under X, the X server is a dependency of gnome-shell and should perhaps be socket activated
Thu 21 Mar 2013 04:54:05 PM EDT Mar 21 16:54:05 <krh> but when gnome-shell *is* the display server, it no longer makes sense to socket activate the wayland server
Thu 21 Mar 2013 04:55:28 PM EDT Mar 21 16:55:28 <halfline> if i run "gedit" in a tty it should start up gnome-shell and run gedit on it
Thu 21 Mar 2013 04:55:40 PM EDT Mar 21 16:55:40 <halfline> or if gnome-shell is already running, jump to gnome-shell and run gedit on it
Thu 21 Mar 2013 04:55:48 PM EDT Mar 21 16:55:48 <halfline> less contrived:
Thu 21 Mar 2013 04:55:57 PM EDT Mar 21 16:55:57 <halfline> if i'm gdm and i run gnome-session
Thu 21 Mar 2013 04:56:05 PM EDT Mar 21 16:56:05 <-- tacg has quit (Read error: 104 (Connection reset by peer))
Thu 21 Mar 2013 04:56:17 PM EDT Mar 21 16:56:17 <halfline> and gnome-session talks wayland, gnome-shell should start
Thu 21 Mar 2013 04:56:27 PM EDT Mar 21 16:56:27 <nacho> hadess, why do you need gnome-shell for gedit?
Thu 21 Mar 2013 04:56:30 PM EDT Mar 21 16:56:30 <rib> I think I need to go and get my head around the pam_systemd bits some more. I'm not quite sure a.t.m how gdm is going to know from the things listed in /usr/share/xsessions what things can just take over the slave xserver vs ones that are going to take over a new vt
Thu 21 Mar 2013 04:56:35 PM EDT Mar 21 16:56:35 <krh> why is gnome-session different from gnome-shell?
Thu 21 Mar 2013 04:56:49 PM EDT Mar 21 16:56:49 <-- c-a has quit (Ping timeout: 600 seconds)
Thu 21 Mar 2013 04:57:09 PM EDT Mar 21 16:57:09 <halfline> rib: oh gdm won't know form /usr/share/xsessions, gdm will know from asking logind
Thu 21 Mar 2013 04:57:28 PM EDT Mar 21 16:57:28 --> tacg (~tiago@bl16-106-68.dsl.telepac.pt) has joined #gnome-os
Thu 21 Mar 2013 04:57:36 PM EDT Mar 21 16:57:36 <halfline> rib: inside gdm right now there's a function called gdm_slave_switch_to_user_session
Thu 21 Mar 2013 04:57:54 PM EDT Mar 21 16:57:54 <halfline> rib: it just asks logind if there are any sessions running for the current user
Thu 21 Mar 2013 04:57:59 PM EDT Mar 21 16:57:59 <halfline> and if so, it jumps to it
Thu 21 Mar 2013 04:58:35 PM EDT Mar 21 16:58:35 <halfline> if not, it returns false, and the caller starts one
Thu 21 Mar 2013 04:59:55 PM EDT Mar 21 16:59:55 <halfline> krh: are you saying you think gnome-shell should take over the role of starting settings-daemon and the various bits of the session ?
Thu 21 Mar 2013 05:00:23 PM EDT Mar 21 17:00:23 <krh> halfline: maybe
Thu 21 Mar 2013 05:00:48 PM EDT Mar 21 17:00:48 <halfline> well smcv and lennart and others actually want to get gnome-session out of the process starting business too
Thu 21 Mar 2013 05:00:56 PM EDT Mar 21 17:00:56 <halfline> but they want to get systemd in --session mode to take over the job
Thu 21 Mar 2013 05:01:11 PM EDT Mar 21 17:01:11 <krh> what I definitely think is that the shell isn't some on-demand started service, it's the main thing you're trying to bring up
Thu 21 Mar 2013 05:01:11 PM EDT Mar 21 17:01:11 <halfline> rib: do you know what pam_systemd does?
Thu 21 Mar 2013 05:01:12 PM EDT Mar 21 17:01:12 rib rishi Robot101 robtaylor rtcm russo79
Thu 21 Mar 2013 05:01:23 PM EDT Mar 21 17:01:23 <halfline> rib: if you don't i'll explain it to you and that might make things clearer
Thu 21 Mar 2013 05:01:37 PM EDT Mar 21 17:01:37 <owen> krh: for the sanity of developers, I think we're going to try hard to keep restartiblity
Thu 21 Mar 2013 05:01:37 PM EDT Mar 21 17:01:37 <halfline> krh: well that's true
Thu 21 Mar 2013 05:02:18 PM EDT Mar 21 17:02:18 <krh> owen: but isn't that the self-re-exec idea we talked about?
Thu 21 Mar 2013 05:02:19 PM EDT Mar 21 17:02:19 <rib> halfline, I get the impression a.t.m that the worker is creating the session when a user gives their credentials via the slave, and at that point there is no reference what kind of session the user wants (wayland vs x)
Thu 21 Mar 2013 05:02:43 PM EDT Mar 21 17:02:43 <owen> krh: probably. But it probably isn't that compatible with gnome-shell being the master babysitter of the session
Thu 21 Mar 2013 05:03:09 PM EDT Mar 21 17:03:09 <halfline> well systemd is the master babysitter of system services and it can reexec itself
Thu 21 Mar 2013 05:03:28 PM EDT Mar 21 17:03:28 --> c-a (~c-a@195.176.94.251) has joined #gnome-os
Thu 21 Mar 2013 05:04:12 PM EDT Mar 21 17:04:12 <krh> owen: yeah, that's probably true...
Thu 21 Mar 2013 05:04:15 PM EDT Mar 21 17:04:15 <halfline> rib: so that's where the xsession file comes in. we could put in the file metadata about the natureo f the session
Thu 21 Mar 2013 05:04:26 PM EDT Mar 21 17:04:26 <halfline> and pass that data along to PAM
Thu 21 Mar 2013 05:04:41 PM EDT Mar 21 17:04:41 <halfline> right now PAM is notified about X sessions via two pam items
Thu 21 Mar 2013 05:04:42 PM EDT Mar 21 17:04:42 <rib> okey, that's joining some dots for me, yup
Thu 21 Mar 2013 05:04:54 PM EDT Mar 21 17:04:54 <halfline> PAM_XAUTH_DATA an PAM_XDISPLAY
Thu 21 Mar 2013 05:05:15 PM EDT Mar 21 17:05:15 <halfline> pam_systemd looks at these items when talking to logind
Thu 21 Mar 2013 05:05:27 PM EDT Mar 21 17:05:27 <halfline> to figure out what arguments to pass to session registration
Thu 21 Mar 2013 05:05:57 PM EDT Mar 21 17:05:57 <halfline> we could add PAM_WAYLAND_SOCKET or whatever
Thu 21 Mar 2013 05:06:10 PM EDT Mar 21 17:06:10 <halfline> or we could even just use environment variables as a first cut
Thu 21 Mar 2013 05:06:11 PM EDT Mar 21 17:06:11 <krh> owen: so there would have to be a way for the session baby sitter (gnome-session or systemd) to poke the compositor to do this self-exec
Thu 21 Mar 2013 05:06:34 PM EDT Mar 21 17:06:34 --- mccann_ is now known as mccann
Thu 21 Mar 2013 05:06:47 PM EDT Mar 21 17:06:47 <halfline> rib: the point is pam_systemd handles session registration with logind, and we just need to make sure we get the right registration calls made based on the session type
Thu 21 Mar 2013 05:07:23 PM EDT Mar 21 17:07:23 <halfline> each desktop file in /usr/share/xsessions maps to one session item in the list of sessions in the gnome shell login screen
Thu 21 Mar 2013 05:09:27 PM EDT Mar 21 17:09:27 <halfline> rib: one thing is, we probably don't want weston-launch to switch vts on its own
Thu 21 Mar 2013 05:09:29 PM EDT Mar 21 17:09:29 <halfline> if possible
Thu 21 Mar 2013 05:09:41 PM EDT Mar 21 17:09:41 <krh> who should do it then?
Thu 21 Mar 2013 05:09:48 PM EDT Mar 21 17:09:48 <halfline> GDM already has code to do it
Thu 21 Mar 2013 05:10:07 PM EDT Mar 21 17:10:07 <halfline> GDM looks at the currently availables sessions for the user that just typed in their password
Thu 21 Mar 2013 05:10:18 PM EDT Mar 21 17:10:18 <halfline> and it switches vt to it
Thu 21 Mar 2013 05:10:42 PM EDT Mar 21 17:10:42 <halfline> code is basically:
Thu 21 Mar 2013 05:10:52 PM EDT Mar 21 17:10:52 <halfline> session_id = get_session_id_for_user (username)
Thu 21 Mar 2013 05:11:06 PM EDT Mar 21 17:11:06 <halfline> session_already_switched = session_is_active (session_id)
Thu 21 Mar 2013 05:11:16 PM EDT Mar 21 17:11:16 <halfline> if (session_already_switched) return;
Thu 21 Mar 2013 05:11:35 PM EDT Mar 21 17:11:35 <halfline> if (!session_already_switched) switch_to_session (session_id)
Thu 21 Mar 2013 05:11:42 PM EDT Mar 21 17:11:42 <halfline> session_unlock (session_id)
Thu 21 Mar 2013 05:12:01 PM EDT Mar 21 17:12:01 <halfline> so as soon as pam_open_session() finishes
Thu 21 Mar 2013 05:12:10 PM EDT Mar 21 17:12:10 <halfline> there will be a session available
Thu 21 Mar 2013 05:12:18 PM EDT Mar 21 17:12:18 <halfline> that session will get returned from get_session_is_for_user
Thu 21 Mar 2013 05:12:35 PM EDT Mar 21 17:12:35 <halfline> and since we haven't already switched it will switch to it
Thu 21 Mar 2013 05:13:03 PM EDT Mar 21 17:13:03 <halfline> my pseudocode above was a little off. the "return;" should have been "return FALSE;"
Thu 21 Mar 2013 05:13:53 PM EDT Mar 21 17:13:53 <halfline> hmm, i guess it's not quite right as is
Thu 21 Mar 2013 05:14:11 PM EDT Mar 21 17:14:11 <halfline> because we're going to need to still run weston-launch after doing the switch
Thu 21 Mar 2013 05:15:05 PM EDT Mar 21 17:15:05 <krh> either way, weston-launch can already be told to run on a given tty
Thu 21 Mar 2013 05:16:05 PM EDT Mar 21 17:16:05 <halfline> okay, that might be important.
Thu 21 Mar 2013 05:16:17 PM EDT Mar 21 17:16:17 <halfline> one of the parameters passed to logind at pam_open_session time is the vt
Thu 21 Mar 2013 05:16:35 PM EDT Mar 21 17:16:35 <halfline> it's part of the information associated with the session
Thu 21 Mar 2013 05:16:49 PM EDT Mar 21 17:16:49 <halfline> and we query that information from logind before doing the vt switch
Thu 21 Mar 2013 05:18:45 PM EDT Mar 21 17:18:45 <halfline> but basically right now we have code like... if (switch_to_user_session_for ("halfline")) reset_greeter (); else tear_down_greeter_and_start_new_session_in_its_place();
Thu 21 Mar 2013 05:18:58 PM EDT Mar 21 17:18:58 <halfline> that code will need to be changed to:
Thu 21 Mar 2013 05:19:30 PM EDT Mar 21 17:19:30 <halfline> if (switch_to_user_session_for ("halfline")) {
Thu 21 Mar 2013 05:20:10 PM EDT Mar 21 17:20:10 <halfline> reset_greeter (); if (session_type == "wayland") start_session();
Thu 21 Mar 2013 05:20:14 PM EDT Mar 21 17:20:14 <halfline> } else {
Thu 21 Mar 2013 05:20:21 PM EDT Mar 21 17:20:21 <halfline> tear_down_greeter_and_start_new_session_in_its_place();
Thu 21 Mar 2013 05:20:23 PM EDT Mar 21 17:20:23 <halfline> }
Thu 21 Mar 2013 05:20:44 PM EDT Mar 21 17:20:44 <halfline> or something along those lines
Thu 21 Mar 2013 05:20:45 PM EDT Mar 21 17:20:45 <-- hashem has quit (Ping timeout: 600 seconds)
Thu 21 Mar 2013 05:20:56 PM EDT Mar 21 17:20:56 <rib> sure
Thu 21 Mar 2013 05:23:16 PM EDT Mar 21 17:23:16 <rib> halfline: well thanks a lot for your patience and explanations, I think I'm fairly happy knowing how to move forward now, though I expect I'll be pestering you for more input later as I get into some specific details :-)
Thu 21 Mar 2013 05:23:48 PM EDT Mar 21 17:23:48 <halfline> sure
Thu 21 Mar 2013 05:24:16 PM EDT Mar 21 17:24:16 <halfline> first thing i'd tackle if i were you is the logind api changes
Thu 21 Mar 2013 05:24:23 PM EDT Mar 21 17:24:23 <halfline> and the pam_systemd adjustments
Thu 21 Mar 2013 05:24:54 PM EDT Mar 21 17:24:54 <rib> yeah, that's also the bit I'm least familiar with, but it sounds like a good starting point
Thu 21 Mar 2013 05:25:30 PM EDT Mar 21 17:25:30 <halfline> read pam_sm_open_session in the pam_systemd source code to see how it registers with logind
Thu 21 Mar 2013 05:26:25 PM EDT Mar 21 17:26:25 <halfline> their's currently a CreateSession dbus api
Thu 21 Mar 2013 05:26:51 PM EDT Mar 21 17:26:51 <halfline> you'll need a new api that does the same thing as CreateSession but has different arguments
Thu 21 Mar 2013 05:27:26 PM EDT Mar 21 17:27:26 <halfline> *there's
Thu 21 Mar 2013 05:27:53 PM EDT Mar 21 17:27:53 <-- jrb has quit (Leaving)
Thu 21 Mar 2013 05:28:09 PM EDT Mar 21 17:28:09 <rib> yeah I recal looking at that api before and had guessed we'd need to augment that somehow
Thu 21 Mar 2013 05:29:53 PM EDT Mar 21 17:29:53 <krh> another point that we were just discussing in #wayland is that weston-launch may need to change to actually read from the input devices and forward the evdev events to the compositor
Thu 21 Mar 2013 05:30:01 PM EDT Mar 21 17:30:01 <krh> instead of passing the evdev fds
Thu 21 Mar 2013 05:30:28 PM EDT Mar 21 17:30:28 <krh> since once a process running as the user has an evdev fd, you can ptrace it and snoop the fd
Thu 21 Mar 2013 05:31:02 PM EDT Mar 21 17:31:02 <halfline> but you could ptrace it and snoop the incoming evdev events too right ?
Thu 21 Mar 2013 05:31:28 PM EDT Mar 21 17:31:28 <krh> you can't ptrace weston-launch, it runs as root
Thu 21 Mar 2013 05:31:44 PM EDT Mar 21 17:31:44 <halfline> rigth we're both talking about ptracing the compositor
Thu 21 Mar 2013 05:31:54 PM EDT Mar 21 17:31:54 <-- nacho has quit (Remote closed the connection)
Thu 21 Mar 2013 05:32:02 PM EDT Mar 21 17:32:02 <rib> krh: yikes, having to have all input events hop from launcher, to compositer to client doesn't sound great :-/
Thu 21 Mar 2013 05:32:13 PM EDT Mar 21 17:32:13 --> hashem (~hashem@c-66-31-36-232.hsd1.ma.comcast.net) has joined #gnome-os
Thu 21 Mar 2013 05:32:15 PM EDT Mar 21 17:32:15 <krh> right, weston-launch needs to stop forwarding events once your session is no longer active
Thu 21 Mar 2013 05:32:25 PM EDT Mar 21 17:32:25 <krh> rib: npoe
Thu 21 Mar 2013 05:32:25 PM EDT Mar 21 17:32:25 <halfline> ohhh
Thu 21 Mar 2013 05:32:26 PM EDT Mar 21 17:32:26 <krh> nope
Thu 21 Mar 2013 05:32:34 PM EDT Mar 21 17:32:34 <halfline> i see, you're talking about a poor man's revoke()
Thu 21 Mar 2013 05:32:38 PM EDT Mar 21 17:32:38 <krh> yeah
Thu 21 Mar 2013 05:32:41 PM EDT Mar 21 17:32:41 <krh> userspace revoke
Thu 21 Mar 2013 05:32:44 PM EDT Mar 21 17:32:44 <halfline> but doesn't evdev already have that feature ?
Thu 21 Mar 2013 05:32:52 PM EDT Mar 21 17:32:52 <halfline> calls it a GRAB i think ?
Thu 21 Mar 2013 05:32:57 PM EDT Mar 21 17:32:57 <krh> no, it has the grab thing
Thu 21 Mar 2013 05:33:12 PM EDT Mar 21 17:33:12 <krh> which we don't use because there's a few other daemons that need to open the evdev devices
Thu 21 Mar 2013 05:33:29 PM EDT Mar 21 17:33:29 <halfline> hmm
Thu 21 Mar 2013 05:33:50 PM EDT Mar 21 17:33:50 <krh> a better solution may be to either 1) have an evdev open mode where you say "only send events when this session is active"
Thu 21 Mar 2013 05:34:06 PM EDT Mar 21 17:34:06 <krh> or 2) figure out how to not have to run those daemons and use grab
Thu 21 Mar 2013 05:34:25 PM EDT Mar 21 17:34:25 <halfline> of course the kernel doesn't know the session really
Thu 21 Mar 2013 05:34:28 PM EDT Mar 21 17:34:28 <-- hashem has quit (Read error: 131 (Connection reset by peer))
Thu 21 Mar 2013 05:34:29 PM EDT Mar 21 17:34:29 <halfline> it knows cgroups
Thu 21 Mar 2013 05:34:47 PM EDT Mar 21 17:34:47 <halfline> and it knows audit session
Thu 21 Mar 2013 05:34:59 PM EDT Mar 21 17:34:59 <krh> yea
Thu 21 Mar 2013 05:35:01 PM EDT Mar 21 17:35:01 <halfline> but i don't think there's any notion of "active" cgroup
Thu 21 Mar 2013 05:35:10 PM EDT Mar 21 17:35:10 <krh> I don't know how you'd realize it
Thu 21 Mar 2013 05:35:32 PM EDT Mar 21 17:35:32 <krh> it could be something that weston-launch controls
Thu 21 Mar 2013 05:36:17 PM EDT Mar 21 17:36:17 <krh> weston-launch could handle more of the vt switching I suppose
Thu 21 Mar 2013 05:36:17 PM EDT Mar 21 17:36:17 <halfline> really the purview of the system compositor
Thu 21 Mar 2013 05:36:21 PM EDT Mar 21 17:36:21 <halfline> which we aren't talking about yet
Thu 21 Mar 2013 05:36:25 PM EDT Mar 21 17:36:25 <krh> of course...
Thu 21 Mar 2013 05:37:12 PM EDT Mar 21 17:37:12 <krh> you could have an evdev "mute" ioctl, and weston-launch could issue that when switching away
Thu 21 Mar 2013 05:38:15 PM EDT Mar 21 17:38:15 <halfline> yea that'd probably be fine
Thu 21 Mar 2013 05:38:39 PM EDT Mar 21 17:38:39 <krh> weston-launch can handle the vt switching signals, notify weston/gnome-shell over the socket, get ack back and then mute evdev devices and ack vt switch
Thu 21 Mar 2013 05:38:50 PM EDT Mar 21 17:38:50 <halfline> or you could fake a hot unplug
Thu 21 Mar 2013 05:39:13 PM EDT Mar 21 17:39:13 <krh> you can even have a timeout mechanism so you never get stuck on the vt, even if the compositor hangs
Thu 21 Mar 2013 05:40:01 PM EDT Mar 21 17:40:01 <krh> faking the hotplug could result it client visible changes
Thu 21 Mar 2013 05:40:06 PM EDT Mar 21 17:40:06 <krh> s/itin
Thu 21 Mar 2013 05:42:39 PM EDT Mar 21 17:42:39 <halfline> true
Thu 21 Mar 2013 05:42:49 PM EDT Mar 21 17:42:49 <halfline> i gotta go now
Thu 21 Mar 2013 05:42:53 PM EDT Mar 21 17:42:53 <halfline> ttyl!
Thu 21 Mar 2013 05:46:26 PM EDT Mar 21 17:46:26 --> weld (~weld@p57A837AE.dip.t-dialin.net) has joined #gnome-os
Thu 21 Mar 2013 05:46:30 PM EDT Mar 21 17:46:30 <krh> halfline: thanks!