1. 25 Mar, 2019 3 commits
  2. 04 Mar, 2019 4 commits
  3. 26 Feb, 2019 4 commits
  4. 25 Feb, 2019 2 commits
  5. 23 Feb, 2019 18 commits
    • Hans de Goede's avatar
      Merge branch 'default-showdelay0' into 'master' · dbb0d768
      Hans de Goede authored
      plymouthd.defaults: Change default ShowDelay to 0
      
      Closes #64
      
      See merge request plymouth/plymouth!26
      dbb0d768
    • Hans de Goede's avatar
      plymouthd.defaults: Change default ShowDelay to 0 · 1de27947
      Hans de Goede authored
      ShowDelay was added with as goal to reduce the number of jarring /
      flickering visual transitions.
      
      The idea being that if a system boots within 5 seconds, we would avoid
      the transition from a black screen to plymouth, instead directly going
      to e.g. gdm.
      
      In practive most modern systems (with SSD) take about 4-7 seconds to
      boot, this causes plymouth to only show briefly (aprox. 1 second).
      
      IOW on some modern systems it quicky flashes by, this "flash" is the end
      result of the ShowDelay=5 default which is intended to *reduce* the number
      of jarring / flickering visual transitions.
      
      On older systems the boot will likely take significantly longer then the
      5 seconds, so we will show the splash anyways and we might as well show
      it right away, so that the user can see something is happening right away.
      
      Note this has been discussed in more detail in issue #64, which also
      contains an alternative much more involved fix for the issues surrounding
      SplashDelay, but simply defaulting it to 0 seems to be best.
      
      Closes #64
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      1de27947
    • Hans de Goede's avatar
      Merge branch 'misc-fixes2' into 'master' · 4d2377f7
      Hans de Goede authored
      Misc fixes
      
      See merge request plymouth/plymouth!25
      4d2377f7
    • Hans de Goede's avatar
      ply-boot-splash: Do not add ply_boot_splash_update_progress timeout multiple times · a1920e8a
      Hans de Goede authored
      Before this commit when freeing the splash, the following would be logged:
      
      multiple matching timeouts found for removal
      multiple matching timeouts found for removal
      
      This is caused by us adding the ply_boot_splash_update_progress timeout
      handler to the event loop 3 times: 1 on first show, 2 on second show with
      a different mode, 3 on becoming idle.
      
      This commit fixes the 2nd add by stopping the timer when changing modes
      and the 3th add by not calling ply_boot_splash_update_progress to update
      the progress, as that will re-add itself. Instead this commit directly calls
      plugin_interface->on_boot_progress from ply_boot_splash_become_idle.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      a1920e8a
    • Hans de Goede's avatar
      logging: Minor log-message fixes · d0e26e24
      Hans de Goede authored
      This fixes 2 minor issues with our log-messages:
      1. ply_trace adds a "\n" itself, so there is no need to pass one extra.
      2. Correct spelling of quitting
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      d0e26e24
    • Hans de Goede's avatar
      logging: Improve logging format · 238e22b6
      Hans de Goede authored
      This commit adds 2 improvemens to the ply_trace logging format:
      
      1) It prefixes the log messages with timestamps (since system boot)
      
      2) Previously function-names where right aligned / left padded to 45
      characters. But they were prefixed with a [file:line] prefix which does
      not have a fixed width, making the column aligment for the actual messages
      fail resulting in hard to read logs.
      
      This commit fixes 2. by printing "<timestamp> file:line:func" to a
      prefix-buffer and then left-aligning / right padding this prefix buffer
      to 75 chars.
      
      The resulting logged lines now look like this:
      
      00:00:01.741 main.c:1928:check_logging                                     : checking if console messages should be redirected and logged
      00:00:01.741 main.c:1937:check_logging                                     : logging will be enabled!
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      238e22b6
    • Hans de Goede's avatar
      Merge branch 'offline-updates' into 'master' · 3d192d5c
      Hans de Goede authored
      Improved offline updates theme support
      
      See merge request plymouth/plymouth!24
      3d192d5c
    • Hans de Goede's avatar
      themes: Update spinner and bgrt theme offline updates mode · 38771c16
      Hans de Goede authored
      Make the spinner and bgrt offline updates mode match the GNOME design
      mockups from: https://wiki.gnome.org/Design/OS/BootProgressSigned-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      38771c16
    • Hans de Goede's avatar
      two-step: Add a per mode setting to suppress messages · 73a44fb1
      Hans de Goede authored
      The messages passed to plymouth display-message can be quite verbose, esp.
      in the offline-updates case. Combined with some themes now showing their
      own prominent title message explaining what is going on this leads to
      undesirable repetitive text being shown.
      
      This commit adds support for a per mode SuppressMessages setting which
      allows themes to suppress messages passed to plymouth display-message
      on a per mode basis.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      73a44fb1
    • Hans de Goede's avatar
      two-step: Add progress-bar support · 746a924c
      Hans de Goede authored
      Some themes may want to use a progress-bar instead of the throbber for
      some modes. This commit adds a new per mode UseProgressBar setting allowing
      this.
      
      One case where this will be used is the offline updates splash-screen
      mockup from: https://wiki.gnome.org/Design/OS/BootProgressSigned-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      746a924c
    • Hans de Goede's avatar
      two-step: Add MessageBelowAnimation option · c5d7b61d
      Hans de Goede authored
      So far we've always printed messages coming from "plymouth display-message"
      in the top left corner. In some cases the theme may want to instead display
      the messages below the animation (where they are more prominently visible).
      
      My first attempt to support this added MessageHorizontal/VerticalAlignment
      options. That did not work since we want a more or less fixed distance
      between the animation bottom and the message and with screen-heights varying
      from 480 to 1200 that is not possible using alignment options to place both
      the animation and the message.
      
      Note the default is unchanged and still is the top left corner.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      c5d7b61d
    • Hans de Goede's avatar
      two-step: Add support for specifying a title and sub-title in the theme file · 2b7bad86
      Hans de Goede authored
      The idea behind this is to allow a splash-screen containing something like this:
      
                  <TITLE FONT>Installing updates...</TITLE FONT>
      
                          Do not turn off your computer
      
                            /-----------------------\
                            |Animation / progres-bar|
                            \-----------------------/
      
      As can be seen in the mockups here:
      https://wiki.gnome.org/Design/OS/BootProgressSigned-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      2b7bad86
    • Hans de Goede's avatar
      two-step: Add per mode settings · 9bfffa92
      Hans de Goede authored
      We want theme files to be able to specify different settings for
      different modes ("boot-up" / "shutdown" / "updates"). Specifically we
      want themes to be able to specify a text for (offline) updates mode to
      tell the user what is going on, see the mockups at:
      https://wiki.gnome.org/Design/OS/BootProgress
      
      This commit adds support for per mode settings to the two-step plugins
      and for starters moves the UseFirmwareBackground setting there, since we
      don't want to show the firmware-background when showing the help-text.
      
      Follow-up commits will add support for specifying the (optional) per mode
      text to show, note eventually we will need to make these texts translatable.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      9bfffa92
    • Hans de Goede's avatar
      two-step: Drop background_is_bgrt view_t member · 3854d005
      Hans de Goede authored
      This is always set to true if plugin->background_bgrt_image is set, so
      we can simply check for plugin->background_bgrt_image instead.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      3854d005
    • Hans de Goede's avatar
      ply-progress-bar: Allow caller to specify the widgets width and height · e33c1f3a
      Hans de Goede authored
      Before this commit ply_progress_bar_show would take coordinates for where
      to show the progress-bar but the width and height were hardcodec. This
      commit adds width and height parametes, so that the caller can specify
      the width and height too.
      
      This commit does not change behavior for existing users (tested with the
      spinfinity theme).
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      e33c1f3a
    • Hans de Goede's avatar
      ply-progress-bar: Allow choosing fore- and back-ground color · 78bb39da
      Hans de Goede authored
      Allow choosing a fore- and back-ground color instead of hardcoding
      the foreground to white and the background to transparent.
      
      This commit does not change behavior for existing users (tested with the
      spinfinity theme).
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      78bb39da
    • Hans de Goede's avatar
      ply-progress-bar: Redraw on percentage update · ebf60f70
      Hans de Goede authored
      All the other plymouth widgets do a (re)draw when one of their
      properties get updated. Make ply-progress-bar also do this, this allows
      dropping the draw calls directly after the 2 current callers of
      ply_progress_bar_set_percent_done.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      ebf60f70
    • Hans de Goede's avatar
      ply-label: Make sure get_width_of_control / get_height_of_control return correct values · dfa1dcc6
      Hans de Goede authored
      Users of ply_label may want to know the height / width of the text before
      calling ply_label_show, so that they can e.g. vertically align it.
      
      This commit adds a size_needs_update bool to the label plugin and uses this
      to check if executing size_control is necessary before returning the
      width / height and also modifies the ply-label code to load the plugin
      from its get_width / get_height methods.
      
      As an added advantage this will also skip unnecessary size_control calls
      when calling ply_label_show on an already visible label.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      dfa1dcc6
  6. 18 Feb, 2019 2 commits
  7. 25 Jan, 2019 1 commit
  8. 21 Jan, 2019 3 commits
    • Hans de Goede's avatar
      ply-device-manager: Handle change events for monitor hotplugging · e54f6a47
      Hans de Goede authored
      Not only handle add but also change events for drm-subsys devices,
      change events are generated when the hardware detect a new monitor
      has been plugged in.
      
      This is esp. important with modern DisplayPort MST docking stations where
      discovery / enumeration can take so long that the connected displays
      are not enumerated by the kernel yet when the drm plugin first calls
      drmModeGetResources(). Causing the monitors on these docks to sometimes
      not show plymouth during boot (based on various timing parameters).
      
      Note that if during the add event drm-renderer could not be bound, this
      commit tries to re-bind the DRM renderer on change events in case a
      monitor got plugged into a GPU which did not have anything connected before.
      This often happens with the second GPU in a laptop with a hybrid GPU setup.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1652279Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      e54f6a47
    • Hans de Goede's avatar
      ply-device-manager: Consume all events in one go · f9e37679
      Hans de Goede authored
      Drm devices generate a bunch of add and change events when the kms
      driver loads, consume these all in one go.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      f9e37679
    • Hans de Goede's avatar
      drm: Stop limiting preferred-mode picking to UEFI systems · ccdb1d1f
      Hans de Goede authored
      When the code to pick the preferred-mode for outputs was first added, it
      was limited to UEFI systems, since it was necessary there.
      
      It was not enabled everywhere right away because there were some worries
      it might cause regressions.
      
      We've been shipping this for a while now and no regressions have been
      reported, moreover with the new hotplug support we really want to pick the
      preferred-mode rather then falling back to the first mode in the list.
      
      Therefor this commits removes the check for UEFI systems from
      should_use_preferred_mode().
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      ccdb1d1f
  9. 17 Jan, 2019 1 commit
    • Hans de Goede's avatar
      drm: Reset mode on display-port connected outputs with a bad link-status · c54870fc
      Hans de Goede authored
      With Display-Port links, esp. with DP MST links we may need to reset the
      mode if the kernel decides to retrain the link.
      
      If the kernel has retrained the link, the list of available modes may
      have changed. If it changed and the mode we picked is no longer available
      because of this, we treat this as an unplug + replug.
      
      Since we may want to set another mode, the kernel does not automatically
      restore the previous mode. So in case the mode did not change we need to
      do an explicit mode-set.
      
      This commits adds support for this, by:
      
      1) Adding a scan_out_buffer_needs_reset member to ply_renderer_head
      2) Storing the link-status when going over the connector properties
      3) Checking the link-status when adding a connector to a head and setting
         the scan_out_buffer_needs_reset flag when the link-status is bad
      
      This commit also makes ply_renderer_head_map set
      scan_out_buffer_needs_reset, avoiding an unnecessary round-trip to the
      kernel in the first reset_scan_out_buffer_if_needed call.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      c54870fc
  10. 16 Jan, 2019 2 commits
    • Hans de Goede's avatar
      drm: Implement handle_change_event · 15ebdd6d
      Hans de Goede authored
      Now that we can call create_heads_for_active_connectors multiple times
      we can implement handle_change_event.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      15ebdd6d
    • Hans de Goede's avatar
      drm: Ensure heads are mapped before flushing them · 475a51d0
      Hans de Goede authored
      The drm plugin's map_to_device function will return true if mapping of
      any of the heads has succeeded, potentially leaving some heads unmapped.
      
      This causes the "assert (buffer != NULL)" in begin_flush to trigger when
      flushing the heads as head->scan_out_buffer_id is 0.
      
      It seems that even though this is a pre-existing problem we sofar have
      not hit this, likely because ply_renderer_head_map in pratice never fails.
      
      However with the new monitor hotplug support, a head may be added after
      map_to_device is called, triggering the assert.
      
      This commit fixes both the theoretical pre-existing problem and the
      actual problem triggered by hotplug support by ensuring that the head
      is mapped before flushing it.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      475a51d0