| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Try to address nvidia race on hybrid graphics setups
Closes #763
See merge request GNOME/gdm!173
|
| |
| |
| |
| |
| |
| |
| |
| | |
GDM now blocks itself at runtime until udev is ready, so there's
no point in delaying GDM startup, too.
This commit reverts udev and systemd logic put in place to stall
GDM start up until udev finished.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If GDM starts faster than graphics initialize, then the
udev rules that write out /run/gdm/custom.conf might get
run too late for GDM to notice.
This commit changes GDM to reread its config after graphicals
initialization completes.
https://gitlab.gnome.org/GNOME/gdm/-/issues/763
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Ideally we would reread /run/gdm/custom.conf after we've decided
graphics setup is complete. This is because the file may not
get written out by udev until after GDM is already started and waiting.
As a first step to get there, this commit adds an API for rereading
the file, and changes the SIGHUP handler to use it (instead of
the complete teardown and reinitialization it was doing before).
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment, GDM waits until systemd says the system supports
graphics (via the CanGraphical logind property).
Unfortunately, this property isn't really what we need, since it flips
to true when *any* graphics are available, not when the main graphics
for the system are ready.
This is a problem on hybrid graphics systems, if one card is slower to
load than another. In particular, the vendor nvidia driver can be slow
to load because it has multiple kernel modules it loads in series.
Indeed on fast systems, that use the vendor nvidia driver, it's not
unusual for boot to get to a point where all of userspace up to and
including GDM is executed before the graphics are ready to go.
This commit tries to mitigate the situation by adding an additional,
check aside from CanGraphical to test if the system is ready.
This check waits for the graphics card associated with boot to be fully
up and running before proceeding to start a login screen.
Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/763
|
| |
|
|\
| |
| |
| |
| | |
data: Fix logic error in single card vendor nvidia cases
See merge request GNOME/gdm!172
|
|/
|
|
|
|
|
|
|
|
| |
At the moment we neglect to clean up the sync file GDM uses
to know when it's okay to start in the case there's only
a single card.
This commit fixes that.
https://gitlab.gnome.org/GNOME/gdm/-/issues/763
|
|\
| |
| |
| |
| | |
data: Don't race with vendor nvidia driver at startup
See merge request GNOME/gdm!170
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vendor nvidia driver has two modules loaded
at startup.
It's not uncommon for the second module to still
be loading when GDM starts.
Our udev rule relies on the second module to set
up GDM's boot configuration.
This commit adds some synchronization to stall
GDM a bit if the vendor driver is still coming
up.
https://gitlab.gnome.org/GNOME/gdm/-/issues/763
|
|
|
|
| |
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|\
| |
| |
| |
| |
| |
| | |
launch-environment: add DATADIR to XDG_DATA_DIRS
Closes #756
See merge request GNOME/gdm!168
|
|/
|
|
| |
so that gnome-session finds gnome-login.session
|
|
|
|
| |
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|\
| |
| |
| |
| | |
gdm.rules: Prefer Wayland with NVIDIA >= 510
See merge request GNOME/gdm!169
|
|/
|
|
|
|
|
| |
NVIDIA driver version 510 and above have support for GBM, use Wayland by
default with NVIDIA proprietary driver version 510 and above.
For versions between 470 and 510, prefer Xorg as before.
|
| |
|
| |
|
|\
| |
| |
| |
| | |
local-display-factory: restart greeter session when crashed
See merge request GNOME/gdm!166
|
|/
|
|
|
|
|
| |
When active vt is gdm initial vt, restart greeter session. Avoiding
the blank screen when greeter session crashed.
https://gitlab.gnome.org/GNOME/gdm/-/issues/735
|
|\
| |
| |
| |
| | |
gdm.rules: Keep wayland enabled for simple-framebuffer DRM drivers
See merge request GNOME/gdm!167
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not all DRM drivers are disabled when the nomodeset kernel cmdline option
is used. For example the simpledrm driver that use the system framebuffer
set-up by the bootloader, provides a modesetting interface.
Exclude the DRM drivers that match against the "simple-framebuffer" device
and only disable wayland for platform DRM drivers.
This allows to start a wayland session when nomodeset is used to disable a
platform DRM driver by using the simpledrm driver instead of legacy fbdev
drivers such as efifb, that does not support modsetting and could only be
used with an Xorg session.
|
|\
| |
| |
| |
| | |
daemon: Support X servers built with -Dlisten_tcp=true
See merge request GNOME/gdm!162
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| |
| |
| |
| | |
local-display-factory: Don't crash if Xorg and Wayland are both unavailable
Closes #739
See merge request GNOME/gdm!160
|
|/
|
|
|
|
|
|
|
|
|
|
| |
At the moment if Wayland doesn't work, the login screen will fall back
to Xorg, and if Xorg doesn't work the login screen will fall back to
Wayland.
But if the fall back choice is disabled explicitly, GDM will just crash.
This commit fixes the crash.
Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/739
|
|\
| |
| |
| |
| | |
pam-arch: Drop pam_faillock counting from fingerprint and smartcard
See merge request GNOME/gdm!163
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in an [fprintd issue comment][1], we need to make sure that
the stack's error status is taken from the main auth module, i.e.
pam_fprintd, otherwise GDM will not behave correctly.
Still use pam_faillock preauth so that we test whether the account is
locked, but don't use authfail/authsucc to log a failure/success so this
stack doesn't participate in triggering the lock.
Ideally we would check which return values we actually want to treat as
a reason to lock the account (e.g. fingerprint mismatch) and which are
neutral (e.g. no fingerprints enrolled), but that's much more effort.
Should fix [FS#71750][2].
[1]: https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/112#note_1016191
[2]: https://bugs.archlinux.org/task/71750
|
|\
| |
| |
| |
| |
| |
| | |
libgdm: Handle GDM_SUPPORTED_SESSION_TYPES being unset
Closes #748
See merge request GNOME/gdm!165
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
If GDM_SUPPORTED_SESSION_TYPES is not set in the environment, calling
any libgdm function which internally calls collect_sessions() will log a
CRITICAL from trying to g_strsplit() a NULL string. This may happen if,
for example, a developer is launching gnome-shell directly, rather than
it being launched by GDM.
Don't try to split the NULL string. The rest of collect_sessions()
already gracefully handles supported_session_types being NULL, so no
further changes are needed to the function.
Fixes: https://gitlab.gnome.org/GNOME/gdm/-/issues/748
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
meson: Fix detection of Xorg versions that need -listen tcp
Closes #704
See merge request GNOME/gdm!161
|
|/
|
|
| |
Closes #704
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
daemon: Infer session type from desktop file if user has no saved session type
Closes #733
See merge request GNOME/gdm!159
|
|/
|
|
|
|
|
|
|
|
| |
The accountsservice user cache file can specify a session type
associated with the saved session. This is optional though. If one
isn't specified GDM needs to figure out the session type based on the
list of preferred session types for the system and the session file
itself.
It was failing to do the latter, though. This commit fixes that.
|
|\
| |
| |
| |
| |
| |
| | |
pam: Drop gdm-pin service
Closes #731
See merge request GNOME/gdm!158
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
gdm-pin was an experimental feature that was going to get added to
gnome-shell many years ago. It never happened and these days it
would probably be implemented a little different anyway.
(It would probably use a gdm pam extension)
There's no point keeping this service file around that we aren't
using, so this commit drops it.
Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/731
|
| |
|
|\
| |
| |
| |
| | |
xdmcp-display-factory: Set supported session types for XDMCP displays
See merge request GNOME/gdm!157
|
|/
|
|
|
|
|
| |
The lower levels of GDM now expect the session types supported by a
display to be specified up front.
This commit makes sure XDMCP displays do that.
|
|\
| |
| |
| |
| | |
local-display-factory: Don't try to respawn displays on shutdown
See merge request GNOME/gdm!156
|