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>
plymouth-switch-root-initramfs.service commands plymouth to release
rootfs to allow the shutdown ramfs to unmount rootfs. However, it only
integrates with dracut. Arch Linux uses mkinitcpio by default, and it
uses shutdown ramfs when layered block storage (e.g. LUKS) is used for
rootfs. Therefore, it fails to unmount rootfs on shutdown if LUKS and
plymouth are used together.
Add a new trigger for plymouth-switch-root-initramfs.service to start
when /run/initramfs/shutdown exists (/run/initramfs/bin/sh may not exist
with mkinitcpio when systemd-based initramfs is used), and add a
dependency to start it after mkinitcpio generates the shutdown ramfs.
Plymouth has 2 hw discovery paths:
1. Enumerating devices already known by udev at plymouth startup
2. Devices which are hotplugged after startup
At boot we have udevd which is enumerating hw and plymouthd racing
with each other, which means that plymouthd may discover the new
SimpleDRM device through either 1. or 2.
Before this patch a check for SimpleDRM was missing from path 1, causing
it to be treated as a normal device instead of being ignored as intended:
plymouth-debug.log for the simpledrm being enumerated in path 1:
ply-device-manager.c:344: create_devices_for_subsystem:
found device /sys/devices/platform/simple-framebuffer.0/drm/card0
ply-device-manager.c:351: create_devices_for_subsystem:
device is initialized
ply-device-manager.c:360: create_devices_for_subsystem:
found node /dev/dri/card0
ply-device-manager.c:283: create_devices_for_udev_device:
found DRM device /dev/dri/card0
ply-device-manager.c:885: create_devices_for_terminal_and_rende:
creating devices for /dev/dri/card0 (renderer type: 1)
plymouth-debug.log for the simpledrm *not* being enumerated in path 1:
ply-device-manager.c:344: create_devices_for_subsystem:
found device /sys/devices/platform/simple-framebuffer.0/drm/card0
ply-device-manager.c:367: create_devices_for_subsystem:
it's not initialized
followed by path 2 enumerating the device very shortly after this:
ply-device-manager.c:532: on_udev_event:
got add event for device /dev/dri/card0
ply-device-manager.c:462: verify_add_or_change:
ignoring since we only handle SimpleDRM devices after timeout
Note how path 2 does correctly ignore SimpleDRM devices, where as
path 1 does not. This commit fixes this by moving the verify_drm_device()
check in to create_devices_for_udev_device() which runs in both paths.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2127663
Reported-by: Michael Catanzaro <mcatanza@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Move verify_drm_device() higher up in ply-device-manager.c, this is
a preparation patch for the next patch in this series.
This is a pure move without any changes to the moved block.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Secure boot is used against several security threats when malware tries to
infect the firmware of the system. Users may inadvertently disable or
software may intentionally disable the secure boot. Consequently, the
system is running on an insecure platform with incorrect configuration. If
Plymouth could offer a warning to the user, the user could reboot and
reconfigure their system or asks for help immediately.
This work can be used to check the secure boot configuration and put a red
warning image on the screen if the secure boot is disabled. Also, this
check can be utterly disabled through the kernel parameter for testing.
If the parameter "secure_boot.warn_if_disabled=false" appears in the
kernel parameter, the secure boot check will be disabled.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
This checks the secure boot status. If the secure boot are enabled,
return true. Otherwise, return false.
The system secure boot settings is at
/sys/firmware/efi/efivars/SecureBoot* and the fifth byte should be
0x1 which means the system secure boot is enabled.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
