| Message ID | 20250918214903.341452-1-rs@ti.com |
|---|---|
| Headers | show |
| Series | Display manager proposal for x11 and wayland | expand |
On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. It's not clear how switching to emptty actually solves that problem; I don't see anything in my (brief) look at the emptty code that would lead me to believe it actually cares about any drm devices being present or handles devices showing up dynamically. Can you maybe elaborate more on this? > > 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. > > [1] 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 > > Randolph Sapp (6): > libx11: create tmpfile dir for x11 domain socket > go: fix sigaction usage on i386 platforms > emptty: add version 0.14.0 > weston-init: convert to virtual-emptty-conf > weston: remove deprecated weston-start scripts > xserver-nodm-init: convert to virtual-emptty-conf > > .../conf/distro/include/default-providers.inc | 1 + > meta/conf/distro/include/maintainers.inc | 6 +- > meta/lib/oeqa/runtime/cases/weston.py | 18 +- > meta/lib/oeqa/runtime/cases/xorg.py | 8 + > meta/recipes-devtools/go/go-1.25.0.inc | 1 + > ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ > meta/recipes-graphics/emptty/emptty-conf.bb | 14 + > meta/recipes-graphics/emptty/emptty.inc | 26 ++ > .../recipes-graphics/emptty/emptty/emptty.tab | 1 + > meta/recipes-graphics/emptty/emptty/pamconf | 10 + > meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ > meta/recipes-graphics/wayland/weston-init.bb | 61 +-- > .../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/default.desktop | 5 + > .../xserver-nodm-init/emptty.conf.in | 77 ++++ > .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ > .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- > .../xserver-nodm-init/xserver-nodm.conf.in | 7 - > .../xserver-nodm-init/xserver-nodm.service.in | 11 - > .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- > meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + > .../xorg-lib/libx11_1.8.12.bb | 15 +- > .../user-creation/xuser-account_0.1.bb | 3 +- > 39 files changed, 581 insertions(+), 918 deletions(-) > create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch > 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/emptty.tab > create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf > create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb > 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/default.desktop > 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 > 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 > create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 > > -- > 2.51.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#223699): https://lists.openembedded.org/g/openembedded-core/message/223699 > Mute This Topic: https://lists.openembedded.org/mt/115318655/3616693 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Thu Sep 18, 2025 at 5:25 PM CDT, Joshua Watt wrote: > On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via > lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. > > It's not clear how switching to emptty actually solves that problem; I > don't see anything in my (brief) look at the emptty code that would > lead me to believe it actually cares about any drm devices being > present or handles devices showing up dynamically. Can you maybe > elaborate more on this? It doesn't currently have any tests to wait for the DRM device. I still need to look into adding that, but what it currently does is add a retry event counter and a small delay between retries that is better than the current console implementations. Especially considering authentication is handled separately from this retry process. By centralizing display manager specific code, common checks and fallback logic can be more easily implemented in the future. I'm hoping this lays the groundwork to let me address some other issues I've seen in multi-card environments as well. >> 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. >> >> [1] 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 >> >> Randolph Sapp (6): >> libx11: create tmpfile dir for x11 domain socket >> go: fix sigaction usage on i386 platforms >> emptty: add version 0.14.0 >> weston-init: convert to virtual-emptty-conf >> weston: remove deprecated weston-start scripts >> xserver-nodm-init: convert to virtual-emptty-conf >> >> .../conf/distro/include/default-providers.inc | 1 + >> meta/conf/distro/include/maintainers.inc | 6 +- >> meta/lib/oeqa/runtime/cases/weston.py | 18 +- >> meta/lib/oeqa/runtime/cases/xorg.py | 8 + >> meta/recipes-devtools/go/go-1.25.0.inc | 1 + >> ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ >> meta/recipes-graphics/emptty/emptty-conf.bb | 14 + >> meta/recipes-graphics/emptty/emptty.inc | 26 ++ >> .../recipes-graphics/emptty/emptty/emptty.tab | 1 + >> meta/recipes-graphics/emptty/emptty/pamconf | 10 + >> meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ >> meta/recipes-graphics/wayland/weston-init.bb | 61 +-- >> .../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/default.desktop | 5 + >> .../xserver-nodm-init/emptty.conf.in | 77 ++++ >> .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ >> .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- >> .../xserver-nodm-init/xserver-nodm.conf.in | 7 - >> .../xserver-nodm-init/xserver-nodm.service.in | 11 - >> .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- >> meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + >> .../xorg-lib/libx11_1.8.12.bb | 15 +- >> .../user-creation/xuser-account_0.1.bb | 3 +- >> 39 files changed, 581 insertions(+), 918 deletions(-) >> create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch >> 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/emptty.tab >> create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf >> create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb >> 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/default.desktop >> 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 >> 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 >> create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 >> >> -- >> 2.51.0 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#223699): https://lists.openembedded.org/g/openembedded-core/message/223699 >> Mute This Topic: https://lists.openembedded.org/mt/115318655/3616693 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On Thu, Sep 18, 2025 at 4:31 PM Randolph Sapp <rs@ti.com> wrote: > > On Thu Sep 18, 2025 at 5:25 PM CDT, Joshua Watt wrote: > > On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via > > lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. > > > > It's not clear how switching to emptty actually solves that problem; I > > don't see anything in my (brief) look at the emptty code that would > > lead me to believe it actually cares about any drm devices being > > present or handles devices showing up dynamically. Can you maybe > > elaborate more on this? > > It doesn't currently have any tests to wait for the DRM device. I still need to > look into adding that, but what it currently does is add a retry event counter > and a small delay between retries that is better than the current console > implementations. Especially considering authentication is handled separately > from this retry process. > > By centralizing display manager specific code, common checks and fallback logic > can be more easily implemented in the future. I'm hoping this lays the > groundwork to let me address some other issues I've seen in multi-card > environments as well. For the systemd parts, is it also possible to solve this with e.g. Requires=dev-dri-card0.device After=dev-dri-card0.device (or similar) ? Seems like anything emptty would be doing would be a reimplementation of the logic that already exists in systemd to do that. > > >> 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. > >> > >> [1] 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 > >> > >> Randolph Sapp (6): > >> libx11: create tmpfile dir for x11 domain socket > >> go: fix sigaction usage on i386 platforms > >> emptty: add version 0.14.0 > >> weston-init: convert to virtual-emptty-conf > >> weston: remove deprecated weston-start scripts > >> xserver-nodm-init: convert to virtual-emptty-conf > >> > >> .../conf/distro/include/default-providers.inc | 1 + > >> meta/conf/distro/include/maintainers.inc | 6 +- > >> meta/lib/oeqa/runtime/cases/weston.py | 18 +- > >> meta/lib/oeqa/runtime/cases/xorg.py | 8 + > >> meta/recipes-devtools/go/go-1.25.0.inc | 1 + > >> ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ > >> meta/recipes-graphics/emptty/emptty-conf.bb | 14 + > >> meta/recipes-graphics/emptty/emptty.inc | 26 ++ > >> .../recipes-graphics/emptty/emptty/emptty.tab | 1 + > >> meta/recipes-graphics/emptty/emptty/pamconf | 10 + > >> meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ > >> meta/recipes-graphics/wayland/weston-init.bb | 61 +-- > >> .../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/default.desktop | 5 + > >> .../xserver-nodm-init/emptty.conf.in | 77 ++++ > >> .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ > >> .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- > >> .../xserver-nodm-init/xserver-nodm.conf.in | 7 - > >> .../xserver-nodm-init/xserver-nodm.service.in | 11 - > >> .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- > >> meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + > >> .../xorg-lib/libx11_1.8.12.bb | 15 +- > >> .../user-creation/xuser-account_0.1.bb | 3 +- > >> 39 files changed, 581 insertions(+), 918 deletions(-) > >> create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch > >> 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/emptty.tab > >> create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf > >> create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb > >> 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/default.desktop > >> 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 > >> 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 > >> create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 > >> > >> -- > >> 2.51.0 > >> > >> > >> -=-=-=-=-=-=-=-=-=-=-=- > >> Links: You receive all messages sent to this group. > >> View/Reply Online (#223699): https://lists.openembedded.org/g/openembedded-core/message/223699 > >> Mute This Topic: https://lists.openembedded.org/mt/115318655/3616693 > >> Group Owner: openembedded-core+owner@lists.openembedded.org > >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com] > >> -=-=-=-=-=-=-=-=-=-=-=- > >> >
On Thu Sep 18, 2025 at 5:35 PM CDT, Joshua Watt wrote: > On Thu, Sep 18, 2025 at 4:31 PM Randolph Sapp <rs@ti.com> wrote: >> >> On Thu Sep 18, 2025 at 5:25 PM CDT, Joshua Watt wrote: >> > On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via >> > lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. >> > >> > It's not clear how switching to emptty actually solves that problem; I >> > don't see anything in my (brief) look at the emptty code that would >> > lead me to believe it actually cares about any drm devices being >> > present or handles devices showing up dynamically. Can you maybe >> > elaborate more on this? >> >> It doesn't currently have any tests to wait for the DRM device. I still need to >> look into adding that, but what it currently does is add a retry event counter >> and a small delay between retries that is better than the current console >> implementations. Especially considering authentication is handled separately >> from this retry process. >> >> By centralizing display manager specific code, common checks and fallback logic >> can be more easily implemented in the future. I'm hoping this lays the >> groundwork to let me address some other issues I've seen in multi-card >> environments as well. > > For the systemd parts, is it also possible to solve this with e.g. > > Requires=dev-dri-card0.device > After=dev-dri-card0.device > > (or similar) ? Seems like anything emptty would be doing would be a > reimplementation of the logic that already exists in systemd to do > that. It gets messy. A udev rule needs to be made to make systemd track that device. In a multi-card environment a device without an actual display may be picked. Systemd cannot directly solve the issue on it's own. >> >> 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. >> >> >> >> [1] 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 >> >> >> >> Randolph Sapp (6): >> >> libx11: create tmpfile dir for x11 domain socket >> >> go: fix sigaction usage on i386 platforms >> >> emptty: add version 0.14.0 >> >> weston-init: convert to virtual-emptty-conf >> >> weston: remove deprecated weston-start scripts >> >> xserver-nodm-init: convert to virtual-emptty-conf >> >> >> >> .../conf/distro/include/default-providers.inc | 1 + >> >> meta/conf/distro/include/maintainers.inc | 6 +- >> >> meta/lib/oeqa/runtime/cases/weston.py | 18 +- >> >> meta/lib/oeqa/runtime/cases/xorg.py | 8 + >> >> meta/recipes-devtools/go/go-1.25.0.inc | 1 + >> >> ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ >> >> meta/recipes-graphics/emptty/emptty-conf.bb | 14 + >> >> meta/recipes-graphics/emptty/emptty.inc | 26 ++ >> >> .../recipes-graphics/emptty/emptty/emptty.tab | 1 + >> >> meta/recipes-graphics/emptty/emptty/pamconf | 10 + >> >> meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ >> >> meta/recipes-graphics/wayland/weston-init.bb | 61 +-- >> >> .../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/default.desktop | 5 + >> >> .../xserver-nodm-init/emptty.conf.in | 77 ++++ >> >> .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ >> >> .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- >> >> .../xserver-nodm-init/xserver-nodm.conf.in | 7 - >> >> .../xserver-nodm-init/xserver-nodm.service.in | 11 - >> >> .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- >> >> meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + >> >> .../xorg-lib/libx11_1.8.12.bb | 15 +- >> >> .../user-creation/xuser-account_0.1.bb | 3 +- >> >> 39 files changed, 581 insertions(+), 918 deletions(-) >> >> create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch >> >> 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/emptty.tab >> >> create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf >> >> create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb >> >> 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/default.desktop >> >> 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 >> >> 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 >> >> create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 >> >> >> >> -- >> >> 2.51.0 >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> >> Links: You receive all messages sent to this group. >> >> View/Reply Online (#223699): https://lists.openembedded.org/g/openembedded-core/message/223699 >> >> Mute This Topic: https://lists.openembedded.org/mt/115318655/3616693 >> >> Group Owner: openembedded-core+owner@lists.openembedded.org >> >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com] >> >> -=-=-=-=-=-=-=-=-=-=-=- >> >> >>
On Thu Sep 18, 2025 at 5:39 PM CDT, Randolph Sapp via lists.openembedded.org wrote: > On Thu Sep 18, 2025 at 5:35 PM CDT, Joshua Watt wrote: >> On Thu, Sep 18, 2025 at 4:31 PM Randolph Sapp <rs@ti.com> wrote: >>> >>> On Thu Sep 18, 2025 at 5:25 PM CDT, Joshua Watt wrote: >>> > On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via >>> > lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. >>> > >>> > It's not clear how switching to emptty actually solves that problem; I >>> > don't see anything in my (brief) look at the emptty code that would >>> > lead me to believe it actually cares about any drm devices being >>> > present or handles devices showing up dynamically. Can you maybe >>> > elaborate more on this? >>> >>> It doesn't currently have any tests to wait for the DRM device. I still need to >>> look into adding that, but what it currently does is add a retry event counter >>> and a small delay between retries that is better than the current console >>> implementations. Especially considering authentication is handled separately >>> from this retry process. >>> >>> By centralizing display manager specific code, common checks and fallback logic >>> can be more easily implemented in the future. I'm hoping this lays the >>> groundwork to let me address some other issues I've seen in multi-card >>> environments as well. >> >> For the systemd parts, is it also possible to solve this with e.g. >> >> Requires=dev-dri-card0.device >> After=dev-dri-card0.device >> >> (or similar) ? Seems like anything emptty would be doing would be a >> reimplementation of the logic that already exists in systemd to do >> that. > > It gets messy. A udev rule needs to be made to make systemd track that device. > In a multi-card environment a device without an actual display may be picked. > Systemd cannot directly solve the issue on it's own. Additionally, there are more init systems supported here than just systemd... >>> >> 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. >>> >> >>> >> [1] 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 >>> >> >>> >> Randolph Sapp (6): >>> >> libx11: create tmpfile dir for x11 domain socket >>> >> go: fix sigaction usage on i386 platforms >>> >> emptty: add version 0.14.0 >>> >> weston-init: convert to virtual-emptty-conf >>> >> weston: remove deprecated weston-start scripts >>> >> xserver-nodm-init: convert to virtual-emptty-conf >>> >> >>> >> .../conf/distro/include/default-providers.inc | 1 + >>> >> meta/conf/distro/include/maintainers.inc | 6 +- >>> >> meta/lib/oeqa/runtime/cases/weston.py | 18 +- >>> >> meta/lib/oeqa/runtime/cases/xorg.py | 8 + >>> >> meta/recipes-devtools/go/go-1.25.0.inc | 1 + >>> >> ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ >>> >> meta/recipes-graphics/emptty/emptty-conf.bb | 14 + >>> >> meta/recipes-graphics/emptty/emptty.inc | 26 ++ >>> >> .../recipes-graphics/emptty/emptty/emptty.tab | 1 + >>> >> meta/recipes-graphics/emptty/emptty/pamconf | 10 + >>> >> meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ >>> >> meta/recipes-graphics/wayland/weston-init.bb | 61 +-- >>> >> .../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/default.desktop | 5 + >>> >> .../xserver-nodm-init/emptty.conf.in | 77 ++++ >>> >> .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ >>> >> .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- >>> >> .../xserver-nodm-init/xserver-nodm.conf.in | 7 - >>> >> .../xserver-nodm-init/xserver-nodm.service.in | 11 - >>> >> .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- >>> >> meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + >>> >> .../xorg-lib/libx11_1.8.12.bb | 15 +- >>> >> .../user-creation/xuser-account_0.1.bb | 3 +- >>> >> 39 files changed, 581 insertions(+), 918 deletions(-) >>> >> create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch >>> >> 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/emptty.tab >>> >> create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf >>> >> create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb >>> >> 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/default.desktop >>> >> 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 >>> >> 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 >>> >> create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 >>> >> >>> >> -- >>> >> 2.51.0 >>> >> >>> >> >>> >> >>> >> >>>
On Thu, Sep 18, 2025 at 4:42 PM Randolph Sapp <rs@ti.com> wrote: > > On Thu Sep 18, 2025 at 5:39 PM CDT, Randolph Sapp via lists.openembedded.org wrote: > > On Thu Sep 18, 2025 at 5:35 PM CDT, Joshua Watt wrote: > >> On Thu, Sep 18, 2025 at 4:31 PM Randolph Sapp <rs@ti.com> wrote: > >>> > >>> On Thu Sep 18, 2025 at 5:25 PM CDT, Joshua Watt wrote: > >>> > On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via > >>> > lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. > >>> > > >>> > It's not clear how switching to emptty actually solves that problem; I > >>> > don't see anything in my (brief) look at the emptty code that would > >>> > lead me to believe it actually cares about any drm devices being > >>> > present or handles devices showing up dynamically. Can you maybe > >>> > elaborate more on this? > >>> > >>> It doesn't currently have any tests to wait for the DRM device. I still need to > >>> look into adding that, but what it currently does is add a retry event counter > >>> and a small delay between retries that is better than the current console > >>> implementations. Especially considering authentication is handled separately > >>> from this retry process. > >>> > >>> By centralizing display manager specific code, common checks and fallback logic > >>> can be more easily implemented in the future. I'm hoping this lays the > >>> groundwork to let me address some other issues I've seen in multi-card > >>> environments as well. > >> > >> For the systemd parts, is it also possible to solve this with e.g. > >> > >> Requires=dev-dri-card0.device > >> After=dev-dri-card0.device > >> > >> (or similar) ? Seems like anything emptty would be doing would be a > >> reimplementation of the logic that already exists in systemd to do > >> that. > > > > It gets messy. A udev rule needs to be made to make systemd track that device. Ya, that's pretty normal. > > In a multi-card environment a device without an actual display may be picked. > > Systemd cannot directly solve the issue on it's own. Sure, but isn't that what udev is for? I don't think adding selection of a drm device makes sense in emptty. Regardless of init system, it really feels like selection of the correct device to use for display should be a udev problem. > > Additionally, there are more init systems supported here than just systemd... > > >>> >> 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. > >>> >> > >>> >> [1] 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 > >>> >> > >>> >> Randolph Sapp (6): > >>> >> libx11: create tmpfile dir for x11 domain socket > >>> >> go: fix sigaction usage on i386 platforms > >>> >> emptty: add version 0.14.0 > >>> >> weston-init: convert to virtual-emptty-conf > >>> >> weston: remove deprecated weston-start scripts > >>> >> xserver-nodm-init: convert to virtual-emptty-conf > >>> >> > >>> >> .../conf/distro/include/default-providers.inc | 1 + > >>> >> meta/conf/distro/include/maintainers.inc | 6 +- > >>> >> meta/lib/oeqa/runtime/cases/weston.py | 18 +- > >>> >> meta/lib/oeqa/runtime/cases/xorg.py | 8 + > >>> >> meta/recipes-devtools/go/go-1.25.0.inc | 1 + > >>> >> ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ > >>> >> meta/recipes-graphics/emptty/emptty-conf.bb | 14 + > >>> >> meta/recipes-graphics/emptty/emptty.inc | 26 ++ > >>> >> .../recipes-graphics/emptty/emptty/emptty.tab | 1 + > >>> >> meta/recipes-graphics/emptty/emptty/pamconf | 10 + > >>> >> meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ > >>> >> meta/recipes-graphics/wayland/weston-init.bb | 61 +-- > >>> >> .../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/default.desktop | 5 + > >>> >> .../xserver-nodm-init/emptty.conf.in | 77 ++++ > >>> >> .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ > >>> >> .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- > >>> >> .../xserver-nodm-init/xserver-nodm.conf.in | 7 - > >>> >> .../xserver-nodm-init/xserver-nodm.service.in | 11 - > >>> >> .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- > >>> >> meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + > >>> >> .../xorg-lib/libx11_1.8.12.bb | 15 +- > >>> >> .../user-creation/xuser-account_0.1.bb | 3 +- > >>> >> 39 files changed, 581 insertions(+), 918 deletions(-) > >>> >> create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch > >>> >> 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/emptty.tab > >>> >> create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf > >>> >> create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb > >>> >> 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/default.desktop > >>> >> 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 > >>> >> 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 > >>> >> create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 > >>> >> > >>> >> -- > >>> >> 2.51.0 > >>> >> > >>> >> > >>> >> > >>> >> > >>> >
On Thu Sep 18, 2025 at 6:03 PM CDT, Joshua Watt wrote: > On Thu, Sep 18, 2025 at 4:42 PM Randolph Sapp <rs@ti.com> wrote: >> >> On Thu Sep 18, 2025 at 5:39 PM CDT, Randolph Sapp via lists.openembedded.org wrote: >> > On Thu Sep 18, 2025 at 5:35 PM CDT, Joshua Watt wrote: >> >> On Thu, Sep 18, 2025 at 4:31 PM Randolph Sapp <rs@ti.com> wrote: >> >>> >> >>> On Thu Sep 18, 2025 at 5:25 PM CDT, Joshua Watt wrote: >> >>> > On Thu, Sep 18, 2025 at 3:49 PM Randolph Sapp via >> >>> > lists.openembedded.org <rs=ti.com@lists.openembedded.org> 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. >> >>> > >> >>> > It's not clear how switching to emptty actually solves that problem; I >> >>> > don't see anything in my (brief) look at the emptty code that would >> >>> > lead me to believe it actually cares about any drm devices being >> >>> > present or handles devices showing up dynamically. Can you maybe >> >>> > elaborate more on this? >> >>> >> >>> It doesn't currently have any tests to wait for the DRM device. I still need to >> >>> look into adding that, but what it currently does is add a retry event counter >> >>> and a small delay between retries that is better than the current console >> >>> implementations. Especially considering authentication is handled separately >> >>> from this retry process. >> >>> >> >>> By centralizing display manager specific code, common checks and fallback logic >> >>> can be more easily implemented in the future. I'm hoping this lays the >> >>> groundwork to let me address some other issues I've seen in multi-card >> >>> environments as well. >> >> >> >> For the systemd parts, is it also possible to solve this with e.g. >> >> >> >> Requires=dev-dri-card0.device >> >> After=dev-dri-card0.device >> >> >> >> (or similar) ? Seems like anything emptty would be doing would be a >> >> reimplementation of the logic that already exists in systemd to do >> >> that. >> > >> > It gets messy. A udev rule needs to be made to make systemd track that device. > > Ya, that's pretty normal. Udev is dependent on systemd. Eudev exists, but why would we pull that in simply to manage displays. It's not necessary for anything else at the moment. >> > In a multi-card environment a device without an actual display may be picked. >> > Systemd cannot directly solve the issue on it's own. > > Sure, but isn't that what udev is for? I don't think adding selection > of a drm device makes sense in emptty. Regardless of init system, it > really feels like selection of the correct device to use for display > should be a udev problem. Udev can track events but it does not report existing states. If a display is already plugged in during boot then we won't know. We can catch the plug event and operate on it, but otherwise it's a guess to see what we can do at boot. For quite some time there has been a service to *manage displays* prior to starting the desktop environment. GDM is a good example of that. Greetd is another. Lightdm is another. Emptty is just an example of a useful all-rounder with a permissive license I thought people would appreciate. >> Additionally, there are more init systems supported here than just systemd... >> >> >>> >> 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. >> >>> >> >> >>> >> [1] 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 >> >>> >> >> >>> >> Randolph Sapp (6): >> >>> >> libx11: create tmpfile dir for x11 domain socket >> >>> >> go: fix sigaction usage on i386 platforms >> >>> >> emptty: add version 0.14.0 >> >>> >> weston-init: convert to virtual-emptty-conf >> >>> >> weston: remove deprecated weston-start scripts >> >>> >> xserver-nodm-init: convert to virtual-emptty-conf >> >>> >> >> >>> >> .../conf/distro/include/default-providers.inc | 1 + >> >>> >> meta/conf/distro/include/maintainers.inc | 6 +- >> >>> >> meta/lib/oeqa/runtime/cases/weston.py | 18 +- >> >>> >> meta/lib/oeqa/runtime/cases/xorg.py | 8 + >> >>> >> meta/recipes-devtools/go/go-1.25.0.inc | 1 + >> >>> >> ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ >> >>> >> meta/recipes-graphics/emptty/emptty-conf.bb | 14 + >> >>> >> meta/recipes-graphics/emptty/emptty.inc | 26 ++ >> >>> >> .../recipes-graphics/emptty/emptty/emptty.tab | 1 + >> >>> >> meta/recipes-graphics/emptty/emptty/pamconf | 10 + >> >>> >> meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ >> >>> >> meta/recipes-graphics/wayland/weston-init.bb | 61 +-- >> >>> >> .../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/default.desktop | 5 + >> >>> >> .../xserver-nodm-init/emptty.conf.in | 77 ++++ >> >>> >> .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ >> >>> >> .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- >> >>> >> .../xserver-nodm-init/xserver-nodm.conf.in | 7 - >> >>> >> .../xserver-nodm-init/xserver-nodm.service.in | 11 - >> >>> >> .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- >> >>> >> meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + >> >>> >> .../xorg-lib/libx11_1.8.12.bb | 15 +- >> >>> >> .../user-creation/xuser-account_0.1.bb | 3 +- >> >>> >> 39 files changed, 581 insertions(+), 918 deletions(-) >> >>> >> create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch >> >>> >> 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/emptty.tab >> >>> >> create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf >> >>> >> create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb >> >>> >> 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/default.desktop >> >>> >> 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 >> >>> >> 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 >> >>> >> create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11 >> >>> >> >> >>> >> -- >> >>> >> 2.51.0 >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >>
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
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.
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.
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
On Mon, 2025-09-22 at 18:16 -0500, Randolph Sapp wrote: > 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. Ideally, we'd create a normal user and have the tests use that normal user. The "root" based tests are historical and were done as testing something was better than nothing. The world expects better security practises and it would be good to ideally update the tests to better match real world usage. I say ideally since I appreciate it sometimes can be too much work but in this case it might not be, I haven't dug into the details though and I'm a bit distracted. I just thought that info might be helpful for direction. Cheers, Richard
On Tue Sep 23, 2025 at 4:03 AM CDT, Richard Purdie wrote: > On Mon, 2025-09-22 at 18:16 -0500, Randolph Sapp wrote: >> 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. > > Ideally, we'd create a normal user and have the tests use that normal > user. The "root" based tests are historical and were done as testing > something was better than nothing. The world expects better security > practises and it would be good to ideally update the tests to better > match real world usage. > > I say ideally since I appreciate it sometimes can be too much work but > in this case it might not be, I haven't dug into the details though and > I'm a bit distracted. I just thought that info might be helpful for > direction. > > Cheers, > > Richard Thanks for the feedback Richard. There is currently already an xuser account that is pulled in when ROOTLESS_X = 0. I assume the default behavior of x11 running as root is a holdover from that period before rootless x was possible. I can rework these tests and drop the root x11 compatibility path if everyone is alright with that. - Randolph
On Tue Sep 23, 2025 at 12:56 PM CDT, Randolph Sapp via lists.openembedded.org wrote: > On Tue Sep 23, 2025 at 4:03 AM CDT, Richard Purdie wrote: >> On Mon, 2025-09-22 at 18:16 -0500, Randolph Sapp wrote: >>> 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. >> >> Ideally, we'd create a normal user and have the tests use that normal >> user. The "root" based tests are historical and were done as testing >> something was better than nothing. The world expects better security >> practises and it would be good to ideally update the tests to better >> match real world usage. >> >> I say ideally since I appreciate it sometimes can be too much work but >> in this case it might not be, I haven't dug into the details though and >> I'm a bit distracted. I just thought that info might be helpful for >> direction. >> >> Cheers, >> >> Richard > > Thanks for the feedback Richard. There is currently already an xuser account > that is pulled in when ROOTLESS_X = 0. I assume the default behavior of x11 > running as root is a holdover from that period before rootless x was possible. > > I can rework these tests and drop the root x11 compatibility path if everyone is > alright with that. > > - Randolph Ah, should have proof read that a little more. ... when ROOTLESS_X = 1 ... Point still stands. I'll drop the root x11 path unless anyone objects.
On Tue, 2025-09-23 at 13:04 -0500, Randolph Sapp wrote: > On Tue Sep 23, 2025 at 12:56 PM CDT, Randolph Sapp via > lists.openembedded.org wrote: > > On Tue Sep 23, 2025 at 4:03 AM CDT, Richard Purdie wrote: > > > On Mon, 2025-09-22 at 18:16 -0500, Randolph Sapp wrote: > > > > 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. > > > > > > Ideally, we'd create a normal user and have the tests use that > > > normal > > > user. The "root" based tests are historical and were done as > > > testing > > > something was better than nothing. The world expects better > > > security > > > practises and it would be good to ideally update the tests to > > > better > > > match real world usage. > > > > > > I say ideally since I appreciate it sometimes can be too much > > > work but > > > in this case it might not be, I haven't dug into the details > > > though and > > > I'm a bit distracted. I just thought that info might be helpful > > > for > > > direction. > > > > > > Cheers, > > > > > > Richard > > > > Thanks for the feedback Richard. There is currently already an > > xuser account > > that is pulled in when ROOTLESS_X = 0. I assume the default > > behavior of x11 > > running as root is a holdover from that period before rootless x > > was possible. > > > > I can rework these tests and drop the root x11 compatibility path > > if everyone is > > alright with that. > > > > - Randolph > > Ah, should have proof read that a little more. > ... when ROOTLESS_X = 1 ... > > Point still stands. I'll drop the root x11 path unless anyone > objects. I think it works on some architectures but not all so dropping it may not be quite that simple. Cheers, Richard
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. [1] 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 Randolph Sapp (6): libx11: create tmpfile dir for x11 domain socket go: fix sigaction usage on i386 platforms emptty: add version 0.14.0 weston-init: convert to virtual-emptty-conf weston: remove deprecated weston-start scripts xserver-nodm-init: convert to virtual-emptty-conf .../conf/distro/include/default-providers.inc | 1 + meta/conf/distro/include/maintainers.inc | 6 +- meta/lib/oeqa/runtime/cases/weston.py | 18 +- meta/lib/oeqa/runtime/cases/xorg.py | 8 + meta/recipes-devtools/go/go-1.25.0.inc | 1 + ...ng-cgo-on-386-call-C-sigaction-funct.patch | 248 ++++++++++++ meta/recipes-graphics/emptty/emptty-conf.bb | 14 + meta/recipes-graphics/emptty/emptty.inc | 26 ++ .../recipes-graphics/emptty/emptty/emptty.tab | 1 + meta/recipes-graphics/emptty/emptty/pamconf | 10 + meta/recipes-graphics/emptty/emptty_0.14.0.bb | 53 +++ meta/recipes-graphics/wayland/weston-init.bb | 61 +-- .../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/default.desktop | 5 + .../xserver-nodm-init/emptty.conf.in | 77 ++++ .../xserver-nodm-init/gplv2-license.patch | 355 ------------------ .../x11-common/xserver-nodm-init/xserver-nodm | 75 ---- .../xserver-nodm-init/xserver-nodm.conf.in | 7 - .../xserver-nodm-init/xserver-nodm.service.in | 11 - .../x11-common/xserver-nodm-init_3.0.bb | 57 +-- meta/recipes-graphics/xorg-lib/libx11/99_x11 | 1 + .../xorg-lib/libx11_1.8.12.bb | 15 +- .../user-creation/xuser-account_0.1.bb | 3 +- 39 files changed, 581 insertions(+), 918 deletions(-) create mode 100644 meta/recipes-devtools/go/go/0001-runtime-when-using-cgo-on-386-call-C-sigaction-funct.patch 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/emptty.tab create mode 100644 meta/recipes-graphics/emptty/emptty/pamconf create mode 100644 meta/recipes-graphics/emptty/emptty_0.14.0.bb 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/default.desktop 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 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 create mode 100644 meta/recipes-graphics/xorg-lib/libx11/99_x11