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. Documents/information on making plugins? (Dean Loros)
2. Re: Documents/information on making plugins? (Ray Strode)
3. Re: Protecting the term from being abused by others using
TIOCSLCKTRMIOS (Ray Strode)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Mar 2009 21:42:47 -0700
From: Dean Loros <[email protected]>
Subject: Documents/information on making plugins?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Greetings!!
I'm looking for information or documents on creating the plugin .so's.
I've played around with the end files to change some images, but I
really want to start creating plugins--can anyone point me the right way?
Cheers!!!!
Dean Loros
------------------------------
Message: 2
Date: Thu, 12 Mar 2009 10:55:12 -0400
From: Ray Strode <[email protected]>
Subject: Re: Documents/information on making plugins?
To: Dean Loros <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi Dean,
> I'm looking for information or documents on creating the plugin .so's.
> I've played around with the end files to change some images, but I
> really want to start creating plugins--can anyone point me the right way?
There's no documentation yet. It's something I really want to have,
but haven't been able to prioritize time for yet.
The best bet is to start with a simple plugin (say fade-in) and copy
it and start editing it. You can experiment without rebooting by
running
plymouthd manually and then typing
plymouth --show-splash
(or the various other plymouth commands. see plymouth --help).
useful key combos: ctrl-v will turn on verbose mode, ctrl-T will turn
on KD_TEXT mode which makes vt switches works and shows redraw
behavior, ctrl-G goes back to KD_GRAPHICS mode.
If you have any questions about how things work, feel free to ask them here.
Hopefully we'll have a better docs story at some point in the near future.
--Ray
------------------------------
Message: 3
Date: Thu, 12 Mar 2009 11:16:00 -0400
From: Ray Strode <[email protected]>
Subject: Re: Protecting the term from being abused by others using
TIOCSLCKTRMIOS
To: Charlie Brej <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Wed, Mar 11, 2009 at 7:20 AM, Charlie Brej <[email protected]> wrote:
> I tried to locate which program was flipping ECHO etc during the boot but
> eventually gave up. Trying to flock the tty didn't help either. Looks like
> TIOCSLCKTRMIOS is the most sensible. Attached is a patch, which does this.
So one thing I'm worried about is how other apps behave if the tty is locked.
Do they error out if they can't make the changes they want? Is boot up smooth?
I also wonder how this works on serial consoles.
> @@ -417,12 +418,19 @@ static bool
> ply_window_set_unbuffered_input (ply_window_t *window)
> {
> struct termios term_attributes;
> + struct termios term_attribute_locks;
>
> - tcgetattr (window->tty_fd, &term_attributes);
> + if (tcgetattr (window->tty_fd, &term_attributes) < 0 )
> + return false;
> + if (ioctl (window->tty_fd, TIOCGLCKTRMIOS, &term_attribute_locks) < 0 )
> + return false;
>
> if (!window->original_term_attributes_saved)
> {
> + if (term_attributes.c_lflag & ECHO)
> + ply_trace ("echo flag has been altered by another program");
Left over debug spew? Can't happen with this patch right?
> window->original_term_attributes = term_attributes;
> + window->original_term_attribute_locks = term_attribute_locks;
> window->original_term_attributes_saved = true;
> }
>
> @@ -431,8 +439,14 @@ ply_window_set_unbuffered_input (ply_window_t *window)
> /* Make \n return go to the beginning of the next line */
> term_attributes.c_oflag |= ONLCR;
>
> + term_attribute_locks.c_iflag |= IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR
> | IGNCR | ICRNL | IXON;
> + term_attribute_locks.c_oflag |= OPOST;
> + term_attribute_locks.c_lflag |= ECHO | ECHONL | ICANON | ISIG | IEXTEN;
This is a bit ugly. I guess at a minimum we should hide this behind
three preprocessor defines... e.g.
#define PLY_WINDOW_TERMINAL_INPUT_ATTRIBUTE_MASK
#define PLY_WINDOW_TERMINAL_OUTPUT_ATTRIBUTE_MASK
#define PLY_WINDOW_TERMINAL_LOCAL_ATTRIBUTE_MASK
and have a comment that says "These are documented in the cfmakeraw man page"
Another idea would be to try to infer the mask based on what bits
cfmakeraw changes versus what the bits were originally.
Something like:
/* We want all the bits that cfmakeraw sets, set in our mask */
input_mask = term_attributes.c_iflag;
/* We also want all the bits that cfmakeraw clears, set in our mask */
input_mask |= (original_term_attributes.c_iflag ^ term_attributes.c_iflag);
Not sure if that logic is right. Or maybe we should just lock everything?
--Ray
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 6, Issue 5
**************************************
