| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This makes it clear what settings gdm is using.
|
| |
|
| |
|
|
|
|
|
| |
This will help make it more clear why autologin goes
one way or the other.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We need to retake control of VT switch processing on logout,
just as we do before login, otherwise we can be left hung
waiting for the VT to be released.
https://bugzilla.gnome.org/show_bug.cgi?id=745217
|
|
|
|
|
|
| |
it's unused.
https://bugzilla.gnome.org/show_bug.cgi?id=745217
|
|
|
|
|
|
|
| |
It's no longer needed and it makes assumptions about
install location.
https://bugzilla.gnome.org/show_bug.cgi?id=740788
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The function is ill named and ill placed. It really
just returns the username of the client that's allowed
to connect to the display.
This commit moves the function to gdm-manager.c
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When plymouth deactivates it correctly leaves the display in
GRAPHICS mode but incorrectly stops processing VT changes. This
combination of VT_AUTO + KD_GRAPHICS makes VT switches hang.
Deal with the situation on our side until plymouth is fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=745465
|
|
|
|
|
|
|
|
|
|
|
|
| |
That signal is blocked when the worker is forked,
because the main daemon uses it to notice when
the X server is ready.
This commit changes the worker to use real-time
signals instead, which are better anyway, since
they queue.
https://bugzilla.gnome.org/show_bug.cgi?id=745465
|
|
|
|
|
|
|
| |
We're going to call it in more than one place in the code,
so it's better to keep it in a separate function.
https://bugzilla.gnome.org/show_bug.cgi?id=745465
|
|
|
|
|
|
|
| |
I think the problem is really just the terminal getting
stuck in KD_GRAPHICS/VT_AUTO mode by plymouth.
https://bugzilla.gnome.org/show_bug.cgi?id=745465
|
| |
|
| |
|
|
|
|
| |
Document a hang that I need to deal with in the near term.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If we're doing an autologin we don't want to inadvertently do
wayland for X11 sessions, so make sure to reset it.
|
|
|
|
|
|
|
|
|
| |
By default GDM is started with a pretty blank environment.
This commit makes sure that the default locale for the
system is used.
https://bugzilla.gnome.org/show_bug.cgi?id=745286
|
|
|
|
|
| |
This time explain why the display mode that's getting picked,
is getting picked.
|
|
|
|
|
| |
This ensures we the session is always given
the tty.
|
|
|
|
|
| |
This will make it clear what VT we're on,
and whether or not the session has control of the tty..
|
|
|
|
|
|
| |
I got them inverted in my head when I did
commit 678ac9657d3166dcdeadbccb7ad9427ba0677339
|
|
|
|
|
|
|
|
|
|
|
| |
If we switch VTs when in KD_TEXT mode there's obvious flicker.
This commit addresses that problem by going to KD_GRAPHICS mode
before switching VTs. Ideally, we wouldn't switch VTs at all,
and instead leave it up to the display servers to manage via
logind. At the moment, the display servers don't use logind
properly, though, so do this as a stop gap.
https://bugzilla.gnome.org/show_bug.cgi?id=745031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that in order for X to work without being
run as root, it needs to have its VT be active at start up.
This is because it bails out of some of its logind codepaths
if it gets given a "paused" device by logind, and then sometimes
fails in its fallback code paths as it races to open
/dev/dri/card0 while logind is still giving the user
permissions to it.
As a workaround, until X is fixed, this commit jumps to the VT up
front before starting X. That adds flicker, which we'll address in
a follow up commit.
https://bugzilla.gnome.org/show_bug.cgi?id=745031
|
|
|
|
|
|
|
|
|
|
| |
If we select a non-wayland session we need to clear the session type,
or it will linger as a wayland session if it was one previously.
Prevents users from getting logged into an X session when with
XDG_SESSION_TYPE=wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=745235
|
|
|
|
|
|
|
| |
This should give a clearer picture about what session type
is getting picked when.
https://bugzilla.gnome.org/show_bug.cgi?id=745235
|
|
|
|
|
|
|
|
| |
We end up printing "looking for session file" a bunch of times
in the log with no indication why. This commit drops the message
and instead adds messages to the callers.
https://bugzilla.gnome.org/show_bug.cgi?id=745235
|
|
|
|
|
|
|
| |
We don't want to quit plymouth until the display is managed,
so there's no chance of flicker.
https://bugzilla.gnome.org/show_bug.cgi?id=745234
|
|
|
|
|
|
| |
It's clear there's a bug if they're hit, but
we shouldn't tank, since it's not a fatal
bug.
|
|
|
|
|
|
|
| |
Some displays may be PREPARED, but not yet MANAGED.
Those need to be finished at finalize time too.
Fixes an assertion failure crash in some cases.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 2d089ea6f5c123f8ad67fcab964e9ca8bd58b7ad.
It's working again.
https://bugzilla.gnome.org/show_bug.cgi?id=745139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After the user goes through initial setup, the initial setup
program logs the user in. Nowadays, this user session starts
on a new X server. The problem is, we also need the initial setup
X server to go away, and we need the login screen wayland server
to come up, all around the same time.
You can't quit one X server on a seat while starting another one up,
it doesn't like that, so there's caos, X server segfaults, and
unpredictable behavior as to "which session wins".
This commit fixes the problem by waiting until the greeter login screen
X server is started before starting the user session. This way they
don't stomp on each other's toes, and the user session ends up in
the foreground.
https://bugzilla.gnome.org/show_bug.cgi?id=745139
|
|
|
|
|
|
| |
We're going to call it higher in the code, so move it up a bit
https://bugzilla.gnome.org/show_bug.cgi?id=745139
|
|
|
|
|
|
|
|
|
|
|
| |
We haven't yet decided to use gnome-initial-setup on wayland.
Before we can, we need to create a wayland based session file
for it anyway.
This commit makes sure we properly fall back to X11 for
gnome-initial-setup.
https://bugzilla.gnome.org/show_bug.cgi?id=745139
|
| |
|
| |
|
| |
|