Re: [oe-core][RFC] Display manager proposal for x11 and wayland

[Randolph Sapp <rs@ti.com>]

On Wed Mar 12, 2025 at 5:52 AM CDT, Otavio Salvador wrote:
> Hi Alexander,
>
> I totally get your concerns about long-term maintainability and how adding
> new components to oe-core can complicate things. Still, Randolph's idea
> does make a lot of sense, especially since our current setup has code
> scattered in different places, making it tricky to maintain and potentially
> causing issues down the road.
>
> Checking out Randolph’s proposal, or maybe something similar, could really
> help tidy things up and improve maintainability for oe-core long-term.
>
> Looking forward to hearing more thoughts on this!
>

Thank you Otavio

> Em qua., 12 de mar. de 2025 às 06:39, Alexander Kanavin via
> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
> escreveu:
>
>> I have a couple of concerns:
>>
>> - can this event handling be achieved simply by using udevadm which is
>> available in any init system?

Yes and no. Just detecting when a device is registered with the drm subsystem
can be achieved with udev though. Udev events for display hotplug events do not
seem to be easy to identify and cannot be handled without some custom daemon
anyway.

One of our workarounds was to add a rule to make systemd track our main dri
device and register a .device unit that we could add as a dependency to the
desktop init service. Great for systemd init with a singe device, ignoring
hotplug.

That being said, emptty doesn't support hotplug events right now either, but I'm
thinking about contributing to that project if people are interested.

>> - who is the author? What if they abandon the component? We've been
>> reluctant to insert core graphical dependencies (e.g. more interesting
>> compositors than weston) on not widely used things with unclear origin
>> and support promise.

As far as the author goes, that's fair. This is one of their more popular
repositories and I'm not personally familiar with them. That's always a risk
though, and when it comes to lightweight display managers with auto-login
capabilities the only other option is lightdm, which comes with potential
license issues being GPL-3.0.

>> - can you produce a patchset that showcases the benefits?

Certainly. Considering our current release window and the bug that brought all
this up, I'll have a little demo for Weston I can post in the next few days.

>> On Wed, 12 Mar 2025 at 01:46, Randolph Sapp via lists.openembedded.org
>> <rs=ti.com@lists.openembedded.org> wrote:
>> >
>> > We've recently run into some issues with weston-init attempting to start
>> > Weston prior to all drm devices being registered. There's not really a
>> > good, scriptable mechanism to listen in to device registration events
>> > that works with the existing weston-init package. Well, at least one
>> > that doesn't involve polling files or introducing more dependency on the
>> > init system being used.
>> >
>> > I also see there is also a lot of scripting around starting X11,
>> > xserver-nodm-init, that (from my limited review) should experience the
>> > same issue.
>> >
>> > I'd like to introduce the following display manager for oe-core, emptty
>> > [1]. This display manager is, as described upstream, a "Dead simple CLI
>> > Display Manager on TTY". It supports both x11 and wayland sessions, with
>> > togglable build parameters to completely remove x11 and pam
>> > dependencies. It's licensed MIT, which shouldn't be an issue for any
>> > users. (It is written in Go, if you have opinions about that.)
>> >
>> > With this, both weston-init and the xserver-nodm-init packages can be
>> > re-tuned to leverage this display manager and simply add a user and
>> > emptty config for an autologin session. This can resolve the current
>> > behavior across init systems without additional scripting, and move some
>> > development out of this layer.
>> >
>> > I already have a recipe for emptty, but I figured I would reach out for
>> > comment to recent contributors before I submit any patches playing with
>> > the existing init packages.
>> >
>> > [1] https://github.com/tvrzna/emptty
>> >
>> > - Randolph
>> >