Automatically choosing a VT for DRM compositor?

Mon Oct 30 13:45:24 UTC 2017

Hello Matt and Pekka,

Actually, we are OK with running weston with a static tty within a systemd service file, but launcher_direct_connect() function is failing when user is not root.

Therefore, we patched weston to remove the expilicit check for root user.  I am planning to send this patch to the mailing list.

We also updated ownership of drm and tty devices accordingly, so that weston can run as non-root user.

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937

> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at lists.freedesktop.org] On Behalf Of Matt Hoosier
> Sent: Montag, 30. Oktober 2017 14:28
> To: Pekka Paalanen
> Cc: wayland mailing list
> Subject: Re: Automatically choosing a VT for DRM compositor?
> 
> 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