This means string operations now can be applied on raw strings rather than
having to cast them using the String() class template wrapper.
String("something").CharAt(3)
now becomes simply:
"something".CharAt(3)
When we access to the kernel console's fb, we don't own
it and shouldn't remove it.
This is like commit 808e129fd1,
but for radeon and nouveau instead of intel.
commit cf766763f2 was
messed up in more than one way. The biggest problem
was that It didn't include the Makefile changes needed
to ship the files added to the repository.
This commit fixes that.
This series of commits adds a few configuration files
to replace the kludgey symlink we use now for theme
specification.
In the future, these config files could potentially
be used for other things as well.
Now that the daemon looks for the default theme in configuration
files, we should make plymouth-set-default-theme write the
configuration files instead of doing symlinks.
That's what this commit does.
Right now we figure out the default theme via a symlink.
This apprach is very simple, but is also a little cumbersome.
It means as the default theme is changed around we have to move
the symlink around.
The symlink is in /usr. We really shouldn't be mucking with
/usr when changing defaults.
This commit checks the filesystem for two config files:
/usr/share/plymouth/plymouthd.defaults
and
/etc/plymouth/plymouthd.conf
The first one is for distributions to use. This is how they can
manage which splash to show from release to release.
The second one is for system administrators. This is how they
can override distribution policy.
We don't actually ship these files yet. In the mean time,
(and even after for the forseeable future) the old symlink method
will still work.
Previously the code was assuming the windows were placed at 0,0. This might not
be the case and the window X and Y values should be used when trying to
position items relative to a window.
This change needs to be applied to all other scripts otherwise mutiple screen
setups may have unaligned elements. Updates scripts should be tested using
multi-head test systems or the x11 test renderer.
Calls to Window.GetWidth/Height/X/Y without a window index now return the
values of the area covered by all windows. This is only the case if all the
windows are aligned (either by their centers, or to a corner).
This allows the theme designer to place an object knowing it will be seen on
all screens.
Minor bug, previously would return the index used rather than a NULL. Would
only cause problems when using a width request as a test of the presence of a
window.
When multiple screens are found, the system will now arrange them so they are
all centered, and the top left corner of the largest screen is at 0,0.
No changes to any scripts are needed.
If we're done with the VT plymouth was running on,
and plymouth wasn't running on the initial VT, we
should jump back to the initial VT and try to
clean up plymouth's VT.
Resetting the mode to text on every write means that if you're
using a text plugin and X starts, X's VT keeps getting reset back to
KD_TEXT since those plugins don't stop writing on deactivate (they
have no renderer).
There's no reason to set this mode here anyway; all paths to using
those plugins already do this.
Instead of setting the terminal to unbuffered (raw) mode on every
write, keep track of whether it's unbuffered or not at the points
we open and close the terminal.
Deactivate already takes care to set back into buffered mode;
otherwise we can end up resetting the terminal mode under X causing
Enter to send X SIGQUIT.
If we don't deactivate the renderer before hiding the splash, the
drm renderer may scan out the buffer contents to the fbcon buffer;
since we only hide the splash when dumping details or when
--retain-splash is *not* given to quit, this is exactly the
opposite of what we want.
The effect of not doing this is partial splash contents behind the
details in cases of error, or when using quit. This doesn't affect
plymouth quit --retain-splash.
One problem with the current deactivate/quit transition into X is that
the display manager will, if Plymouth was running, re-use the currently
active VT.
That only works if Plymouth was actually displaying a splash screen on
that VT. If --show-splash hasn't been called yet because we booted too
fast, we'll be on the wrong VT.
Add a request to ask whether the Plymouth VT is active; I've done it
this way so the answer defaults to "yes" for Fedora who use VT1.
The pseudo-code for transition is thus:
if plymouth is running (ping):
plymouth deactivate
if plymouth has active vt:
start X on current VT with -nr
if X starts ok:
plymouth quit --retain-splash
else if X fails:
plymouth quit
else if plymouth doesn't have active vt:
plymouth quit
start X as normal
else if plymouth isn't running:
start X as normal
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.
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.
