Plymouth currently gets keyboard input from the terminal. This isn't
ideal, since it means plymouth requires VTs to be enabled in the kernel.
Furthermore, most display servers use /dev/input and libxkbcommon for
keyboard handling these days.
This commit adds similar support to the plymouth core code. Subsequent
commits will add support to the render plugins.
Some contributions by n3rdopolis and Ray Strode.
At the moment the keyboard-render script only generates short
names for console layouts.
We're going to add /dev/input support to plymouth using
libxkbcommon, so we're going to need a list of of those keymaps
too.
This commit adds that.
Some contributions by n3rdopolis and Ray Strode.
At the moment we ignore any udev events that come in before the
device timeout that are not drm devices.
That is because we don't want to use framebuffer devices as anything
but a last resort fallback option.
In the near future we're going to be handling input events from udev
as well. Those will obviously need to be handled right away, just like
drm devices.
This commit makes the check only defer framebuffer devices and not
anything that isn't a drm device.
strcmp is kind of a confusing function in that it returns
non-zero when the strings are not equal. That is
especially counterintuitive when this non-zero value is
treated as a TRUE boolean.
This commit just adds some != 0's to a couple of strcmp
calls for clarity.
Right now callers of ply_buffer_append_bytes have to be
very careful to make sure the data they're appending is
non-zero in length. This is kind of inconvenient, since
it's not unusual for data to come in that's zero bytes
long.
For simplicity, this commit just makes
ply_buffer_append_bytes support that use case.
In the future we're going to start reading keyboard input from
/dev/input instead of the tty. When that happens, input will
still be sent by the kernel to the tty.
This input would eventually back up and overflow.
To address that problem before it exists, this commit adds a new
API, ply_terminal_flush_input, that will drain the input buffer
on demand.
We can later use that API to keep the tty from backing up.
Right now triggers can only fire off handlers that have one piece
of data associated with them, but sometimes it's useful to have
an object associated with the data too.
This commit adds new api for adding "instance handlers" that have
an additional parameter and a new method `ply_trigger_set_instance`
that allows an object to be associated with the trigger and get
used for the additional parameter of the instance handlers.
At the moment, iterating over a ply_list_t requires an an
ugly looking for loop.
This commit adds a little sugar in the form of a
ply_list_foreach macro in the name of convenience.
Apparently the:
[x] Squash commits
box was checked when merge request plymouth/plymouth!177 was merged.
Oops.
We want good commit messages for such a big change, though, so people
doing code spelunking later have a fighting chance of following what's
going on.
This reverts commit dacfb36b57.
Subsequents commits will bring it back, peicemeal.
We thought we could get away with a NULL local_console_terminal
when the terminal isn't a VT, but it turns out we need it for
various reasons anyway.
This commit just makes sure we keep it in place.
At the moment, plymouth requires VT support be enabled in the kernel
to show graphical splashes.
This is because:
1. it relies on the tty to show details
2. when VT support is disabled the kernel will use ttyS0 as the default
console which makes plymouth disable graphical splashes since it assumes
the machine is a server with a serial console.
This commit addresses the first problem by disabling the
escape-to-toggle-details feature and addresses the second problem by
introducing a new kernel parameter plymouth.graphical that is like
the "splash" option and "plymouth.ignore-serial-consoles" option
combined.
label-freetype was giving a wrong line width for two reasons:
* Unproper handling of negative left bearings as it was using it as normal
while in fact the plugin draws full character boxes.
* Loading of the character used different flags when calculating width
and when actually printing the characters.
label->width is used to calculate wrapping of lines and it is by
default -1. We need to use label->area.width instead when aligning a
line, as label->width might not have been set.
Now that there's a freetype plugin available, it should be installed in
the initramfs.
This commit adds the changes to plymout-populate-initrd to make that
happen.
Some contributions by Petr Vorel and Nathan Pratta Teodosio.
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Fabian Vogt <fvogt@suse.com>
Right now plymouth uses pango for rendering text. Pango is
fully featured, but also carries a lot of depedencies.
Since plymouth goes in the initramfs, using a library that
brings in a lot of dependencies is less than optimal.
This commit adds a new freetype based plugin, alongside the
pango one.
It doesn't have quite the same feature set, but it brings in
a smaller dependency footprint.
Contributions to this commit from Nathan Pratta Teodosio,
Alfonso Sánchez-Beato, Petr Vorel, and Ondrej Holecek.
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Ondrej Holecek <oholecek@suse.com>
[ oholecek: fix plugin for newline characters ]
Signed-off-by: Fabian Vogt <fvogt@suse.com>
Right now if the label plugin fails during initialization, the plymouth
daemon crashes.
This commit adds a NULL check to fail more gracefully.
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Fabian Vogt <fvogt@suse.com>
commit 0e59dde8 changed the details plugin to clear the terminal when
first opening it. This was done to prevent duplicate messages from
showing up when toggling back and forth between details and graphical
splashes.
That has the negative side effect of purging serial console output too
though. Furthermore, it makes little sense to replay the boot buffer
on serial consoles, since serial consoles don't aggressively purge
scrollback like VTs do.
This commit adds a check to make sure the terminal is a VT before trying
to clear and replay the scrollback buffer.
Closes: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/187
Some hardware vendor may not open source display driver. (Such as pangu
M900). They load drm driver via kernel modules. On such devices, drm driver
load more slowly then other devices, which may cause logo show later and no
seem to get the Plymouth decryption screen to show. To avoid this problem,
add a bootargs for people who want to forced use fb in plymouth.
When found "plymouth.force-frame-buffer-on-boot flags" in kernel parameter,
During the system start, PLY_DEVICE_MANAGER_FLAGS_FORCE_FRAM_BUFFER will be
add to device_manager_flags. Then "force_fb" mode will enable, and the
renderer_type set as framebuffer.
Signed-off-by: shiptux <shiptux@gmail.com>
