Automatically choosing a VT for DRM compositor?

Mon Oct 30 13:26:55 UTC 2017

On Mon, Oct 30, 2017 at 5:10 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

For any one specific device, I do do know the fine-grained details. The
logistical trouble is in trying to harmonize the Weston configuration
across numerous devices (from different chip vendors), all of which differ
in ways which (to me) seem incidental. There is always a surplus of VT's
compared to the zero (or one) early-boot users of DRM, so it doesn't cause
me much worry that Weston will fail to select an available TTY.

It seems like there's a small mismatch of expectations. The existing
weston-launch implementation already uses VT_OPENQRY to select whatever
free VT happens to be available, if you do 'weston-launch -u <new_user>'.
I'm not really seeing the reason for that being okay, but regarding similar
automatic selection in the direct launcher as sloppy design.

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

No, that wasn't the intent. Running a DRM instance of Weston as a non-root
user doesn't require anything really more than adjusting ownership on the
/dev/tty* character devices so that the VT can be configured. I.e. a user
'weston' would need added to the 'tty' Unix group to have permission to run
ioctl(/dev/tty0, VT_OPENQRY) and would also need assigned ownership of
/dev/tty[0...7] in order to do KDSETMODE. Nobody would want to do that on
the desktop because of the security implications, but that seems fine to do
on an embedded system.

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

Okay, I appreciate that. If you find the replies (including the bit about
VT_OPENQRY already getting used in weston-launch) above unconvincing, let's
just drop the thought then.

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

Well, as I said above in the thought about making it less difficult to
deploy Weston across a fleet of devices which have varying configurations
of other small DRM/VT programs, this is just an additional reason. I don't
deny the usefulness during development too though.

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

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