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.
Because enter and general keystrokes are handled separately, enter would not
activate the keystroke trigger. Now, you can watch specifically for an enter
press, and enter is accepted as a general any-key trigger.
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.
