summaryrefslogtreecommitdiff
path: root/daemon/gdm-local-display-factory.c
Commit message (Collapse)AuthorAgeFilesLines
* local-display-factory: Don't try to respawn displays on shutdownRay Strode2021-09-291-1/+10
| | | | | | | | | | | At the moment in the shutdown path we may try to respawn displays that just got killed. The respawning happens when things are half torn down leading to crashes. This commit makes sure we turn off the respawn logic in the shutdown path.
* daemon: Consolidate session-type and supported-session-types listRay Strode2021-09-061-77/+116
| | | | | | | | | | | | | | | | | | | | There's currently a bug in computing the session-type to use. The `i > 0` check means wayland will overwrite x11 in the transient session type list. Morever, the separation between "session-type" and "supported-session-types" is a little redundant. Since supported-session-types is a sorted list, the first item should always be the same as "session-type". This commit addresses the bug and the redundant logic, by computing the supported session types early in the function and indexing into it to get the session-type. A future cleanup could probably get rid of session-type entirely. https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/153
* local-display-factory: Add missing continue statementsRay Strode2021-07-271-0/+2
| | | | | | | | | | | commit f4922c046607c45d76e2911aa8f133d0ad4f9223 tried to fix an overrun in the code, but it neglected to add "continue" statements to the loops, so it was stuffing two different values into the same element of an array, which leads to the wrong session type getting preference. This commit fixes that.
* local-display-factory: Fix overrun in session type list generationRay Strode2021-07-221-7/+9
| | | | | | | Some confusion in the session type list generation from GNOME/gdm!146, means we could actually overrun the list. This commit fixes that.
* daemon: Provide more flexibility for configuring display serverRay Strode2021-07-221-38/+182
| | | | | | | | | | | | | | | | | | | There's currently a way to disable wayland, but no way to disable Xorg. We currently prefer wayland if it's not disabled, but have no way to prefer Xorg without disabling wayland entirely. There's currently no way use legacy Xorg support at all if user display server support is enabled at a build time. This commit adds more flexibility to display server selection. It adds two new keys: XorgEnable and and PreferredDisplayServer. XorgEnable=false disables Xorg support entirely on seat 0. PreferredDisplayServer can be set to "wayland", "xorg", "legacy-xorg" or "none" to select which display server is used by default. If it's set to "wayland", it will fall back to "xorg". If it's set to "xorg" it will fall back to "wayland".
* local-display-factory: Fix wait for graphicalBenjamin Berg2021-03-151-1/+2
| | | | | | | | In commit a37e5a950fbd ("local-display-factory: Wait for seats to become graphical") we introduced logic to wait for up to 10s for the seat to become graphical before trying to use it. Unfortunately, the logic was slightly wrong, resulting us to immediately do the fallback rather than waiting.
* local-display-factory: Wait for seats to become graphicalBenjamin Berg2021-02-251-9/+168
| | | | | | | | | | | | | It may happen that seats are not graphical initially because the DRM device is not ready yet. In that case, ignore the seat and wait for the CanGraphical property notification in order to add it at that point. However, there are some rare cases where CanGraphical will never turn TRUE. To catch these, add a timeout and fall back to simply trying to bring seat0 up after 10 seconds. When we do so, go directly for the X11 fallback as wayland is unlikely to be functional. Fixes: #662
* local-display-factory: Move session type checking into create_displayBenjamin Berg2021-02-251-37/+20
| | | | | | | | | | | We used to check the session type when enumerating the seats at startup (and on VT switch). However, this misses cases where seats are added dynamically (such as at boot time). Simply move the check into create_display and pass in the failure count so that it can handle the X11 fallback when wayland failed to come up. Related: #662
* local-display-factory: Rename create_display to show it is idempotentBenjamin Berg2021-02-251-13/+13
| | | | Also drop the return value as it is never used.
* daemon,common,libgdm: Drop use of sd_seat_can_multi_sessionRay Strode2021-02-251-1/+1
| | | | It's deprecated now, and always returns TRUE.
* local-display-factory: again don't require wayland support to kill XRay Strode2020-07-241-4/+4
| | | | | | | | | | | | | | commit ac083ec2d3d663a48c4aa6693978669243880dd0 attempted fix killing X in the background even when wayland support is disabled. Unfortunately, it missed yet more places in the code that does ifdef ENABLE_WAYLAND_SUPPORT endif This commit fixes that. Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/614
* local-display-factory: don't require wayland support to kill XRay Strode2020-07-241-1/+1
| | | | | | | | | | | | | | | | | commit d35805116113acbf1e112962c54785c604b13181 changed GDM to kill X on login just like it does for wayland sessions. Unfortunately, that commit neglected to pull the code out of the ifdef ENABLE_WAYLAND_SUPPORT endif guards, so users who build without wayland support entirely, don't get the feature. This commit fixes that. Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/614
* local-display-factory: kill X on login just like waylandRay Strode2020-07-131-9/+0
| | | | | | | | | | | | | | These days we kill the wayland login screen during login to conserve system resources. We've been reluctant to do the same for X based login screens, because X didn't handle being killed in the background so well. This is no longer a problem, since this commit: https://gitlab.freedesktop.org/xorg/xserver/-/commit/ff91c696ff8f5f56da40e107cb5c321539758a81 So let's go ahead and kill it now.
* local-display-factory: Always force login screen to VT 1Ray Strode2020-05-151-0/+3
| | | | | | | | | | | | These days we always want the login screen on VT 1, even when it's created by user switching. Unfortunately, since commit f843233ad the login screen won't naturally pick VT 1 when user switching. This commit forces it to make the right choice. Closes https://gitlab.gnome.org/GNOME/gdm/-/issues/602
* local-display-factory: reap login session on vt switch to registered sessionRay Strode2019-09-041-5/+71
| | | | | | | | | | | | | Since commit 1c061b84ffc3e874da825982d18d970556ff74bb we reap the login screen after the user logs into a session, instead of after a timeout. Unfortunately, that means we no longer reap the login screen when unlocking a session. This commit adds back the timeout in the case seat0 is switched to a registered login session. Closes https://gitlab.gnome.org/GNOME/gdm/issues/509
* Allow sessions to register with GDMIain Lane2019-05-291-23/+27
| | | | | | | | | | | | | | | | | | | | | | 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
* GdmLocalDisplayFactory: Store VT number, not tty identifierIain Lane2019-05-291-24/+26
| | | | This makes the code a fair bit simpler.
* local-display-factory: don't return value from foreach funcsRay Strode2019-02-211-4/+2
| | | | | | | | The local display factor code is returning FALSE from its display store foreach functions, which is useless since commit 47d01abe. This commit makes it return void instead.
* local-display-factory: use G_DECLARE_FINAL_TYPENiels De Graef2018-12-231-56/+52
|
* local-display-factory: handle reviving displays that are waiting to dieRay Strode2018-09-251-1/+4
| | | | | | | | We may end up re-using a display in waiting-to-finish state before it gets finished in this case reset its state to managed to avoid it getting finished while it is being used. Closes https://gitlab.gnome.org/GNOME/gdm/merge_requests/45
* local-display-factory: Remove same VT so don't switch checkRay Strode2018-09-251-26/+13
| | | | | | | | | We avoid changing to the login screen vt if we're already on it, but the call is racy since we react to vt changes concurrently with logind (who we query for the active vt). This check drops the active vt check since it's pointless and getting in the way.
* local-display-factory: Remove initial VT is in use checkHans de Goede2018-09-251-13/+0
| | | | | | | | | | | | | | | | | | | | | | The initial VT is in use check in on_vt_changed() is racy, when switching to VT1 from an active session, on_vt_changed() may run before logind has processed the VT change and then sd_seat_get_active() will return the active session which we are switching away from. This results in the greeter not being started on VT1. On my system gdm reliably wins the race resulting in not getting a greeter when manually switching from an active session to VT1. gdm already starts the greeter unconditionally from gdm_local_display_factory_sync_seats() on both startup and when an user session exits. gdm also starts it unconditionally when selecting "Switch user" from an user session. Now autologin sessions avoid the initial VT as well. So we now can assume that the initial VT is free for the login screen's use. And create_display already checks for and re-uses an existing greeter, so we can safely remove the racy check.
* local-display-factory: don't autoreap initial-setupRay Strode2018-09-251-0/+8
| | | | | | | | We automatically kill the login screen when switching VTs away from it, but we should never kill the initial-setup screen in that situation. This commit adds a check to prevent that from happening.
* daemon: Move the waiting the session to have taken over the fb to ↵Hans de Goede2018-09-121-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* local-display-factory: fix build with --disable-user-display-serverRay Strode2018-09-011-1/+1
| | | | | | | | | | | | | commit cf8d918f added a call to `lookup_by_session` which was previously only defined when built GDM was built with `--enable-user-disable-server`. That causes the build to fail with `--disable-user-display-server`. This commit fixes the build by moving `lookup_by_session` out of conditionalized code. Closes https://gitlab.gnome.org/GNOME/gdm/issues/416
* local-display-factory: defer killing greeter until new session registersRay Strode2018-08-311-6/+37
| | | | | | | | | | | | At the moment we kill the greeter the second the VT change to the new session happens. That can cause flicker if the new session doesn't take over the display quickly enough. This commit defers killing the greeter until the new display registers. Closes https://gitlab.gnome.org/GNOME/gdm/issues/413
* local-display-factory: ignore spurios SeatNew signal at start upRay Strode2018-08-141-7/+26
| | | | | | | | | | | | | | Sometimes during startup, logind will send a `SeatNew` signal for seat0 after GDM has already called `ListSeats` and processed `seat0`. That `SeatNew` signal leads to GDM calling `create_display` twice in quick succession. This commit changes GDM to avoid such double processing, by ignoring the `create_display` requests for seats that already have a prepared display ("prepared" means "starting up"). Closes: https://gitlab.gnome.org/GNOME/gdm/issues/410
* display-store: Pass the display object rather than the id in the removed signalChris Coulson2018-08-131-10/+3
| | | | | | | | | | | | | By the time GdmDisplayStore emits the "display-removed" signal, the display is no longer in the store and gdm_display_store_lookup will not work in signal handlers. Change the "display-removed" parameter from the display id to the GdmDisplay object, so that signal handers can perform any cleanup they need to do CVE-2018-14424 Closes: https://gitlab.gnome.org/GNOME/gdm/issues/401
* local-display-factory: add some more debug statementsRay Strode2018-08-091-0/+5
| | | | | This commit just sprinkles in a few more `g_debug`'s for log file clarity.
* local-display-factory: don't jump to failed displayRay Strode2018-08-091-4/+15
| | | | | | | | | | | | Since commit 5e737a57 `create_display` will jump to any already running login screen if it can find one. Right now if a display fails we call `create_display` to create a new one. It will look for any already running login screen and find the recently failed display. This commit make sure we never jump to a display that isn't in good working order.
* local-display-factory: don't start two greeters at startupRay Strode2018-08-081-0/+6
| | | | | | | | | | | | | | | | commit c0188a7030 added some complex code for starting the login screen when the user switches to the initial VT if nothing is running on that VT. The problem is, we get a VT change event on that VT as part of the start up process. This leads to an additional greeter getting started. This commit adds a check to side step the new code during startup. Closes: https://gitlab.gnome.org/GNOME/gdm/issues/409
* local-display-factory: add more debug messages to new vt handling codeRay Strode2018-08-081-9/+35
| | | | | | | | | | commit c0188a7030 added some complex code for starting and stopping the login screen based on VT changes. That code currently has zero debug statements in it making it trickier than necessary to debug. This commit sprinkles some g_debug's throughout the function.
* daemon: kill and restart greeter on demand under waylandRay Strode2018-08-031-0/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now we leave the greeter alive after the user logs in. This is for two reasons: 1) When the greeter is running Xorg, there's no way to kill it when it's running on an inactive VT (X jumps to the foreground when being killed) 2) The greeter, in a way, provides a securepath for unlock. Users in theory could know that by hitting ctrl-alt-f1 to secure attention, the login screen presented is not spoofed. Since we use wayland by default, 1 isn't that much of a concern, and 2 is a bit of niche feature that most users probably haven't considered. And there's a huge downside to keeping the greeter alive: it uses a very large amount of memory. This commit changes GDM to kill the login screen when switching away from the login screen's VT and restarting it when switching back. Based heavily on work by Hans de Goede <hdegoede@redhat.com> Closes: https://gitlab.gnome.org/GNOME/gdm/issues/222
* local-display-factory: ensure non-seat0 codepath doesn't affect seat0Ray Strode2018-08-031-1/+1
| | | | | | | | | | create_display currently bails in some cases if any display is running on the seat. That's the right thing to do on seats other than seat0, but wrong for seat0 (which an have multiple sessions at the same time). To ensure we never hit the case for seat0, add a call to check if the passed seat is multi-session capable.
* daemon: try harder to get to a login screen at logoutRay Strode2018-08-021-5/+31
| | | | | | | | | | | | | commit 22c332ba and some follow up commits try to ensure the user never stays on a blank VT by jumping to a login screen in the event they'd end up on one. Unfortunately, that part of the code can't start a login screen if there's not one running at all. This commit moves the code to GdmLocalDisplyFactory where the login screens are created, so users won't end up on a blank VT even if no login screen is yet running.
* local-display-factory: Use correct session-type for new transient displaysHans de Goede2018-08-021-0/+2
| | | | | | Use the new gdm_local_display_factory_use_wayland() helper to correctly set the session-type properties for displays created through gdm_local_display_factory_create_transient_display().
* local-display-factory: Add gdm_local_display_factory_use_wayland() helperHans de Goede2018-08-021-8/+15
| | | | | Factor out the code which decides if Xorg or Wayland should be used into a helper function.
* display-factory: avoid removing a display from store while iterating itLubomir Rintel2018-07-171-5/+2
|
* Use standard exit codes.Robert Ancell2017-10-031-2/+2
| | | | | | | | | Use EXIT_ defines for readibility. There were some exit codes > 1, but they don't seem to be checked by any of the parent process code. This does mean that the logs might have changed, but modern logging techniques have probably made this obsolete. https://bugzilla.gnome.org/show_bug.cgi?id=788307
* daemon: check for Xwayland availabilityFrederic Crozat2017-09-181-1/+1
| | | | | | | prevent gnome-shell crash when testing Wayland session if Xwayland isn't installed. https://bugzilla.gnome.org/show_bug.cgi?787837
* local-display-factory: add missing comma to fix user switchingRay Strode2017-04-031-1/+1
| | | | | | | | | | commit 4b47633b36a22195e7976a8e597862eff695ca86 refactored some code and inadvertently dropped an important comma, which broke user switching. This commit reintroduces the comma. https://bugzilla.gnome.org/show_bug.cgi?id=780879
* daemon: add knob to disable starting X server as userRay Strode2017-02-271-1/+12
| | | | | | | | | | | | Some deployments need to be able to turn off running X servers as a user for backward compatibility. This commit adds some #ifdef goop to that end. Note wayland requires running as the user, so this option, merely deprioritizes wayland sessions under X sessions. https://bugzilla.gnome.org/show_bug.cgi?id=779338
* local-display-factory: disconnect signal handlers when factory is disposedRay Strode2016-06-221-11/+15
| | | | | | | | | | | | There's the potential for a crash in the shutdown path after the factory is disposed, since we fail to disconnect signal handlers to the displays / display store at factory dispose time. This commit changes the g_signal_connect to g_signal_connect_object, to avoid any potential for crash. (this is a fix noticed when reading through the source. It's tangentially related to a discussion on irc for a different bug)
* local-display-factory: don't sweat hardcoding seat0 for transient displaysRay Strode2015-11-061-12/+1
| | | | | | seat0 is the only thing that has a chance of supporting multiple sessions at th moment, so drop the FIXME that we won't be making traction on.
* local-display-factory: drop obsolete FIXMERay Strode2015-11-061-2/+0
|
* local-display-factory: track autologin displaysRay Strode2015-09-101-5/+56
| | | | | | | | | | | | At the moment the display-factory only tracks displays it adds itself. autologin displays aren't added by the display-factory, but by the manager. This commit makes sure the display-factory is notified about the autologin display, so when it finishes a login screen can be put in its place. https://bugzilla.gnome.org/show_bug.cgi?id=749418
* local-display-factory: call sync function after display finishesRay Strode2015-09-101-2/+7
| | | | | | | | | | | | | | | | | | Right now if a local display finishes we create a new one of the same type to replace it. But if a user display finishes we don't want to create a new user display, we want to create greeter display. Furthermore if the user session is X11, we still want the login screen that comes up to be wayland by default. This commit changes the code to just call sync_seats after a display finishes, since sync_seats is where the logic for where the login screen display information is stored. sync_seats is idempotent anyway, and will only create displays for seats that need them, so it's safe to call it any time any local display finishes. https://bugzilla.gnome.org/show_bug.cgi?id=749418
* local-display-factory: spacing clean upRay Strode2015-09-101-1/+2
| | | | | | | | | | The function declaration for gdm_local_display_factory_sync_seats put the return type on the same line as the function name. That doesn't follow the GDM codebase's style. This commit moves the return type to its own line. https://bugzilla.gnome.org/show_bug.cgi?id=749418
* require logind supportRay Strode2015-06-121-42/+4
| | | | | | | Now that consolekit support is gone, this commit drops all the conditionalizing of logind support. https://bugzilla.gnome.org/show_bug.cgi?id=743940
* drop consolekit supportRay Strode2015-06-121-10/+1
| | | | | | It was deprecated in 3.16 to be removed in 3.18 https://bugzilla.gnome.org/show_bug.cgi?id=743940
View Lorry Controller Status