Xwayland uses API such as wl_proxy_set_tag()/wl_proxy_get_tag() which
appeared in Wayland 1.18, but the build system still requires Wayland
1.5 at least.
Bump the Wayland version to match the requirements.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This extension exists to serve one purpose: reliably identifying
Xwayland. Previous attempts at doing so included querying root window
properties, output names or input device names. All these attempts are
somewhat unreliable. Instead, let's use an extension - where that
extension is present we have an Xwayland server.
Clients should never need to do anything but check whether the extension
exists through XQueryExtension or search through XListExtensions.
This extension provides a single QueryVersion request only, and
that is only to provide future compatibility if we ever need anything
other than "this extension exists" functionality.
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/54
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bumped in response to warning from meson:
WARNING: Project specifies a minimum meson_version '>= 0.47.0' but uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
Even though there is no warning, we need 0.52.0 for include_type (added in 8264b51e8e8b4c193dc8324cae4f9f675cfbf172) per:
https://mesonbuild.com/Reference-manual_functions.html#arguments17
When running rootful, the Xwayland window is not decorated (as all
Wayland surfaces), which makes it quite inconvenient to move on screen.
libdecor is "a client-side decorations library for Wayland clients"
which can be used precisely for adding decorations to Wayland surfaces.
Add optional support for libdecor in Xwayland to gain decorations when
running rootful and a new command line option "-decorate".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1332
WARNING: Project specifies a minimum meson_version '>= 0.47.0' but uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
libxcvt is a library providing a standalone version of the X server
implementation of the VESA CVT standard timing modelines generator.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
With Wayland compositors now being able to start Xwayland on demand, the
next logical step is to be able to stop Xwayland when there is no more
need for it.
The Xserver itself is capable of terminating itself once all X11 clients
are gone, yet in a typical full session, there are a number of X11
clients running continuously (e.g. the Xsettings daemon, IBus, etc.).
Those always-running clients will prevent the Xserver from terminating,
because the actual number of X11 clients will never drop to 0. Worse,
the X11 window manager of a Wayland compositor also counts as an X11
client, hence also preventing Xwayland from stopping.
Some compositors such as mutter use the XRes extension to query the X11
clients connected, match their PID with the actual executable name and
compare those with a list of executables that can be ignored when
deciding to kill the Xserver.
But that's not just clumsy, it is also racy, because a new X11 client
might initiate a connection the X11 server right when the compositor is
about to kill it.
To solve this issue directly at the Xserver level, this add new entries
to the XFixes extension to let the X11 clients themselves specify the
disconnect mode they expect.
Typically, those X11 daemon clients would specify the disconnect mode
XFixesClientDisconnectFlagTerminate to let the Xserver know that they
should not be accounted for when checking the remaining clients prior
to terminate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Meson has a built-in facility to use bundled versions of dependencies
if system packages are too old. Enable for xorgproto after 8e504d8b36eb:
Run-time dependency xproto found: YES 7.0.33
Run-time dependency randrproto found: YES 1.6.0
Run-time dependency renderproto found: YES 0.11.1
Run-time dependency xextproto found: YES 7.3.0
Dependency inputproto found: NO found 2.3.2 but need: '>= 2.3.99.1'
Found CMake: /usr/local/bin/cmake (3.20.2)
Run-time dependency inputproto found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency inputproto
meson.build:73:0: ERROR: Neither a subproject directory nor a xorgproto.wrap file was found.
This bumps the minimum Wayland version to 1.5 (released in 2014).
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Kernel modesettings support also depends on dri2, see
./hw/xfree86/drivers/modesetting/meson.build
So update meson.build to reflect the changes made in configure.ac by
commit 9c81b8f5b5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Xwayland is usually spawned by the Wayland compositor which sets the
command line options.
If a command line option is not supported, Xwayland will fail to start.
That somehow makes the Xwayland command line option sort of ABI, the
Wayland compositor need to know if a particular option is supported by
Xwayland at build time.
Also, currently, Xwayland is being installed along with the rest of the
common executable programs that users may run, which is sub-optimal
because, well, Xwayland is not a common executable program, it's meant
to be a proxy between the Wayland compositor and the legacy X11 clients
which wouldn't be able to run on Wayland otherwise.
Xwayland would be better installed in `libexec` but that directory is
(purposedly) not in the user `PATH` and therefore the Wayland compositor
may not be able to find Xwayland in that case.
To solve both problems (which options are supported by Xwayland and
where to look for it), add a `pkg-config` file specifically for Xwayland
which gives the full path to Xwayland (`xwayland`) and which options it
supports (using `pkg-config` variables).
The `pkg-config` file also provides the `Version` so the build scripts
can check for a particular version if necessary.
Obviously, Wayland compositors are not required to use the `pkg-config`
file and can continue to use whatever mechanism they deem preferable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently glamor depends on epoxy and gbm, even the autotools build
enforces that.
Follow suite and do the same for the meson build.
v1: Split out from larger patch (Pekka)
Signed-off-by: Emil Velikov <emil.velikov@collbora.com>
There's not really a good reason to keep these separate, the vbe code
requires int10 and is not very large. This change eliminates the
build-time options for vbe; if you build int10, you get vbe.
Gitlab: https://gitlab.freedesktop.org/xorg/xserver/issues/692
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This adds support for xdg-output-unstable-v1 version 3, added in [1].
This new version deprecates zxdg_output_v1.done and replaces it with
wl_output.done. If the version is high enough, there's no need to wait for both
an xdg_output.done event and a wl_output.done event -- we only care about
wl_output.done.
[1]: 962dd53537
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
When building Xwayland with neither DRI nor GLamor support enabled with
the Meson build system, the resulting binary would still link against
libdrm and epoxy even though those are not used/needed.
Make sure we require and link against libdrm and epoxy only if needed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Some modules are required in multiple places in the meson file.
Move the actual requirements to the top of the file as a variable so
that updating a version does not require changing the actual value in
multiple places.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Differences from autotools:
* Autotools defined NO_ALLOCA for OSX builds. I don't think we need
this anymore as Xalloc.h is no longer used anywhere in the xserver.
* X11.bin is linked with -u,miDCInitialize, and then libserver_mi
provided to satisfy (just) that. It's been that way since the commit
which added it. We can't write the equivalent in meson due to linker
argument ordering issues, but do we really need to?
* An explicit -Dsecure-rpc=false is required for OSX, since in meson we
don't do the checks that XTRANS_SECURE_RPC_FLAGS did for the existence
of the specific RPC functions required.
Promote the generated file containing the date & time build was
configured to top-level.
Rename it from xf86Build.h to buildDateTIme.h.
Use it as well in XQuartz, stringize BUILD_DATE when needed.
This has always been described as 'experimental'
We don't think this has any users: This mode has been disabled in Cygwin
packages since March 2016. We've never provided the xwinwm WM for x86_64
Cygwin. No one has even asked where the option has gone.
This leaves XQuartz as the only user of the rootless extension.
Remove --enable-windowswm configure option
Remove multiwindowextwm stuff from Makefiles
Remove -mwextwm option
Remove -mwextwm from man-page and help
Un-ifdef XWIN_MULTIWINDOWEXTWM
v2:
Remove rootless include paths
Remove windowswmproto from meson.build
Applying get_pkgconfig_variable() to a not-found dependency was always
documented as an error, but meson 0.49 now actually raises an error[1]:
meson.build:110:4: ERROR: 'xkbcomp' is not a pkgconfig dependency
Check xkbcomp_dep is a suitable dependency type before applying
get_pkgconfig_variable() to it.
[1] but this is more by accident than design (see the discusssion at [2]
et seq.), so who knows where things will come to rest...
[2] https://github.com/mesonbuild/meson/pull/4444#issuecomment-442443301
We were being naughty:
WARNING: Project specifies a minimum meson_version '>= 0.42.0' but uses features which were added in newer versions:
* 0.46.0: {'compiler.has_multi_link_argument', 'compiler.has_link_argument'}
We forget to assign a value to xf86dgaproto_dep if -Ddga=false, which
causes the meson build to fail:
meson.build:448:0: ERROR: Unknown variable "xf86dgaproto_dep".
A full log can be found at /home/lyudess/build/xserver/meson-logs/meson-log.txt
FAILED: build.ninja
So, just set it to an empty dependency to fix that.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Dependencies are ported from the automake build.
v2: Make it a tristate defaulting to 'auto'. Use pkg-config for libaudit.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Olivier Fourdan
Peter Hutterer
Jeremy Huddleston Sequoia
Xaver Hugl
Povilas Kanapickas
Simon Ser
Jon Turney
Jan Beich
Fabrice Fontaine
Adam Jackson
E5ten
Michel Dänzer
Emil Velikov
Alan Coopersmith
Lyude Paul
Eric Anholt