| Message ID | 20250505224801.3181046-1-rs@ti.com |
|---|---|
| Headers | show |
| Series | Display manager proposal for x11 and wayland | expand |
On Tue May 6, 2025 at 12:47 AM 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. > > [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 Hi Randolph, Thanks for the v2. However, it looks like we still have an error with the emptty dependency: ERROR: Nothing RPROVIDES 'emptty' (but /srv/pokybuild/yocto-worker/qemux86-64-x32/build/meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb RDEPENDS on or otherwise requires it) emptty was skipped: incompatible with host x86_64-poky-linux-gnux32 (not in COMPATIBLE_HOST) https://autobuilder.yoctoproject.org/valkyrie/#/builders/11/builds/1512 Can you have a look at the issue please?
On Tue May 6, 2025 at 2:47 AM CDT, Mathieu Dubois-Briand wrote: > On Tue May 6, 2025 at 12:47 AM 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. >> >> [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 > > Hi Randolph, > > Thanks for the v2. > > However, it looks like we still have an error with the emptty > dependency: > > ERROR: Nothing RPROVIDES 'emptty' (but /srv/pokybuild/yocto-worker/qemux86-64-x32/build/meta/recipes-graphics/x11-common/xserver-nodm-init_3.0.bb RDEPENDS on or otherwise requires it) > emptty was skipped: incompatible with host x86_64-poky-linux-gnux32 (not in COMPATIBLE_HOST) > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/11/builds/1512 > > Can you have a look at the issue please? Ah, this is the first I hearing about the gnux32 triplet. Well, that is being filtered out by COMPATIBLE_HOST in the goarch bbclass. Some of those values seem to be invalid now (powerpc64 is supported upstream). That being said, I don't see any mention of the new x32 ABI upstream. Not entirely sure how to address that at the moment.
On Wed, 7 May 2025 at 01:03, Randolph Sapp via lists.openembedded.org <rs=ti.com@lists.openembedded.org> wrote: > Ah, this is the first I hearing about the gnux32 triplet. Well, that is being > filtered out by COMPATIBLE_HOST in the goarch bbclass. Some of those values seem > to be invalid now (powerpc64 is supported upstream). That being said, I don't > see any mention of the new x32 ABI upstream. Not entirely sure how to address > that at the moment. There are two options: - set up the x32 build as specified in [1], replicate the fail, tweak COMPATIBLE_HOST as needed (in a separate commit) and see if any further issues come up. - correct [1] to no longer build core-image-sato for x32, and replace it with core-image-full-cmdline, reducing x32 to non-graphical targets. It's been a controversial target for a long time, as no one has ever seen actual usage of it, and there's been a stream of graphical related crashes and build failures. We keep it around for now, but I'd fully support dropping the graphics and leaving only the console images. [1] https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n867 Alex
On Wed May 7, 2025 at 8:37 AM CDT, Alexander Kanavin wrote: > On Wed, 7 May 2025 at 01:03, Randolph Sapp via lists.openembedded.org > <rs=ti.com@lists.openembedded.org> wrote: > >> Ah, this is the first I hearing about the gnux32 triplet. Well, that is being >> filtered out by COMPATIBLE_HOST in the goarch bbclass. Some of those values seem >> to be invalid now (powerpc64 is supported upstream). That being said, I don't >> see any mention of the new x32 ABI upstream. Not entirely sure how to address >> that at the moment. > > There are two options: > > - set up the x32 build as specified in [1], replicate the fail, tweak > COMPATIBLE_HOST as needed (in a separate commit) and see if any > further issues come up. > > - correct [1] to no longer build core-image-sato for x32, and replace > it with core-image-full-cmdline, reducing x32 to non-graphical > targets. It's been a controversial target for a long time, as no one > has ever seen actual usage of it, and there's been a stream of > graphical related crashes and build failures. We keep it around for > now, but I'd fully support dropping the graphics and leaving only the > console images. > > [1] https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n867 > > Alex Alright, well I did a little work poking around go. It has no understanding of the x32 ABI currently. Dropping the x32 tests from core-image-sato to core-image-full-cmdline can work, but that does mask a bit of a regression. As useful as a display manager will be, I'm not sure I can justify that much of a regression for an entire ABI. I know the linux kernel has debated about dropping x32 support a number of times, GCC seems to be the only compiler that has fully implemented it, and Yocto is one of 3 listed distro solutions that currently support it. Still feels a little rough. I don't know. Anyone got any strong opinions here?
On Wed May 7, 2025 at 3:42 PM CDT, Randolph Sapp via lists.openembedded.org wrote: > On Wed May 7, 2025 at 8:37 AM CDT, Alexander Kanavin wrote: >> On Wed, 7 May 2025 at 01:03, Randolph Sapp via lists.openembedded.org >> <rs=ti.com@lists.openembedded.org> wrote: >> >>> Ah, this is the first I hearing about the gnux32 triplet. Well, that is being >>> filtered out by COMPATIBLE_HOST in the goarch bbclass. Some of those values seem >>> to be invalid now (powerpc64 is supported upstream). That being said, I don't >>> see any mention of the new x32 ABI upstream. Not entirely sure how to address >>> that at the moment. >> >> There are two options: >> >> - set up the x32 build as specified in [1], replicate the fail, tweak >> COMPATIBLE_HOST as needed (in a separate commit) and see if any >> further issues come up. >> >> - correct [1] to no longer build core-image-sato for x32, and replace >> it with core-image-full-cmdline, reducing x32 to non-graphical >> targets. It's been a controversial target for a long time, as no one >> has ever seen actual usage of it, and there's been a stream of >> graphical related crashes and build failures. We keep it around for >> now, but I'd fully support dropping the graphics and leaving only the >> console images. >> >> [1] https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n867 >> >> Alex > > Alright, well I did a little work poking around go. It has no understanding of > the x32 ABI currently. Dropping the x32 tests from core-image-sato to > core-image-full-cmdline can work, but that does mask a bit of a regression. > > As useful as a display manager will be, I'm not sure I can justify that much of > a regression for an entire ABI. I know the linux kernel has debated about > dropping x32 support a number of times, GCC seems to be the only compiler that > has fully implemented it, and Yocto is one of 3 listed distro solutions that > currently support it. Still feels a little rough. I don't know. > > Anyone got any strong opinions here? Well, I guess we'll go with a old fashioned scream test. Let me know if there are any other issues that need to be addressed or if I need to resubmit this series if the following is accepted. https://lists.yoctoproject.org/g/yocto-patches/message/1539
On Thu, 2025-05-08 at 15:39 -0500, Randolph Sapp wrote: > On Wed May 7, 2025 at 3:42 PM CDT, Randolph Sapp via lists.openembedded.org wrote: > > On Wed May 7, 2025 at 8:37 AM CDT, Alexander Kanavin wrote: > > > On Wed, 7 May 2025 at 01:03, Randolph Sapp via lists.openembedded.org > > > <rs=ti.com@lists.openembedded.org> wrote: > > > > > > > Ah, this is the first I hearing about the gnux32 triplet. Well, that is being > > > > filtered out by COMPATIBLE_HOST in the goarch bbclass. Some of those values seem > > > > to be invalid now (powerpc64 is supported upstream). That being said, I don't > > > > see any mention of the new x32 ABI upstream. Not entirely sure how to address > > > > that at the moment. > > > > > > There are two options: > > > > > > - set up the x32 build as specified in [1], replicate the fail, tweak > > > COMPATIBLE_HOST as needed (in a separate commit) and see if any > > > further issues come up. > > > > > > - correct [1] to no longer build core-image-sato for x32, and replace > > > it with core-image-full-cmdline, reducing x32 to non-graphical > > > targets. It's been a controversial target for a long time, as no one > > > has ever seen actual usage of it, and there's been a stream of > > > graphical related crashes and build failures. We keep it around for > > > now, but I'd fully support dropping the graphics and leaving only the > > > console images. > > > > > > [1] https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n867 > > > > > > Alex > > > > Alright, well I did a little work poking around go. It has no understanding of > > the x32 ABI currently. Dropping the x32 tests from core-image-sato to > > core-image-full-cmdline can work, but that does mask a bit of a regression. > > > > As useful as a display manager will be, I'm not sure I can justify that much of > > a regression for an entire ABI. I know the linux kernel has debated about > > dropping x32 support a number of times, GCC seems to be the only compiler that > > has fully implemented it, and Yocto is one of 3 listed distro solutions that > > currently support it. Still feels a little rough. I don't know. > > > > Anyone got any strong opinions here? > > Well, I guess we'll go with a old fashioned scream test. Let me know if there > are any other issues that need to be addressed or if I need to resubmit this > series if the following is accepted. > > https://lists.yoctoproject.org/g/yocto-patches/message/1539 Sadly, people don't pay attention and simply won't see this to know they need to scream. I've just gone ahead and merged it. We're not seeing much use of x32 as far as I can tell. Cheers, Richard
On Tue May 6, 2025 at 12:47 AM 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. > > [1] https://github.com/tvrzna/emptty > Ok, so I tried again to merge this patch, and I believe I've got new errors: RESULTS - xorg.XorgTest.test_xorg_running: FAILED (1.43s) ... AssertionError: 1 != 0 : Xorg does not appear to be running https://autobuilder.yoctoproject.org/valkyrie/#/builders/9/builds/1579 https://autobuilder.yoctoproject.org/valkyrie/#/builders/20/builds/1567 https://autobuilder.yoctoproject.org/valkyrie/#/builders/67/builds/1620 https://autobuilder.yoctoproject.org/valkyrie/#/builders/68/builds/1661 https://autobuilder.yoctoproject.org/valkyrie/#/builders/74/builds/1582 https://autobuilder.yoctoproject.org/valkyrie/#/builders/92/builds/1589 Traceback (most recent call last): File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/runtime/cases/weston.py", line 63, in test_wayland_info self.assertEqual(status, 0, msg='wayland-info error: %s' % output) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: 255 != 0 : wayland-info error: failed to create display: Connection refused Traceback (most recent call last): File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/runtime/cases/weston.py", line 67, in test_weston_can_initialize_new_wayland_compositor existing_wl_processes = self.get_processes_of('weston-desktop-shell', 'existing') File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/runtime/cases/weston.py", line 32, in get_processes_of self.assertEqual(status, 0, msg='Retrieve %s (%s) processes error: %s' % (target, error_msg, output)) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: 1 != 0 : Retrieve weston-desktop-shell (existing) processes error: Traceback (most recent call last): File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/runtime/cases/weston.py", line 28, in test_weston_running self.assertEqual(status, 0, msg=msg) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ AssertionError: 1 != 0 : Weston does not appear to be running PID USER VSZ STAT COMMAND Traceback (most recent call last): File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/lib/oeqa/runtime/cases/weston.py", line 89, in test_weston_supports_xwayland self.assertEqual(status, 0, msg=msg) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ AssertionError: 1 != 0 : xwayland does not appear to be running ... RESULTS - weston.WestonTest.test_wayland_info: FAILED (0.51s) RESULTS - weston.WestonTest.test_weston_can_initialize_new_wayland_compositor: FAILED (0.30s) RESULTS - weston.WestonTest.test_weston_running: FAILED (0.78s) RESULTS - weston.WestonTest.test_weston_supports_xwayland: FAILED (0.49s) https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1661 https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1514 Traceback (most recent call last): File "/srv/pokybuild/yocto-worker/no-x11/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/no-x11/build/meta/lib/oeqa/runtime/cases/weston.py", line 63, in test_wayland_info self.assertEqual(status, 0, msg='wayland-info error: %s' % output) AssertionError: 255 != 0 : wayland-info error: failed to create display: No such file or directory ... RESULTS - weston.WestonTest.test_wayland_info: FAILED (0.52s) https://autobuilder.yoctoproject.org/valkyrie/#/builders/25/builds/1596 https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/1545 https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/2356168/raw_inline 2025-05-12 21:09:25,962 - oe-selftest - INFO - ERROR: Nothing RPROVIDES 'weston-init' (but /srv/pokybuild/yocto-worker/reproducible/build/meta/recipes-graphics/wayland/weston_14.0.1.bb, /srv/pokybuild/yocto-worker/reproducible/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb RDEPENDS on or otherwise requires it) 2025-05-12 21:09:25,962 - oe-selftest - INFO - weston-init was skipped: Recipe weston-init, package weston-init: system groupname "nopasswdlogin" does not have a static ID defined. Add nopasswdlogin to one of these files: /srv/pokybuild/yocto-worker/reproducible/build/build-st/meta-selftest/files/static-group ... 2025-05-12 21:09:25,963 - oe-selftest - INFO - ERROR: Nothing RPROVIDES 'weston-dev' (but /srv/pokybuild/yocto-worker/reproducible/build/meta/recipes-graphics/wayland/weston_14.0.1.bb RDEPENDS on or otherwise requires it) ... 2025-05-12 21:09:25,963 - oe-selftest - INFO - ERROR: Nothing RPROVIDES 'weston' (but /srv/pokybuild/yocto-worker/reproducible/build/meta/recipes-graphics/wayland/weston_14.0.1.bb, /srv/pokybuild/yocto-worker/reproducible/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb RDEPENDS on or otherwise requires it) ... 2025-05-12 21:09:25,963 - oe-selftest - INFO - ERROR: Nothing RPROVIDES 'weston-examples' (but /srv/pokybuild/yocto-worker/reproducible/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb RDEPENDS on or otherwise requires it) ... https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/1642
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 Randolph Sapp (3): emptty: add version 0.14.0 weston-init: convert to virtual-emptty-conf 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 | 2 +- meta/lib/oeqa/runtime/cases/xorg.py | 8 + 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 - .../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 +-- .../user-creation/xuser-account_0.1.bb | 3 +- 32 files changed, 307 insertions(+), 886 deletions(-) create mode 100644 meta/recipes-graphics/emptty/emptty-conf.bb create mode 100644 meta/recipes-graphics/emptty/emptty.inc create mode 100644 meta/recipes-graphics/emptty/emptty/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/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