Hi, >> plymouth watches for the creation of drm display devices during boot. >> If it finds one, it starts a graphical splash and that is that. >> However, if the system finishes loading drivers and no drm device is >> available, it falls back onto a fbdev-based splash or a text-based >> boot. Once it has made that choice there is no turning back, it >> basically ignores drm devices if they become available later. > > To my knowledge newer versions don't do this anymore and actively > watch drm devices coming. We watch them coming and going but only if we haven't fallen back to text mode. The issue is that plymouth currently only supports one kind of splash at a time (text or graphics, not both), so if we fall back, we can't do much. it would be weird if a boot started out showing a text splash then spontaneously switched to a different graphical splash for the last split second before X came up.
There is something to be said for showing a graphical splash on a DisplayLink device when the main machine only supports text splash, and it wouldn't be too hard to fix, but it's a bit of a niche case, and i never got around to it. > No, applications should not watch the queue. And the file is internal > to udev anyway. If you watch it, you get to keep the pieces. udev recently gained public api for monitoring the queue. Regardless, I think using a timeout is a better way to go anyway. key points: 1) if boot is less than say 5 seconds we shouldn't show anything but black (which we accomplish today with the ShowSplashDelay config key) 2) if boot takes much more than 5 seconds then we need some sort of indication that boot is progressing, so if graphics isn't ready by then we should fall back to text splash (right now we only fall back after we think "coldplug completes", so we need fixes here) 3) we shouldn't ever upgrade from text to graphics on any given output, since that would look weird (this works today, but we could do better by allowing different splashes on different outputs) 4) relying on the udev queue to drain to decide on falling back is wrong and we should stop doing that Still, there's may be another problem...is there a decent sized hole in boot time between udev exiting in the initrd and then starting back up on the main root filesystem? If so, graphics that don't manage to get marked initialized in the initrd, may not get marked initialized until some seconds later after they would otherwise be ready to go, and from one boot to the next the user may get graphics or text mode. maybe udev should stick around and switch into the root filesystem on its own (and i guess potentially re-exec itself once it gets there), so it doesn't have to blow it's queue and retrigger? --Ray _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
