After changing the active vt during start up,
we get a signal when it finishes, because we're in
VT_PROCESS mode, so we don't need to explicitly block
waiting for it to finish.
During the quit path, though, we aren't in VT_PROCESS mode anymore,
won't get any signals, and still need to know that the VT switch
is finished before informing the client that the quit is
finished.
This commit forces ply_terminal_deactivate_vt to block until the
VT switch it initiates finishes.
The system now keeps a list of messages so they can be shown again when the
user flips themes or if the messages were passed before the splash was shown.
This also enables the splashes to show multiple messages (should they choose to
do so). There will later be a way of undisplaying a message.
There is a small window after plymouth is told
to quit or deactivate before it actually does.
During this window, if the user happens to hit
escape, bad things could happen.
We really don't want to mess with, e.g., the tty
settings when we're about to exit.
This commit puts plymouth in a sort of "degraded"
mode while it's deactivating. During this time
frame, user input is ignored.
From time to time, various external programs
will muck with the tty we're using and make
the users password for encrypted disks show
up, make the enter key not work, etc.
We used to work around this by resetting the
tty the way we like it everytime we write the
screen.
We no longer do that after commit
e9a22723da
Instead of changing it every time, it's probably
better to just prevent other programs from messing
up the settings in the first place.
This commit locks the terminal so if those programs
try to change the settings, they fail.
A better long term solution might be to get user input
/dev/input instead of the tty
The x and y offsets were supposed to allow only a part of the image data to be
drawn, but this didn't work correctly. Instead the clip region can be used to
emulate the same effect. So the x and y paramiters in these functions are now
dropped. The only instance that used these now uses a clip. All other calls had
x and y set to zero.
This prevents the event loop from freeing sources
early in an iteration of the loop, and then dispatching
handlers for the source later in that same iteration.
If we don't do this, then the splash display handler will
still be set, causing all sorts of undefined and weird
behavior.
This makes hitting the escape key multiple times act more
reliable.
On my system, some headers seem to be stuffed in /usr/include/libdrm
and other headers seem to be stuffed in /usr/include/drm .
I think the ultimate upstream goal is for everything to be in
/usr/include/libdrm but my system seems to be in some transition state.
My pkgconfig files only point me to one of the directories, so add some
heuristics to find the other one.
The ask-for-password command has an option
to specify the maximum number of retries to
get the correct password. The default number
of retries was 3. This makes sense for /opt,
and to a lesser degree /home, but it doesn't
make sense at all for /, since failing means
the system won't boot.
The new default is "unlimited". This fixes the
/ case, but has the downside that all integration
code that was depending on the 3 default before
will need to get updated.
If calling a function which is connected to the current object, the object
operated on in the function call is the current object. This is rarely used and
somehow survived without causing crashes despite incorrectly not increasing the
refcount.
When using the old style transition code path where
plymouth quits before X starts, we can't use the drm
renderer for single head nouveau and readeon setups
because their kernel memory manager doesn't allow userspace
write access to the console fb and the old style
transition code needs to dump the last frame of the
plymouth animation to the console fb as intermediate step
of the transition process.
The newer plymouth deactivate mechanism doesn't need the
intermediate console fb copy, so we can stick with the
drm renderer all the time.
This commit conditionalizes the "bail to frame-buffer renderer"
check based on whether the build is configured to enable
the old style transition.
Previously we were connecting to the keyboard but not disconnecting from it as
unset_keyboard was not called before the plugin being destroyed. Now we connect
when on splash start and destroy which makes sure we disconnect before being
destroyed.
Drawing to renderers was resetting the terminal to unbuffered, but this was
also discarding any queued input keys. The fix should keep the input buffer
untouched.
It's possible for activate to be called before map_to_device, for
example if a non-graphical splash plugin is in use. Initialize
map_address to MAP_FAILED so that we won't try to redraw in this
situation.
If the splash hasn't picked up any displays it will abort. We wait for the
possible abort before attaching the keyboard. This is a slight hack as now
add_displays_and_keyboard_to_boot_splash no longer adds the keyboards. Also the
splash plugin can access the keyboard before it is officially opened.
For now it just fixes the terminal fd < 0 assertion bug.
Since the boot splashes handle opening the terminal now,
we need to make sure that we don't try to watch for input on
the terminal until they've opened it.
This should fix some crashes users are reportedly seeing with
the details splash.
A potentially better fix would be to make watch_for_input defer
doing anything on its own using the terminal is opened. That
would require a trigger and some new api to ply-terminal, I think.
