Keyboard input / init + questions

[Ray Strode]

Hi,

On Sat, Sep 25, 2010 at 5:13 PM, Jerome Martin <tramjoe.merin at gmail.com> wrote:
> What about a default handler that
> would call details mode, and user-defined handlers that would override this
> ?
It probably makes sense to add a mechanism for plugins to prevent
escape from switching to details.

 > Of course, I do not know yet how much overhead this will add to my script
> as I intend to also capture inputs as text in some future functionality (I
> try to use plymouth as a basic GUI toolkit for FB, I confess that this might
> not be ideal ).
Yea, plymouth isn't really designed to be a windowing system or
anything, just "enough" to get something reasonable up during the boot
process.
You may end up hitting your head against the limitations of plymouth
once you get far enough into your project.  If you're looking for a
windowing system that isn't X, the wayland project may be more up your
ally.

> There is one weird thing though in the above explanation about the way key
> input is rendered. I tried at first to render the key string representation
> as a sprite to display it, but that was crashing on arrow keys input. I
> assumed this was because somehow the typing was lax in plymouth and the
> resulting variable was not a string, but now that I think about it maybe it
> was the Image.Text crashing because it could not render non-printable chars.
Do you have backtrace or an error message from the crash?

>> One thing to watch out for is plymouth is normally started within the
>> initrd, before the root filesystem (and its available programs) are
>> accessible.  You shouldn't try to run anything until after the
>> on_root_mounted callback has been called.
> Mmmh. Why ? I do start plymouth in my custom initramfs and I intend to maybe
> call on some external programs while still in doing initrd tasks, if there
> is a problem mounting the root FS for instance (a squahfs in my case). But
> of course this would be limited to binaries actually available in the
> initramfs and supposed to be called at that time. It do control what is or
> is not available in my initramfs, so why would that be a problem ?
It's okay to run things before the root fs is mounted, it just means
you'll only be able to run things you stuff into your initramfs.

Note if you use the system() call you need to have /bin/sh in your
initramfs (or you can use fork()/execve() or whatever)

--Ray