Hans de Goede [Tue, 27 Nov 2018 07:24:20 +0000 (08:24 +0100)]
two-step: Fix crash asking for password with multiple heads
Commit 9639ed895331 ("two-step: Fix animation not starting on later
added heads") unconditionally calls view_start_progress_animation() when
adding secondary heads, to fix the animation not running on secondary
heads when not asking for a password.
But we should not start the animation when adding a head after we've
already entered PLY_BOOT_SPLASH_DISPLAY_PASSWORD_ENTRY state, otherwise
we end up starting it a second time when the user is done entering his
password, causing plymouth to crash and the boot to hang.
We already have the is_animating bool to indicate whether animations have
been started or not, use this to decide if we should start the animation
when adding a new head, fixing the crash.
Fixes: 9639ed895331 ("two-step: Fix animation not starting on ... added heads") Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 12 Nov 2018 11:50:33 +0000 (12:50 +0100)]
two-step: Fix animation not starting on later added heads
Fix the animation not starting on heads added after show_splash_screen
has been called. Since the core calls show_splash_screen after adding
the first head / pixel_display in practice this fixes the animation not
starting on all monitors other then the first.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sat, 10 Nov 2018 15:04:31 +0000 (16:04 +0100)]
ply-device-manager: Fix race causing undesired creation of non-gfx devs
On systems with working drm/kms devices we still sometimes see:
"Creating non-graphical devices, since there's no suitable graphics hardware"
in the logs (and actually create non-gfx devices).
This is caused by a race where the create_devices_from_udev timeout handler
runs just after the pivot-root, just at the time when the "udev trigger"
from the real root is done.
This causes create_devices_for_subsystem() to hit the "it's not initialized"
code-path for all drm and fb devices, even though before (from the initrd)
drm-devices where already setup successfully.
One way of solving this would be to stop the timer as soon as we successfully
enumerate the first drm device. But we need the timer to enumerate fb devices
so on machines where some outputs only have a fbdev driver (corner case) this
would break support for those outputs.
Instead this commit moves the found_drm_device and found_fb_device to the
global manager state and sets them from create_devices_for_udev_device().
This way they will be set when we check them from the create_devices_from_udev
timeout handler even if create_devices_for_subsystem skips over the devices
because of the udev trigger race.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 17 Jul 2018 07:46:12 +0000 (09:46 +0200)]
logger: Add a separator between different boot logs
Since we concatenate boot logs one after the other in /var/log/boot.log
it is hard to tell where the logs from one boot end the next boot starts.
This commit makes plymouth write out a separator including a time + date
of the date, when the log file gets opened to add new boot messages to it.
Note ply_logger_open_file() is only called from ply_terminal_session_open_log()
which in turn is only used for /var/log/boot.log, so this only effects
/var/log/boot.log.
Closes #29
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 2 Oct 2018 09:44:28 +0000 (11:44 +0200)]
drm: Use preferred mode for outputs instead of current mode
When enumerating outputs pick the preferred mode instead of the current
active mode, which may be e.g. a very low res mode.
Sofar we've been relying on fbcon setting up the modes for us, but as
mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=101520#c22
we really should not rely on this.
With the recent flickerfree boot changes we can no longer rely on fbcon
to do the setup for us, hence this commit. For now this commit only
changes the mode-picking logic on UEFI setups as we only have
flickerfree boot there. Once the setup code is more mature we should
probably always use it.
Closes #68
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 2 Oct 2018 12:13:19 +0000 (14:13 +0200)]
drm: Refactor ply_renderer_connector_get_rotation
ply_renderer_connector_get_rotation walks over all properties to add
support for selecting the preferred mode we also want to know if a connector
is part of a tiled output or not, which also requires walking over the props.
This commit refactors ply_renderer_connector_get_rotation into
ply_renderer_connector_get_rotation_and_tiled to prepare for this.
While at also properly use ply_pixel_buffer_rotation_t for the orientation
instead of an int.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 2 Oct 2018 08:26:28 +0000 (10:26 +0200)]
drm: Reset LUT/gamma table before the first drmModeSetCrtc call
When we takeover the kms master from whatever process came before us the
LUT table may be a mess making the graphics funky. So lets reset it once
before our first drmModeSetCrtc call.
Closes #59
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Michal Srb [Tue, 23 Oct 2018 07:10:25 +0000 (09:10 +0200)]
throbber: Don't skip last frame when waiting for end.
If the stop_trigger is set and we are waiting for the last frame to stop the
animation, make sure we don't accidentally skip the last frame. It could
happen if the machine is busy and can't keep up with the frames or when the
animation has more than 60 frames (30FPS * 2 seconds).
When running in a container with plymouth installed, plymouth is started
unnecessarily and systemd prints warnings:
[ OK ] Reached target Shutdown.
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Process 253 (plymouthd) has been been marked to be excluded from killing. It is running from the root file system, and thus likely to block re-mounting of the root file system to read-only. Please consider moving it into an initrd file system instead.
It makes little sense to start plymouth in contains, so add
'ConditionVirtualization=!container' everywhere where
ConditionKernelCommandLine=!plymouth.enable=0 appears to disable plymouth
in containers.
Hans de Goede [Mon, 2 Jul 2018 08:01:05 +0000 (10:01 +0200)]
configure: Pass -Wno-cast-function-type if available
plymouth uses function type casts for callbacks in quite a few places, fixing
these needlessly complicates the code, so lets pass -Wno-cast-function-type.
This fixes 218 warnings like this one:
ply-command-parser.c: In function ‘ply_command_parser_stop_parsing_arguments’:
ply-command-parser.c:680:48: warning: cast between incompatible function types from ‘void (*)(ply_command_parser_t *)’ {aka ‘void (*)(struct _ply_command_parser *)’} to ‘void (*)(void *, int, ply_event_loop_t *)’ {aka ‘void (*)(void *, int, struct _ply_event_loop *)’} [-Wcast-function-type]
(ply_event_loop_exit_handler_t)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 26 Jun 2018 07:15:25 +0000 (09:15 +0200)]
main: Fix getting detailed logs from systemd
This are 3 issues with the detailed logs handling:
1) plymouth attaches to the session directly on a show-splash command
(in on_show_splash()), but it does not tell systemd to start printing
details until the splash is actually shown after the splash_delay.
2) If the splash is actually shown during the initrd (e.g. a diskcript
password is necessary) then we tell the initrd systemd instance to
print details, but we don't tell the regular initrd instance which takes
over as pid 1 after the switch-root to print details.
This leads to rather inconsistent logging/printing behavior, e.g.:
* If a diskcrypt password is asked for, we only log details from
the initrd phase.
* If the boot is shorter then splash_delay no details are logged
* If the user presses ESC during boot during the initrd, only initrd
messages are printed
* If the user presses ESC during boot after the initrd, only normal
messages are printed
This commit fixes both these issues by:
1) Telling systemd to print details as soon as we have attached to the session;
and to stop printing details when we detach from the session (*)
2) Telling systemd to print details after the rootfs has been remounted rw
*) This is necessary to have a smooth transition to e.g. gdm if the splash
has not shown because the boot is shorter then splash_delay
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 3 Jul 2018 06:44:33 +0000 (08:44 +0200)]
main: Show details when ESC is pressed during splash_delay
Start listening for keypresses on the first show_splash() call, so that
pressing ESC while we're delaying show the non-details splash will show
the details splash.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 2 Jul 2018 21:46:59 +0000 (23:46 +0200)]
drm: Remove unnecessary reset_scan_out_buffer_if_needed() call from ply_renderer_head_map()
ply_renderer_head_map() gets only called from map_to_device() which
calls activate() directly afterwards which calls
ply_renderer_head_set_scan_out_buffer(), so there is no need for the
reset_scan_out_buffer_if_needed() call.
Not only is it not needed, but it is actually harmful, there are 2 problems
woth it:
1) Normally the drm plugin gets instantiated by ply-renderer.c with
rendered->is_active=true, backend->is_active=false. The
rendered->is_active=true causes the first ply_renderer_activate call
to be a no-op without calling backend->activate(). So when the first
map_to_device() calls happen activate() has not been called yet and we've
not yet claimed master rights, so ply_renderer_head_set_scan_out_buffer()
calls will always fail, resulting in this in a ply-trace:
Mapping buffer for 1920x1080 renderer head
Redrawing 1920x1080 renderer head
Setting scan out buffer of 1920x1080 head to our buffer
Couldn't set scan out buffer for head with controller id 41
This is harmless, but also shows that the reset_scan_out_buffer_if_needed()
is really not needed.
2. If deactivate_renderer() gets called before the first show-splash then
rendered->is_active will become false, so renderer_activate() done before
map_to_device() will now actually call backend->activate() claiming
drm master rights and setting backend->is_active=true.
The map_to_device() -> ply_renderer_head_map() call done after this, calls
ply_renderer_head_redraw() -> flush_head() which under 1. was a no-op
as it exits directly when backend->is_active=false. But now it actually
flushes the buffers by calling reset_scan_out_buffer_if_needed(). This
itself is fine.
But since reset_scan_out_buffer_if_needed() has already happened in
ply_renderer_head_redraw() the reset_scan_out_buffer_if_needed() call this
commit removes would always return false (no reset necessary) causing
ply_renderer_head_map() to destroy the buffer and return an error.
This results in the splash briefly showing, followed by the core soon after
trying another map_to_device(), which again briefly shows the splash, etc.
With the end result being a badly flickering display.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 2 Jul 2018 07:39:12 +0000 (09:39 +0200)]
main: Only activate renderers if the splash uses pixel-displays
Since commit eb147e52b123 ("renderer: support reactivating renderer without
closing it first"), the show_theme() call done by
toggle_between_splash_and_details() will reactivate the renderers after
switching to details mode, causing the drm renderer to switch the screen
from text to graphics mode hiding the details being logged on the console.
This commit fixes this by only calling ply_device_manager_activate_renderers()
and ply_device_manager_deactivate_renderers if the splash uses pixel-displays.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=107047
Hans de Goede [Mon, 25 Jun 2018 14:55:39 +0000 (16:55 +0200)]
main: move ply_device_manager_deactivate_renderers() into hide_splash()
hide_splash() should be the counter-part of show_splash(). show_splash()
calls ply_device_manager_activate_renderers() (through show_theme()).
2 of the 3 callers of hide_splash() are already calling
ply_device_manager_deactivate_renderers() directly before calling
hide_splash(). This commit moves the deactivate call into hide_splash()
so that it also gets called from the 3th code-path, which is when
the user hits the escape to key to toggle from the splash to details.
It's important that plymouth deactivates its renderers before going
to details, because those renderers can block the kernel from
initializing fbcon, which the kernel will start doing lazily in the
future:
https://lkml.org/lkml/2018/6/26/489.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=107047
Hans de Goede [Mon, 25 Jun 2018 20:02:07 +0000 (22:02 +0200)]
renderer: support reactivating renderer without closing it first
At the moment, ply_renderer_activate() doesn't work immediately following
ply_renderer_deactivate(). This is because the renderer isn't marked
inactive until it's closed.
This commit marks the renderer inactive when it's deactivated.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugs.freedesktop.org/show_bug.cgi?id=107047
Adam Williamson [Thu, 7 Jun 2018 00:06:14 +0000 (17:06 -0700)]
device-manager: skip graphical renderer setup when details forced
If neither "rhgb" nor "splash" is on the kernel cmdline, then
plymouth forces the "details" splash. This splash is merely
a passthrough plugin, where it makes boot looks like plymouth
isn't even running.
In this case, the code sets PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV.
The idea is to not bother waiting for udev events notifying
plymouth when graphics devices show up, since it doesn't need
to use the grpahics devices directly anyway.
Unfortunately, it does still erroneously try to setup graphical
renderers in this case, including the /dev/fb renderer.
Before commit e4f86e3c, these graphical renderers failed because
they were given the wrong device name, but since that fix, they're
suceeding. We definitely don't want the /dev/fb renderer to
load if we're ignoring udev on efi systems, since during very
early boot /dev/fb is backed by efifb, something we never want to
use. efifb is supposed to get replaced during the boot process
by other fb implementations like say radeondrmfb, virtiodrmfb or
bochsdrmfb, and some of those implementations can't handle the
transition if /dev/fb is open at switchover time.
This commit adds a new flag to tell the device manager to
not bother trying to setup graphical renderers when details are
forced.
Ray Strode [Thu, 26 Apr 2018 14:15:14 +0000 (10:15 -0400)]
wip! plymouth: stub out drm escrow program
Right now plymouthd forces itself to stay alive for the duration of
shutdown, so the splash screen can stay up until the power is killed.
This causes unclean mounts in some situations following system updates.
Rather than keep plymouthd around, all we really need to do is keep
the drm fd around. That can be down with a separate program executed
just in time from the initramfs.
As a first step toward acheiving that goal, this commit creates a
simple new program "plymouth-drm-escrow" that doesn't do anything
at all but try to stay alive.
A future commit will change plymouthd to run plymouth-drm-escrow,
and pass it the drm fd.
Hans de Goede [Tue, 10 Apr 2018 15:33:31 +0000 (11:33 -0400)]
branch-merge: support device rotation
On some devices the LCD panel is mounted in the casing in such a way
that the up/top side of the panel does not match with the top side of
the device.
Examples of this are:
-Tablets where the LCD panel is mounted upside-down (various models)
-Clamshell design devices use portrait tablet screens in a landscape fashion /
a landscape case, e.g. the GPD pocket, GPD win, Asus T100HA and the VIOS LTH17
(so the didplay is mounted rotated 90 degrees clock-wise or counter-clock-wise).
Starting with kernel 4.16 there is code in the kernel to:
-Detect affected devices
-Automatically rotate the fbconsole to compensate
-Let userspace know about this with a new "panel orientation" property on the drm connector of the panel
The patch series I'm attaching to this bug adds support for this to
plymouth, so that the boot-splash and diskcrypt-ask-password are shown
with the correct orientation / the right way up on these devices.
Hans de Goede [Sat, 20 Jan 2018 11:20:29 +0000 (12:20 +0100)]
drm: Reset primary plane rotation to DRM_MODE_ROTATE_0
On devices where the (LCD) panel is mounted upside-down in the case
the kernel's drm_fb_helper code may have set up rotation on the primary
plane to make the text-console (and other fbdev using apps) show the right
way up.
We inherit this rotation from the text-mode and since we do our own rotation
where necessary we end up rotating twice and showing the boot-splash
upside-down again.
Dealing with hardware rotation may require using a specific framebuffer
tiling which we do not support, so we should just disable the hardware
rotation and keep using our own software rotation.
This commit adds code to find the primary plane and its rotation property
and if it is not DRM_MODE_ROTATE_0 then sets it to DRM_MODE_ROTATE_0. fixing
the double rotation issue.
Hans de Goede [Tue, 12 Dec 2017 18:47:26 +0000 (19:47 +0100)]
drm: Check for "panel orientation" connector property
On some devices the LCD panel is mounted in the casing in such a way
that the up/top side of the panel does not match with the top side of
the device (e.g. it is mounted upside-down).
Kernel 4.16 introduces a new "panel-orientation" property on the drm
connector which allows modesetting applications / code to check for
such LCD panels.
This commit adds support for this new property and passes this to the
pixel_buffer code using the new ply_pixel_buffer_new_with_device_rotation
method, so that the pixel_buffer code will automatically rotate the
image to correct for the panel orientation.
Hans de Goede [Wed, 6 Dec 2017 16:37:12 +0000 (17:37 +0100)]
pixel-buffer: Add the concept of device rotation
On some devices the LCD panel is mounted in the casing in such a way
that the up/top side of the panel does not match with the top side of
the device (e.g. it is mounted upside-down).
This commit adds support to the ply-pixel-buffer code to create
buffers which take device rotation into account and which will rotate
the picture to compensate.
Hans de Goede [Sun, 21 Jan 2018 13:07:39 +0000 (14:07 +0100)]
main: Do not update the display on backspace when there is no input to remove
On machines with a slow CPU (Atom) and a highres screen drawing the
diskcrypt dialog may take longer then the keyrepeat speed, this leads to
a long delay before showing keypresses when doing the following:
1) Type long password
2) Realize it is wrong, press + hold backspace
the key-repeat will now generate backspace key presses faster then we
process them as main.c does an update_display for each press
3) Users releases backspace when we've processed input-length backspace
key-presses, but since we were drawing slower then key-presses were
coming in many more backspace keypresses are in the keyboard buffer
4) User types first character of the right password, this shows up up to
a couple of seconds later because first we are still processing all
the queued up backspace presses and doing a redraw for each.
This commit fixes this by skipping the redraws in on_backspace when there
is no more input left in the input buffer.
Ray Strode [Wed, 20 Dec 2017 15:49:19 +0000 (10:49 -0500)]
device-manager: drop superfluous create_pixel_displays_for_renderer call
commit 29e27637694eefc962d53333c729e6cac1c66518 tried to move
create_pixel_displays_for_renderer down a couple of lines, but it
inadvertently copied it instead of moved it.
Ray Strode [Mon, 11 Dec 2017 15:39:13 +0000 (10:39 -0500)]
x11: don't call gdk_display_get_name before gtk_init
The x11 plugin calls gdk_display_get_name at load time
to set the device name state. This no longer works, since
gtk_init_check() happens later at open_device time, and
GTK+ no longer allows gdk_display_get_name before gtk_init.
This commit moves the gtk_init call earlier, to
create_backend, so gdk_display_get_name works again.
Not all distros use the upstream plymouth-populate-initrd
script to populate their initramfs. As a consequence,
some themes have been developed that use subdirectories,
(which is not supported by plymouth-populate-initrd).
This commit adds support for that feature, so that
preexisting themes get properly installed.
Ray Strode [Tue, 7 Nov 2017 18:49:30 +0000 (13:49 -0500)]
device-manager: fall back to text mode if graphical devices fail
Right now we assume if we find a /dev/dri/card0 that it will work.
That may not be true. The proprietary nvidia driver, for instance,
provides /dev/dri/card0 but disables modesetting by default.
This commit makes sure we fall back to text mode if /dev/dri/card0
is insufficient for our needs.
This makes possible to support shipping a self-contained initrd which
completely overrides the plymouth theme. The configuration and theme are
copied to /run by a custom service before plymouth starts, so plymouth
can load the correct config from /run both during bootup and shutdown.
This commit changes the routine which resolves plymouth.defaults' path,
to have it look first in plymouth's runtime directory.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
When a theme is shipped exclusively in the initrd, plymouth will not be
able to load is if it starts the boot splash after the bootup process
already switched from the initrd. One way to make it work is to copy the
theme to plymouth's runtime directory in /run, which is preserved during
switch root.
This commit changes the routine which resolves a theme's path to have it
look first in themes/ under plymouth's runtime directory.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Michael Kuhn [Mon, 22 Aug 2016 19:54:18 +0000 (21:54 +0200)]
libply, main: Add device scale setting
This adds a DeviceScale setting to plymouthd.conf. It can be used to
override the device scale detection when setting the
PLYMOUTH_FORCE_SCALE environment variable is too complicated.
Ray Strode [Mon, 20 Jun 2016 15:06:49 +0000 (11:06 -0400)]
drm: don't pick up drm master implicitly
If a client opens the drm device, they're given drm master
implicitly. We already explicitly take DRM master when we need it,
so that featuer is unneeded.
Furthermore, it's actively harmful, since fbdev won't let you change
the color palette of the terminal if drm master is held.
This commit makes sure to drop master as soon as we get it from
open().
Daniel Drake [Thu, 16 Jun 2016 22:25:05 +0000 (15:25 -0700)]
device-manager: probe existing DRM devices at startup
A regression introduced in 7e37d58be3e9acff36c53c420b399c18d08bd8f8
means that we only look for DRM devices that appear while we're waiting,
we don't consider any that are already present before we started.
shutdown splash was not appearing because of this.
Solve this by explicitly searching for already-initialized DRM devices as
we start up.
projects / thirdparty / plymouth.git / log
