We're going to need to do at least basic parsing of terminal text
so we can show the console to the user in color when they hit
escape and VTs are disabled.
This commit adds the start of a class to do this basic parsing.
The way it works is the terminal text is inject into the object
and all escape sequences are filtered out. When a color control
sequence is found, the current color is noted, along with which
characters it applies to. A list of the text spans and their
color attributes is then iteratable using a an api.
- Fix script plugin to handle monitor hotplug events
- Expose Plymouth.SetDisplayHotplugFunction to set script callback
after display hotplug
fixes#186
The node pointer is reused in the if (data->full_refresh) block
causing the following sprite list walking to fail. Fix this by
moving the sprite list first node getting next to the while loop
where it belongs.
When a lock modifier is pressed, plymouth goes through some gymnastics
to ensure the LEDs on all attached keyboards are appropriately updated.
Unfortunately, an optimization in the code used to avoid redundant
updates of keyboards that already have the correct state is actually
preventing the initiating keyboard from getting its LEDs turned on.
This is because the initiating keyboard gets its state updated at
key press time before the LED handling code runs, thus making it
seem like that run is redundant.
This commit introduces a new state variable `leds_state_invalid`
on the input device to mark this situation and updates the optimization
check to also check the new variable.
Some contributions by Ray Strode.
It seems like specifying -rdynamic in meson cflags doesn't work
on some systems, but meson has a built in way of doing the same
thing:
export_dynamic: true
This commit switches over to the probably more right way of
achieving a working dlopen(NULL).
Commit 7fcfcdf2d63025151a160f7948ee7406f0f16843 tried to fall back to
reading from a tty if no xkb layout was specified, but neglected to
actually check if no xkb layout was specified and force fall back to
reading from a tty in that case.
This commit changes device manager to actually disable reading from
/dev/input if the user doesn't specify a layout to use in vconsole.conf.
Closes https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/199
At the moment if a user doesn't specify a xkb layout in vconsole.conf we
just fall back to assuming a us qwerty layout.
This isn't really optimal, since it might not match the keyboard.
Furthermore, the tty does have a usable layout, so it makes more sense
to fall back to it.
This commit changes device manager to disable reading from /dev/input
if the user doesn't specify a layout to use in vconsole.conf.
Close https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/199
Right now if there are two graphics cards, there ends up with two
renderers active at the same time. Both process keyboard inputs
and both end up sending those events to plymouthd, resulting in
duplicate input.
This commit changes the input handlers so the first one wins, and
the rest don't get input.
Closes https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/197
This commit adds a way for instance handlers to say "My handler
completed things, don't run any other handlers".
It does that by adding a boolean return value to the handler type
and making the callers return true for done.
Note, this commit doesn't update the callers to use the new api,
so it's sort of leaving things in a broken state.
The next commit will update the callers.
plymouthd may not be able to show the splash screen as soon as the
boot process wants it shown (if e.g. the driver isn't fully loaded
yet)
In that case, we sit tight and wait. Unfortunately, we aren't
logging boot messages while waiting.
This commit sets KD_GRAPHICS mode early to hide text from hitting
the console, but still tells systemd to print messages. This way
we get boot logging but don't display the text while we wait on
the splash.
Now that the core plymouth code supports /dev/input, the renderer
plugins need to support it as well.
As a first step, this commit adds such support to the drm renderer
plugin.
Some contributions by n3rdopolis and Ray Strode.
Plymouth currently gets keyboard input from the terminal. This isn't
ideal, since it means plymouth requires VTs to be enabled in the kernel.
Furthermore, most display servers use /dev/input and libxkbcommon for
keyboard handling these days.
This commit adds similar support to the plymouth core code. Subsequent
commits will add support to the render plugins.
Some contributions by n3rdopolis and Ray Strode.
At the moment the keyboard-render script only generates short
names for console layouts.
We're going to add /dev/input support to plymouth using
libxkbcommon, so we're going to need a list of of those keymaps
too.
This commit adds that.
Some contributions by n3rdopolis and Ray Strode.
At the moment we ignore any udev events that come in before the
device timeout that are not drm devices.
That is because we don't want to use framebuffer devices as anything
but a last resort fallback option.
In the near future we're going to be handling input events from udev
as well. Those will obviously need to be handled right away, just like
drm devices.
This commit makes the check only defer framebuffer devices and not
anything that isn't a drm device.
strcmp is kind of a confusing function in that it returns
non-zero when the strings are not equal. That is
especially counterintuitive when this non-zero value is
treated as a TRUE boolean.
This commit just adds some != 0's to a couple of strcmp
calls for clarity.
Right now callers of ply_buffer_append_bytes have to be
very careful to make sure the data they're appending is
non-zero in length. This is kind of inconvenient, since
it's not unusual for data to come in that's zero bytes
long.
For simplicity, this commit just makes
ply_buffer_append_bytes support that use case.
In the future we're going to start reading keyboard input from
/dev/input instead of the tty. When that happens, input will
still be sent by the kernel to the tty.
This input would eventually back up and overflow.
To address that problem before it exists, this commit adds a new
API, ply_terminal_flush_input, that will drain the input buffer
on demand.
We can later use that API to keep the tty from backing up.
Right now triggers can only fire off handlers that have one piece
of data associated with them, but sometimes it's useful to have
an object associated with the data too.
This commit adds new api for adding "instance handlers" that have
an additional parameter and a new method `ply_trigger_set_instance`
that allows an object to be associated with the trigger and get
used for the additional parameter of the instance handlers.
At the moment, iterating over a ply_list_t requires an an
ugly looking for loop.
This commit adds a little sugar in the form of a
ply_list_foreach macro in the name of convenience.
Apparently the:
[x] Squash commits
box was checked when merge request plymouth/plymouth!177 was merged.
Oops.
We want good commit messages for such a big change, though, so people
doing code spelunking later have a fighting chance of following what's
going on.
This reverts commit dacfb36b57.
Subsequents commits will bring it back, peicemeal.
We thought we could get away with a NULL local_console_terminal
when the terminal isn't a VT, but it turns out we need it for
various reasons anyway.
This commit just makes sure we keep it in place.
At the moment, plymouth requires VT support be enabled in the kernel
to show graphical splashes.
This is because:
1. it relies on the tty to show details
2. when VT support is disabled the kernel will use ttyS0 as the default
console which makes plymouth disable graphical splashes since it assumes
the machine is a server with a serial console.
This commit addresses the first problem by disabling the
escape-to-toggle-details feature and addresses the second problem by
introducing a new kernel parameter plymouth.graphical that is like
the "splash" option and "plymouth.ignore-serial-consoles" option
combined.
