Automatically choosing a VT for DRM compositor?

Fri Oct 27 12:05:13 UTC 2017

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.
> > >
> > > Do you mean in 'weston-launch' specifically, or in all the launcher
> > > implementations?
> >
> > Sorry for the imprecise wording. I'm not thinking of a adding a duty
> that's
> > specifically carried out by the weston-launch executable. My suggestion
> > would be to add the logic somewhere in with the code in launcher-direct.c
> > that gets executed directly in-process when Weston is invoked something
> > like 'weston --tty=2 --backend=drm-backend.so ...'.
> >
> > I think that the call graph in mind would be something like:
> >
> >   compositor-drm.c:      drm_backend_create()
> >   launcher-util.c:         weston_launcher_connect()
> >   launcher-direct.c:         launcher_direct_connect()
> >   launcher-direct.c:           setup_tty()
>
> Ah, so the launcher direct path only, which means you run weston and
> all its clients as root. Weston does spawn some clients of its own
> automatically, depending on configuration. None of them are written to
> be safe to run as root.
>

That's understood. And while I admit to being presently guilty of running
Weston as root in this style, it's not difficult at all to use system's
'User=' directive to change that. As far as I can tell though, choosing to
execute as some non-zero UID is a separate question than TTY management
though.

>
> > > If for 'weston-launch' specifically, then I'd like to ask why you want
> > > that instead of a logind service?
> > >
> > > I've been hoping there would be no need for new development on
> > > weston-launch. It is sensitive code, being setuid root. It seems it
> > > cannot be nicely generalized to support all libweston-based
> compositors.
> >
> > I'm uncertain whether the code impacted in launcher-direct.c actually
> gets
> > exercised too by some indirect path in weston-launch. Maybe you know the
> > answer to that?
>
> No, it does not. launcher-direct.c is purely for running weston as
> root, without any helpers like logind or weston-launch.
>
> > >
> > > What is the launching context in you use case? E.g.
> > > - manual login, type 'weston' in VT
> > > - type 'weston -Bdrm-backend.so' in a terminal window
> > > - launching weston from a systemd system unit
> > > - launching weston from a systemd user unit
> > > - something else?
> >
> > The case I'd like to improve is launching weston from a systemd system
> > unit. Currently that involves either hacking the systemd unit with a
> > manually chosen TTYPath= directive, or else baking in a command-line
> option
> > like --tty=3 to Weston. Those both feel forced and (in my opinion)
> require
> > building in an unnecessary amount of product-specific knowledge into the
> > systemd unit; there's no reason I can see that Weston should really care
> > what VT is used.
> >
> > Maybe I'm not recognizing some reason why it's advantageous for Weston to
> > have an explicitly chosen VT though?
>
> 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?

>
> 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).

>
> Btw. have you seen https://phabricator.freedesktop.org/T63 ?
> I think we could use a bunch of example systemd unit files in Weston
> upstream, but have had no time to work on that.
>
> > > What is the "non-session" use exactly? Why do you not care which VT
> > > weston will occupy in that case?
> >
> > This is another case where I was groping for a good term to use.
> > "Non-session" isn't quite right. What I meant was: the instance of
> Weston is
> >
> > - Well known to systemd;
> > - Not the parent of the graphical clients (those are each managed from
> > their own systemd units); and
> > - Not a "session" in the sense of being a login initiated explicitly
> from a
> > VT in the way that GDM does.
> >
> > The identity of the VT on which Weston binds doesn't really seem to
> matter
> > for an embedded device. There's no user sitting at the keyboard typing
> > Ctrl+Alt+F2 to multiplex among numerous sessions.
>
> Ok, that makes sense.
>
> > If any of the regular contributors here who work with embedded devices
> have
> > a different experience, I'd be interested to hear. But typically, I find
> > that every silicon manufacturer's delivery of Weston has a default
> systemd
> > unit that does one of the following:
> >
> >   - uses TTYPath=
> >   - passes some arbitrary value to Weston with --tty=
> >   - wraps the entire Weston process with openvt(1)
>
> Right. :-)
>
> > > I haven't checked recently, but I have a feeling that Weston is not
> > > expecting to be spawned on a currently inactive VT, so that might need
> > > fixing as well.
> >
> > I think this use-case actually works well already. If you open up an SSH
> > shell to an embedded device (hence, its controlling terminal is just a
> PTY
> > rather than a Linux VT) you can do:
> >
> >     weston --tty=1; sleep 1 &
> >     weston --tty=2; sleep 1 &
> >     weston --tty=3; sleep 1
> >     ...
> >
> > Each instance of Weston will manage to activate the VT it's been told to
> > use.
>
> Indeed, you are right. Looks like all three launcher implementations
> make the switch.
>
> > >> The closest I can find to a question about this topic prior on the
> > >> mailing list is
> > >>
> > https://lists.freedesktop.org/archives/wayland-devel/2013-
> October/011472.html
> > .
> > >> That change was never adopted, but it doesn't look like the use of
> > >> VT_OPENQRY has anything to do with Kristian's objections at the time.
> > >
> > > Picking the first free VT sounds fine to me, but do display servers
> > > actually do that on their own or does e.g. the graphical login manager
> > > do it for them? Or rather, when and who usually picks the VT?
> >
> > I think that I get the point you're making about the graphical login
> > manager selecting the VT. I agree for desktop usage. The embedded cases I
> > keep seeing have no graphical login manager though. You might be likely
> to
> > respond that in this situation weston-launch should be the poor-man's
> > graphical login manager. I have some thoughts on why that's awkward when
> > crafting a systemd system unit -- we can maybe discuss that more if
> you're
> > inclined to pursue it.
>
> No need. :-)
>
> weston-launch could indeed be the poor-man's login manager when you
> don't have systemd.
>
> I think that weston-launch should never be used in a systemd unit,
> system or user. You will have logind, it's better to rely on that
> instead. The poor-man's login manager is the systemd system unit
> written to launch weston as a specific user, which I believe will also
> set up the user session as a side effect.
>
> With logind, it seems the VT/tty is chosen before Weston starts and
> launcher-logind.c just ensures it's the same as what the user defined
> with --tty if any. I think that would make it not possible to let
> Weston pick the tty on logind - you do it in the unit file.
>
> After all the above, would you still want automatic allocation of a VT
> in any of the weston launcher implementations?
>
>
> Thanks,
> pq
>
> 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.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171027/f7163c4e/attachment.html>