Automatically choosing a VT for DRM compositor?

[Pekka Paalanen]

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?

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


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

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?


Thanks,
pq
-------------- 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/20171027/ba4750d2/attachment.sig>