Change the display_normal() function so that rather than being a no-op
if we already saved the state as normal, it restarts any animations and
redraws the views.
The only thing we now do if the state is not previously the same is
hide any prompt.
This allows this to be used to reanimate the plugin on reactivate.
Change the display_normal() function so that rather than being a no-op
if we already saved the state as normal, it restarts any animations and
redraws the views.
The only thing we now do if the state is not previously the same is
hide any prompt.
This allows this to be used to reanimate the plugin on reactivate.
Since deactivate uses on_boot_splash_idle, there's a good chance that
plugins will have stopped animating. Prod them to animate again by
calling update_display()
More for debugging and completeness than anything else, add a
"reactivate" command to the daemon that undoes the effects of
deactivate and continues the splash screen on its way.
Another possible use for this could be (for example) providing a
seamless shutdown experience.
A future commit will implement the client bits needed.
Currently deactivate is mostly like hide splash, except it deactivates
the renderer first and doesn't reset the VT to text mode and dump the
details plugin over top.
Unfortunately this means that the renderer is closed and freed, and in
the case of the Intel DRM renderer, closing the DRM file descriptor
means that the kernel frees the buffers and restores the fbcon buffer
on our screen - losing the smooth transition.
This now changes deactivate such that it leaves the boot splash open,
but in an inactivate state, with the DRM connection still open, etc.
now the fbcon contents are not restored.
We deliberately stop watching for keyboard input, detach any logging
session from the console, take the VT out of VT_PROCESS mode and
put it back into cooked mode, etc.
This means the X server can be started, and this state can be cleaned
up by calling plymouth quit with affecting X.
To allow deactivate_splash() to do more than affect the boot splash
plugin and renderer, call it from the deactivate path when there is
no boot splash screen as well.
In order to deactivate without pulling everything, we need to be able
to take the terminal in and out of VT_PROCESS mode directly; so change
the two functions from static to exported.
Since we ignore --show-splash, it makes no sense to process
--hide-splash either; in theory this does nothing already because
we won't have a boot_splash in our state - but that changes with
future patches and it's worth being safe.
The last thing we want to do after plymouth deactivate is called by
the X display manager is listen to calls to show the splash screen
again.
So don't.
When it comes to quitting, which must be carefully coordinated
with other subsystems during the boot process, we need to make
sure the client doesn't return early.
When it comes to deactivation where the various steps of boot
have to be carefully synchronized, we need to make sure that
the client doesn't return early.
Likewise if plymouth quit is called when we're waiting for the boot
splash to become idle, we also end up asserting that there's not
already an idle trigger.
Fix it in the same way as deactive, ignore the second quit command
except for pulling its trigger.
If plymouth deactivate is called when we're waiting for the boot
splash to become idle, we end up asserting that there's not
already an idle trigger.
Fix it by checking for an existing deactive trigger, and if there
is, ignoring the new deactivate command (except for pulling its
trigger so it doesn't block).
In the cases where the boot splash plugin does not become idle
immediately, we go back into the main loop and can receive additional
commands.
Since quit and deactive both use this facility, one scenario is the
quit command arriving after the deactivate command, but before the
deactivate command has actually been run.
In that situation, we want to quit, not deactivate.
One of the main differences between Ubuntu's use of Plymouth and
Fedora's is that on Ubuntu we've tried to keep the X server on VT7
so that the historical documentation of Ctrl-Alt-F1 giving you a
text console is preserved.
This obviously means that for a smooth transition, Plymouth must also
run on VT7.
We discovered that although Plymouth does have code to attempt to deal
with VTs, none of it is quite right and there are many paths that don't
work unless Plymouth is run on VT1.
This patch set fixes our known problems with the VT handling making it
possible to run Plymouth on any VT of your choosing, with VT1 remaining
the default.
Add a command-line option to specify the TTY that plymouth should
use. This is mostly useful for debugging, for example you can put
plymouth onto a TTY not used by the X server; or if you're feeling
particularly sneaky, plymouth into an xterm.
Change the renderer so that it defaults to inactive, then when we
map to the device, activate the renderer by activating the VT;
unless the VT is already active in which case activate the
renderer directly.
Change the renderer so that it defaults to inactive, then when we
map to the device, activate the renderer by activating the VT;
unless the VT is already active in which case activate the
renderer directly.
Move the responsiblity to activate the VT into the text and details
plugins; this not only matches the graphical renderers, but it also
ensures we activate the VT in all possible code paths.
Previously if we fell back to text.so because we couldn't activate
a renderer, this would not activate the VT.
Move the responsibility to actually open the terminal to the renderers
and text/details plugin, this allows the X11 renderer to not actually
open the terminal - and thus not crash the X server.
When we activate our VT, now we actually have it in VT_PROCESS not the
VT we started from, we get the proper signal so don't need an ioctl to
wait until its active.
If we were to leave our VT, we'd get the opposite signal as well and
we don't really care whether we actually get to the other VT, just
that we leave ours.
And this code was in the wrong place anyway.
Trying to keep track of whatever VT is actually active is inherently
racy; instead just keep track of whether our VT is the active one.
Since we guarantee that's the VT in VT_PROCESS now, this is easy.
Rather simplifies the on_vt_changed functions in renderers too.
Now we can simply test whether a terminal is virtual or not, add
a guard in the mode and vt change functions that ensure they only
operate on virtual terminals.
We want to be able to query whether a terminal is an ordinary terminal
or a virtual terminal, rather than looking up the vt number and knowing
what the right numbers are, add a function that knows that.
Remove all of the references to ply_console_t from the code, now
we operate exclusively on the terminal object. In some places
this means switching from one to the other, but in many it just
means dropping the console object and using the terminal object
we were already passed.
This removes the separation in code of "console" functions and
"terminal" functions; this never really made sense, and doesn't
particularly map to the behaviour of Linux virtual terminals.
The three principle operations that Plymouth was using "console"
for were:
* changing the active VT
* notification of changes to the active VT through VT_PROCESS
* switching between text and graphics mode
And it was using the "foreground terminal" alias /dev/tty0 to do
this. While this is fine for the first of those, since any console
device will do, it's always wrong for the latter two which should
always be on the actual VT we want Plymouth to run from.
If running on tty7, only tty7 should be in VT_PROCESS mode (since
we want to know when we enter this VT and leave this VT), and
certainly only tty7 should be in graphics mode.
Since you can use that same tty to obtain the current active VT,
and switch VT, you don't need another; so the need for a separate
"console" functionality goes away.
Since script implements a set_keyboard function (the only plugin to
do so), the previous commit reveals a bug where set_keyboard is
called for the plugin but unset_keyboard isn't called if the plugin
fails to be loaded
The script plugin only works on pixel displays, however there wasn't
any check for this, so if a script-based theme was your default
Plymouth would not fallback to using the text plugin instead.
I think when I originally added the fallback case, I looked at the
tcgetattr man page, saw cfmakeraw()'s settings and just inverted them.
That's obviously wrong. These settings should hopefully make a little
more sense.
Adds the SubString function which returns a string segment. The two paramiters
are the sub-string start and end indicies. Negative start and end values return
a NULL, as does start index being beyond the end index. Start being beyond the
end of the string returns an empty string.
