summaryrefslogtreecommitdiff
path: root/daemon/gdm-x-session.c
Commit message (Collapse)AuthorAgeFilesLines
* daemon: Support X servers built with -Dlisten_tcp=trueAlan Coopersmith2021-12-221-6/+6
| | | | | | | | | | | | | | | | | Xorg since version 1.17 doesn't listen to tcp sockets by default unless it's explicitly built with -Dlisten_tcp=true. GDM currently assumes X servers 1.17 and later are always built without specifying -Dlisten_tcp=true and doesn't work properly otherwise. This commit enhances GDM to better handle these non-standard builds by always passing '-nolisten tcp' on the command line when tcp should be disabled, and likewise always passing '-listen tcp' on the command line, assuming the X server is new enough to support it, when tcp should be enabled. Related #704
* gdm-{wayland,x}-session: don't overwrite user env with fallback varsGigadoc22021-02-241-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In both gdm-wayland-session and gdm-x-session, environment variables from the systemd user manager are imported, if it is available. Those environment variables are set up for the session-to-be-spawned, however, environment variables that the gdm-{wayland,x}-session process itself has are also inherited to the new session, and they are given preference over what is imported from systemd. That is not accidential, the gdm-{wayland,x}-session process has fresh variables as to what the new user session will be (think $DISPLAY, $XDG_CURRENT_DESKTOP, etc.) and those should not be overwritten by stale data from the systemd user manager, who might have those variables still set from a previous session. As the gdm-{wayland,x}-session process does not inherit the environment in which GDM itself is launched, but gets a fresh environment with only purposefully added variables, this is in general not a problem (i.e. there are no environment variables from the systemd system instance overwriting those in our user session). However, the GDM session worker sets a default fallback PATH for gdm-{wayland,x}-session. This then gets preferred over whatever the systemd user manager has, resulting in the session always getting the fallback PATH. As GDM probably needs to consider scenarios where no variables can get imported from the systemd user manager (maybe it is not used at all), removing the default PATH is not an option. Instead, this commit adds a list of environment variables declared as fallbacks, for which we the imported variables _do_ get preference over our own ones. Currently, this is only PATH. Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/385
* Correct a typo in gdm-x-session.cFelix Yan2020-09-291-1/+1
|
* gdm-x-session: tell x server to not vt switchRay Strode2020-07-131-0/+1
| | | | | | gdm already handles the VT switching on X's behalf, so it's redundant, and X does it at inopportune times, so instruct it to not get involved.
* Revert "Merge branch 'environment-fix' into 'master'"Ray Strode2019-09-041-1/+1
| | | This reverts merge request !71
* gdm-{wayland,x}-session: allow users to overwrite environmentDaniel Otero2019-08-131-1/+1
| | | | | | | | This commit allows the user to full control over the session environment, not only allowing to add new variables but to replace existing ones. The most tipical use case is adding entries to the PATH. https://bugzilla.gnome.org/show_bug.cgi?id=736660
* Allow sessions to register with GDMIain Lane2019-05-291-18/+63
| | | | | | | | | | | | | | | | | | | | | | Recording when sessions start, for Wayland → Xorg fallback or transitioning to the user session, is currently done with timeouts. This isn't ideal, because on some very slow machines the timeout can be hit before the session has had a chance to fail: if gnome-session takes more than 3 seconds to fail then the session will be considered to have exited rather than failed, and so we don't do Xorg fallback. We can do this more reliably if we allow sessions to optionally register themselves with GDM. Then we will know when they've started, so can shut down the greeter or fall back to Xorg as appropriate. The mechanism is that they specify X-GDM-SessionRegisters=true in their file, and then call RegsterSession on the DisplayManager interface on the bus (added in the previous commit) to say that they've started up. If X-GDM-SessionRegisters is missing or false, GDM will call the same method for them after 10 seconds. Closes: #483
* daemon: Move the waiting the session to have taken over the fb to ↵Hans de Goede2018-09-121-17/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gdm-local-display-factory Commit 708618746683 ("gdm-wayland-session,gdm-x-session: register after delay") delayed displays changing their status from PREPARED to MANAGED so that their status would not change until the session has had a change to install its own framebuffer and tell the GPU to scanout this new fb. Commit 74ee77717df7 ("local-display-factory: defer killing greeter until new session registers") uses this to avoid a flicker when transitioning from the greeter to the user-session by deferring the stopping of the greeter-session until the new display moves to the MANAGED state. But this only works when transitioning to a new user-session, when moving to an existing user-session (fast user switching) the display already is in MANAGED state and instead of deferring the stopping of the greeter commit 74ee77717df7 causes us to now never stop the greeter-session. This commit fixes this by starting a timeout when switching away from the initial-vt and letting that timeout stop the greeter-session. This commit removes the finish_waiting_displays_on_seat() call when the display's status changes to MANAGED, so that we still only have one code path stopping the greeter and not two. This means we also no longer need to delay registering the display. So this commit removes the code adding the delay (reverts commit 74ee77717df7). Note this commit uses a delay of 10 seconds, rather then 2 seconds. The transition to a new user-session takes about 8 seconds on my budget Apollo Lake based laptop (with SSD). Note this all really is a workaround, the proper solution for this would be able to tell the kernel to keep the greeter framebuffer around until a new framebuffer is installed. There is a patch to add a new unref_fb ioctl for this: https://www.spinics.net/lists/dri-devel/msg140912.html . We need to get this patch upstream and teach mutter to use it.
* gdm-wayland-session,gdm-x-session: register after delayRay Strode2018-08-311-8/+17
| | | | | | | | | | | | | | | | Right now gdm-x-session registers with GDM as soon as the X server is started, and gdm-wayland-session registers as soon as the session is started. Ideally registration wouldn't happen until the session says things started successfully. This commit inches us toward that ideal but adding a little timeout before proceeding with registration. A future commit will add a new xsession file key to allow us to know whether or not the session manager of the session supports doing registration.
* gdm-{wayland,x}-session: fix segfault if run with no argumentsRay Strode2018-02-121-3/+5
| | | | | | | | Right now we crash on clean up paths if the programs are invoked wrong. This commit fixes that. https://bugzilla.gnome.org/show_bug.cgi?id=770561
* gdm-{wayland,x}-session: omit GNOME_SHELL_SESSION_MODE from environmentXiaoguang Wang2017-09-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | After a user logs out, the systemd --user session may still be running (if, say, the user session was left around in the closing state, because of pulseaudio). If that happens, new user sessions will inherit the environment of previous sessions. Some of these environment variables are already intentionally pruned, DISPLAY, XAUTHORITY, WAYLAND_SOCKET, etc. One environment variable that isn't pruned, but should be, is GNOME_SHELL_SESSION_MODE. If it lingers, users could end up in classic mode even though they picked the non-classic mode from the gear menu. This commit adds GNOME_SHELL_SESSION_MODE to the list of environment variables to prune. (minor changes to original patch and commit message from Ray Strode) https://bugzilla.gnome.org/show_bug.cgi?id=785918
* gdm-{wayland,x}-session: only omit unset session variables from environmentRay Strode2017-09-081-3/+16
| | | | | | | | | | | | | | The display server launcher wrapper scripts try to unset any stale environment variables imported from systemd. There is a possibility, some of these stale variables, however, could be "refreshed" by gdm in the current session. If that's the case, we shouldn't clear them. This reworks the unset calls into a loop, and guards each unset call with a check to make sure it's not in the current environment. https://bugzilla.gnome.org/show_bug.cgi?id=785918
* Revert "gdm-{wayland,x}-session: omit GNOME_SHELL_SESSION_MODE from environment"Ray Strode2017-08-141-2/+0
| | | | | | This reverts commit 9bd3c5f04efc0da7de9fc27237244e22942ef720. It breaks the greeter and initial-setup.
* gdm-{wayland,x}-session: omit GNOME_SHELL_SESSION_MODE from environmentXiaoguang Wang2017-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | After a user logs out, the systemd --user session may still be running (if, say, the user session was left around in the closing state, because of pulseaudio). If that happens, new user sessions will inherit the environment of previous sessions. Some of these environment variables are already intentionally pruned, DISPLAY, XAUTHORITY, WAYLAND_SOCKET, etc. One environment variable that isn't pruned, but should be, is GNOME_SHELL_SESSION_MODE. If it lingers, users could end up in classic mode even though they picked the non-classic mode from the gear menu. This commit adds GNOME_SHELL_SESSION_MODE to the list of environment variables to prune. (minor changes to original patch and commit message from Ray Strode) https://bugzilla.gnome.org/show_bug.cgi?id=785918
* gdm-{wayland,x}-session: fix empty string check on import environmentRay Strode2017-02-211-1/+1
| | | | | | We were doing an empty string check incorrectly. This commit fixes that.
* gdm-{wayland,x}-session: import environment from systemd managerRay Strode2016-08-311-0/+57
| | | | | | | | The user may have configured the user environment via user.conf or other means. This commit makes sure this session gets those environment changes. https://bugzilla.gnome.org/show_bug.cgi?id=736660
* gdm-{x,wayland}-session: drop dependency on DBUS_SESSION_BUS_ADDRESSRay Strode2016-08-291-23/+32
| | | | | | | | | | | | DBUS_SESSION_BUS_ADDRESS is not the preferred way to find the session bus these days. Instead it's expected to be found at $XDG_RUNTIME_DIR/bus This commit changes the session launcher code, to just try to get a connection to the bus explicitly, instead relying on the presence of DBUS_SESSION_BUS_ADDRESS to know whether to start a fallback bus. https://bugzilla.gnome.org/show_bug.cgi?id=770395
* gdm-x-session: use cancellable in UpdateActivationEnvironment callRay Strode2016-08-291-1/+1
| | | | | | | I just noticed when reading the code that we pass a cancellable into the function, but then don't use it. https://bugzilla.gnome.org/show_bug.cgi?id=770396
* daemon: import DISPLAY into user busRay Strode2016-05-041-40/+62
| | | | | | | | | | | | | | | commit 99eeae91c1f11997521ad3bc016a7b2d23ec7942 attempted to support dbus user buses with X sessions, by supposedly importing DISPLAY and XAUTHORITY into the dbus user bus activation environment. It didn't actually work, though, because the spawn_bus function quits early if the dbus daemon is already running. This commit fixes the code so that the activation environment is always updated. https://bugzilla.gnome.org/show_bug.cgi?id=761568
* gdm-{x,wayland}-session: add newlines to g_printerrRay Strode2016-02-231-5/+5
| | | | g_printerr needs newlines or log entries butt up against each other.
* gdm-x-session: fix pointer confusion in UpdateActivationEnv callRay Strode2016-02-091-1/+1
| | | | | | commit 99eeae91c1f11997521ad3bc016a7b2d23ec7942 introduced a call to UpdateActivationEnvironment but mucked up the GVariantBuilder declaration. This commit fixes that.
* gdm-x-session: fix tiny leak in error pathRay Strode2016-02-051-1/+1
| | | | | | | I wasn't cleaning up the dbus connection in out: so it leaked in an error path. Spotted by Michael Catanzaro
* daemon: support dbus user buses with X sessionsRay Strode2016-02-041-3/+39
| | | | | | | | | | | | | | | | | | | If the dbus user bus was started when the user first logged in, before the session was started, then that dbus daemon won't have DISPLAY and XAUTHORITY in its activation environment. This means programs activated from that dbus daemon also won't have DISPLAY and XAUTHORITY in their activation environments. This commit changes GDM to explicitly put the two variables in the activation environment via D-Bus, rather than sending them into the bus environment process when launching the bus (since in the case of the user bus, we don't launch it). https://bugzilla.gnome.org/show_bug.cgi?id=761568
* Use -listen instead of -nolisten for new XorgNathaniel Roach2015-11-101-0/+12
| | | | | | | | | | | | | | | | Newer Xorg versions don't listen to tcp sockets by default, so instead of explicitly passing -nolisten to disable tcp sockets by default, we need to explicitly pass -listen to enable tcp sockets when DisallowTCP=false. Older versions don't support the -listen flag, so we check the version and if it's >= 1.17 then we specify -listen tcp Signed-off-by: Nathaniel Roach <nroach44@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=750026
* gdm-x-session: drop spurious g_getenv callRay Strode2015-07-221-1/+1
| | | | | | | | | | | We call g_getenv("XDG_VTNR") twice in a row, when the result the first time around is stored in the vt variable. This commit just uses the vt variable again, and avoids the second call. https://bugzilla.gnome.org/show_bug.cgi?id=752724
* gdm-x-session: kill subprocesses on sigtermRay Strode2015-07-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | <dsd> Jasper: can you explain the logic bug? just curious <Jasper> dsd, GCancellable is a way of cancelling an ongoing operation. <Jasper> dsd, so we start up a wait_async, which says "call this callback when the subprocess exits". And then when we get a SIGTERM, we fire off the cancellable, saying "no no, don't actually wait for to finish, let's just cancel that now" <Jasper> dsd, the callback is called, but wait_finish returns FALSE, meaning that the wait was cancelled. And then the callback says "oh, cool, we're done here" and clears the x_session object. <Jasper> dsd, I'd have to inspect closer to determine a proper fix should we still cancel the wait but not actually clear the object, so we wait synchronously in cleanup?) <Jasper> Depends on what else uses the cancellable. <dsd> ahh <dsd> got it <Jasper> dsd, the other thing that should fix it would be moving the g_clear_object above the "out" label here: https://git.gnome.org/browse/gdm/tree/daemon/gdm-x-session.c?h=gnome-3-16#n185 <Jasper> And doing that for all of session / bus / x subprocesses. <Jasper> Maybe that's the cleaner fix. Based on a patch by João Paulo Rechi Vita <jprvita@endlessm.com> [endlessm/eos-shell#4921] https://bugzilla.gnome.org/show_bug.cgi?id=752388
* gdm-{x,wayland}-session: don't start dbus-daemon if unneededDavid Herrmann2015-06-031-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Desktop sessions require a message bus to be present for IPC between the various desktop services and applications. GDM handles that by manually, unconditionally spawning an instance of dbus-daemon at login time before starting the user session (from the gdm-x-session and gdm-wayland-session launcher programs). Newer versions of the kernel will support this message bus functionality without needing to start dbus-daemon (via kdbus). The message bus is initialized as part of the login process by a kernel interface exercised from pam_systemd. Since gdm-x-session and gdm-wayland-session spawn a dbus-daemon unconditionally as part of session startup, users using kdbus end up with two message buses per session. The extra bus gets in the way, confusing programs and wasting resources. This commit changes gdm-x-session and gdm-wayland-session to check for DBUS_SESSION_BUS_ADDRESS in the environment, and if set, skip spawning a dbus-daemon based session bus. https://bugzilla.gnome.org/show_bug.cgi?id=750358
* gdm-x-session: set XORG_RUN_AS_USER_OK=1 environment variableRay Strode2015-03-271-0/+1
| | | | | | This lets the X server know that it can safely drop privileges. https://bugzilla.gnome.org/show_bug.cgi?id=746891
* gdm-x-session: pass display location to dbus-daemonMantas Mikulėnas2015-02-221-0/+4
| | | | | | | | The DISPLAY and XAUTHORITY environment variables need to be set in the bus daemon environment so that programs activated via the session bus can access the display. https://bugzilla.gnome.org/show_bug.cgi?id=744946
* gdm-x-session: set session bus address properlyRay Strode2015-02-211-1/+1
| | | | | We weren't setting it in the session environment, but the X server environment.
* gdm-x-session: don't hardcode path to dbus-daemonRay Strode2015-02-201-3/+1
| | | | | | | It's not always in BINDIR, but it is always in the PATH, so just let the shell/execvp figure it out. https://bugzilla.gnome.org/show_bug.cgi?id=744787
* gdm-x-session: fix debug messageRay Strode2015-02-201-1/+1
| | | | | | | It says "could not start X server" when failing to start the dbus-daemon. https://bugzilla.gnome.org/show_bug.cgi?id=744787
* gdm-x-session: initialize local pointers to NULLRay Strode2015-02-201-16/+16
| | | | | | | | | | We follow the "goto out" idiom for error handling, and so it's important that pointers cleaned up at out time, are initialized. This commit does a sweep and nullifies them across the board. https://bugzilla.gnome.org/show_bug.cgi?id=744787
* daemon: add wrapper for launching X sessionRay Strode2015-02-181-0/+768
This commit adds a utility for launching an X server and session together. This utility works a lot like xinit, but makes use of modern X features (like -displayfd) and has GDM specific integration (like reading from gdm configuration, and optionally running through /etc/gdm/Xsession) The eventual idea is to get the main GDM code out of the X server launching business and instead farm the logic off to an unprivileged helper that gets run within the logind session of the user. https://bugzilla.gnome.org/show_bug.cgi?id=744764
View Lorry Controller Status