<div dir="ltr"><font face="monospace, monospace">On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> 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>> Do you mean in 'weston-launch' specifically, or in all the launcher<br>> implementations?</font><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Sorry for the imprecise wording. I'm not thinking of a adding a duty that's specifically carried out by the weston-launch executable. My suggestion would be to add the logic somewhere in with the code in launcher-direct.c that gets executed directly in-process when Weston is invoked something like 'weston --tty=2 --backend=drm-backend.so ...'.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I think that the call graph in mind would be something like:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">  compositor-drm.c:      drm_backend_create()</font></div><div><font face="monospace, monospace">  launcher-util.c:         weston_launcher_connect()</font></div><div><font face="monospace, monospace">  launcher-direct.c:         launcher_direct_connect()</font></div><div><font face="monospace, monospace">  launcher-direct.c:           setup_tty()</font></div><div><font face="monospace, monospace"><br>> If for 'weston-launch' specifically, then I'd like to ask why you want<br>> that instead of a logind service?<br>><br>> I've been hoping there would be no need for new development on<br>> weston-launch. It is sensitive code, being setuid root. It seems it<br>> cannot be nicely generalized to support all libweston-based compositors.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I'm uncertain whether the code impacted in launcher-direct.c actually gets exercised too by some indirect path in weston-launch. Maybe you know the answer to that?</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">><br>> What is the launching context in you use case? E.g.<br>> - manual login, type 'weston' in VT<br>> - type 'weston -Bdrm-backend.so' in a terminal window<br>> - launching weston from a systemd system unit<br>> - launching weston from a systemd user unit<br>> - something else?</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">The case I'd like to improve is launching weston from a systemd system unit. Currently that involves either hacking the systemd unit with a manually chosen TTYPath= directive, or else baking in a command-line option like --tty=3 to Weston. Those both feel forced and (in my opinion) require building in an unnecessary amount of product-specific knowledge into the systemd unit; there's no reason I can see that Weston should really care what VT is used.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Maybe I'm not recognizing some reason why it's advantageous for Weston to have an explicitly chosen VT though?<br><br>> What is the "non-session" use exactly? Why do you not care which VT<br>> weston will occupy in that case?</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">This is another case where I was groping for a good term to use. "Non-session" isn't quite right. What I meant was: the instance of Weston is</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">- Well known to systemd;</font></div><div><font face="monospace, monospace">- Not the parent of the graphical clients (those are each managed from their own systemd units); and</font></div><div><font face="monospace, monospace">- Not a "session" in the sense of being a login initiated explicitly from a VT in the way that GDM does.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">The identity of the VT on which Weston binds doesn't really seem to matter for an embedded device. There's no user sitting at the keyboard typing Ctrl+Alt+F2 to multiplex among numerous sessions.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">If any of the regular contributors here who work with embedded devices have a different experience, I'd be interested to hear. But typically, I find that every silicon manufacturer's delivery of Weston has a default systemd unit that does one of the following:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">  - uses TTYPath=</font></div><div><font face="monospace, monospace">  - passes some arbitrary value to Weston with --tty=</font></div><div><font face="monospace, monospace">  - wraps the entire Weston process with openvt(1)</font></div><div><font face="monospace, monospace"><br><br>> I haven't checked recently, but I have a feeling that Weston is not<br>> expecting to be spawned on a currently inactive VT, so that might need<br>> fixing as well.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I think this use-case actually works well already. If you open up an SSH shell to an embedded device (hence, its controlling terminal is just a PTY rather than a Linux VT) you can do:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    weston --tty=1; sleep 1 &<br>    weston --tty=2; sleep 1 &</font></div><div><font face="monospace, monospace">    weston --tty=3; sleep 1</font></div><div><font face="monospace, monospace">    ...</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Each instance of Weston will manage to activate the VT it's been told to use.</font></div><div><font face="monospace, monospace"><br>>> The closest I can find to a question about this topic prior on the<br>>> mailing list is<br>>> <a href="https://lists.freedesktop.org/archives/wayland-devel/2013-October/011472.html">https://lists.freedesktop.org/archives/wayland-devel/2013-October/011472.html</a>.<br>>> That change was never adopted, but it doesn't look like the use of<br>>> VT_OPENQRY has anything to do with Kristian's objections at the time.<br>><br>> Picking the first free VT sounds fine to me, but do display servers<br>> actually do that on their own or does e.g. the graphical login manager<br>> do it for them? Or rather, when and who usually picks the VT?</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I think that I get the point you're making about the graphical login manager selecting the VT. I agree for desktop usage. The embedded cases I keep seeing have no graphical login manager though. You might be likely to respond that in this situation weston-launch should be the poor-man's graphical login manager. I have some thoughts on why that's awkward when crafting a systemd system unit -- we can maybe discuss that more if you're inclined to pursue it.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Thanks,</font></div><div><font face="monospace, monospace">Matt</font></div></div>