| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We don't have a --version and it was adding a gap in the output
|
|
|
|
|
|
Previously, it said that "rhgb" was required for plymouth
to run, but plymouth runs no matter what. This just
specifies which splash is displayed
|
|
They weren't completely accurate, you don't need to reinstall
grub after editing its config, since it has built-in filesystem
drivers. Also, those details very from system to system, so we
should probably just leave it out.
|
|
It referenced rhgb, but not splash. While rhgb was
there first, most distributions use splash since it's
more logical (among other reasons).
|
|
We don't want to provide a history of what distributions
used before plymouth, because that history could get long,
isn't super relevant, and will add noise for a users looking
for help (they probably only care about their distributions,
not others).
|
|
This way we can put other documents there as well.
|
|
It explains the basic concepts of plymouth and the usage of tools to be
used to setup it.
|
|
|
|
Minor rejig to make the help messages more consistant. Also removes some tabs
and empty lines.
|
|
This way the top line of the help output gives usage.
|
|
When running new, unfamiliar commands I usually invoke them with
--help to see what options they have. For plymouth-set-default-theme,
there is no --help option which I find a bit confusing, especially
since the usage is not straight-forward.
There is now an additional function "show_help" which displays an
help output when invoking plymouth-set-default-theme with --help.
|
|
When redirecting stdio to the tty, the
tty was opened and its fd was dup()'d to
the standard ones, but then wasn't closed.
|
|
These are the Window.GetX/Y that pair up with Window.SetX/Y already present.
They return the position of the window.
|
|
Maintainer mode is assumed on when executing configure, and thus is not needed
within autogen.
|
|
Previously, in non-icon mode when clicking on the window decoration close, the
window would hide and carry on running. It should quit.
https://bugs.freedesktop.org/show_bug.cgi?id=20228
|
|
If is_animating was not set, the draw would quit before drawing the dialog.
|
|
We collected the color information before, but did nothing with it.
|
|
Previously we drew two overlapping labels, one in black and one in white, to
make sure it was vsible on all backgrounds. Now we can pick an appropreate
color for each theme. The default is white. If changing the label color once it
has been shown, it will redraw that part of the screen.
|
|
Although the windows are set up to in a reasonable default configuration, the
themes may align the windows differently to not crop some important elements.
The Window.SetX and SetY allow positioning the window anywhere on the canvas.
Use this sparingly as it induces a full refresh of all screens.
If there is a desire to have totally different scenes, the second window can be
positioned somewhere far away so there is overlap and a complete different set
of sprites is used. Another sensible configuration is to have the screens side
by side and allow sprites to span the gap. Remember to create password dialogs
for each screen as not all may be visible.
|
|
When multiple displays were introduced, each display had its own script plugin
instance. This made things easy as the scripts would not have to be rewritten
for multiple screens. Unfortunately this also meant that each image was loaded
multiple times, and the scripts consumed much more processing power.
Additionally the scripts were not aware of each other.
This patch allows a single script instance to control multiple displays while
maintaining reasonable backward compatibility. All sprites are placed on a
virtual canvas. Displays (or windows) then expose parts of this canvas to the
user.
As a default, window 0 is placed at 0,0. Further windows are placed on top of
the window 0 area matching the centre point so the password dialog (which is
placed in the centre) is visible on all windows. If you target window 0 only
and you place dialogs in the middle of the screen, then everything should work
fine.
Window.GetWidth/GetHeight now takes a window number (if none supplied it will
assume 0). If it replies a NULL, then you accessed beyond the end of the
window set.
|
|
Typo in the previous patch.
|
|
Gets the Nth node in the list. If the index is outside the range, it will
return NULL
|
|
Stable sort sorts but does not change the order of elements which are equal.
This is important in the sprite based plugins where if the level of the sprites
is equal because it may be unimportant which is on top, changing the order
between frames looks bad.
|
|
Typo, sort line was missing.
|
|
The renderers commit the rectangles derived from the region in a random order.
This gives some tearing as the screen is displayed with a random regions in
their new state. The change sorts the list of rectangles according to their Y
value to commit them from top to bottom. This gives fewer tear lines.
|
|
It is a simple quicksort implementation which does no randomisation.
|
|
Sorts 100 random integers. Reports any out of order and returns an error code.
|
|
|
|
This merges the "no-fbcon" branch to master.
Previously, the way to get a transition between
plymouth and X was for plymouth to quit,
leaving the tty in KD_GRAPHICS mode, and hope
X starts and picks up the peices. In this
limbo state where plymouth isn't running but X
isn't started yet the user is unable to
switch VTs or really do anything at all.
If X doesn't start then the user is hosed; they
have to reboot.
Now, instead of quitting plymouth before starting
X we "deactivate" it. This gets plymouth into a
state where X can take over the display, but
plymouth stays running. Once X has fully started
up or failed to start the display manager can
tell plymouth to quit (with --retain-splash if
X started successfully and without if X started
unsucessfully)
|
|
This tells the daemon we're about to start X with -nr and
to get ready for the transition.
|
|
In order for plymouth to be able to stay around until
after X is started, we need to put the daemon into a
"deactivated" state where it makes the splash becomes idle
and relinquishes control of the scan out hardware and keyboard
for X to seize.
This commit listens for deactivation requests in the daemon and
performs the deactivation.
A future commit will implement the client bits needed.
|
|
We disable flushing when inactive.
|
|
We basically just do what we were doing before
implicitly on VT switch, explicitly on activate
and deactivate.
|
|
We basically just do what we were doing before on
implicitly on VT switch, explicitly on activate
and deactivate.
We also don't scan out the splash to the fbcon
on unmap if the renderer is inactive.
|
|
The point of these methods are to put the renderer in
and out of a state where it is no longer going to
be on screen.
This should cause flush calls to be no-ops and device
specific locks should be dropped.
These methods will be necessary to keep plymouth running
while X is getting started up.
|
|
There may be cases where there is no keyboard set.
|
|
|
|
|
|
Testing with it replying random strings to make sure the error cases were
caught. Code accidentally left in.
|
|
Currently the strings must be manually told to adopt from the library functions
by using String("string").function(). This is temporary and later it should be
possible to apply functions directly to strings.
CharAt gives the a single character string at the index specified. The first
character is at index zero. Characters beyon the end are empty strings, and
errors return NULL. This can be used thusly:
str = "something";
letter = String(str).CharAt(7); # letter = "n"
letter = String(str).CharAt(12); # letter = ""
letter = String(str).CharAt("foo"); # letter = NULL
|
|
Previously, refresh, each sprite would refresh its old area, then its new area.
This, combined with situations where there are many sprites caused the area to
be redrawn many times, each time redrawing each overlapping sprite data.
Now we add all areas which need to be refreshed to a region and this makes a
smaller set of rectangles to refresh, and these are not overlapping.
Also uses the freeze display updates, which should work better now.
|
|
If the width and X position of the two rectangles is the same, we can merge
them together. The new set of exact overlaps detects this and determines the
direction the rectangle should be extended.
The region code now uses this. WARNING, when expanding rectangles, these have
to be merged with the other rectangles down the list as there may be overlap.
|
|
The previous version had a flaw where it would find the rectangles overlapping
if they spanned a range in one axis. Despite them having no overlap in the
other axis.
Because this version has strange (although correct) behaviour when dealing with
empty rectangles, region only calls the overlap function when both rectangles
are not-empty.
The issue is if an empty rectangle sits on the edge of a full rectangle, the
function reports (possibly correctly) that the edge is overlapped by the empty
rectangle. The region code then nudges the rectangle down one space and
subtracts one from the empty rectangle height. This creates a rectangle with
negative height (bad thing).
If the other version can be fixed I will put it back, but this one is also
useful for the combining two rectangles of equal width.
|
|
Now that we cannot rely on the next_node element. We must finish processing the
entry before removing it. Easiest way is to recurse and remove after return.
|
|
new_area->width depends on new_area->x and vice versa. Break the dependency by
adding a temp variable.
|
|
Also one redundant line. I think this code was never used in anger. There is a
major bug in the rectangle collision code which makes this detection ad-hoc.
|
|
Probably a typo in the original version.
|
|
Previously we just returned and did not free.
|
