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

[Randolph Sapp <rs@ti.com>]

On Mon Sep 22, 2025 at 5:21 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> On Mon Sep 22, 2025 at 4:51 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
>> 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.
>
> Whoops, I see the issue now. v10 inbound.

Well, I know what the issue is, but I guess I should ask how people want to
address it. Currently, that test expect a root x11 instance to autostart. I have
it attempt to do that currently, and my old test images were being built with
"empty-root-password allow-empty-password allow-root-login" features enabled,
allowing it to proceed as usual. The password auth is what is currently failing.

1. We can do passwordless root auth for these by adjusting the pam rule for
emptty to allow auth as root for that application.

2. I would suggest that we instead make sure the root user is in the
nopasswdlogin group, as it makes it clear that the user has unprotected GUI
access.

I'm not sure either of these should really be allowed in a production
environment though. Technically we can disable this behavior outright when
ROOTLESS_X is set, but it's still a little odd to me.

3. Should the test images explicitly enable the empty-root-password
allow-empty-password? That means the x11 test will have to move from an
arbitrary runtime test to something like the way locales are currently tested.

Seems like solution 2 is the easiest and preserves the expected behavior for
that test, assuming people are okay with that behavior.

- Randolph