Automatically choosing a VT for DRM compositor?

[Pekka Paalanen]

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.

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

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?

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.

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. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171026/f940f510/attachment-0001.sig>