Support wayland in qm main package
- Dominant language
- Shell
- Stars
- 37
- Forks
- 36
- Avg merge
- 10h 36m
- Merged PRs (30d)
- 2
Description
## 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?
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.