Keyboard input / init + questions

[Jerome Martin]

Hi,

On Sat, Sep 25, 2010 at 7:32 PM, Ray Strode <halfline at gmail.com> wrote:

> 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.
>
Thanks.


>
> > 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.
>

0.8.3-9 package from debian testing.
Your precisions seem to confirm what I deduced, so I will either patch init
or plymouth depending on what looks easiest. TBH, I only need a very simple
boot sequence, so I am even looking at replacing init altogether with a
custom script, unsure yet. However, having the fix in plymouth could help
dealing with other pieces of code trying to steal the tty. Thanks for the
clarifications.

> 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.
>

Indeed, I think this is what happens, I noticed the call in init source
meanwhile.



> > - 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
>

Yup, ANSI/VT100 control sequences.


> 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.
>

I know, I already wrote some code using that for CLIs I develop, basically a
"rich text" rendered for ANSI terminals.


> 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.
>

Mmmhh. Okay. Well, I will try experimenting from the use-side and give you
some feedback. I thought there was no trivial way to get arrows when I saw
the blocks example plugin NOT using arrow keys :-) In the worst case
scenario, if plymouth "swallows" the initial escape, I can still rely on the
argument of the escape sequence ([A etc...) if I do not assign anything else
to those keys. Unless there is some error message that whill trigger
plymouth switch to detail mode :-) So yeah, thinking about it, I think it
would not be a nig deal to handle that from the script IF we can
configure/reassign the escape key handler. What about a default handler that
would call details mode, and user-defined handlers that would override this
? 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 ).

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.
In which case, that might be a call for a saner behavior :-)


>
> > - 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.
>


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 ?


> > 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.
>

OK, thanks a lot for your answers :-)

Best,
-- 
Jérôme Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/plymouth/attachments/20100925/3e1a79a3/attachment.html>