We should call ply_label_show any time we have a message
to show, so that if the root filesystem gets mounted, we
can try to load the label plugin again.
This should prevent weird situations where the text shows up
invisible unless the user hits escape twice.
http://bugs.freedesktop.org/show_bug.cgi?id=55669
We should call ply_label_show any time we have a message
to show, so that if the root filesystem gets mounted, we
can try to load the label plugin again.
This should prevent weird situations where the text shows up
invisible unless the user hits escape twice.
http://bugs.freedesktop.org/show_bug.cgi?id=55669
We should call ply_label_show any time we have a message
to show, so that if the root filesystem gets mounted, we
can try to load the label plugin again.
This should prevent weird situations where the text shows up
invisible unless the user hits escape twice.
http://bugs.freedesktop.org/show_bug.cgi?id=55669
Right now if the user hits escape a couple of times they'll get
a crash, since the details plugin doesn't support system updates.
This commit makes ply_boot_splash_system_update a no-op in the
event the splash doesn't support that feature.
It's possible that a throbber could get freed while animating.
In that case, stop the animation right away, so we don't keep
running the animation timeout on freed memory.
It's possible that an animation could get freed before it finishes.
In that case, finish the animation right away, so we don't keep running the
animation timeout on freed memory.
It's possible to get in a state where plymouthd is
started in the initrd but not displayed. In the
event this happens, we'll neglect to ever show it,
since it already has a pid file.
plymouthd is now hardened against getting called
multiple times, so we no longer need to protect it
at the systemd level.
This commit drops the
ConditionPathExists=!@plymouthruntimedir@/pid
line from the systemd service file, so we always
call plymouthd from the main fs and always call
plymouth show-splash.
Make plymouthd idempotent to multiple calls. This will make
it easier to integrate with boot scripts that start plymouthd
in the initrd and from the main fs.
The first thing plymouthd should do is try to take control
over its server socket. If it can't do that, then no plymouth
client will be able to communicate with it. The socket is
also how we can detect if plymouthd is already running.
Enables scripts to choose the text alignment they want with a seventh
argument to Image.Text API:
new_image = Image.Text("Hello\n"
"Plymouth aligned world",
1, 1, 1, 1,
"DejaVu Bold,Italic 18",
"center");
This argument can be ignored, the default being left aligned.
Possible values are "left", "center", or "right".
http://lists.freedesktop.org/archives/plymouth/2012-August/000676.html
the initrd hits the local-fs.target as part of its normal
boot process. We used to use local-fs.target as a way of
knowing the system / is read-write. This no longer is a
valid mechanism.
This commit:
1) Stops installing plymouth-read-write service in the initrd
2) Makes it so if it does end up in the initrd it won't be
used
Related to fedora bug 830482
systemd tries to bring down the world when going from
the initramfs to /
commit 9e5a276f32 tried
to prevent plymouthd from getting killed by settings
argv[0][0] to @
This isn't seemingly sufficient. Throw some lines into
the plymouth-start service file that should hopefully help.
The previous systemd commit introduced a file named
systemd-ask-password-plymouth.path.in
The makefile was only looking for .service.in files
when stripping the .in suffix, so it got installed
incorrectly.
This commit fixes up the Makefile.
When plymouth service files were moved from systemd to plymouth
two files got lost in the shuffle.
This commit adds them.
http://bugzilla.freedesktop.org/51573
plymouth uses a shadow framebuffer to cache screen contents for
quick compositing. This shadow framebuffer may or may not have
the same memory layout as the hardware framebuffer. In cases
where the size and layout of pixels are the same between the shadow
framebuffer and the hardware framebuffer we can memcpy()
the pixels line-by-line to the hardware. If the width of area being
flushed is the same number of bytes as the width of the hardware buffer,
then we can memcpy() the entire flush area in one call to memcpy.
The check for this latter fast-path has a miscalculation that tests
the number of pixels in the flush area width to number of bytes in the
buffer width. This commit adds the * 4 multiplier to correctly compare
bytes with bytes instead of pixels with bytes.
This commit also adds a sanity check to make sure the byte size of the
hardware framebuffer width is equal to the advertised row stride.
The udev trigger calls that are there, are actually
spurious. udev will coldplug those subsystems at
start up anyway, so doing it explicitly is wrong.
This commit drops those trigger calls.
What does matter is the udevadm settle call. It's
what makes things block until the graphics driver
is loaded.
udevadm settle is a big sledgehammer, though. It blocks
until all the triggered events (even stuff unrelated to
graphics) are finished.
This commit adds a --exit-if-exists argument to udevadm settle,
so it will bail early as soon as the graphics devices
are up.
plymouth-start.service does this sort of hacky
"udevadm trigger" stuff before doing plymouth show-splash,
to ensure plymouth show-splash is called after the
graphcis subsystem is up.
It actually does two calls:
- one call that triggers any pci devices with the class
0x030000 (which is "vga compatible display device")
- another call that triggers the gpu subsystem
The first call is borrowed from dracut:
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commitdiff;h=2c02c8318
and I can't find any historical context on why its needed. As I
understand things, the latter should be a superset of the former.
Furthermore, the first trigger is missing a --subsystem-match=pci call
so it's matching the "class" attribute in every subsystem, which is slow.
I'm going to drop the first trigger until I start hitting problems
and need to add it back.
plymouth-start.service does this sort of hacky
"udevadm trigger" call before doing plymouth show-splash,
to ensure plymouth show-splash is called after the
graphcis subsystem is up. Because this udev trigger call
only passes --subsystem-match calls with no corresponding
--subsystem call, it will trawl through all subsystems in
/sys rather than just the pci subsystem (where all the matches
are guaranteed to be).
This commit adds --subsystem=pci to stop doing that extra work.
All of this will eventually be replaced with plymouthd either
listening for the udev events itself (or potentially logind,
if logind gains a way to tag a "graphics" capability on a seat).
get_os_string either returns a string describing the distribution,
or NULL on error.
This NULL later causes problems since we run strlen on it.
This commit makes get_os_string return "" instead of NULL for error
cases.
Spotted by Andreas Henriksson.
