Automatically choosing a VT for DRM compositor?

[Pekka Paalanen]

On Fri, 27 Oct 2017 09:10:02 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

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

Hi,

I'm afraid that sound quite much like you don't actually know what runs
in the (embedded) system you are developing.

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

Does this mean you would only cater for the "run weston as root"
case? ;-)

If the aim is to make it easier to test during development, that's fine
by me. But if the aim is to use that for production, then I'd be
disappointed. Of course, we cannot know what people will use it for.

I don't think I could NAK the patch only because of adding differences
between the launchers.


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

Right, so this is the underlying true reason for the suggestion.

Does something eventually clean up the VTs where weston/direct crashed,
or will you run out of VTs soon?

If you did not run weston directly as root, then there would always be
something, either weston-launch or logind, to reset the VT to a sane
state, I believe... weston-launch should, I presume logind as well?


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

I was more thinking about input devices. The launchers intend to block
input from the TTY when weston starts, but there have been issues where
it somehow failed and when you typed in a weston session the same
typing would go into the TTY (text login, shell, ...) as well.


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/20171030/b74cc053/attachment.sig>