The keymap and capslock code in src/plugins/renderers/drm/plugin.c relies
on the terminal passed to backend_create() to get the keymap and current
capslock state (when not using evdev input because of e.g. no XKBLAYOUT
in /etc/vconsole.conf which is the default in at least Fedora).
When 2 GPUs which both have displays attached are used only the first
one gets passed the local_console_terminal as terminal (it is considered
the terminal owner and e.g. listens for keypresses). This leads to keymap
and capslock icons not being shown on displays attached to the second GPU.
To fix this add a second ply_terminal_t argument to backend_create() called
local_console_terminal, which will pass the local_console_terminal to both
drm plugin instances. And modify the drm plugin capslock and keymap code to
use this instead of the normal terminal argument which will be NULL on
the second GPU.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2375854
Signed-off-by: Hans de Goede <hansg@kernel.org>
Add a UseSimpledrmNoLuks config file keyword this enables simpledrm use,
like the existing "UseSimpledrm" config file keyword. Except when using
LUKS. Showing the LUKS unlock screen using simpledrm has 2 problems:
1. If the GPU drivers are built into the initrd then typically the
unlock screen will briefly show and then the screen goes black
2. The i915 driver uses the firmware framebuffer as fallback when
userspace has not installed a fb to scan out from. This happens
e.g. on logout between the user-session and the display-manager.
Drawing the unlock screen on the simpledrm fb results in it briefly
showing when logging out, which looks quite ugly.
This allows distributions to chose to only enable simpledrm when
LUKS is not used.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2359283
Signed-off-by: Hans de Goede <hansg@kernel.org>
The drm plugin code installs a fd disconnect handler for the terminal fd
which simply calls open_input_source () again.
This assumes that the ply-terminal code's disconnect handler has run first
(which it should) and that ply_terminal_reopen_device () has successfully
re-opened the terminal. This last condition is not always true, resulting
in open_input_source () calling ply_event_loop_watch_fd () with a -1 fd
triggerig an assert in ply_event_loop_watch_fd ():
5 0x00007f62d39a1c6f in __assert_fail (assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=<optimized out>) at assert.c:127
6 0x00007f62d3bc22c7 in ply_event_loop_watch_fd (loop=<optimized out>, fd=-1, status=status@entry=PLY_EVENT_LOOP_FD_STATUS_HAS_DATA,
status_met_handler=status_met_handler@entry=0x7f62d3790870 <on_terminal_key_event>,
disconnected_handler=disconnected_handler@entry=0x7f62d3790c70 <on_input_source_disconnected>, user_data=user_data@entry=0x5647f7dd9fb8)
at ../src/libply/ply-event-loop.c:732
7 0x00007f62d3790bf6 in open_input_source (backend=0x5647f7dd9f90, input_source=0x5647f7dd9fb8) at ../src/plugins/renderers/drm/plugin.c:1930
8 0x00007f62d3bcbd53 in ply_event_loop_handle_disconnect_for_source (loop=<optimized out>, source=0x5647f7dd69f0) at ../src/libply/ply-event-loop.c:1065
9 ply_event_loop_disconnect_source (loop=<optimized out>, source=0x5647f7dd69f0) at ../src/libply/ply-event-loop.c:1157
10 ply_event_loop_process_pending_events (loop=0x5647f7dd13e0) at ../src/libply/ply-event-loop.c:1277
11 0x00007f62d3bcc068 in ply_event_loop_run (loop=0x5647f7dd13e0) at ../src/libply/ply-event-loop.c:1311
12 0x00005647c99bba48 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:2572
Fix this by checking that the fd >= 0 before calling
ply_event_loop_watch_fd ().
The above backtrace is from the drm plugin, but the same problem exists
in the frame-buffer plugin. So this fix is applied to both.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2370979
Signed-off-by: Hans de Goede <hansg@kernel.org>
Two-step's disk unlock screen shows the prompt text directly below
the text entry field without any padding which looks bad.
Add some padding to make things look better.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2356893
Signed-off-by: Hans de Goede <hansg@kernel.org>
When asked for e.g. a disk unlock passphrase, plymouth will be passed
a prompt like: "Please enter passphrase for disk $DISK:" the ':' in
the end makes sense when asking for this a text console, but this makes
less sense in the two-step disk unlock screen where the text is below
the passphrase entry field.
Strip any ':' char at the prompt's end on two-step's disk unlock screen.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2356893
Signed-off-by: Hans de Goede <hansg@kernel.org>
In order for the fallback path (keymap_icon->has_prerendered_text == false)
to work properly keymap_icon->keymap_name must be set when no pre-rendered
text is found.
Tested by temporarily removing the "us" entry from ply-keymap-metadata.h.
Signed-off-by: Hans de Goede <hansg@kernel.org>
For devicetree based systems simpledrm might know the actual physical
display dimensions. Test if the reported connector width and height
result in a pixel density larger than 96 DPI. If that's the case
calculate the device scale instead of guessing it based on the
resolution.
This restores HiDPI scaling on 13-inch Apple silicon Macbooks with a
resolution of 2560x1600 (224 - 227 DPI) after commit 1421a9f6
("ply-utils: Increase threshold for guessed hiDPI scaling
to >= 2880x1620").
Signed-off-by: Janne Grunau <j@jannau.net>
This matches mutter's behaviour before
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3616 was merged.
It first rounded to the newest fractional scale factor (in 0.25 steps)
and then rounded N.25 and N.5 down to N and N.75 up to N+1.
Commit 3b8e9184 ("ply-utils: Only choose scale 2 when the perfect scale
would be >= 1.75") interprets the mentioned difference of at most 0.25
for rounding up very literal. A differnt ionterpretation of
d03dce4378
intend is that it's desireable to round N.5 down.
This change has unexpected side effect of using a device scale of 1 for
most of Apple's Retina displays in Macbooks (221 - 227 DPI). Raised as
https://gitlab.gnome.org/GNOME/mutter/-/issues/4110 in mutter.
Using 1.75f cut-off value requires a pixel density of 236.25 for HiDPI
while 1.625f requires only 219.375 DPI.
Mutter use the same calculation with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4490 merged.
Signed-off-by: Janne Grunau <j@jannau.net>
According to ECMA-48 [1], Select Graphic Rendition (SGR) attribute 21
is for "doubly underlined", not "disabling bold" in current plymouth
implementation.
Additionally, SGR 22 is for "normal colour or normal intensity (neither
bold nor faint)", both bold and dim should be disabled with it.
[1] 8.3.117, https://www.ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf
Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com>
Currently plymouth applies Select Graphic Rendition (SGR) attribute 21
to disable bold text. However, per ECMA-48 [1], this attribute is for
doubly underlined text, not for disabling bold, resulting unintended
doubly underlined output on boot. Fix it by conditionally applying
standard bold attribute (SGR 1) on bold text.
[1] 8.3.117, https://www.ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf
Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com>
handle_ksmg_message wrongly assumed that all messages are terminated
with a trailing line feed: kernel messages emitted by pr_cont() may
not. At any rate, the return value of the strchr() call ought to be
checked to avoid crashing when parsing incoming messages.
Closes#303
