Details
-
Task
-
Resolution: Done
-
P1: Critical
-
None
-
None
-
4cbc411f60d17a6d4f4e9d4156146537d5dc2f16 2e0efd201aa75121f4dd4049598f4d120811d784
Description
Building the QtWayland module is a mess because of how the hardware integrations work. Generally when people build QtWayland, what they expect a wayland platform plugin that will work with Weston. That means that they need to use the wayland-egl hardware integration. This should be the default, as this is the only thing that makes sense without the QtCompositor API.
When the QtCompositor API is enabled, there is the possiblity to have compatibility with other Wayland clients, but only when using the wayland-egl hardware integration. This should be doecumented and wayland-egl should be the default.
All other hardware integration backends are only compatible with other Qt wayland clients also using the same hardware integration backends. This is a completely different usecase than the two previous scenarios, and the way we build Qt should reflect it:
Client Side:
Each hardware integration is built/deployed as a seperate plugin. Wayland-egl is the default and gets the key "wayland". Every other plugin will have a separate plugin key (eg "brcm-wayland" for the BRCM hardware integration).
Server Side:
Hardware integrations should be build/loaded as plugins.