Hans de Goede [Sun, 26 May 2019 15:54:05 +0000 (17:54 +0200)]
drm: Fix tiled mode detection
The TILE property is present on all connectors which are DisplayPort
MST (Multi-Stream) outputs, independent if they are connected to a tiled
display are not.
Starting with the 5.2 kernel, it is actually present on almost all outputs.
Rather then just checking if the property is present, check that if it
is present it has a valid (non zero) blob-id assigned to it, this fixes
us mis-identifying DP MST outputs as always being tiled.
Which in turn fixes us failing to pick the preferred mode on these outputs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ZhaoQiang [Tue, 28 May 2019 14:49:41 +0000 (14:49 +0000)]
Translation: Update plymouth.pot's misc infomation
plymouth.pot is using old Bugzilla as issue discussing URL, update it to
Gitlab, and also correct other translation files which already been
traslated.
ZhaoQiang [Thu, 23 May 2019 19:24:55 +0000 (19:24 +0000)]
main.c: Deprecate gdm transition signal
plymouth used to create a file in /var to tell gdm to start in active vt,
but gdm don't use this file now. and create file in filesystem too early
will cause race problem when /var is a seperate partition or it's on an
lvm volume.
Hans de Goede [Mon, 25 Mar 2019 07:13:26 +0000 (08:13 +0100)]
themes: Update spinner and bgrt background settings
Update the spinner and bgrt themes background to solid black so that we get
the same background, independent of whether the firmware-splash (ACPI
BGRT extension) is available and to closer match the mock-ups from:
https://wiki.gnome.org/Design/OS/BootProgress
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 1 Mar 2019 16:22:30 +0000 (17:22 +0100)]
ply-pixel-buffer: Fix right and bottom edge rendering of scaled buffers
When scaling a buffer 2x and calling ply_pixels_interpolate to interpolate
the last row / column, the extra pixels used for pixels would go out of
bounds and be replaced with a black pixel. This causes a 50% dimming of the
last row / column.
This 50% dimming leads to an ugly darkline when a theme draws 2 images
which are supposed to be joined together.
This commit fixes this by clipping the coordinates to the source image
limits instead of using black pixels when interpolating right and bottom
edge pixels.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 26 Feb 2019 10:03:36 +0000 (11:03 +0100)]
Add support for translating the user visible strings in some themes
This commit adds initial translation support, for now translation support
is limited to the user visible strings in some splash plugins and themes,
the daemon and commandline utils output are left untranslated for now.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 26 Feb 2019 09:23:06 +0000 (10:23 +0100)]
Prefix Title and Subtitle theme config keywords with an underscore
Prefix Title and Subtitle theme config keywords with an underscore ('_')
so that "intltool-extract --type=gettext/ini" can be used to make the
title and subtitle translatable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 25 Feb 2019 15:47:13 +0000 (16:47 +0100)]
Add new reboot and system-upgrade modes
Some themes show certain text strings to the user depending on the mode,
see e.g. the shutdown vs reboot mockups of:
https://wiki.gnome.org/Design/OS/BootProgress
Besides during shutdown vs reboot, we also want different theming for
installing offline (security) updates versus doing an offline OS upgrade.
To make this possible this commit adds new reboot and system-upgrade
modes which can be specified either when starting plymouthd, or through
plymouth change-mode --<mode>.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 25 Feb 2019 14:45:26 +0000 (15:45 +0100)]
main: Remove private ply_mode_t
Remove the private ply_mode_t from main.c, this is a 1:1 mirror of
ply_boot_splash_mode_t, so use ply_boot_splash_mode_t directly, leading
to a nice cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 13 Feb 2019 14:10:23 +0000 (15:10 +0100)]
plymouthd.defaults: Change default ShowDelay to 0
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 16 Jan 2019 11:51:05 +0000 (12:51 +0100)]
ply-boot-splash: Do not add ply_boot_splash_update_progress timeout multiple times
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 16 Jan 2019 11:27:01 +0000 (12:27 +0100)]
logging: Minor log-message fixes
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 13 Feb 2019 13:39:42 +0000 (14:39 +0100)]
logging: Improve logging format
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 12 Feb 2019 14:15:26 +0000 (15:15 +0100)]
two-step: Add a per mode setting to suppress messages
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 8 Feb 2019 21:41:15 +0000 (22:41 +0100)]
two-step: Add progress-bar support
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/BootProgress
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 7 Feb 2019 16:44:32 +0000 (17:44 +0100)]
two-step: Add MessageBelowAnimation option
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 6 Feb 2019 09:34:56 +0000 (10:34 +0100)]
two-step: Add per mode settings
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 8 Feb 2019 13:38:44 +0000 (14:38 +0100)]
ply-progress-bar: Allow caller to specify the widgets width and height
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Fri, 8 Feb 2019 17:04:01 +0000 (18:04 +0100)]
ply-progress-bar: Redraw on percentage update
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 6 Feb 2019 10:48:55 +0000 (11:48 +0100)]
ply-label: Make sure get_width_of_control / get_height_of_control return correct values
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 14 Jan 2019 10:47:21 +0000 (11:47 +0100)]
ply-device-manager: Handle change events for monitor hotplugging
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.
Hans de Goede [Mon, 21 Jan 2019 14:41:37 +0000 (15:41 +0100)]
drm: Stop limiting preferred-mode picking to UEFI systems
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 17 Jan 2019 10:41:46 +0000 (11:41 +0100)]
drm: Reset mode on display-port connected outputs with a bad link-status
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 16 Jan 2019 13:50:34 +0000 (14:50 +0100)]
drm: Ensure heads are mapped before flushing them
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: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 15 Jan 2019 09:43:45 +0000 (10:43 +0100)]
drm: Allow calling create_heads_for_active_connectors multiple times
To support hotplugging monitors while plymouth is running, we must
rebuild our outputs list and create and/or remove heads as necessary
on every change event.
This commit adds support for removing single outputs (rather then
tearing down the whole backend) and adds a new first step to
create_heads_for_active_connectors which goes over our view of the
outputs before the change and removes any changed outputs from the
heads they belong to, destroying the head if the last output/connector
is removed.
On the first call backend->output_len is 0, so this new first step
is a no-op.
On subsequent calls we can simply build the list as we do on the first
call, changed outputs will already be removed by the new first step
and for unchanged outputs we end up in ply_renderer_head_add_connector
which will ignore the already added connector.
Note this drops the "couldn't connect monitor to existing head" message,
this is confusing when create_heads_for_active_connectors is called more
then once and is unnecessary as ply_renderer_head_add_connector already
logs a message on both failure exit paths.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 15 Jan 2019 08:21:05 +0000 (09:21 +0100)]
drm: Limit backend->resources lifetime to within query_device
We do not need / use backend->resources anywhere outside of the query_device
function and with the upcoming hotplug support we need to get a fresh set
of resources on change events, so limit the resources lifetime to
query_device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 15 Jan 2019 07:58:45 +0000 (08:58 +0100)]
drm: Store and keep all the outputs in the backend
Put all outputs in the outputs array instead of just the connected ones
and store the outputs array and the controller_id-to-head hashtable in the
backend object instead of temporarily allocating them during enumeration.
Also add new heads to the heads list and to the controller_id-to-head
hashtable in ply_renderer_head_new where this really belongs. This
allows nicely balancing these 2 with removing the head from the list
and hash_table in the ply_renderer_head_remove function which is added
in a follow-up commit.
This is a preparation patch for adding support for hotplugging
monitors while plymouth is running.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 15 Jan 2019 07:31:20 +0000 (08:31 +0100)]
drm: Stop storing a pointer to drmModeConnector in ply_output_t
This is a preparation patch for hotplug support, for hotplug support we
want to keep the ply_output_t for connectors around, this change decouples
the lifetime of the drmModeConnector from the ply_output_t lifetime.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 15 Jan 2019 06:31:32 +0000 (07:31 +0100)]
drm: Stop keeing a drmModeConnector instance around
Before this commit we were storing a pointer to the drmModeConnector
in struct _ply_renderer_head, solely so that we can free it when
destroying the head. This was necessary because we also stored a pointer
to the mode we picked, which comes from insided the drmModeConnector.
The drmModeModeInfo struct has no pointers, so we can simply store a copy
of it instead of a pointer, which removes the need to keep the
drmModeConnector around after probing the connectors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 14 Jan 2019 16:36:22 +0000 (17:36 +0100)]
drm: Refactor ply_renderer_head_add_connector and ply_renderer_head_new
Both these function take a bunch of info coming from the ply_output_t
struct and with upcoming changes they are going to be using even more
ply_output_t fields. Instead of passing all these fields one by one,
simply directly pass a pointer to ply_output_t.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 9 Jan 2019 13:52:33 +0000 (14:52 +0100)]
themes: spinner: Add watermark alignment settings
Add watermark alignment settings, so that distros can simply drop
a watermark.png into the theme dir from another package and then have it
show up in the right place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 9 Jan 2019 13:38:26 +0000 (14:38 +0100)]
plymouth-populate-initrd: Don't assume the ImageDir is the theme-dir
Before this commit plymouth-populate-initrd was only recursively copying the
/usr/share/plymouth/themes/$PLYMOUTH_THEME_NAME to the initrd, assuming
that ImageDir will point there.
This makes it impossible for 2 themes to share their ImageDir, which is
desirable for example for the spinner and bgrt themes, which use the same
images with slightly different settings.
This commit also makes plymouth-populate-initrd also copy the ImageDir
if it is different from the theme-dir, making it possible for ImageDir
to point to a different dir.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 19 Dec 2018 12:33:08 +0000 (13:33 +0100)]
two-step: Make clearing the dialog-background when using the firmware background optional
Since the ask-for-password or ask-question dialog and the firmware background
may intersect so far we've been clearing the screen to black when showing a
dialog and using the firmware background.
This is not always desirable, this commit adds a new
"DialogClearsFirmwareBackground" option to the two-step based theme config
file, which enables this behavior when set.
The new default is to keep using the initial (firmware) background when
showing a dialog, which matches the non firmware-background paths.
Also update the bgrt theme to use the "DialogClearsFirmwareBackground"
option, keeping the current behavior for that theme.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 19 Dec 2018 12:28:28 +0000 (13:28 +0100)]
two-step: Add support for non center alignment of the (diskcrypt) dialog
Add DialogHorizontalAlignment and DialogVerticalAlignment options which
allow placing the (diskcrypt) dialog aligned at another place then the
center of the screen.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Thu, 20 Dec 2018 11:47:39 +0000 (12:47 +0100)]
two-step: Rename UseBGRT to UseFirmwareBackground
Rename the UseBGRT theme configfile option to UseFirmwareBackground,
to make it clear what this does using language which most users will be
able to understand, rather then using the cryptic BGRT ACPI table reference.
While at it also switch to using the new ply_key_file_get_bool function, so
that users can edit an existing configfile with "UseFirmwareBackground=true"
in there and change it to "=false" and actually have that work as expected.
The switch to ply_key_file_get_bool also fixes a memleak as
ply_key_file_get_value returns a strdup-ed value which we were not free-ing.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 9 Jan 2019 10:31:06 +0000 (11:31 +0100)]
libply: Add ply_key_file_get_bool function
Add a function to read a boolean value from a ply-key-file.
This function will return true if the key exists and it has a value of "1",
"y", "yes" or "true" (case-insensitive). In all other cases it returns
false.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 19 Dec 2018 09:45:51 +0000 (10:45 +0100)]
two-step: Use plymouth_strtod
Use the locale agnostic plymouth_strtod helper which always uses a "."
as decimal seperator. This fixes the various Alignment options not working
with some locales.
While at it also add a ply_trace to log the size and chosen centering for
the watermark image.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sun, 9 Dec 2018 14:19:08 +0000 (14:19 +0000)]
Merge branch 'plugin-iface' into 'master'
When a renderer goes away on a udev remove event, free keyboards associated with the renderer, before freeing the renderer. This avoids a null pointer dereference when ply_device_manager_deactivate_keyboards gets called later on:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1794292
Hans de Goede [Tue, 27 Nov 2018 23:53:46 +0000 (00:53 +0100)]
drm: Pick a controller for unconfigured connectors
So far we've been relying on the kernel fbcon code to set up all outputs,
now that distros have started using deferred fbcon takeover for flickerfree
booting, we can no longer rely on this and in some cases we must pick
our own controllers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 27 Nov 2018 22:09:27 +0000 (23:09 +0100)]
drm: Store tiled and rotation in ply_output_t
This avoids the need to call ply_renderer_connector_get_rotation_and_tiled
twice and thus also the need to call drmModeGetProperty twice for all
properties.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 27 Nov 2018 18:50:33 +0000 (19:50 +0100)]
drm: Refactor create_heads_for_active_connectors
Refactor create_heads_for_active_connectors to prepare it for adding a
step where we assign controllers to connected outputs which do not have
a controller assigned yet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 13 Nov 2018 08:03:10 +0000 (09:03 +0100)]
two-step: bgrt: Deal with quirky firmwares
On laptops / tablets the LCD panel is typically brought up in
its native resolution, so we can trust the x- and y-offset values
provided by the firmware to be correct for a screen with the panels
resolution.
Moreover some laptop / tablet firmwares to do all kind of hacks wrt
the y-offset. This happens especially on devices where the panel is
mounted 90 degrees rotated, but also on other devices.
So on devices with an internal LCD panel, we prefer to use the firmware
provided offsets, to make sure we match its quirky behavior.
We check that the x-offset matches what we expect for the panel's
native resolution to make sure that the values are indeed for the
panel's native resolution and then we correct for any difference
between the (external) screen's and the panel's resolution.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 7 Nov 2018 19:27:08 +0000 (20:27 +0100)]
two-step: Speed up background-tile drawing on HiDPI screens
Before this commit background drawing on HiDPI screens is quite slow
and CPU intensive, because we do the interpolating scale, which does
a whole bunch of double-precision float operations for *each* pixel
for every frame we draw.
When using two-step with a background-tile on a Cherry Trail machine with
a HiDPI screen this results in the diskcrypt password entry being visible
laggy, I can type the password much faster then the bullets show up.
This also means we are pegging the CPU during boot, significantly slowing
down the boot.
This commit fixes this by creating the background_buffer at the screen's
device_scale and rotation, only doing the scaling once.
This commit further speeds things up by also doing the solid/gradient fill
of the background + the alpha blend of the tiled background-image once,
creating a solid background which allows us to hit the
ply_pixel_buffer_fill_with_buffer memcpy fast-path and avoids the need to
re-do the solid/gradient fill + alpha-blend each frame we render.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For some themes we want to use the firmware-logo / splash as background,
when the LCD panel of a laptop is mounted non-upright then the image which
we get from the firmware will be pre-rotated to match the LCD panel mount.
Until now our device-rotation support was limited to using rotated
pixel_buffer-s as destination / canvas only.
This commit adds a ply_pixel_buffer_rotate_upright helper to rotate
a nop-upright source buffer upright so that we can use it as source-buffer
to other functions which expect source-buffers to always be upright.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For some themes we want to use the firmware-logo / splash as background,
when the LCD panel of a laptop is mounted non-upright then the image which
we get from the firmware will be pre-rotated to match the LCD panel mount.
This commit adds ply_pixel_buffer_set/get_device_rotation helpers to
help deal with this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 7 Nov 2018 14:49:40 +0000 (15:49 +0100)]
ply-pixel-buffer: Fix fill_with_buffer fastpath when device_scale != 1
After calling ply_pixel_buffer_crop_area_to_clip_area cropped_area.x/y
are in device coordinates. So when calculating the x/y offset in the
source-buffer due to device-clip areas possible making cropped_area.x/y
larger then just the xoffset/yoffset (in the canvas) we must multiply
the original xoffset/yoffset by device_scale before subtracting.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Wed, 7 Nov 2018 11:24:12 +0000 (12:24 +0100)]
ply-renderer: Add ply_renderer_get_panel_properties function
For some themes we want to read the firmware-logo to use as background,
when the LCD panel of a laptop is mounted non-upright and/or if it is
using scaling because of HiDPI then the image which we get from the
firmware will be pre-rotated and scaled to match the LCD panel.
This new function will allow renderers to let themes know about this so
that they can adjust for the logo being pre-rotated and scaled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 5 Nov 2018 14:03:28 +0000 (15:03 +0100)]
ply-image: Do not assume all files are PNGs
So far the image loading code has been assuming that all files are PNGs,
this commit makes the code check the file-header before assuming the file
is a PNG.
This is a preparation patch for adding support for also being able to load
BMP files.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>