<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 27, 2017 at 8:05 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 27 Oct 2017 07:05:13 -0500<br>
<span class="">Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>
<br>
> HI Pekka,<br>
><br>
> On Thu, Oct 26, 2017 at 2:06 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
><br>
> > On Tue, 24 Oct 2017 08:26:04 -0500<br>
> > Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>
> ><br>
> > > On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>><br>
> > wrote:<br>
> > > > On Mon, 23 Oct 2017 14:37:37 -0500<br>
> > > > Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>
> > > ><br>
> > > >> It would be nice for non-session uses of Weston (embedded systems) if<br>
> > > >> the controlling TTY didn't need to be manually supplied.<br>
> > > >><br>
> > > >> Has anybody suggested using something like VT_OPENQRY in the<br>
> > > >> weston-launcher code to pick a TTY if one wasn't manually given? (Or<br>
> > > >> if that's too auto-magic for taste here, then only do that if a<br>
> > > >> specific command-line option is supplied.)<br>
> > > ><br>
> > > > Hi,<br>
> > > ><br>
> > > > I do not recall such proposals. I'd like to hear more about your use<br>
> > > > case.<br>
<br>
</span><span class="">> > You're right in that Weston shouldn't care, but I would expect the<br>
> > system designer or administrator to care, usually.<br>
> ><br>
><br>
> I think that it would only typically be important if the designer has some<br>
> use-case for actively hopping among more than one VT. That is, at least,<br>
> not my case. Weston is the only DRM user -- it just needs some valid VT to<br>
> use. I would be interested to hear counterexamples though. Are you thinking<br>
> that some program like Plymouth would get used early during boot, and it<br>
> would need to persist and occasionally show itself during the main body of<br>
> the runtime?<br>
<br>
</span>Nope. My rationale is simply: if you don't care which VT is being used,<br>
why not hardcode tty0 in a systemd unit and be done with it?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> ><br>
> > If there actually is a need to runtime discover a free VT because there<br>
> > are also other units grabbing VTs, then would you not have a race<br>
> > causing everything to be launched on random VTs?<br>
> ><br>
><br>
> In the spirit of my reply above, I don't think there are really other units<br>
> to be worried about racing against.<br>
><br>
><br>
> ><br>
> > You should be able to avoid the TTYPath hardcoding by using a systemd<br>
> > instantiated units (e.g. getty@.service) or template units. The<br>
> > instantiated approach will leave the TTY choice for the system<br>
> > administrator, but guarantee the same tty is always used once<br>
> > "configured".<br>
> ><br>
> > FWIW, running Weston directly as root is meant only for debugging. If<br>
> > you are using systemd units, I would very much recommend using the<br>
> > systemd PAM directives to run weston as non-root and relying on logind<br>
> > instead of launcher-direct.c. An alternative would be to arrange<br>
> > auto-login with a getty and launch weston from systemd user units along<br>
> > with all the other stuff you need, but it's not always as flexible as<br>
> > one might like.<br>
> ><br>
><br>
> I had a look at the logind support code in Weston does. Unless I'm missing<br>
> something, I think it's fair to summarize it as simply code that queries<br>
> systemd to ask "what TTY has already been allocated for the cgroup in which<br>
> my PID is a member?". If that's right, then I think taking this approach<br>
> still tacitly agrees to the idea that a system designer has hand-picked a<br>
> TTY (whether through a getty@.service default instance, a weston@<tty>.service<br>
> default instance, or similar).<br>
<br>
</span>I'm not sure of the details, but yes, that's what it does. From what I<br>
could tell, I suppose the logind-launcher intergration also cannot be<br>
extended to open the next free VT, unless there is logind DBus API to<br>
do that.<br>
<br>
As an unrelated side note, there is also the systemd plugin in Weston,<br>
which you might find useful if you are not using it already.<br></blockquote><div><br></div><div>Oh yes, the systemd integration is very useful. In particular (though not much fanfare is given to it in the notes), socket activation works extremely well. You can use this to squeeze out several hundreds of milliseconds' extra boot speed by using systemd socket activation as the guarantor of freedom from race conditions from the clients' perspective, but also then start the main weston.service unit in parallel so that Weston is typically immediately ready to dispatch requests submitted through the Unix domain socket by the time clients actually get around to doing wl_display_connect().</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> > Ps. It might be interesting to make Weston work in a system where the<br>
> > kernel has CONFIG_VT=n. ;-)<br>
> ><br>
><br>
> Making Weston operate with CONFIG_VT=n would indeed be interesting.<br>
><br>
> I think I'd just like to float the original question again: would anybody<br>
> be receptive to a very limited patch that does nothing more than narrowly<br>
> allow Weston to survive the TTY selection phase in the absence of any<br>
> external hint such as --tty=, logind, or being spawned from a process whose<br>
> stdin is already a VT?<br>
><br>
> If that seems contrary to the direction you'd like to take Weston, that's<br>
> okay. It's not a huge burden to do explicit TTY selection at system-design<br>
> time. That just seems a bit unnecessary for devices whose only raw DRM user<br>
> is Weston.<br>
<br>
</span>If someone writes the patch and someone else reviews and lands it, I<br>
suppose I'm ok with that. We have two non-logind launchers: direct and<br>
weston-launch the suid binary.<br></blockquote><div><br></div><div>I'll volunteer to be the first 'someone'. Maybe I can convince daniels to be the second. ;)</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I do know people have struggled with starting weston via ssh or a<br>
serial terminal. Would this make that simply work? I think that would<br>
be a good justification.<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
OTOH, I would always recommend relying on logind if it is present in a<br>
system because that is the most appropriate way to use weston: logind<br>
handles the privilege separation, session multiplexing, revoking input<br>
devices and DRM master, etc. However, I have no idea how to launch with<br>
logind via ssh or serial aside from writing a systemd service unit.<br>
<br>
I wonder, if VT_OPENQRY picks, say, tty2, and then Weston VT-switches<br>
there, does something prevent it from clashing with the getty that<br>
systemd would launch there on the first switch to tty2? Or is it a<br>
non-issue?<br></blockquote><div><br></div><div><br></div><div>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.</div></div></div></div>