lp:plymouth

Created by Scott James Remnant (Canonical) on 2009-11-17 and last modified on 2018-07-10
Get this branch:
bzr branch lp:plymouth

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Plymouth Developers
Project:
Plymouth
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://anongit.freedesktop.org/plymouth.

The next import is scheduled to run in 1 hour.

Last successful import was 4 hours ago.

Import started 4 hours ago on alnitak and finished 4 hours ago taking 20 seconds — see the log
Import started 10 hours ago on izar and finished 10 hours ago taking 15 seconds — see the log
Import started 16 hours ago on alnitak and finished 16 hours ago taking 20 seconds — see the log
Import started 22 hours ago on izar and finished 22 hours ago taking 15 seconds — see the log
Import started on 2018-07-22 on alnitak and finished on 2018-07-22 taking 20 seconds — see the log
Import started on 2018-07-22 on izar and finished on 2018-07-22 taking 15 seconds — see the log
Import started on 2018-07-21 on izar and finished on 2018-07-21 taking 20 seconds — see the log
Import started on 2018-07-21 on alnitak and finished on 2018-07-21 taking 20 seconds — see the log
Import started on 2018-07-21 on izar and finished on 2018-07-21 taking 15 seconds — see the log
Import started on 2018-07-21 on alnitak and finished on 2018-07-21 taking 15 seconds — see the log

Recent revisions

1856. By Ray Strode <email address hidden> on 2018-07-10

main: fix build

I slightly modified Hans patch in commit 129b4a50 before pushing it
and broke the build.

This fixes the build by adding a forward declaration.

1855. By Hans de Goede <email address hidden> on 2018-07-10

Fix miscellaneous compiler warnings

Fix all compiler warnings (and one type) except for the deprectation warnings
for the gdk_screen_get_monitor_* functions used in the x11 renderer.

Signed-off-by: Hans de Goede <email address hidden>

1854. By Hans de Goede <email address hidden> on 2018-07-10

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 <email address hidden>

1853. By Hans de Goede <email address hidden> on 2018-07-10

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 <email address hidden>

1852. By Hans de Goede <email address hidden> on 2018-07-10

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 <email address hidden>

1851. By Hans de Goede <email address hidden> on 2018-07-10

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 <email address hidden>

1850. By Hans de Goede <email address hidden> on 2018-07-10

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 <email address hidden>

https://bugs.freedesktop.org/show_bug.cgi?id=107047

1849. By Hans de Goede <email address hidden> on 2018-06-29

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 <email address hidden>

https://bugs.freedesktop.org/show_bug.cgi?id=107047

1848. By Hans de Goede <email address hidden> on 2018-06-29

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 <email address hidden>

https://bugs.freedesktop.org/show_bug.cgi?id=107047

1847. By Adam Williamson on 2018-06-07

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.

http://bugzilla.redhat.com/1518464

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.