Hi,<br><br><div class="gmail_quote">On Sat, Sep 25, 2010 at 7:32 PM, Ray Strode <span dir="ltr"><<a href="mailto:halfline@gmail.com">halfline@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<div class="im"><br>
On Sat, Sep 25, 2010 at 6:50 AM, Jerome Martin <<a href="mailto:tramjoe.merin@gmail.com">tramjoe.merin@gmail.com</a>> wrote:<br>
> I am using plymouth for a project of mine. Basically, using the script<br>
> modules, I have done a theme that among other things displays boot logs in a<br>
> pager, and also can display an help screen. When testing, everything works<br>
> fine. I can scroll up or down in my pager with the keys 'u' and 'd' and<br>
> toggle my help screen with the keypress 'h'.<br>
</div>Sounds interesting.<br></blockquote><div>Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> However, during an actual boot sequence, it seems that my keyboard input<br>
> hook does not get any keypress anymore after init switches runlevels.<br>
</div>Some init implementations forcefully steal the tty away from plymouth.<br>
What version of plymouth are you using? There have been a few<br>
workarounds added to the code to lock the tty so nothing can muck with<br>
the attributes and reopen it if it ever gets stolen away. If you try<br>
the latest snapshot in git does it work okay for you? I want to get a<br>
0.8.4 release out soonish. It's a little overdue.<br></blockquote><div><br></div><div>0.8.3-9 package from debian testing.</div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> tried various ways to debug this, but it really seems to happen in init<br>
> itself.<br>
</div>Right, i've seen it in the past from a TIOCSCTTY ioctl in sysvinit,<br>
for instance.<br></blockquote><div><br></div><div>Indeed, I think this is what happens, I noticed the call in init source meanwhile.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> - Is there a way to check the keypress callback function argument for<br>
> non-string keys like arrows ? When trying to get their value, I always get<br>
> errors that seem to indicate the contents are not string, but I do not have<br>
> any other type/predefs values to check them against.<br>
</div>So an example of non-printable input are control keys. These keys are<br>
the letter xored with \100<br>
<br>
e.g. '\100' ^ 'G'<br>
<br>
would be ctrl-g. Alternatively, if you run<br>
<br>
man ascii<br>
<br>
and trace your finger across the line for any given capital letter on<br>
the right side of the screen, all the way to the left side of the<br>
screen, you'll see the ascii number associated with the control<br>
character associated with that letter (so ctrl-g is 0x7). Arrows are<br>
a little different because they are a sequence of bytes, not just one<br>
byte.<br>
<br>
If you run the "cat' command at a terminal and then press the arrow<br>
keys you'll see something like:<br>
<br>
^[[A<br>
^[[B<br>
^[[C<br>
^[[D<br></blockquote><div><br></div><div>Yup, ANSI/VT100 control sequences.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
with the '^[" being a control character (the "escape" character<br>
(ctrl-[ , i.e. '\100' ^ '[')) and the next two characters '[' and a<br>
letter. This is called an escape sequence.<br></blockquote><div><br></div><div>I know, I already wrote some code using that for CLIs I develop, basically a "rich text" rendered for ANSI terminals.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So if you want to read the arrow keys you need to start buffering the<br>
input stream as soon as you see a ctrl-[ and latch from there. I<br>
realize this is a little groaty. We should probably do this inside<br>
the core of the plymouth daemon automatically under the hood and then<br>
pass this to the plugins as actual ARROW events via a new callback or<br>
something similar. Given that I've never tried to use arrow keys in<br>
a plymouth plugin before, you may run into gotchas trying to do the<br>
above. For instance, since the first character in any escape sequence<br>
is "escape", the plymouth daemon will probably interpret that as the<br>
user htting the escape key and toggle to "details mode" instead of<br>
relaying the key to the plugin. Plymouth is implemented in a sort of<br>
"needs based", organic way, and we've never needed support for arrow<br>
keys before, so it hasn't been given a lot of thought. I can look<br>
into making the experience better if you like. Give me a few days to<br>
experiment, i'll know more after I've actually tried to get it work.<br>
Hopefully, as we get closer to 1.0 we can get details like this (and<br>
better documentation, etc) in better shape.<br></blockquote><div><br></div><div>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 ).</div>
<div><br></div><div>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 :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> - Is there a way to call up an external binary from plymouth, like a<br>
> system() function ?<br>
</div>One thing to watch out for is plymouth is normally started within the<br>
initrd, before the root filesystem (and its available programs) are<br>
accessible. You shouldn't try to run anything until after the<br>
on_root_mounted callback has been called.<br></blockquote><div><br></div><div><br></div><div>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 ?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> If not, I guess this would not be much to add, I can dorr<br>
<div class="im">> it if you give me a proper pointer in your code (hints on the proper parse<br>
> token to use, etc.).<br>
> - I desperately miss a couple of possibilities regarding strings, like<br>
> determining a string length, and addressing strings as lists (a="foobar";<br>
> c=a[2]), thus making it possible to do strings transformations, iterate on<br>
> strings, etc. Did I miss something ? Would that be hard to implement ?<br>
> - Last, but related to the previous, I currently keep an index on lists I<br>
> create to knopw their length before iterating on them, but it would be nice<br>
> to have a mylist.Len() method.<br>
> Can any of the two previous points be done with a "list | []" method of<br>
> sorts ?<br>
<br>
</div>As far as questions about and tips for extending the feature set of<br>
the script plugin go, I'll let Charlie chime in there. He wrote the<br>
script plugin and knows its details a lot better than I do.<br></blockquote><div><br></div><div>OK, thanks a lot for your answers :-)</div><div> </div><div>Best,</div></div>-- <br>Jérôme Martin<br>