Re: [oe-core][PATCHv9 0/6] Display manager proposal for x11 and wayland

[Randolph Sapp <rs@ti.com>]

On Sun Sep 21, 2025 at 7:25 AM CDT, Mathieu Dubois-Briand wrote:
> On Thu Sep 18, 2025 at 11:48 PM CEST, rs wrote:
>> From: Randolph Sapp <rs@ti.com>
>>
>> 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.
>>
>> This lists myself as a maintainer of emptty as well as xserver-nodm-init and
>> xuser-account since these are currently unassigned and I've reworked them
>> significantly here.
>>
>> Sorry for the delay on this series. I found a few bugs in emptty that I wanted
>> to address before submitting this officially.
>>
>
> Hi Randolph,
>
> Thanks for your patch.
>
> I took this series, but it looks like we have a build issue, maybe only
> with altcfg distro:
>
> Traceback (most recent call last):
>   File "/srv/pokybuild/yocto-worker/qemux86-alt/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
>     return func(*args, **kwargs)
>   File "/srv/pokybuild/yocto-worker/qemux86-alt/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
>     return func(*args, **kwargs)
>   File "/srv/pokybuild/yocto-worker/qemux86-alt/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
>     return func(*args, **kwargs)
>   File "/srv/pokybuild/yocto-worker/qemux86-alt/build/meta/lib/oeqa/runtime/cases/xorg.py", line 31, in test_xorg_running
>     self.assertEqual(status, 0, msg=msg)
> AssertionError: 1 != 0 : Xorg does not appear to be running   PID USER       VSZ STAT COMMAND
> ...
> 2025/09/21 11:59:34 Closing PAM auth
> 2025/09/21 11:59:34 Failure setting user credentials
> 2025/09/21 11:59:34 Authentication failure
> ...
> RESULTS - xorg.XorgTest.test_xorg_running: FAILED (1.41s)
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/20/builds/2402
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/9/builds/2407
>
> Can you have a look at it please?
>
> Thanks,
> Mathieu

In the past auth issues can occur if the user was created after the current
system time (of which the default would be the kernel build time if it is unable
to get a value from NTP).

I've already tested this series with an equivalent config to poky-altcfg, with
both root and rootless x11. I reset my cache and did another local build to
match that CICD failure and it still works for me.

My local.conf for my test build was:

MACHINE ??= "qemux86"
DISTRO ??= "poky-altcfg"
BBMULTICONFIG ?= ""
IMAGE_CLASSES += "testimage"

Other variables were dictated by templateconf.cfg:

meta-poky/conf/templates/default

Is that automation setting anything that could possibly play with the build time
or system time values for the testimage? I'm not seeing anything in the logs,
but I'm also not seeing anything that reports the current config outright.

I guess I should add some messages for that as part of the test function
regardless.