Support wayland in qm main package

[aesteve-rh]

Goal

With the goal set to support wayland in QM, we need a place to put these files that represent the workloads that will be included in the QM container:

├── etc
│   ├── container
│   │   └── systemd
│   │       ├── qm-dbus-broker.container
│   │       ├── wayland-base.container
│   │       └── wayland-base.container.d
│   │           └── wayland-extra-devices.conf
│   ├── pam.d
│   │   ├── systemd-user
│   │   └── wayland-autologin
│   └── systemd
│       └── system
│           ├── qm-dbus.socket
│           ├── wayland-session.service
│           └── wayland.socket
└── usr
    └── bin
        └── wayland-session

These would handle the user session, the dbus user session, and the wayland compositor itself. The idea is that the setup will be available in every installed qm instance, but if the user does not want support for graphics, it should be disabled by default. And enabled ONLY if graphical target is enabled.

The goal is to have them using, by default, an image that could reside in a public repository. Probably in https://quay.io/organization/qm-images, at least in the first iteration. For this, we could also upstream the containerfiles in qm so that these container images are easy to maintain, build, and update.

AIB

However, there are two missing parts that will need to be handled from automotive-image-builder:

• Flag for enabling the wayland usescase: this flag will create drop-ins for qm with all additional devices requires for logind seat support, and graphics.
• Flag for overriding wayland-base (compositor) images (and possibly others): to make the scenario flexible with custom, non-standard (or simply alternative) compositor build for certain boards, etc, we can allow aib to override the container image of the compositor container within qm. Probably with another drop-in.

Questions

• Currently there is the subsystems/windowmanager folder for containing the scenario, as a subpackage. The problem is that the scenario has evolved a bit since we did that. And we do not want it to be a subpackage, but part of the main package instead. Where would be a good place in the repository to put the .container and .socket files, etc? Do we want to make the containerfiles also available? (I think so, but asking it here to see what others think).
• Do we want to use https://quay.io/organization/qm-images?
• How can we test that the scenario?

[aesteve-rh]

cc: @telemaco @alexlarsson @dougsland @Yarboa

[Yarboa]

Currently there is the subsystems/windowmanager folder for containing the scenario, as a subpackage. The problem is that the scenario has evolved a bit since we did that. And we do not want it to be a subpackage, but part of the main package instead.
Where would be a good place in the repository to put the .container and .socket files, etc? Do we want to make the containerfiles also available? (I think so, but asking it here to see what others think).

I think we should rename all subpackages -> demos
maintain the dir tree,
Once tests are running they will create configurations to
rootfs
qmrootfs

Do we want to use https://quay.io/organization/qm-images?

SGTM

How can we test that the scenario?

I think weston should run with --log=/tmp/weston.log,
first check /run/user/0/wayland-0 created successfully
All containers are active

Note: For aib, i think it should be in 2nd step,
AFAIR, there is no agreement of autosd to have configurations through QM repo
Once it will be discussed with autosd community we will have a way how to approach it

VM need to run in gpu emulation,
Adding vulkan dependency container

[Yarboa]

Once it is ready,
Need to update this part to work with upstream oci-hooks
#934