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

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

[Randolph Sapp]

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

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

[Alexander Kanavin]

I have a couple of concerns:

- can this event handling be achieved simply by using udevadm which is
available in any init system?

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

- can you produce a patchset that showcases the benefits?

Alex

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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#212636): https://lists.openembedded.org/g/openembedded-core/message/212636
> Mute This Topic: https://lists.openembedded.org/mt/111652153/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 3557 bytes --]

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!

Cheers,

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?
>
> - 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.
>
> - can you produce a patchset that showcases the benefits?
>
> Alex
>
> 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
> >
> >
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#212640):
> https://lists.openembedded.org/g/openembedded-core/message/212640
> Mute This Topic: https://lists.openembedded.org/mt/111652153/3617537
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> otavio.salvador@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854

[-- Attachment #2: Type: text/html, Size: 5180 bytes --]

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

[Randolph Sapp]

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

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

[Randolph Sapp]

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