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: [PATCH 09/21] [terminal] drop next_active_vt (Ray Strode)
2. Re: [PATCH 21/21] [configure] allow boot and shutdown ttys to
be changed (Ray Strode)
3. Re: [PATCH 19/21] [terminal] guard open and close against
repeated calls (Ray Strode)
4. Re: [PATCH 00/21] Improve VT Handling (Ray Strode)
5. Re: [PATCH 09/21] [terminal] drop next_active_vt
(Scott James Remnant)
6. Re: [PATCH 21/21] [configure] allow boot and shutdown ttys to
be changed (Scott James Remnant)
7. Re: [PATCH 19/21] [terminal] guard open and close against
repeated calls (Scott James Remnant)
8. Re: [PATCH 09/21] [terminal] drop next_active_vt (Ray Strode)
9. Re: [PATCH 19/21] [terminal] guard open and close against
repeated calls (Ray Strode)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Mar 2010 15:02:40 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH 09/21] [terminal] drop next_active_vt
To: Scott James Remnant <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, Mar 18, 2010 at 12:32 AM, Scott James Remnant <[email protected]> wrote:
> When we activate our VT, now we actually have it in VT_PROCESS not the
> VT we started from, we get the proper signal so don't need an ioctl to
> wait until its active.
>
> If we were to leave our VT, we'd get the opposite signal as well and
> we don't really care whether we actually get to the other VT, just
> that we leave ours.
>
> And this code was in the wrong place anyway.
> ---
> ?src/libply-splash-core/ply-terminal.c | ? ?9 ---------
> ?1 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/src/libply-splash-core/ply-terminal.c
> b/src/libply-splash-core/ply-terminal.c
> index e0baf2e..3e54075 100644
> --- a/src/libply-splash-core/ply-terminal.c
> +++ b/src/libply-splash-core/ply-terminal.c
> @@ -65,7 +65,6 @@ struct _ply_terminal
> ? char *name;
> ? int ? fd;
> ? int ? vt_number;
> - ?int ? next_active_vt;
>
> ? ply_list_t *vt_change_closures;
> ? ply_fd_watch_t *fd_watch;
> @@ -336,12 +335,6 @@ on_leave_vt (ply_terminal_t *terminal)
> ?{
> ? ioctl (terminal->fd, VT_RELDISP, 1);
>
> - ?if (terminal->next_active_vt > 0)
> - ? ?{
> - ? ? ?ioctl (terminal->fd, VT_WAITACTIVE, terminal->next_active_vt);
> - ? ? ?terminal->next_active_vt = 0;
> - ? ?}
> -
I was pretty sure you have to call VT_WAITACTIVE after VT_ACTIVATE for
internal kernel bookkeeping reasons. I have some vague notion of
someone (Alan Cox?) telling me that at some point. Looking though, I
can't find any evidence that I'm right.
In fact, it seems there's a new VT_WAITEVENT interface that directly
conflicts with the idea that VT_WAITACTIVE is mandatory. So i'm going
to say i'm wrong.
--Ray
------------------------------
Message: 2
Date: Thu, 18 Mar 2010 15:06:19 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH 21/21] [configure] allow boot and shutdown ttys to
be changed
To: Scott James Remnant <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, Mar 18, 2010 at 1:16 AM, Scott James Remnant <[email protected]> wrote:
> @@ -223,6 +229,7 @@ AC_OUTPUT([Makefile
> ? ? ? ? ? ?src/plugins/renderers/frame-buffer/Makefile
> ? ? ? ? ? ?src/plugins/renderers/drm/Makefile
> ? ? ? ? ? ?src/plugins/renderers/x11/Makefile
> + ? ? ? ? ? src/plugins/renderers/vga16fb/Makefile
> ? ? ? ? ? ?src/plugins/splash/Makefile
> ? ? ? ? ? ?src/plugins/splash/throbgress/Makefile
> ? ? ? ? ? ?src/plugins/splash/fade-throbber/Makefile
Stray hunk here...
--Ray
------------------------------
Message: 3
Date: Thu, 18 Mar 2010 15:08:28 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH 19/21] [terminal] guard open and close against
repeated calls
To: Scott James Remnant <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, Mar 18, 2010 at 1:06 AM, Scott James Remnant <[email protected]> wrote:
> Since we have a status flag whether or not the terminal fd is open,
> use it in the open and close functions to guard against repeated
> calls.
Should these be assertions?
--Ray
------------------------------
Message: 4
Date: Thu, 18 Mar 2010 15:21:24 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH 00/21] Improve VT Handling
To: Scott James Remnant <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, Mar 18, 2010 at 1:24 AM, Scott James Remnant <[email protected]> wrote:
> One of the main differences between Ubuntu's use of Plymouth and
> Fedora's is that on Ubuntu we've tried to keep the X server on VT7
> so that the historical documentation of Ctrl-Alt-F1 giving you a
> text console is preserved.
>
> This obviously means that for a smooth transition, Plymouth must also
> run on VT7.
>
> We discovered that although Plymouth does have code to attempt to deal
> with VTs, none of it is quite right and there are many paths that don't
> work unless Plymouth is run on VT1.
>
> This patch set fixes our known problems with the VT handling making it
> possible to run Plymouth on any VT of your choosing, with VT1 remaining
> the default.
There are some great patches and fixes here. I've given it a cursory
look over, and it all looks pretty reasonable.
I'll give it a closer look soon, but I'd like you to go ahead and
commit this stuff to master right away. We can do any fix ups that
might be necessary once it's landed.
The normal way I land big patchsets like this is:
1) put the changes in a local branch that's rebased to latest master
2) git push origin local-branch-name
3) git merge --no-ff --no-merge local-branch-name
4) git commit with a message like:
[branch-merge] Improve VT Handling
Summary of how all changes come together go here. You could probably
just cut-and-paste your PATCH 00/21 text here.
5) git push origin master
This is a little different than how other projects work, but it has
the nice advantage that it groups the commits as one contained unit in
history with a nice message explaining why they're grouped.
Thanks for doing the legwork on this.
--Ray
------------------------------
Message: 5
Date: Thu, 18 Mar 2010 19:54:53 +0000
From: Scott James Remnant <[email protected]>
Subject: Re: [PATCH 09/21] [terminal] drop next_active_vt
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <1268942093.913.2.ca...@quest>
Content-Type: text/plain; charset="utf-8"
On Thu, 2010-03-18 at 15:02 -0400, Ray Strode wrote:
> I was pretty sure you have to call VT_WAITACTIVE after VT_ACTIVATE for
> internal kernel bookkeeping reasons. I have some vague notion of
> someone (Alan Cox?) telling me that at some point. Looking though, I
> can't find any evidence that I'm right.
>
> In fact, it seems there's a new VT_WAITEVENT interface that directly
> conflicts with the idea that VT_WAITACTIVE is mandatory. So i'm going
> to say i'm wrong.
>
As far as I can tell, even X doesn't call VT_WAITACTIVE
You need it if you call VT_ACTIVATE and then expect to be on the VT you
activated, since that ioctl() returns immediately and doesn't block.
There are reasons you might need that, synchronous code for example; or
if you need to use one of the silly ioctl()s that require that the VT be
the foreground one (font and keymap settings, etc.)
If you have the VT you're going to activate in VT_PROCESS mode though,
you get a signal when you enter, so that's just a good a way of knowing
that you're on the VT - indeed better because you're then not blocking
on the VT you're leaving being in VT_PROCESS and waiting for something
else.
So yeah, in summary, this is better and I'm pretty sure it's valid (it
certainly works :p)
Scott
--
Scott James Remnant
[email protected]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/plymouth/attachments/20100318/c20c7b57/attachment-0001.pgp>
------------------------------
Message: 6
Date: Thu, 18 Mar 2010 19:59:17 +0000
From: Scott James Remnant <[email protected]>
Subject: Re: [PATCH 21/21] [configure] allow boot and shutdown ttys to
be changed
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <1268942357.913.3.ca...@quest>
Content-Type: text/plain; charset="utf-8"
On Thu, 2010-03-18 at 15:06 -0400, Ray Strode wrote:
> On Thu, Mar 18, 2010 at 1:16 AM, Scott James Remnant <[email protected]> wrote:
> > @@ -223,6 +229,7 @@ AC_OUTPUT([Makefile
> > src/plugins/renderers/frame-buffer/Makefile
> > src/plugins/renderers/drm/Makefile
> > src/plugins/renderers/x11/Makefile
> > + src/plugins/renderers/vga16fb/Makefile
> > src/plugins/splash/Makefile
> > src/plugins/splash/throbgress/Makefile
> > src/plugins/splash/fade-throbber/Makefile
> Stray hunk here...
>
Yeah caught that after sending the patches;
Will obviously send the vga16fb patches later, once the next batch or
two are out of the way
Scott
--
Scott James Remnant
[email protected]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/plymouth/attachments/20100318/ee5ac56f/attachment-0001.pgp>
------------------------------
Message: 7
Date: Thu, 18 Mar 2010 20:00:08 +0000
From: Scott James Remnant <[email protected]>
Subject: Re: [PATCH 19/21] [terminal] guard open and close against
repeated calls
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <1268942408.913.4.ca...@quest>
Content-Type: text/plain; charset="utf-8"
On Thu, 2010-03-18 at 15:08 -0400, Ray Strode wrote:
> On Thu, Mar 18, 2010 at 1:06 AM, Scott James Remnant <[email protected]> wrote:
> > Since we have a status flag whether or not the terminal fd is open,
> > use it in the open and close functions to guard against repeated
> > calls.
>
> Should these be assertions?
>
I thought about that; but one advantage of just making them guards is
that then the renderers and plugins don't have to care.
They can just call ply_terminal_open() on the terminal, without first
checking the is_open -- which makes it much more "I need this terminal
open, open it if it isn't" -- and I kinda like that.
Scott
--
Scott James Remnant
[email protected]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/plymouth/attachments/20100318/9bfbd232/attachment-0001.pgp>
------------------------------
Message: 8
Date: Thu, 18 Mar 2010 16:06:27 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH 09/21] [terminal] drop next_active_vt
To: Scott James Remnant <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, Mar 18, 2010 at 3:54 PM, Scott James Remnant <[email protected]> wrote:
> As far as I can tell, even X doesn't call VT_WAITACTIVE
It didn't used to on the shutdown path until a couple of years ago.
It's always done it on the start up path, I think, though.
It was added to fix races between one X quitting and another starting
(some issue Red Hat was hitting with RHGB)
>
> You need it if you call VT_ACTIVATE and then expect to be on the VT you
> activated, since that ioctl() returns immediately and doesn't block.
> There are reasons you might need that, synchronous code for example; or
> if you need to use one of the silly ioctl()s that require that the VT be
> the foreground one (font and keymap settings, etc.)
Right, I thought there was some book keeping reason as well, though,
for the kernel to clean up some allocated resource, but I dug a bit
and couldn't find anything to support that. So I think I'm probably
wrong.
> So yeah, in summary, this is better and I'm pretty sure it's valid (it
> certainly works :p)
Good enough for me.
--Ray
------------------------------
Message: 9
Date: Thu, 18 Mar 2010 16:08:53 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH 19/21] [terminal] guard open and close against
repeated calls
To: Scott James Remnant <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
> I thought about that; but one advantage of just making them guards is
> that then the renderers and plugins don't have to care.
>
> They can just call ply_terminal_open() on the terminal, without first
> checking the is_open -- which makes it much more "I need this terminal
> open, open it if it isn't" -- and I kinda like that.
Alright, sounds fine then. It would probably be a good idea to have a
ply_trace in those cases just so we can identify when it happens when
debugging.
--Ray
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 17, Issue 12
****************************************
