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 (Ray Strode)
2. Re: Keyboard input / init + questions (Charlie Brej)
3. Re: Keyboard input / init + questions (Jerome Martin)
4. Re: Keyboard input / init + questions (Charlie Brej)
5. Re: Keyboard input / init + questions (Jerome Martin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Sep 2010 16:53:59 -0400
From: Ray Strode <[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=UTF-8
Hi,
> Yeah the \123 is more standard.
Note C supports \123 for octal and \x123 for hex.
python uses \u1234 for unicode codepoints.
> 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).
that works for control characters (and sort of what we have now) but
not for escape sequences. There's not unicode codepoint for "user hit
the up arrow key"
I don't really think it should be inline with the user's typed keys,
honestly. We should filter it out at the plymouth daemon level, and
send it to the plugin out-of-band using a different call back.
--Ray
------------------------------
Message: 2
Date: Tue, 28 Sep 2010 22:06:41 +0100
From: Charlie Brej <[email protected]>
Subject: Re: Keyboard input / init + questions
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 09/28/2010 09:53 PM, Ray Strode wrote:
> Hi,
>
>
>> Yeah the \123 is more standard.
> Note C supports \123 for octal and \x123 for hex.
> python uses \u1234 for unicode codepoints.
The thing I wasn't sure about these was the uglyness of two or even one
digit codes, and the formation of illegal utf-8 sequences.
>> 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).
> that works for control characters (and sort of what we have now) but
> not for escape sequences. There's not unicode codepoint for "user hit
> the up arrow key"
>
> I don't really think it should be inline with the user's typed keys,
> honestly. We should filter it out at the plymouth daemon level, and
> send it to the plugin out-of-band using a different call back.
You're right. Control sequences should be handled seperately from keys.
Password/question entry for one is somewhere we dont want them, but I
think currently they go in.
------------------------------
Message: 3
Date: Tue, 28 Sep 2010 23:07:27 +0200
From: Jerome Martin <[email protected]>
Subject: Re: Keyboard input / init + questions
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Sep 28, 2010 at 10:53 PM, Ray Strode <[email protected]> wrote:
> Hi,
>
>
> > Yeah the \123 is more standard.
> Note C supports \123 for octal and \x123 for hex.
> python uses \u1234 for unicode codepoints.
>
The first two are trivial to do with string.h, as for the third I do not
know. I say let's support all three, but honestly I never saw anyone use the
hex ascii representation in the last 20 years...
>
> > 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).
> that works for control characters (and sort of what we have now) but
> not for escape sequences. There's not unicode codepoint for "user hit
> the up arrow key"
>
Right.
>
> I don't really think it should be inline with the user's typed keys,
> honestly. We should filter it out at the plymouth daemon level, and
> send it to the plugin out-of-band using a different call back.
>
Well, that idea is fine too, but I suggest, as normal chars are, well ...
single chars, that if you do some preprocessing the raw chars are passed as
single chars to the callback, and special ones (ANSI sequences) as
multi-chars strings, like "UP", "DOWN" in cooked mode, using the same
callback (I cannot see any reason to use a different one there). The only
problem is that you get some control out of the users hands by doing that.
Unless you do a blend of both, cooking escape sequences at plymouth C code
level, and sending a generic string to the callback to signify that, without
needing to implement a large case statement in the C code. Instead of "UP",
you would get the actual ESC char + [ + A (allowing "if (key == "\033[A")
{...} ). _I_ would prefer that last solution. It would mean just decide the
duration of a "compose delay", and every chars arriving at less than this
interval are just grouped together and sent to the script. Easy, robust and
unobtrusive while being powerfulland solving all escape sequence issues.
However, a String.Len might come in handy to handle that ;-)
--
J?r?me Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/plymouth/attachments/20100928/70e01639/attachment.html>
------------------------------
Message: 4
Date: Tue, 28 Sep 2010 22:21:20 +0100
From: Charlie Brej <[email protected]>
Subject: Re: Keyboard input / init + questions
To: Jerome Martin <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
> 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.
> 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. Is there anything else you need to add
to it?
------------------------------
Message: 5
Date: Tue, 28 Sep 2010 23:23:18 +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"
Hi Ray,
On Tue, Sep 28, 2010 at 7:41 PM, Ray Strode <[email protected]> wrote:
> Hi,
>
> On Mon, Sep 27, 2010 at 6:20 PM, Jerome Martin
> <[email protected]> wrote:
> > Bingo, I never actually quit plymouth this explain why I did not get the
> > logs :-)
> > Please find the log file attached :-)
>
> So, I'm seeing some strangeness in the fidelity of the logs. It seems
> like ply-logger may have a bug in it, which is unfortunate...
>
> Anyway, looking at the output, I see:
>
> [ 38.755306] [main.c]
> on_display_message:displaying message Running scripts in rcS.d/ took 4
> seconds.
> [...]
> [ 38.794012] [ply-terminal.c]
> on_tty_disconnected:tty disconnected (fd 10)
> [ 38.794015] [ply-terminal.c]
> on_tty_disconnected:trying to reopen terminal '/dev/tty1'
> [...]
> [ 38.794021] [./plugin.c]
> on_input_source_disconnected:input source disconnected, reopening
>
> So it looks like both parts of the code that are supposed to notice
> the tty going away, do it notice it going away, and then both parts
> reopen without any error messages.
>
<nod>, so you do get the hang up properly notified.
>
> 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
And for reference, tty2 where my getty is:
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 = <undef>; 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
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
>
> after the keyboard is stolen away but before qutting plymouth? Also
> the output of
>
> ls -l /proc/$(/sbin/pidof plymouthd)/fd
>
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
>
> would be useful. I may have to do a debian install and try to
> reproduce to make head way on this issue though. If I do go that
> route, tips on how to recreate your reproduction environment would be
> useful.
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.
But I'd be glad to help as much as I can.
Regards,
--
J?r?me Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/plymouth/attachments/20100928/5e09adf5/attachment.htm>
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 23, Issue 12
****************************************
