Interested in this ability as well.

I guess what we need to do at this point is detect the kind of console that's specified in the console argument.  If it's a normal tty then use a normal splash and if it's a serial device use a detailed splash.

Unfortuantely right now we can only have "details" or a graphical splash loaded at any given time, not both.

We'll need to restructure the code to support having both loaded at the same time.

This is now biting us more than before, as OLPC is finally adopting plymouth.

Our kernel boot params remain the same:
  console=ttyS0,115200 console=tty0

In kernel land, this means "run a serial console on ttyS0, but also use tty0 as a console". And when multiple console= arguments are passed, the last one specified is used as primary.

plymouth has the right idea of not running anything on my serial console (thanks), but it should realise in the above case that the primary console is tty0 and there is no reason not to run a splash there. (right now it doesn't do anything on this configuration)

On a related note, OLPC also needs a way of specifying that the splash should always be active, even when "rhgb" is not passed on the kernel command line. This is because our logic for when we want splash or not is a little complex, so we have that logic implemented elsewhere and we only launch plymouthd when we really do want graphical splash. A command line option for plymouthd would be great, a config file option would also work.

We've temporarily worked around both of these issues by passing --kernel-command-line="rhgb" to plymouthd.

Created attachment 60317 [details] [review]
Patch to maybe fix issue

Comment on attachment 60317 [details] [review]
Patch to maybe fix issue

I've just posted a patch to the mailing list that may fix this, but I'll attach
it here as well; if you wouldn't mind testing it for me and letting me know
what happens, that would be great.  If this works for you, I'll axe the OLPC
workarounds that were added for this bug, as they seem very hackish...

Created attachment 60326 [details]
plymouthd debug log

Thanks a lot for working on this!
Doesn't quite work, unfortunately. No splash appears. Here is a plymouthd log.


/sys/class/tty/console/active has contents "ttyS0 tty0"
/proc/cmdline has contents "console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 no_console_suspend selinux=0"

Your commit message suggests that you're using the first found console as the primary one. Maybe that is the cause of the issue. I think you should be using the last one, which acts as the primary console. From kernel docs:




You can specify multiple console= options on the kernel command line.
Output will appear on all of them. The last device will be used when
you open /dev/console. So, for example:

	console=ttyS1,9600 console=tty0

defines that opening /dev/console will get you the current foreground
virtual console, and kernel messages will appear on both the VGA
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.

Created attachment 60442 [details] [review]
amended patch for default pixel renderer detection

Ah, I see what's happened here.  I assumed plymouth had some way to figure out how to associate a terminal with a framebuffer; I had no idea it just defaulted to /dev/fb0.  I've amended my patch to set the renderer to the default display, which is how it worked before my patch.

I wonder if there's some ioctl that plymouth can use to get a list of framebuffer devices....  They should really be detected separately from text consoles.

Created attachment 60488 [details]
plymouthd debug logs

Still no splash output unfortunately. Here are the new logs.

Created attachment 60494 [details] [review]
patch to change criteria for force details

Interesting.  The log says everything went as expected.

There's a line in the code that tells plymouth to force details if it finds a console that's not tty0; this patch changes that criteria to force details if no pixel displays are found.  Apply this on top of the last patch and see what it does for you.

Doesn't help. I see whats going on.

Here's the initial plymouthd output, before any commands are processed:
[main.c]                        initialize_environment:initializing minimal work environment
[main.c]                               check_verbosity:checking if tracing should be enabled
[main.c]                               check_verbosity:tracing shouldn't be enabled!
[main.c]                                 check_logging:checking if console messages should be redirected and logged
[main.c]                                 check_logging:logging will be enabled!
[main.c]                        initialize_environment:source built on Apr 23 2012
[main.c]                        initialize_environment:checking if '/dev/tty1' exists
[main.c]                            check_for_consoles:checking for consoles
[main.c]                        add_consoles_from_file:opening /sys/class/tty/console/active
[main.c]                        add_consoles_from_file:reading file
[main.c]                        add_consoles_from_file:console /dev/ttyS0 found!
[main.c]                        add_consoles_from_file:console /dev/tty0 found!
[main.c]                            check_for_consoles:After processing serial consoles there are now 0 text displays and 0 pixel displays
[main.c]                        initialize_environment:Making sure /run/plymouth exists
[ply-utils.c]                          ply_create_directory:directory '/run/plymouth' already exists
[main.c]                        initialize_environment:initialized minimal work environment
[main.c]                       get_cache_file_for_mode:returning cache file '/usr/var/lib/plymouth//boot-duration'
[main.c]                                          main:entering event loop

In the above run, I have modified the check_for_consoles line to count the number of pixel displays in addition to text displays (current code only debug-logs how many text displays there are).

As 0 pixel displays were found, it sets should_force_details to 1 as per your patch.

When plymouthd is later asked to show the splash, it rescans the consoles and finds 2 text displays and 1 pixel displays. But by that time it's too late, should_force_details is already 1 so it doesn't try to do the graphical splash.

Created attachment 60502 [details] [review]
Amended patch for force details criteria

Ah, okay, in the first pass it doesn't try to add displays for devices, so we shouldn't make any decisions about forcing details unless we actually try to add displays.  Again, this goes on top of the first patch.  Hopefully that should solve it. :)

Thanks for looking into this, i'll look at your patches later today.

Thanks, it's working now!

Created attachment 60544 [details] [review]
reverts commit for --ignore-implicit-consoles

Excellent, good to hear!  Would you mind trying this one just to make sure nothing breaks for you?  I've gotten rid of the --ignore-implicit-consoles option since it seems unnecessary now that your bug is fixed.

Hey Kevin,

I most of your add_console_from_file changes and pushed them:

http://cgit.freedesktop.org/plymouth/commit/?id=6baab7a8f889f6b48cb559fd5a62750203f62c3b

I didn't keep the parts of your patch that consolidate add_default_displays_and_keyboard with add_display_and_keyboard_for_console.  We the only time we want to allocate a renderer is the default case.

What we really need is the ability to run the correct splash for each seat (a text splash for serial console, a graphical splash for virtual console, etc).  That requires loading more than one splash, or making the graphical splashes do the same job details can do.  I'm leaning toward the former approach.  Eventually, I'd like to add a --watch-udev argument to plymouthd or so and have it automatically show splashes on new heads as they come available.

For now, I've commited a change to fix show-splash such that if tty0 is the only thing in /sys/class/tty/console/active we do the default action.  If there's anything more exotic we do the "force details" action. This is pretty close to how it worked before we read /sys/class/tty/console/active.

That still leaves Daniel in a bind, so I've added a plymouth.ignore-serial-consoles kernel command line option he can use to get out of that bind.  We we eventually support running details on serial console, and e.g. charge on the main vc, then that option won't be needed anymore.

Thanks for accepting part of it :)  I do have a few comments, however:

The part that moved logic out of add_default_displays still only added a renderer for the default display, and keeping that code where I put it will help you add multiple renderers in the long run.  If the code will need to go there anyway, I think it would be best to put it there now.

I like the idea about watching udev and I'm actually willing to work on that and loading multiple splashes if you'd like.

I have to say I also disagree with having the ignore-serial-consoles option as it currently exists, and that it seems like a more tasteful solution to only force details if there are no pixel displays (which is still only the case if the default display isn't found).  Alternatively, another idea would be for ignore-serial-consoles to tell read_consoles_from_file to ignore entries of the form ttyS*.  I just disagree with the way it's being done currently; it doesn't make much sense to me.

Is there any progress on this bug?

I'm trying to use a Raspberry Pi, which similarly ships with two console= parameters (first for serial, second for tty1, similar to OLPC).

It's running Plymouth 0.9.0-7 and still shows the same behaviour ("serial consoles detected, managing them with details forced"), resulting in just displaying three dots with nothing else.

If I remove both console parameters then I get no output at all until the login prompt appears.  ("no seats available to show splash on")  If I add only console=tty1 then it still thinks this is a serial console.  If I add "plymouth.ignore-serial-consoles" to the kernel command line then it still sees the console= lines and forces details.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/plymouth/plymouth/issues/24.