Keyboard input / init + questions

[Ray Strode]

Hi,

On Sat, Sep 25, 2010 at 6:50 AM, Jerome Martin <tramjoe.merin at gmail.com> wrote:
> I am using plymouth for a project of mine. Basically, using the script
> modules, I have done a theme that among other things displays boot logs in a
> pager, and also can display an help screen. When testing, everything works
> fine. I can scroll up or down in my pager with the keys 'u' and 'd' and
> toggle my help screen with the keypress 'h'.
Sounds interesting.

> However, during an actual boot sequence, it seems that my keyboard input
> hook does not get any keypress anymore after init switches runlevels.
Some init implementations forcefully steal the tty away from plymouth.
 What version of plymouth are you using?  There have been a few
workarounds added to the code to lock the tty so nothing can muck with
the attributes and reopen it if it ever gets stolen away.  If you try
the latest snapshot in git does it work okay for you? I want to get a
0.8.4 release out soonish.  It's a little overdue.

> tried various ways to debug this, but it really seems to happen in init
> itself.
Right, i've seen it in the past from a TIOCSCTTY ioctl in sysvinit,
for instance.

> - Is there a way to check the keypress callback function argument for
> non-string keys like arrows ? When trying to get their value, I always get
> errors that seem to indicate the contents are not string, but I do not have
> any other type/predefs values to check them against.
So an example of non-printable input are control keys.  These keys are
the letter xored with \100

e.g. '\100' ^ 'G'

would be ctrl-g. Alternatively, if you run

man ascii

and trace your finger across the line for any given capital letter on
the right side of the screen, all the way to the left side of the
screen, you'll see the ascii number associated with the control
character associated with that letter (so ctrl-g is 0x7).  Arrows are
a little different because they are a sequence of bytes, not just one
byte.

If you run the "cat' command at a terminal and then press the arrow
keys you'll see something like:

^[[A
^[[B
^[[C
^[[D

with the '^[" being a control character (the "escape" character
(ctrl-[ , i.e. '\100' ^ '[')) and the next two characters '[' and a
letter.  This is called an escape sequence.

So if you want to read the arrow keys you need to start buffering the
input stream as soon as you see a ctrl-[ and latch from there.  I
realize this is a little groaty.  We should probably do this inside
the core of the plymouth daemon automatically under the hood and then
pass this to the plugins as actual ARROW events via a new callback or
something similar.   Given that I've never tried to use arrow keys in
a plymouth plugin before, you may run into gotchas trying to do the
above.  For instance, since the first character in any escape sequence
is "escape", the plymouth daemon will probably interpret that as the
user htting the escape key and toggle to "details mode" instead of
relaying the key to the plugin.  Plymouth is implemented in a sort of
"needs based", organic way, and we've never needed support for arrow
keys before, so it hasn't been given a lot of thought.  I can look
into making the experience better if you like.  Give me a few days to
experiment, i'll know more after I've actually tried to get it work.
Hopefully, as we get closer to 1.0 we can get details like this (and
better documentation, etc) in better shape.

> - Is there a way to call up an external binary from plymouth, like a
> system() function ?
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.

> If not, I guess this would not be much to add, I can dorr
> it if you give me a proper pointer in your code (hints on the proper parse
> token to use, etc.).
> - I desperately miss a couple of possibilities regarding strings, like
> determining a string length, and addressing strings as lists (a="foobar";
> c=a[2]), thus making it possible to do strings transformations, iterate on
> strings, etc. Did I miss something ? Would that be hard to implement ?
> - Last, but related to the previous, I currently keep an index on lists I
> create to knopw their length before iterating on them, but it would be nice
> to have a mylist.Len() method.
> Can any of the two previous points be done with a "list | []" method of
> sorts ?

As far as questions about and tips for extending the feature set of
the script plugin go, I'll let Charlie chime in there.  He wrote the
script plugin and knows its details a lot better than I do.

--Ray