This is strongly implied in the command line help and man page.
While GNU date doesn't care about ordering, uutils (Rust) date does
enforce the ordering (in current releases). Use the ordering suggested
by date's own documentation and supported by all implementations.
It was fixed upstream this week:
https://github.com/uutils/coreutils/issues/10972https://github.com/uutils/coreutils/issues/10910
Some devices (phones/tablets) don't have keyboards, so this allows
specifying an additional key using a new config option
(XkbExtraEscButton) that works like Esc e.g. for hiding the splash.
The input device management functions (on_each_renderer_add_input_device,
add_input_device_to_renderers, on_each_input_device_add_to_renderer,
add_input_devices_to_renderer, on_each_input_device_remove_from_renderer,
remove_input_device_from_renderers) were placed inside the #ifdef HAVE_UDEV
block, but are called unconditionally from
create_devices_for_terminal_and_renderer_type(). This caused an
"implicit declaration" build error when udev support is disabled.
Move these functions outside the #ifdef HAVE_UDEV guard, and place the
genuinely udev-specific functions (drm_device_in_use,
fb_device_has_drm_device) into their own #ifdef HAVE_UDEV block.
Plymouth was skipping all input devices when no XKB layout was configured.
Passing NULL to xkb_keymap_new_from_names to lets libxkbcommon use
its own defaults, so input devices are used regardless of whether
the system has a keyboard layout configured in vconsole.conf.
It's possible for a read from the terminal to provide a partial command
sequence, starting with the CSI ('\x1b\x5b') but not terminating with
its function character ('\x40'..'\x7e'). In that case, the input byte
handling loop would not terminate, causing plymouthd to hang both itself
and possibly completion of the boot.
Break from the input byte handling loop when an incomplete command
sequence is found so that the program does not hang. The incomplete
command sequence will remain in the input buffer so that a later
completion of the command sequence can be handled.
Fixes: b41e40e065 ("Add support for CSI sequences")
Fixes: plymouth/plymouth#321
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2433079
Currently translated at 100.0% (8 of 8 strings)
Translated using Weblate (Estonian)
Currently translated at 100.0% (8 of 8 strings)
Translated using Weblate (Estonian)
Currently translated at 100.0% (8 of 8 strings)
Co-authored-by: Weblate Translation Memory <noreply-mt-weblate-translation-memory@weblate.org>
Translate-URL: https://translate.fedoraproject.org/projects/plymouth/master/et/
Translation: plymouth/main
On hidpi screens, label-freetype will trigger a use-after-free in
set_font_for_control() via the call in update_scale_factor_from_pixel_buffer().
That call passes label->font as the font parameter to set_font_for_control().
set_font_for_control() then calls strdup() on its font argument, and
frees label->font. In this case this causes font to point into freed
memory, causing a read use-after-free in the following strstr() and
strrchr() calls.
Fix the issue by only using the freshly strdup()'d new_font variable
after freeing label->font.
When multiple displays of different resolutions are attached, the Plymouth script
plugin uses a virtual "max canvas" (defined by max_width and max_height) for
rendering. Individual displays calculate their offsets (display->x, display->y)
relative to this max canvas for mirroring/centering.
The script-level centering formula, as seen in example themes:
logo.sprite.SetX (Window.GetX() + Window.GetWidth() / 2 - logo.image.GetWidth() / 2);
Issue:
For the script to correctly calculate the absolute center position on the max canvas,
Window.GetX() must conceptually return the origin of the max canvas, which is 0.
However, the non-indexed implementation of sprite_window_get_x (and GetY) currently
returns the maximum calculated display offset (MAX(display->x)), which corresponds to
the offset of the smallest display. This incorrect, non-zero return value introduces
an unintended shift, pushing sprites (like the logo) off-center, and breaking the
centering logic.
Solution:
Update sprite_window_get_x and sprite_window_get_y to return the minimum calculated
display offset (MIN(display->x)). Since the largest display always has an offset of 0,
this guarantees that Window.GetX() and Window.GetY() return 0 when called without
parameters, correctly anchoring the script-calculated center position to the absolute
max canvas origin.
Signed-off-by: xinpeng.wang <wangxinpeng@uniontech.com>
