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

[Randolph Sapp <rs@ti.com>]

On Wed Mar 12, 2025 at 12:58 PM CDT, Randolph Sapp wrote:
> 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.

I've posted a RFC series for scarthgap showing my proposed solution for
weston-init.

https://lists.openembedded.org/g/openembedded-core/message/212726

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