Automatically choosing a VT for DRM compositor?

Fri Oct 27 14:10:02 UTC 2017

On Fri, Oct 27, 2017 at 8:05 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Fri, 27 Oct 2017 07:05:13 -0500
> Matt Hoosier <matt.hoosier at gmail.com> wrote:
>
> > HI Pekka,
> >
> > On Thu, Oct 26, 2017 at 2:06 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >
> > > On Tue, 24 Oct 2017 08:26:04 -0500
> > > Matt Hoosier <matt.hoosier at gmail.com> wrote:
> > >
> > > > On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen <ppaalanen at gmail.com
> >
> > > wrote:
> > > > > On Mon, 23 Oct 2017 14:37:37 -0500
> > > > > Matt Hoosier <matt.hoosier at gmail.com> wrote:
> > > > >
> > > > >> It would be nice for non-session uses of Weston (embedded
> systems) if
> > > > >> the controlling TTY didn't need to be manually supplied.
> > > > >>
> > > > >> Has anybody suggested using something like VT_OPENQRY in the
> > > > >> weston-launcher code to pick a TTY if one wasn't manually given?
> (Or
> > > > >> if that's too auto-magic for taste here, then only do that if a
> > > > >> specific command-line option is supplied.)
> > > > >
> > > > > Hi,
> > > > >
> > > > > I do not recall such proposals. I'd like to hear more about your
> use
> > > > > case.
>
> > > You're right in that Weston shouldn't care, but I would expect the
> > > system designer or administrator to care, usually.
> > >
> >
> > I think that it would only typically be important if the designer has
> some
> > use-case for actively hopping among more than one VT. That is, at least,
> > not my case. Weston is the only DRM user -- it just needs some valid VT
> to
> > use. I would be interested to hear counterexamples though. Are you
> thinking
> > that some program like Plymouth would get used early during boot, and it
> > would need to persist and occasionally show itself during the main body
> of
> > the runtime?
>
> Nope. My rationale is simply: if you don't care which VT is being used,
> why not hardcode tty0 in a systemd unit and be done with it?
>

I appreciate that though. In practice, it's difficult to guarantee that
there won't be some transient early splash type program squatting on the
first TTY which is just waiting to die until somebody comes along and
VT_ACTIVATE's away from it.

I hope that doesn't sound like a bait-and-switch argument. I'm not denying
that there may be some random little graphical program that uses VT's. My
claim is just that these are usually not relevant to the main runtime of
the system. Once Weston get running, it owns the foreground graphics
permanently.

>
> > >
> > > If there actually is a need to runtime discover a free VT because there
> > > are also other units grabbing VTs, then would you not have a race
> > > causing everything to be launched on random VTs?
> > >
> >
> > In the spirit of my reply above, I don't think there are really other
> units
> > to be worried about racing against.
> >
> >
> > >
> > > You should be able to avoid the TTYPath hardcoding by using a systemd
> > > instantiated units (e.g. getty at .service) or template units. The
> > > instantiated approach will leave the TTY choice for the system
> > > administrator, but guarantee the same tty is always used once
> > > "configured".
> > >
> > > FWIW, running Weston directly as root is meant only for debugging. If
> > > you are using systemd units, I would very much recommend using the
> > > systemd PAM directives to run weston as non-root and relying on logind
> > > instead of launcher-direct.c. An alternative would be to arrange
> > > auto-login with a getty and launch weston from systemd user units along
> > > with all the other stuff you need, but it's not always as flexible as
> > > one might like.
> > >
> >
> > I had a look at the logind support code in Weston does. Unless I'm
> missing
> > something, I think it's fair to summarize it as simply code that queries
> > systemd to ask "what TTY has already been allocated for the cgroup in
> which
> > my PID is a member?". If that's right, then I think taking this approach
> > still tacitly agrees to the idea that a system designer has hand-picked a
> > TTY (whether through a getty at .service default instance, a weston@
> <tty>.service
> > default instance, or similar).
>
> I'm not sure of the details, but yes, that's what it does. From what I
> could tell, I suppose the logind-launcher intergration also cannot be
> extended to open the next free VT, unless there is logind DBus API to
> do that.
>
> As an unrelated side note, there is also the systemd plugin in Weston,
> which you might find useful if you are not using it already.
>

Oh yes, the systemd integration is very useful. In particular (though not
much fanfare is given to it in the notes), socket activation works
extremely well. You can use this to squeeze out several hundreds of
milliseconds' extra boot speed by using systemd socket activation as the
guarantor of freedom from race conditions from the clients' perspective,
but also then start the main weston.service unit in parallel so that Weston
is typically immediately ready to dispatch requests submitted through the
Unix domain socket by the time clients actually get around to doing
wl_display_connect().

>
>
> > > Ps. It might be interesting to make Weston work in a system where the
> > > kernel has CONFIG_VT=n. ;-)
> > >
> >
> > Making Weston operate with CONFIG_VT=n would indeed be interesting.
> >
> > I think I'd just like to float the original question again: would anybody
> > be receptive to a very limited patch that does nothing more than narrowly
> > allow Weston to survive the TTY selection phase in the absence of any
> > external hint such as --tty=, logind, or being spawned from a process
> whose
> > stdin is already a VT?
> >
> > If that seems contrary to the direction you'd like to take Weston, that's
> > okay. It's not a huge burden to do explicit TTY selection at
> system-design
> > time. That just seems a bit unnecessary for devices whose only raw DRM
> user
> > is Weston.
>
> If someone writes the patch and someone else reviews and lands it, I
> suppose I'm ok with that. We have two non-logind launchers: direct and
> weston-launch the suid binary.
>

I'll volunteer to be the first 'someone'. Maybe I can convince daniels to
be the second. ;)

Because the weston-launch approach is centered around the notion of
executing from some session, I think I'd be inclined not to touch the suid
binary. Do you think that would be objectionably unsymmetric?

>
> I do know people have struggled with starting weston via ssh or a
> serial terminal. Would this make that simply work? I think that would
> be a good justification.
>

Yes, serial and ssh terminal usage is (in addition to formal systemd usage)
one of the clunky situations that demands the --tty command line option
right now. This is typical for iterative development of Weston on embedded
devices. And because the preceding instance of the Weston process may well
have crashed and not cleaned up the VT it was on, you always have to be
changing the value of that --tty parameter. Automatic selection would be
extremely convenient for this case too. (Note, I'm not talking about
unbounded growth in the numeric value of the -tty= parameter. Just toggling
back and forth between '1' and '2', for example.)

>
> OTOH, I would always recommend relying on logind if it is present in a
> system because that is the most appropriate way to use weston: logind
> handles the privilege separation, session multiplexing, revoking input
> devices and DRM master, etc. However, I have no idea how to launch with
> logind via ssh or serial aside from writing a systemd service unit.
>
> I wonder, if VT_OPENQRY picks, say, tty2, and then Weston VT-switches
> there, does something prevent it from clashing with the getty that
> systemd would launch there on the first switch to tty2? Or is it a
> non-issue?
>

I'm not certain about that. In order to prevent ugly text console prompts
from appearing transiently on-screen prior to Weston's launch, I (as the
system designer) typically mask all getty@ unit instances which would
operate on VT's.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171027/d8db5335/attachment-0001.html>