Automatically choosing a VT for DRM compositor?

[Matt Hoosier]

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.
>
> Do you mean in 'weston-launch' specifically, or in all the launcher
> implementations?

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

I think that the call graph in mind would be something like:

  compositor-drm.c:      drm_backend_create()
  launcher-util.c:         weston_launcher_connect()
  launcher-direct.c:         launcher_direct_connect()
  launcher-direct.c:           setup_tty()

> If for 'weston-launch' specifically, then I'd like to ask why you want
> that instead of a logind service?
>
> I've been hoping there would be no need for new development on
> weston-launch. It is sensitive code, being setuid root. It seems it
> cannot be nicely generalized to support all libweston-based compositors.

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?

>
> What is the launching context in you use case? E.g.
> - manual login, type 'weston' in VT
> - type 'weston -Bdrm-backend.so' in a terminal window
> - launching weston from a systemd system unit
> - launching weston from a systemd user unit
> - something else?

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.

Maybe I'm not recognizing some reason why it's advantageous for Weston to
have an explicitly chosen VT though?

> What is the "non-session" use exactly? Why do you not care which VT
> weston will occupy in that case?

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

- Well known to systemd;
- Not the parent of the graphical clients (those are each managed from
their own systemd units); and
- Not a "session" in the sense of being a login initiated explicitly from a
VT in the way that GDM does.

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.

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:

  - uses TTYPath=
  - passes some arbitrary value to Weston with --tty=
  - wraps the entire Weston process with openvt(1)


> I haven't checked recently, but I have a feeling that Weston is not
> expecting to be spawned on a currently inactive VT, so that might need
> fixing as well.

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:

    weston --tty=1; sleep 1 &
    weston --tty=2; sleep 1 &
    weston --tty=3; sleep 1
    ...

Each instance of Weston will manage to activate the VT it's been told to
use.

>> The closest I can find to a question about this topic prior on the
>> mailing list is
>>
https://lists.freedesktop.org/archives/wayland-devel/2013-October/011472.html
.
>> That change was never adopted, but it doesn't look like the use of
>> VT_OPENQRY has anything to do with Kristian's objections at the time.
>
> Picking the first free VT sounds fine to me, but do display servers
> actually do that on their own or does e.g. the graphical login manager
> do it for them? Or rather, when and who usually picks the VT?

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.

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171024/151d7b89/attachment.html>