[oe-core][PATCHv16 0/6] Display manager proposal for x11 and wayland

[oe-core][PATCHv16 0/6] Display manager proposal for x11 and wayland

[rs]

From: Randolph Sapp <rs@ti.com>

No functional changes. Just bumping PR to help with automated testing issues.

Information from v15:

Alright, now that cgo binary reproducibility has been addressed this should be
good to go. One slight change from v13, I replaced the inittab.d entry with a
rootfs-postcommands function since busybox-init doesn't support it.

Information from v13:

Hello maintainers, I wanted to wait for the latest tag to get cut before
bringing this back up, but here it is. This version addresses most of the
concerns I've seen regarding this series and adds on a little more functionality
considering we now allow for proper session selection.

This led me into a bit of a dive into the desktop-entry-spec [1] and associated
validator [2] that I wouldn't mind some opinions on as well if people are
curious about that.

Legacy details follow:

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 [3].
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.

[1] https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/110
[2] https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/merge_requests/28
[3] https://github.com/tvrzna/emptty

v2:
	- Address spelling issues in commit messages
	- Attempt to resolve some test related issues with weston
	- Add additional logs to X11 related tests
v3:
	- Reset AUTOLOGIN_MAX_RETRY to the default value of 2. When running
	  under QEMU the first auth attempt almost always fails.
v4:
	- Add a tmpfile entry for the x11 domain socket directory.
	- Remove some scripts associated with weston-init that were being
	  shipped with weston
v5:
	- Move tmpfile data to individual files
	- Add explicit entries for these in the FILES variable
v6:
	- Do not attempt to ship a tmpfiles.d entry in libx11
v7:
	- Include a backported fix for go/runtime to address segfault issues
	  reported on x86 platforms in previous revisions
v8:
	- Sign-off backported patch
v9:
	- Resolve merge conflict in maintainers file
v10:
	- Remove the ability to run x11 as root in xserver-nodm-init, see
	  https://lists.openembedded.org/g/openembedded-core/topic/115318655#msg223906
	  for more information
	- Merge xuser-account and xserver-nodm-init as this is now a direct
	  dependency with no other consumers
	- Fix warning about multiple providers for virtual-emptty-conf
v11:
	- Bump emptty revision to 0.15.0
	- Add session entries for all the session providers
	- Make autologin default session configurable for xserver-nodm-init
v12:
	- Add util-linux-mcookie as a runtime dependency to emptty when x11
	  support is enabled
v13:
	- Add nopasswdlogin to the static group definitions list, also register
	  it in the emptty recipe itself since the pam rule provided in that
	  package mentions it
	- Always ship the legacy inittab entry, since it's possible the end user
	  has some unusual distro configuration with multiple init managers
	  enabled
v14:
	- Move from legacy inittab.d entry that only sysvinit supports to
	  modifying the inittab file itself for both sysvinit and busybox init
	  support
v15:
	- Remind myself how POSIX shell "return" is supposed to work when not
	  given an explicit value
v16:
	- Bump PR to make sure caching isn't generating weird test results after
	  changes to source date epoch calculation method


Randolph Sapp (6):
  emptty: add version 0.15.0
  weston-init: convert to virtual-emptty-conf
  weston: remove deprecated weston-start scripts
  xserver-nodm-init: convert to virtual-emptty-conf
  xuser-account: merge with xserver-nodm-init
  xsessions: add unique desktop entries

 meta-selftest/files/static-group              |   2 +-
 .../rootfs-postcommands.bbclass               |  14 +-
 .../conf/distro/include/default-providers.inc |   1 +
 meta/conf/distro/include/maintainers.inc      |   5 +-
 meta/lib/oeqa/runtime/cases/weston.py         |  18 +-
 meta/lib/oeqa/runtime/cases/xorg.py           |   8 +
 meta/recipes-graphics/emptty/emptty-conf.bb   |  14 +
 meta/recipes-graphics/emptty/emptty.inc       |  27 ++
 meta/recipes-graphics/emptty/emptty/pamconf   |  10 +
 meta/recipes-graphics/emptty/emptty_0.15.0.bb |  55 +++
 .../matchbox-session/matchbox-session.desktop |   6 +
 .../matchbox-session/matchbox-session_0.1.bb  |  13 +-
 .../files/mini-x-session.desktop              |   6 +
 .../mini-x-session/mini-x-session_0.1.bb      |  13 +-
 meta/recipes-graphics/wayland/weston-init.bb  |  66 +---
 .../wayland/weston-init/emptty.conf           |  77 ++++
 .../recipes-graphics/wayland/weston-init/init |  54 ---
 .../wayland/weston-init/weston-autologin      |  11 -
 .../wayland/weston-init/weston-socket.sh      |  20 -
 .../wayland/weston-init/weston-start          |  76 ----
 .../wayland/weston-init/weston.env            |   0
 .../wayland/weston-init/weston.service        |  71 ----
 .../wayland/weston-init/weston.socket         |  14 -
 .../weston/systemd-notify.weston-start        |   9 -
 .../wayland/weston/xwayland.weston-start      |   6 -
 .../recipes-graphics/wayland/weston_14.0.2.bb |  10 -
 .../x11-common/xserver-nodm-init/X11/Xsession |  38 --
 .../X11/Xsession.d/13xdgbasedirs.sh           |  19 -
 .../X11/Xsession.d/89xdgautostart.sh          |   7 -
 .../X11/Xsession.d/90XWindowManager.sh        |   7 -
 .../x11-common/xserver-nodm-init/Xserver      |  25 --
 .../xserver-nodm-init/capability.conf         |   2 -
 .../xserver-nodm-init/emptty.conf.in          |  77 ++++
 .../xserver-nodm-init/gplv2-license.patch     | 355 ------------------
 .../xserver-nodm-init}/system-xuser.conf      |   0
 .../x11-common/xserver-nodm-init/xserver-nodm |  75 ----
 .../xserver-nodm-init/xserver-nodm.conf.in    |   7 -
 .../xserver-nodm-init/xserver-nodm.service.in |  13 -
 .../x11-common/xserver-nodm-init_3.0.bb       |  73 ++--
 .../user-creation/xuser-account_0.1.bb        |  30 --
 40 files changed, 358 insertions(+), 976 deletions(-)
 create mode 100644 meta/recipes-graphics/emptty/emptty-conf.bb
 create mode 100644 meta/recipes-graphics/emptty/emptty.inc
 create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf
 create mode 100644 meta/recipes-graphics/emptty/emptty_0.15.0.bb
 create mode 100644 meta/recipes-graphics/matchbox-session/matchbox-session/matchbox-session.desktop
 create mode 100644 meta/recipes-graphics/mini-x-session/files/mini-x-session.desktop
 create mode 100644 meta/recipes-graphics/wayland/weston-init/emptty.conf
 delete mode 100644 meta/recipes-graphics/wayland/weston-init/init
 delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston-autologin
 delete mode 100755 meta/recipes-graphics/wayland/weston-init/weston-socket.sh
 delete mode 100755 meta/recipes-graphics/wayland/weston-init/weston-start
 delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.env
 delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.service
 delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.socket
 delete mode 100644 meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
 delete mode 100644 meta/recipes-graphics/wayland/weston/xwayland.weston-start
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/13xdgbasedirs.sh
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/89xdgautostart.sh
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/90XWindowManager.sh
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xserver
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
 create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/emptty.conf.in
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/gplv2-license.patch
 rename meta/{recipes-support/user-creation/files => recipes-graphics/x11-common/xserver-nodm-init}/system-xuser.conf (100%)
 delete mode 100755 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf.in
 delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
 delete mode 100644 meta/recipes-support/user-creation/xuser-account_0.1.bb

--
2.53.0

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

[Randolph Sapp]

On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via lists.openembedded.org wrote:
> From: Randolph Sapp <rs@ti.com>
>
> No functional changes. Just bumping PR to help with automated testing issues.
>
> Information from v15:
>
> Alright, now that cgo binary reproducibility has been addressed this should be
> good to go. One slight change from v13, I replaced the inittab.d entry with a
> rootfs-postcommands function since busybox-init doesn't support it.
>
> Information from v13:
>
> Hello maintainers, I wanted to wait for the latest tag to get cut before
> bringing this back up, but here it is. This version addresses most of the
> concerns I've seen regarding this series and adds on a little more functionality
> considering we now allow for proper session selection.
>
> This led me into a bit of a dive into the desktop-entry-spec [1] and associated
> validator [2] that I wouldn't mind some opinions on as well if people are
> curious about that.
>
> Legacy details follow:
>
> 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 [3].
> 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.
>
> [1] https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/110
> [2] https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/merge_requests/28
> [3] https://github.com/tvrzna/emptty
>
> v2:
> 	- Address spelling issues in commit messages
> 	- Attempt to resolve some test related issues with weston
> 	- Add additional logs to X11 related tests
> v3:
> 	- Reset AUTOLOGIN_MAX_RETRY to the default value of 2. When running
> 	  under QEMU the first auth attempt almost always fails.
> v4:
> 	- Add a tmpfile entry for the x11 domain socket directory.
> 	- Remove some scripts associated with weston-init that were being
> 	  shipped with weston
> v5:
> 	- Move tmpfile data to individual files
> 	- Add explicit entries for these in the FILES variable
> v6:
> 	- Do not attempt to ship a tmpfiles.d entry in libx11
> v7:
> 	- Include a backported fix for go/runtime to address segfault issues
> 	  reported on x86 platforms in previous revisions
> v8:
> 	- Sign-off backported patch
> v9:
> 	- Resolve merge conflict in maintainers file
> v10:
> 	- Remove the ability to run x11 as root in xserver-nodm-init, see
> 	  https://lists.openembedded.org/g/openembedded-core/topic/115318655#msg223906
> 	  for more information
> 	- Merge xuser-account and xserver-nodm-init as this is now a direct
> 	  dependency with no other consumers
> 	- Fix warning about multiple providers for virtual-emptty-conf
> v11:
> 	- Bump emptty revision to 0.15.0
> 	- Add session entries for all the session providers
> 	- Make autologin default session configurable for xserver-nodm-init
> v12:
> 	- Add util-linux-mcookie as a runtime dependency to emptty when x11
> 	  support is enabled
> v13:
> 	- Add nopasswdlogin to the static group definitions list, also register
> 	  it in the emptty recipe itself since the pam rule provided in that
> 	  package mentions it
> 	- Always ship the legacy inittab entry, since it's possible the end user
> 	  has some unusual distro configuration with multiple init managers
> 	  enabled
> v14:
> 	- Move from legacy inittab.d entry that only sysvinit supports to
> 	  modifying the inittab file itself for both sysvinit and busybox init
> 	  support
> v15:
> 	- Remind myself how POSIX shell "return" is supposed to work when not
> 	  given an explicit value
> v16:
> 	- Bump PR to make sure caching isn't generating weird test results after
> 	  changes to source date epoch calculation method
>
>
> Randolph Sapp (6):
>   emptty: add version 0.15.0
>   weston-init: convert to virtual-emptty-conf
>   weston: remove deprecated weston-start scripts
>   xserver-nodm-init: convert to virtual-emptty-conf
>   xuser-account: merge with xserver-nodm-init
>   xsessions: add unique desktop entries
>
>  meta-selftest/files/static-group              |   2 +-
>  .../rootfs-postcommands.bbclass               |  14 +-
>  .../conf/distro/include/default-providers.inc |   1 +
>  meta/conf/distro/include/maintainers.inc      |   5 +-
>  meta/lib/oeqa/runtime/cases/weston.py         |  18 +-
>  meta/lib/oeqa/runtime/cases/xorg.py           |   8 +
>  meta/recipes-graphics/emptty/emptty-conf.bb   |  14 +
>  meta/recipes-graphics/emptty/emptty.inc       |  27 ++
>  meta/recipes-graphics/emptty/emptty/pamconf   |  10 +
>  meta/recipes-graphics/emptty/emptty_0.15.0.bb |  55 +++
>  .../matchbox-session/matchbox-session.desktop |   6 +
>  .../matchbox-session/matchbox-session_0.1.bb  |  13 +-
>  .../files/mini-x-session.desktop              |   6 +
>  .../mini-x-session/mini-x-session_0.1.bb      |  13 +-
>  meta/recipes-graphics/wayland/weston-init.bb  |  66 +---
>  .../wayland/weston-init/emptty.conf           |  77 ++++
>  .../recipes-graphics/wayland/weston-init/init |  54 ---
>  .../wayland/weston-init/weston-autologin      |  11 -
>  .../wayland/weston-init/weston-socket.sh      |  20 -
>  .../wayland/weston-init/weston-start          |  76 ----
>  .../wayland/weston-init/weston.env            |   0
>  .../wayland/weston-init/weston.service        |  71 ----
>  .../wayland/weston-init/weston.socket         |  14 -
>  .../weston/systemd-notify.weston-start        |   9 -
>  .../wayland/weston/xwayland.weston-start      |   6 -
>  .../recipes-graphics/wayland/weston_14.0.2.bb |  10 -
>  .../x11-common/xserver-nodm-init/X11/Xsession |  38 --
>  .../X11/Xsession.d/13xdgbasedirs.sh           |  19 -
>  .../X11/Xsession.d/89xdgautostart.sh          |   7 -
>  .../X11/Xsession.d/90XWindowManager.sh        |   7 -
>  .../x11-common/xserver-nodm-init/Xserver      |  25 --
>  .../xserver-nodm-init/capability.conf         |   2 -
>  .../xserver-nodm-init/emptty.conf.in          |  77 ++++
>  .../xserver-nodm-init/gplv2-license.patch     | 355 ------------------
>  .../xserver-nodm-init}/system-xuser.conf      |   0
>  .../x11-common/xserver-nodm-init/xserver-nodm |  75 ----
>  .../xserver-nodm-init/xserver-nodm.conf.in    |   7 -
>  .../xserver-nodm-init/xserver-nodm.service.in |  13 -
>  .../x11-common/xserver-nodm-init_3.0.bb       |  73 ++--
>  .../user-creation/xuser-account_0.1.bb        |  30 --
>  40 files changed, 358 insertions(+), 976 deletions(-)
>  create mode 100644 meta/recipes-graphics/emptty/emptty-conf.bb
>  create mode 100644 meta/recipes-graphics/emptty/emptty.inc
>  create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf
>  create mode 100644 meta/recipes-graphics/emptty/emptty_0.15.0.bb
>  create mode 100644 meta/recipes-graphics/matchbox-session/matchbox-session/matchbox-session.desktop
>  create mode 100644 meta/recipes-graphics/mini-x-session/files/mini-x-session.desktop
>  create mode 100644 meta/recipes-graphics/wayland/weston-init/emptty.conf
>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/init
>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston-autologin
>  delete mode 100755 meta/recipes-graphics/wayland/weston-init/weston-socket.sh
>  delete mode 100755 meta/recipes-graphics/wayland/weston-init/weston-start
>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.env
>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.service
>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.socket
>  delete mode 100644 meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
>  delete mode 100644 meta/recipes-graphics/wayland/weston/xwayland.weston-start
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/13xdgbasedirs.sh
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/89xdgautostart.sh
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/90XWindowManager.sh
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xserver
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
>  create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/emptty.conf.in
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/gplv2-license.patch
>  rename meta/{recipes-support/user-creation/files => recipes-graphics/x11-common/xserver-nodm-init}/system-xuser.conf (100%)
>  delete mode 100755 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf.in
>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>  delete mode 100644 meta/recipes-support/user-creation/xuser-account_0.1.bb
>
> --
> 2.53.0

Hey Paul, have you gotten a chance to review this series yet? I've been told you
may have some comments.

Randolph

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

[Randolph Sapp]

On Mon Mar 16, 2026 at 12:25 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via lists.openembedded.org wrote:
>> From: Randolph Sapp <rs@ti.com>
>>
>> No functional changes. Just bumping PR to help with automated testing issues.
>>
>> Information from v15:
>>
>> Alright, now that cgo binary reproducibility has been addressed this should be
>> good to go. One slight change from v13, I replaced the inittab.d entry with a
>> rootfs-postcommands function since busybox-init doesn't support it.
>>
>> Information from v13:
>>
>> Hello maintainers, I wanted to wait for the latest tag to get cut before
>> bringing this back up, but here it is. This version addresses most of the
>> concerns I've seen regarding this series and adds on a little more functionality
>> considering we now allow for proper session selection.
>>
>> This led me into a bit of a dive into the desktop-entry-spec [1] and associated
>> validator [2] that I wouldn't mind some opinions on as well if people are
>> curious about that.
>>
>> Legacy details follow:
>>
>> 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 [3].
>> 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.
>>
>> [1] https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/110
>> [2] https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/merge_requests/28
>> [3] https://github.com/tvrzna/emptty
>>
>> v2:
>> 	- Address spelling issues in commit messages
>> 	- Attempt to resolve some test related issues with weston
>> 	- Add additional logs to X11 related tests
>> v3:
>> 	- Reset AUTOLOGIN_MAX_RETRY to the default value of 2. When running
>> 	  under QEMU the first auth attempt almost always fails.
>> v4:
>> 	- Add a tmpfile entry for the x11 domain socket directory.
>> 	- Remove some scripts associated with weston-init that were being
>> 	  shipped with weston
>> v5:
>> 	- Move tmpfile data to individual files
>> 	- Add explicit entries for these in the FILES variable
>> v6:
>> 	- Do not attempt to ship a tmpfiles.d entry in libx11
>> v7:
>> 	- Include a backported fix for go/runtime to address segfault issues
>> 	  reported on x86 platforms in previous revisions
>> v8:
>> 	- Sign-off backported patch
>> v9:
>> 	- Resolve merge conflict in maintainers file
>> v10:
>> 	- Remove the ability to run x11 as root in xserver-nodm-init, see
>> 	  https://lists.openembedded.org/g/openembedded-core/topic/115318655#msg223906
>> 	  for more information
>> 	- Merge xuser-account and xserver-nodm-init as this is now a direct
>> 	  dependency with no other consumers
>> 	- Fix warning about multiple providers for virtual-emptty-conf
>> v11:
>> 	- Bump emptty revision to 0.15.0
>> 	- Add session entries for all the session providers
>> 	- Make autologin default session configurable for xserver-nodm-init
>> v12:
>> 	- Add util-linux-mcookie as a runtime dependency to emptty when x11
>> 	  support is enabled
>> v13:
>> 	- Add nopasswdlogin to the static group definitions list, also register
>> 	  it in the emptty recipe itself since the pam rule provided in that
>> 	  package mentions it
>> 	- Always ship the legacy inittab entry, since it's possible the end user
>> 	  has some unusual distro configuration with multiple init managers
>> 	  enabled
>> v14:
>> 	- Move from legacy inittab.d entry that only sysvinit supports to
>> 	  modifying the inittab file itself for both sysvinit and busybox init
>> 	  support
>> v15:
>> 	- Remind myself how POSIX shell "return" is supposed to work when not
>> 	  given an explicit value
>> v16:
>> 	- Bump PR to make sure caching isn't generating weird test results after
>> 	  changes to source date epoch calculation method
>>
>>
>> Randolph Sapp (6):
>>   emptty: add version 0.15.0
>>   weston-init: convert to virtual-emptty-conf
>>   weston: remove deprecated weston-start scripts
>>   xserver-nodm-init: convert to virtual-emptty-conf
>>   xuser-account: merge with xserver-nodm-init
>>   xsessions: add unique desktop entries
>>
>>  meta-selftest/files/static-group              |   2 +-
>>  .../rootfs-postcommands.bbclass               |  14 +-
>>  .../conf/distro/include/default-providers.inc |   1 +
>>  meta/conf/distro/include/maintainers.inc      |   5 +-
>>  meta/lib/oeqa/runtime/cases/weston.py         |  18 +-
>>  meta/lib/oeqa/runtime/cases/xorg.py           |   8 +
>>  meta/recipes-graphics/emptty/emptty-conf.bb   |  14 +
>>  meta/recipes-graphics/emptty/emptty.inc       |  27 ++
>>  meta/recipes-graphics/emptty/emptty/pamconf   |  10 +
>>  meta/recipes-graphics/emptty/emptty_0.15.0.bb |  55 +++
>>  .../matchbox-session/matchbox-session.desktop |   6 +
>>  .../matchbox-session/matchbox-session_0.1.bb  |  13 +-
>>  .../files/mini-x-session.desktop              |   6 +
>>  .../mini-x-session/mini-x-session_0.1.bb      |  13 +-
>>  meta/recipes-graphics/wayland/weston-init.bb  |  66 +---
>>  .../wayland/weston-init/emptty.conf           |  77 ++++
>>  .../recipes-graphics/wayland/weston-init/init |  54 ---
>>  .../wayland/weston-init/weston-autologin      |  11 -
>>  .../wayland/weston-init/weston-socket.sh      |  20 -
>>  .../wayland/weston-init/weston-start          |  76 ----
>>  .../wayland/weston-init/weston.env            |   0
>>  .../wayland/weston-init/weston.service        |  71 ----
>>  .../wayland/weston-init/weston.socket         |  14 -
>>  .../weston/systemd-notify.weston-start        |   9 -
>>  .../wayland/weston/xwayland.weston-start      |   6 -
>>  .../recipes-graphics/wayland/weston_14.0.2.bb |  10 -
>>  .../x11-common/xserver-nodm-init/X11/Xsession |  38 --
>>  .../X11/Xsession.d/13xdgbasedirs.sh           |  19 -
>>  .../X11/Xsession.d/89xdgautostart.sh          |   7 -
>>  .../X11/Xsession.d/90XWindowManager.sh        |   7 -
>>  .../x11-common/xserver-nodm-init/Xserver      |  25 --
>>  .../xserver-nodm-init/capability.conf         |   2 -
>>  .../xserver-nodm-init/emptty.conf.in          |  77 ++++
>>  .../xserver-nodm-init/gplv2-license.patch     | 355 ------------------
>>  .../xserver-nodm-init}/system-xuser.conf      |   0
>>  .../x11-common/xserver-nodm-init/xserver-nodm |  75 ----
>>  .../xserver-nodm-init/xserver-nodm.conf.in    |   7 -
>>  .../xserver-nodm-init/xserver-nodm.service.in |  13 -
>>  .../x11-common/xserver-nodm-init_3.0.bb       |  73 ++--
>>  .../user-creation/xuser-account_0.1.bb        |  30 --
>>  40 files changed, 358 insertions(+), 976 deletions(-)
>>  create mode 100644 meta/recipes-graphics/emptty/emptty-conf.bb
>>  create mode 100644 meta/recipes-graphics/emptty/emptty.inc
>>  create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf
>>  create mode 100644 meta/recipes-graphics/emptty/emptty_0.15.0.bb
>>  create mode 100644 meta/recipes-graphics/matchbox-session/matchbox-session/matchbox-session.desktop
>>  create mode 100644 meta/recipes-graphics/mini-x-session/files/mini-x-session.desktop
>>  create mode 100644 meta/recipes-graphics/wayland/weston-init/emptty.conf
>>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/init
>>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston-autologin
>>  delete mode 100755 meta/recipes-graphics/wayland/weston-init/weston-socket.sh
>>  delete mode 100755 meta/recipes-graphics/wayland/weston-init/weston-start
>>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.env
>>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.service
>>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/weston.socket
>>  delete mode 100644 meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
>>  delete mode 100644 meta/recipes-graphics/wayland/weston/xwayland.weston-start
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/13xdgbasedirs.sh
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/89xdgautostart.sh
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/X11/Xsession.d/90XWindowManager.sh
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/Xserver
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf
>>  create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/emptty.conf.in
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/gplv2-license.patch
>>  rename meta/{recipes-support/user-creation/files => recipes-graphics/x11-common/xserver-nodm-init}/system-xuser.conf (100%)
>>  delete mode 100755 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.conf.in
>>  delete mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>>  delete mode 100644 meta/recipes-support/user-creation/xuser-account_0.1.bb
>>
>> --
>> 2.53.0
>
> Hey Paul, have you gotten a chance to review this series yet? I've been told you
> may have some comments.
>
> Randolph

Has anyone gotten a chance to review this yet?

Randolph

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

[Richard Purdie]

On Thu, 2026-03-26 at 13:35 -0500, Randolph Sapp wrote:
> On Mon Mar 16, 2026 at 12:25 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> > On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via lists.openembedded.org wrote:
> > > From: Randolph Sapp <rs@ti.com>
> > > 
> > > No functional changes. Just bumping PR to help with automated 
> > 
> > Hey Paul, have you gotten a chance to review this series yet? I've been told you may have some comments.
> > 
> > Randolph
> 
> Has anyone gotten a chance to review this yet?

Paul and Ross have some thoughts but we're basically still drowning in
the backlog of patch review. We're all frustrated about that. This one
is more Ross' area of expertise than mine so I'm waiting on that.I'm
replying since I do feel bad we've not got to this yet.

I wish it were different, I'm doing what I can with various patches but
I'm also behind on review for several.

The challenge with this patchset is it is a fairly invasive change, it
does inject a go dependency into a core part of our graphics stack and
as such, I think we're all quite nervous about it. It has taken a lot
of back and forth to pass the autobuilder's tests and that in itself is
a bit of a worry.

Cheers,

Richard

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

[Otavio Salvador]

Richard,

Em sex., 27 de mar. de 2026 às 14:09, Richard Purdie via
lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> escreveu:
>
> On Thu, 2026-03-26 at 13:35 -0500, Randolph Sapp wrote:
> > On Mon Mar 16, 2026 at 12:25 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> > > On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via lists.openembedded.org wrote:
> > > > From: Randolph Sapp <rs@ti.com>
> > > >
> > > > No functional changes. Just bumping PR to help with automated
> > >
> > > Hey Paul, have you gotten a chance to review this series yet? I've been told you may have some comments.
> > >
> > > Randolph
> >
> > Has anyone gotten a chance to review this yet?
>
> Paul and Ross have some thoughts but we're basically still drowning in
> the backlog of patch review. We're all frustrated about that. This one
> is more Ross' area of expertise than mine so I'm waiting on that.I'm
> replying since I do feel bad we've not got to this yet.
>
> I wish it were different, I'm doing what I can with various patches but
> I'm also behind on review for several.
>
> The challenge with this patchset is it is a fairly invasive change, it
> does inject a go dependency into a core part of our graphics stack and
> as such, I think we're all quite nervous about it. It has taken a lot
> of back and forth to pass the autobuilder's tests and that in itself is
> a bit of a worry.

I understand the concern — this is an invasive change and caution is
warranted for something that touches such a core part of the graphics
stack.

That said, I think it's worth recognizing that Randolph has been
exceptionally persistent and responsive throughout this process. We're
at v16 now, and every issue that has come up — from cgo
reproducibility to busybox-init support to autobuilder failures — has
been addressed. That level of commitment to getting it right speaks
well for the long-term maintainability of this work.

Regarding the Go dependency: Go support in OE-Core has a long history
at this point and is well-maintained. I don't think introducing it as
a dependency in the graphics stack is as risky as it might seem at
first glance — we're not pulling in something experimental.

The problems this series solves are real. The race conditions with
weston-init and DRM device registration, the scripting sprawl around
xserver-nodm-init — these are pain points that affect downstream
users. emptty offers a clean, unified solution for both X11 and
Wayland sessions.

In my opinion, this patchset should go in.

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

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

[Richard Purdie]

Hi Otavio,

On Fri, 2026-03-27 at 19:38 -0300, Otavio Salvador via lists.openembedded.org wrote:
> Em sex., 27 de mar. de 2026 às 14:09, Richard Purdie via
> lists.openembedded.org
> <richard.purdie=linuxfoundation.org@lists.openembedded.org> escreveu:
> > 
> > On Thu, 2026-03-26 at 13:35 -0500, Randolph Sapp wrote:
> > > On Mon Mar 16, 2026 at 12:25 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> > > > On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via lists.openembedded.org wrote:
> > > > > From: Randolph Sapp <rs@ti.com>
> > > > > 
> > > > > No functional changes. Just bumping PR to help with automated
> > > > 
> > > > Hey Paul, have you gotten a chance to review this series yet? I've been told you may have some comments.
> > > > 
> > > > Randolph
> > > 
> > > Has anyone gotten a chance to review this yet?
> > 
> > Paul and Ross have some thoughts but we're basically still drowning in
> > the backlog of patch review. We're all frustrated about that. This one
> > is more Ross' area of expertise than mine so I'm waiting on that.I'm
> > replying since I do feel bad we've not got to this yet.
> > 
> > I wish it were different, I'm doing what I can with various patches but
> > I'm also behind on review for several.
> > 
> > The challenge with this patchset is it is a fairly invasive change, it
> > does inject a go dependency into a core part of our graphics stack and
> > as such, I think we're all quite nervous about it. It has taken a lot
> > of back and forth to pass the autobuilder's tests and that in itself is
> > a bit of a worry.
> 
> I understand the concern — this is an invasive change and caution is
> warranted for something that touches such a core part of the graphics
> stack.
> 
> That said, I think it's worth recognizing that Randolph has been
> exceptionally persistent and responsive throughout this process. We're
> at v16 now, and every issue that has come up — from cgo
> reproducibility to busybox-init support to autobuilder failures — has
> been addressed. That level of commitment to getting it right speaks
> well for the long-term maintainability of this work.

I realise and fully recognise Randoplh has been really patient and
persistent, yes. I can only apologise for the length of time this is
taking, I do feel really bad about it.

I've been talking about one of the issues here in meetings recently,
specifically that patches passing on the autobuilder doesn't mean the
patches are "right", just that they don't regress our automated tests.
I think we need to make it clearer that we put patches in for testing
in parallel with other review on the basis it is easier in some ways
and can highlight issues. It doesn't negate the other half of the
process. In this case, the patches had a lot of issues there and it
took a while so there weren't regressions.

You mention the cgo reproducibility issue, I want to be mention there
are a number of other complaints in my inbox about the changes made
there, how there are regressions elsewhere caused by those changes. I
can't really ask anyone else to try and handle that so that just falls
to me, but it does reduce my bandwidth elsewhere.

Unfortunately the people who need to review and sign off on this have a
number of other things in their queues. People only have finite time
and I can't force them to do things. I'd also note that I did ask many
times in the weekly calls and other project meetings about what should
block this release and this patchset was not raised. That isn't to say
it isn't important but there are other pressing issues competing with
it.

> Regarding the Go dependency: Go support in OE-Core has a long history
> at this point and is well-maintained. I don't think introducing it as
> a dependency in the graphics stack is as risky as it might seem at
> first glance — we're not pulling in something experimental.
> 
> The problems this series solves are real. The race conditions with
> weston-init and DRM device registration, the scripting sprawl around
> xserver-nodm-init — these are pain points that affect downstream
> users. emptty offers a clean, unified solution for both X11 and
> Wayland sessions.

Whilst it does solve a real world problem, that doesn't mean it should
go in without the right level of review and wider community buy-in. We
don't have that yet. There is also significant risk to changing a key
runtime component like that this close to release. Build components
aren't so bad as we have better testing, runtime is hard. The rpm 6
patchset is in a similar position - too risky for the release now.

> In my opinion, this patchset should go in.

Noted, thanks. I appreciate the review of it.

Cheers,

Richard

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

[Randolph Sapp]

On Sun Mar 29, 2026 at 4:06 AM CDT, Richard Purdie wrote:
> Hi Otavio,
>
> On Fri, 2026-03-27 at 19:38 -0300, Otavio Salvador via lists.openembedded.org wrote:
>> Em sex., 27 de mar. de 2026 às 14:09, Richard Purdie via
>> lists.openembedded.org
>> <richard.purdie=linuxfoundation.org@lists.openembedded.org> escreveu:
>> > 
>> > On Thu, 2026-03-26 at 13:35 -0500, Randolph Sapp wrote:
>> > > On Mon Mar 16, 2026 at 12:25 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
>> > > > On Fri Feb 27, 2026 at 12:31 PM CST, Randolph Sapp via lists.openembedded.org wrote:
>> > > > > From: Randolph Sapp <rs@ti.com>
>> > > > > 
>> > > > > No functional changes. Just bumping PR to help with automated
>> > > > 
>> > > > Hey Paul, have you gotten a chance to review this series yet? I've been told you may have some comments.
>> > > > 
>> > > > Randolph
>> > > 
>> > > Has anyone gotten a chance to review this yet?
>> > 
>> > Paul and Ross have some thoughts but we're basically still drowning in
>> > the backlog of patch review. We're all frustrated about that. This one
>> > is more Ross' area of expertise than mine so I'm waiting on that.I'm
>> > replying since I do feel bad we've not got to this yet.
>> > 
>> > I wish it were different, I'm doing what I can with various patches but
>> > I'm also behind on review for several.
>> > 
>> > The challenge with this patchset is it is a fairly invasive change, it
>> > does inject a go dependency into a core part of our graphics stack and
>> > as such, I think we're all quite nervous about it. It has taken a lot
>> > of back and forth to pass the autobuilder's tests and that in itself is
>> > a bit of a worry.
>> 
>> I understand the concern — this is an invasive change and caution is
>> warranted for something that touches such a core part of the graphics
>> stack.
>> 
>> That said, I think it's worth recognizing that Randolph has been
>> exceptionally persistent and responsive throughout this process. We're
>> at v16 now, and every issue that has come up — from cgo
>> reproducibility to busybox-init support to autobuilder failures — has
>> been addressed. That level of commitment to getting it right speaks
>> well for the long-term maintainability of this work.
>
> I realise and fully recognise Randoplh has been really patient and
> persistent, yes. I can only apologise for the length of time this is
> taking, I do feel really bad about it.
>
> I've been talking about one of the issues here in meetings recently,
> specifically that patches passing on the autobuilder doesn't mean the
> patches are "right", just that they don't regress our automated tests.
> I think we need to make it clearer that we put patches in for testing
> in parallel with other review on the basis it is easier in some ways
> and can highlight issues. It doesn't negate the other half of the
> process. In this case, the patches had a lot of issues there and it
> took a while so there weren't regressions.
>
> You mention the cgo reproducibility issue, I want to be mention there
> are a number of other complaints in my inbox about the changes made
> there, how there are regressions elsewhere caused by those changes. I
> can't really ask anyone else to try and handle that so that just falls
> to me, but it does reduce my bandwidth elsewhere.
>
> Unfortunately the people who need to review and sign off on this have a
> number of other things in their queues. People only have finite time
> and I can't force them to do things. I'd also note that I did ask many
> times in the weekly calls and other project meetings about what should
> block this release and this patchset was not raised. That isn't to say
> it isn't important but there are other pressing issues competing with
> it.
>
>> Regarding the Go dependency: Go support in OE-Core has a long history
>> at this point and is well-maintained. I don't think introducing it as
>> a dependency in the graphics stack is as risky as it might seem at
>> first glance — we're not pulling in something experimental.
>> 
>> The problems this series solves are real. The race conditions with
>> weston-init and DRM device registration, the scripting sprawl around
>> xserver-nodm-init — these are pain points that affect downstream
>> users. emptty offers a clean, unified solution for both X11 and
>> Wayland sessions.
>
> Whilst it does solve a real world problem, that doesn't mean it should
> go in without the right level of review and wider community buy-in. We
> don't have that yet. There is also significant risk to changing a key
> runtime component like that this close to release. Build components
> aren't so bad as we have better testing, runtime is hard. The rpm 6
> patchset is in a similar position - too risky for the release now.
>
>> In my opinion, this patchset should go in.
>
> Noted, thanks. I appreciate the review of it.
>
> Cheers,
>
> Richard

Please let me know when you all have the time to review this series and I'll
resubmit it accordingly. I figure this is the sort of change that should go into
a major version bump as there are subtle differences downstream layers may need
to take into account if they were modifying these session managers or their
startup scripts.

At this point though, these patches no longer cleanly apply.