[22:50] random thought [22:50] fedora people [22:50] does plymouth actually have a long-running process? [22:50] or does it just paint to the screen and exit? [22:52] IIRC, it does animation, so it must have a long-running process. [22:52] Even without graphics, it does a simple text-based animation. [22:54] yeah [22:54] but you could do that by having one process paint the screen [22:54] then if you wanted a throbber, start a throbbler process that animates that bit of the screen [22:54] and if you wanted an input, start a different process that took another bit of the screen for input [22:54] it'd solve the whole fifo issue :) [22:56] True [22:57] But i’d expect a single process that listens on a socket for multiple connections would be simpler to implement. [22:59] possibly [23:00] but then you have to deal with things getting out of the way before X and stuff [23:00] in Moblin, their plymouth-lite thing does just paint the image and go [23:01] True. Animation will also use resources one could use to, say, boot the system. :-P [23:01] yeah [23:03] Even with some magic to retain the splash when X is initializing, until the first X window being painted, animation would seem to get hung for a while, whereas if the splash was static in the first place, things would look quite nice. [23:03] yeah, exactly [23:03] Retain the framebuffer contents, that is [23:03] that's what I was thinking [23:03] have a program to write a static image (THE DESKTOP BACKGROUND!) [23:03] if we need to do fsck, just have a small program that paints over the top in one area of the screen [23:04] if we need to do input, just have a small program that paints over the top in a different area of the screen [23:04] and both of those block X from starting anyway [23:07] How about a splash program that is still long-running and listens on a socket, but actually just draws the static image once and then does single updates for input/progress? It would solve the same issue, but it would be more efficient, there would be no need for different things to have predefined display areas (it could allocate them when on demand) and it could easily handle the ‘multiple clients want input, use tabulator to switch focus’ case. [23:08] that would work too [23:09] then at least you could show multiple progress bars [23:09] and ask for multiple passphrases [23:09] and I guess you'd want cancellation and stuff [23:10] It could also easily do the pretty text UI when KMS is not available. [23:11] right [23:11] which is I guess how plymouth works [23:50] keybuk: http://heh.fi/tmp/text-splash-mockup.png http://heh.fi/tmp/text-splash-mockup.text :-P