Send plymouth mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.freedesktop.org/mailman/listinfo/plymouth
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of plymouth digest..."


Today's Topics:

   1. Re: Keyboard input / init + questions (Jerome Martin)
   2. Re: Keyboard input / init + questions (Ray Strode)
   3. Re: Keyboard input / init + questions (Jerome Martin)


----------------------------------------------------------------------

Message: 1
Date: Tue, 28 Sep 2010 23:44:23 +0200
From: Jerome Martin <[email protected]>
Subject: Re: Keyboard input / init + questions
To: Charlie Brej <[email protected]>
Cc: [email protected]
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Sep 28, 2010 at 11:21 PM, Charlie Brej <[email protected]> wrote:

> On 09/28/2010 09:28 PM, Jerome Martin wrote:
>
>>    Yeah the \123 is more standard. Although now I am thinking all of
>>    this should be unicode characters and have a unique character for
>>    each key stroke (ctrl-V, esc, etc).
>>
>>
>> I think that would make things more difficult, but you know what fits
>> best with the plymouth style. I would not have done the indenting in the
>> code the same as you neither, this is just a matter of style ;-)
>>
>
> Well, lets start with what Ray was saying and have a side channel for non
> text keys, and that should be half the issue solved. I'm only erring towards
> unicode because thats what other scripting systems do.


<nod>.
OTOH, other script systems usually use LUA or embed some sort of lisp or
python interpreter, NOT a full-blown homemade C-like syntax parser not even
leveraging any grammar generator tool :-)


>  Then what do you suggest ? Frankly is the only issue is a plugin script
>> writer forgetting to properly bind a key for viewing details, well, I
>> think people are grown ups :-)
>>
>
> Thats the interesting question. I currently treat theme writers as foolish
> users who even if they screw up, will not screw up the system boot. This may
> be over protective.


I guess I might not be your average target then.
But honestly, highly capable people like Frederic Crozat or I assume other
guys working for larger distros should not be dismissed as foolish by
default. I think they would actually like more control. As for end-users
just toying with themes, well, I said that I was advising to make the
pass-through behavior _optionnal_, so either "forget" to document the
callback setter  function for those essential keystrokes, or have a clear
and loud warning that it should not be used lightly and WILL backfire on
them.


>  Sure, no problem. It is simple, really. Find a sample script attached
>> (pardon the awkward implementation details, this is just a
>> proof-of-concept so some tidying up has yet to be done).
>>
>
> Wow, that is rather impressive.


Thanks, but it really is very simple code in a rough prototype state...
TBH, most of it took less than an afternoon, including testing usplash,
splashy, discovering that plymouth existed on google, reading your blog's
howtos and coding 90% of it. Plymouth really _is_ straigthforward to use.
The most difficult part was to tame the gimp :-)


> Is there anything else you need to add to it?
>

A lot :-) I have some ideas that I will probably implement at some time. I
have more urgent matters to do now, but in the mid-term I will probably add
switching info screens with left/right arrows and put a separate event log
aside for "live" debug. Also, I will add a menu for basic tasks (you
probably guessed that this is a cluster node) like rebooting the node,
dumping configuration on a USB key, running a self-check, things like that
for recovery mostly.

Also, the node normally auto-configures itself and connects to the cluster
without any assistance, but for recovery scenarios I might add an emergency
IP setup menu, that will require the user to pick a network interface,
optionally a vlan number, and type in an IP address, netmask and optional
gateway. For the list selection of eth widget, no problem, this is easy to
do, same for picking a vlan number with +/-  keys, the only thing I haven't
experimented yet is with text entry, aka do I have to code it myself in
either C or script or is the "ask" feature you have will work ?

BTW, I forgot to say so, but this is a very nice piece of work guys !
And I love the script syntax and parser, I thought that was impressive to
code a parser for a splash tool, nice move (I would have been OK with python
bindings, you know ;-) - kidding, I realize you needed something that works
in initrd).

Best,
-- 
J?r?me Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/plymouth/attachments/20100928/478bc080/attachment-0001.htm>

------------------------------

Message: 2
Date: Tue, 28 Sep 2010 17:45:23 -0400
From: Ray Strode <[email protected]>
Subject: Re: Keyboard input / init + questions
To: Jerome Martin <[email protected]>
Cc: plymouth <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset=UTF-8

Hi,

On Tue, Sep 28, 2010 at 5:23 PM, Jerome Martin
<[email protected]> wrote:
>> Can you post the output of
>> sudo stty -a --file=/dev/tty1
>
> r...@000c29af1815:~# stty -a --file=/dev/tty1
> speed 38400 baud; rows 30; columns 80; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 =
> <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
> rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
> -ixoff -iuclc -ixany -imaxbel iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
> ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
> echoctl echoke
Okay, so this is all wrong.  This is called "cooked" mode, and
plymouth requires "raw" mode.
(-icanon among other things).

plymouth explicitly locks the terminal with a TIOCGLCKTRMIOS ioctl
call, so other programs can't change it.
That means that either

a) plymouth is setting the wrong mode before locking the terminal
b) plymouth is failing to lock the terminal correctly
c) something else is unlocking the terminal and then setting the wrong mode.

At any rate, this is what's causing your problem.

> And tty1 after exiting plymouth:
> r...@000c29af1815:~# plymouth quit
> r...@000c29af1815:~# stty -a --file=/dev/tty1
> speed 38400 baud; rows 30; columns 80; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 =
> <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
> rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
> -ixoff -iuclc -ixany -imaxbel iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
> ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
> echoctl echoke
So that's exactly the same as before plymouth quit.  When plymouth
quit's, it's supposed to restore the attributes to what it found them
as when it was started.

So either,

1) Those are the settings it found the tty in originally (which is
plausible actually)
2) The tty is locked by something else so plymouth can't restore the
settings it found the tty in

> r...@000c29af1815:~# ls -l /proc/250/fd
> total 0
> lrwx------ 1 root root 64 2010-09-28 21:19 0 -> /dev/console (deleted)
> lrwx------ 1 root root 64 2010-09-28 21:19 1 -> /dev/console (deleted)
> lrwx------ 1 root root 64 2010-09-28 21:19 10 -> /dev/tty1
> lrwx------ 1 root root 64 2010-09-28 21:19 2 -> /dev/console (deleted)
> lrwx------ 1 root root 64 2010-09-28 21:19 3 -> anon_inode:[eventpoll]
> lr-x------ 1 root root 64 2010-09-28 21:19 4 -> pipe:[1922]
> l-wx------ 1 root root 64 2010-09-28 21:19 5 -> pipe:[1922]
> lrwx------ 1 root root 64 2010-09-28 21:19 6 -> /dev/ptmx
> lrwx------ 1 root root 64 2010-09-28 21:19 7 -> /dev/tty1
> lrwx------ 1 root root 64 2010-09-28 21:19 8 -> socket:[1927]
> lrwx------ 1 root root 64 2010-09-28 21:19 9 -> /dev/fb0
So this confirms that the tty is definitely getting reopened okay.  The

/dev/console (deleted)

suggests that

http://cgit.freedesktop.org/plymouth/commit/?id=5b4ed8f35a1e9358d94df4b84ad49cea790f57e9

isn't working like it should be (but it shouldn't really affect your
present issue)

> Mmhh. This is really going to be difficult. See, I have a live distro with
> some proprietary software in, a lot of customs packages, in a prototype
> form, that is built with a complex sequence of Makefiles and scripts...
> Mostly is ressembles a debian squeeze and a debian-live initramfs. Also, it
> lacks many packages and typical binaries found on a normal distro, the user
> will never see a shell on it, it is mostly remote-controlled by a cluster
> admin CLI.
Okay, well I probably just need a distro that uses sysvinit.  So i
could go with stock debian,
opensuse, or mandriva i guess.  Let's try to do more
debugging-by-proxy first though.

I'll reply again after I've looked over the code a bit closer.

--Ray


------------------------------

Message: 3
Date: Wed, 29 Sep 2010 00:02:29 +0200
From: Jerome Martin <[email protected]>
Subject: Re: Keyboard input / init + questions
To: Ray Strode <[email protected]>
Cc: plymouth <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Sep 28, 2010 at 11:45 PM, Ray Strode <[email protected]> wrote:

> Hi,
>
> On Tue, Sep 28, 2010 at 5:23 PM, Jerome Martin
> <[email protected]> wrote:
> >> Can you post the output of
> >> sudo stty -a --file=/dev/tty1
> >
> > r...@000c29af1815:~# stty -a --file=/dev/tty1
> > speed 38400 baud; rows 30; columns 80; line = 0;
> > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 =
> > <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
> > rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> > -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
> > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
> > -ixoff -iuclc -ixany -imaxbel iutf8
> > opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
> vt0
> > ff0
> > isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
> -echoprt
> > echoctl echoke
> Okay, so this is all wrong.  This is called "cooked" mode, and
> plymouth requires "raw" mode.
> (-icanon among other things).
>

When you speak of raw vs cooked, it takes me back to the 80's, writing some
asm to use int16h to setup the keyboard. That makes me nostalgic :-)


>
> plymouth explicitly locks the terminal with a TIOCGLCKTRMIOS ioctl
> call, so other programs can't change it.
> That means that either
>
> a) plymouth is setting the wrong mode before locking the terminal
> b) plymouth is failing to lock the terminal correctly
> c) something else is unlocking the terminal and then setting the wrong
> mode.
>

Any idea how I can help debug that ?


>
> At any rate, this is what's causing your problem.
>
> > And tty1 after exiting plymouth:
> > r...@000c29af1815:~# plymouth quit
> > r...@000c29af1815:~# stty -a --file=/dev/tty1
> > speed 38400 baud; rows 30; columns 80; line = 0;
> > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 =
> > <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
> > rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> > -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
> > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
> > -ixoff -iuclc -ixany -imaxbel iutf8
> > opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
> vt0
> > ff0
> > isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
> -echoprt
> > echoctl echoke
> So that's exactly the same as before plymouth quit.  When plymouth
> quit's, it's supposed to restore the attributes to what it found them
> as when it was started.
>
> So either,
>
> 1) Those are the settings it found the tty in originally (which is
> plausible actually)
> 2) The tty is locked by something else so plymouth can't restore the
> settings it found the tty in
>

Find attached a screenshot taken with break=bottom.
One weird thing is that sh says "can't access tty; job control turned off",
but the tty devs do exist in /dev...
Hope it helps.


>
> > r...@000c29af1815:~# ls -l /proc/250/fd
> > total 0
> > lrwx------ 1 root root 64 2010-09-28 21:19 0 -> /dev/console (deleted)
> > lrwx------ 1 root root 64 2010-09-28 21:19 1 -> /dev/console (deleted)
> > lrwx------ 1 root root 64 2010-09-28 21:19 10 -> /dev/tty1
> > lrwx------ 1 root root 64 2010-09-28 21:19 2 -> /dev/console (deleted)
> > lrwx------ 1 root root 64 2010-09-28 21:19 3 -> anon_inode:[eventpoll]
> > lr-x------ 1 root root 64 2010-09-28 21:19 4 -> pipe:[1922]
> > l-wx------ 1 root root 64 2010-09-28 21:19 5 -> pipe:[1922]
> > lrwx------ 1 root root 64 2010-09-28 21:19 6 -> /dev/ptmx
> > lrwx------ 1 root root 64 2010-09-28 21:19 7 -> /dev/tty1
> > lrwx------ 1 root root 64 2010-09-28 21:19 8 -> socket:[1927]
> > lrwx------ 1 root root 64 2010-09-28 21:19 9 -> /dev/fb0
> So this confirms that the tty is definitely getting reopened okay.  The
>
> /dev/console (deleted)
>
> suggests that
>
>
> http://cgit.freedesktop.org/plymouth/commit/?id=5b4ed8f35a1e9358d94df4b84ad49cea790f57e9
>
> isn't working like it should be (but it shouldn't really affect your
> present issue)
>

ok.


>
> > Mmhh. This is really going to be difficult. See, I have a live distro
> with
> > some proprietary software in, a lot of customs packages, in a prototype
> > form, that is built with a complex sequence of Makefiles and scripts...
> > Mostly is ressembles a debian squeeze and a debian-live initramfs. Also,
> it
> > lacks many packages and typical binaries found on a normal distro, the
> user
> > will never see a shell on it, it is mostly remote-controlled by a cluster
> > admin CLI.
> Okay, well I probably just need a distro that uses sysvinit.  So i
> could go with stock debian,
> opensuse, or mandriva i guess.  Let's try to do more
> debugging-by-proxy first though.
>
> I'll reply again after I've looked over the code a bit closer.
>

You know, after that sh complaint during initrd, I wonder if something is
not broken in my initramfs. What exactly is needed for proper tty setup ? I
might have broken something (or pasted a bug from debian-live scripts).

Best,
-- 
J?r?me Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/plymouth/attachments/20100929/215eee84/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clnode1 @ 2010-09-28 23:58:17.png
Type: image/png
Size: 8692 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/plymouth/attachments/20100929/215eee84/attachment.png>

------------------------------

_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth


End of plymouth Digest, Vol 23, Issue 13
****************************************

Reply via email to