[Splashy-devel] handling signals
Pat Suwalski
pats at xandros.com
Mon Mar 20 14:47:39 UTC 2006
Luis M wrote:
> I've added signal handlers to splashy main thread. Now it updates the
> progressbar by 1 tick if a USR1 signal is sent, and by 10 ticks if a
> USR2 signal is sent. This means that it's possible to update the
> progressbar completely from splashy-init without having to write to
> the fifo.
Hey, that's pretty cool.
> The fifo file is not going away, so, don't be alarmed. The reason I
> added this to be able to update the progressbar from initramfs and
> other read-only filesystems.
When one pivots, does the initramfs free itself? One of the big problems
of running splashy from initrd is that it can only be unmounted after
splashy exits. I haven't had a chance to investigate initramfs more, but
I assume it's still a problem and splashy is being re-run by init?
> Now we only need to handle HUP signals correctly, so that splashy
> re-reads the fifo from the new root (pivot_root) after init starts and
> initrd's root tree gets moved to some other structure. I'm open to new
> ideas if you guys have a better way of handling the change of root
> tree...
I don't know if this adds to the problem or is a possible solution, but
in playing with splashy and directfb in general, I've noticed it's
possible to "share" the framebuffer. I've had the splashy progressbar
draw over other framebuffer backgrounds.
I wonder if it would be possible to detect a running splashy and simply
not reinitialize directfb and redraw the background? That might work and
have a smooth transition.
Just an idea I've been kicking around.
--Pat
More information about the Splashy-devel
mailing list