1. 11 Nov, 2018 1 commit
  2. 08 Nov, 2018 1 commit
  3. 05 Nov, 2018 1 commit
  4. 31 Oct, 2018 5 commits
  5. 26 Oct, 2018 2 commits
  6. 16 Oct, 2018 7 commits
  7. 10 Oct, 2018 2 commits
  8. 27 Aug, 2018 2 commits
  9. 07 Aug, 2018 2 commits
  10. 06 Aug, 2018 1 commit
  11. 10 Jul, 2018 8 commits
    • Ray Strode's avatar
      two-step: add unhandled splash mode case to switch · f151b22e
      Ray Strode authored
      This fixes a compiler warning.
      f151b22e
    • Ray Strode's avatar
      main: fix build · 75ef8ee2
      Ray Strode authored
      I slightly modified Hans patch in commit 129b4a50 before pushing it
      and broke the build.
      
      This fixes the build by adding a forward declaration.
      75ef8ee2
    • Hans de Goede's avatar
      Fix miscellaneous compiler warnings · b145b25d
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      b145b25d
    • Hans de Goede's avatar
      configure: Pass -Wno-cast-function-type if available · 7fdfeecd
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      7fdfeecd
    • Hans de Goede's avatar
      main: Fix getting detailed logs from systemd · 6a1fdabf
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      6a1fdabf
    • Hans de Goede's avatar
      main: Show details when ESC is pressed during splash_delay · 129b4a50
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      129b4a50
    • Hans de Goede's avatar
      drm: Remove unnecessary reset_scan_out_buffer_if_needed() call from ply_renderer_head_map() · b527834c
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      b527834c
    • Hans de Goede's avatar
      main: Only activate renderers if the splash uses pixel-displays · 447c7830
      Hans de Goede authored
      Since commit eb147e52 ("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: default avatarHans de Goede <hdegoede@redhat.com>
      
      https://bugs.freedesktop.org/show_bug.cgi?id=107047
      447c7830
  12. 29 Jun, 2018 2 commits
  13. 07 Jun, 2018 1 commit
    • Adam Williamson's avatar
      device-manager: skip graphical renderer setup when details forced · 014c2158
      Adam Williamson authored
      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
      014c2158
  14. 06 Jun, 2018 1 commit
    • ZhaoQiang's avatar
      docs: fix some typos · 179ba1e0
      ZhaoQiang authored
      There are few word spelling errors in the documentation.
      
      This commit addresses those problems.
      179ba1e0
  15. 31 May, 2018 4 commits