Linux: select between X11 and Wayland at runtime.

[dbstream]

Background

On Linux, there are two commonly used WSI platforms available: Wayland and X11 (note: X11 is available in Vulkan as both XCB and Xlib, but they can be considered "basically the same"). X11 has been the dominating WSI platform for some time, but Wayland is gaining momentum.

Problem

Currently the application is distributed as distinct binaries for Wayland and X11. This is impractical as users migrate from X11 to Wayland, and for other reasons.

Proposed solution

The application can test for Wayland presence by looking at the return value of getenv("WAYLAND_DISPLAY"). Based on the returned value, the application can create either a wl_surface or an xcb_surface_t and use it as the basis for VkSurfaceKHR creation. If wl_surface creation fails, the application can fallback to XCB.

Considerations

1. Can we cheat? Does Qt5 provide shortcuts to creating a wl_surface or an xcb_surface? If it does, should we use them?
2. Should libwayland be a requirement of the application? If yes, it adds burden to the users by requiring them to install libwayland even if they only use X11. If no, it adds burden to the code, in the form of dlopen and dlsym lookups.

[dbstream]

I can probably work on this, but not until in three or four days from now, as I will be busy. Will post PR if any positive results are achieved.

[dbstream]

My opinion on the above considerations:

1. We shouldn't cheat using Qt5. This is mainly for two reasons: low-level interactions with the platform are most likely internal to Qt5 (and if they aren't, they should be), and if the application is migrated to another graphics toolkit (or Qt6), it can affect our code.
2. No, and neither should libxcb.

[HildarTheDorf]

I am also happy to work on this.
I did the minimum to unbreak things by default in #221 #222. But I agree that there should be no reason to need to ship two binaries.

My answer to the above questions is:

1. NO. The backend used by Qt should not in any way limit the surface backend selected by the application.
2. YES. We should continue to expose the X11/WAYLAND compile flags. However enabling both should just work (either default to wayland unless inavailable, or a stretch goal of obtaining information from both surface backends). Packagers can then choose to ship two binaries or a combined binary.

@SaschaWillems Does the database API support a single report having information for multiple surface backends?

[dbstream]

Issue #216 is relevant.

[SaschaWillems]

Does the database API support a single report having information for multiple surface backends?

Can you elaborate? How would that look like?

It's a SQL database, so linear tables and a e.g. 1:n relation between a report and it's surface formats.

[HildarTheDorf]

So on Linux it is possible (and increasingly common) to run a wayland compositor with xwayland. This means that both native wayland connections and X connections (via xwayland) are possible at the same time.

So right now on my laptop X surfaces support BGRA8_SRGB and BGRA8_UNORM. While Wayland surfaces support considerably more. There's no requirement that the X-supported formats are a subset of the wayland formats (or vice versa).

It looks like the DB has merged my two reports into a single entry? https://vulkan.gpuinfo.org/listreports.php?submitter=Karen%20Webb

[SaschaWillems]

Well, the database doesn't really support that scenario. The "merge" you see is the update logic that allows for certain attributes of a report to be updated for an already submitted report.

[HildarTheDorf]

Given the DB only supports a single set of surface capabilities for a device, would it be acceptable to just report wayland information where possible and X only when wayland isn't available?

[SaschaWillems]

Sure, should be fine.