Increases the default warning level to 3, which includes pedantic
errors. Disable them on C++, which is the way it was done before.
To resolve most pedantic warnings on C++ either the compiler standard
would need to be increased to c++2a or the remaining copositor backends
would require porting to plain C. One of each or both should happen in
the future.
Since we already specify a `warning_level` in the project settings, it
is redundant to manually specify it as compiler parameters.
This patch resolves the following meson warning:
```
meson.build:25: WARNING: Consider using the built-in warning_level option instead of using "-Wall".
meson.build:25: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
```
The project currently is set to meson version 0.49.0 but uses features
the install argument for configure_file was introduced with meson 0.50.0.
This patch removes the unused parameter fixes the following warnings:
```
WARNING: Project targeting '>=0.49.0' but tried to use feature introduced in '0.50.0': install arg in configure_file
WARNING: Project specifies a minimum meson_version '>=0.49.0' but uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
WARNING: Deprecated features used:
* 0.50.0: {'install arg in configure_file'}
```
In an initial patch I just bumped the meson version, but this introduced
problems in our Debian CI.
An increase in the meson version would be possible by using a meson
distribution from pip, as it's done for old distros in xrdesktop.
Since there currently is no Vulkan extension that takes XCB handles to
aqcuire the display Xlib interop needs to be used.
Before this patch Monado was opening connections for both APIs, which
introduced overhead.
Even though all XCB handles can be casted to Xlib ones, this cannot be
done with the main xcb_connection_t / Display. In it's design the
interop between both APIs can create a xcb_connection_t from a XCB
handle, but not the other way round. So in an interop case the Xlib
connection is the main one, since it's on a higher level.
More information on this can be found here:
https://xcb.freedesktop.org/MixingCalls/
Unfortunately the clean solution for this would be to specify a Vulkan
extension that takes XCB handles. This would make sense since Vulkan
is aware of XCB in other parts of the API as well. In Mesa the Xlib
structs will be ultimately casted to XCB.
According the XCB documentation the reply structs must be freed. I found
this when running a minimal example related to the direct mode code in
valgrind.
This allows the data to be safely shared and passed around, even allowing us
to tag frames with the data and passed around that way instead.
Since it now can be passed around more safely make the prober call the save
function instead of the calibration code. This then forms a basis for further
work where we can hook this up into a more proper configuration file.
The previous two call helper macro copied the entire input struct to output struct.
In particular this did not keep the .type and .next fields intact.
Rather than trying to keep those intact, each struct type should have its own fill function,
only filling in the data we actually want to fill in.
