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>
This is silly to have optional based on detection of the protocol
headers, particularly now that we have a single protocol header repo
to install.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
paths returned by get_option('foodir') are potentially relative to prefix
Noticed when comparing manpages generated by a meson build with those
generated by an autotools build
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead, substitute the same values as autotools does
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
meson.build has code to set the module_dir variable to
${libdir}/xorg/modules if the module_dir option string is empty.
However, this has several problems:
1. The variable is only used for an unused @moduledir@ substitution in
the man page. The rule for xorg-server.pc uses option('module_dir')
directly instead.
2. The 'module_dir' option has a default value of 'xorg/modules' so the
above rule doesn't do anything by default.
3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so
the effect of #2 is that the default moduledir is different between
autoconf and meson. E.g. if ${prefix} is /X, then you get
autoconf: moduledir=/X/lib/xorg/modules
meson: moduledir=/X/xorg/modules
Fix this by using the module_dir variable when generating xorg-server.pc, and by
using join_paths() to assign module_dir unconditionally.
v2: Keep the 'xorg/modules' default path, but use join_paths() unconditionally (Thierry Reding)
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Seems that while glxvnd relies on some of the hashtable functions in
Xext, we only build hashtable support for Xext if we're also building
the res extension. This leads to some errors if you try to build glx
without res enabled:
glx/liblibglxvnd.a(vndcmds.c.o): In function `LookupVendorPrivDispatch':
/home/lyudess/Projects/xserver/glx/vndcmds.c:65: undefined reference to `ht_find'
/home/lyudess/Projects/xserver/glx/vndcmds.c:67: undefined reference to `ht_add'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchInit':
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_generic_compare'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_generic_hash'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_create'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchReset':
/home/lyudess/Projects/xserver/glx/vndcmds.c:468: undefined reference to `ht_destroy'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
So, make sure that hashtable.c gets both for both glx and res
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
pixman headers will be included for builds of external modules against
the xorg-server SDK. Make sure pixman is listed as a required module so
that the correct CFLAGS will be added.
Note that the xorg-server.pc generated by the autotools-based build has
many more modules listed, but this seems to be enough to build at least
some of the external drivers against an X server built with Meson (I've
tested with xf86-input-libinput, xf86-video-nouveau and xf86-video-ati).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Querying a pkg-config variable using the --variable option produces the
value of the given variable as stored in the pkg-config file and should
not be used to add directories to the include search path.
The reason for this is that it breaks cross-compilation, because header
files are installed relative to the host sysroot. pkg-config supports a
PKG_CONFIG_SYSROOT_DIR environment variable that points to this sysroot
and will prepend that to the path of directories in -I or -L options in
pkg-config's Cflags, Libs or Libs.private keywords. However, because no
context can be inferred from variable names, as opposed to the keywords
with fixed meaning, the sysroot path will not be prepended to them. The
build system is responsible for doing so if necessary since it is aware
of the context in which the variable is used.
Adding the include directory returned by pkg-config to the include path
leaks build system information into the cross-build and break with very
confusing errors such as this:
In file included from include/misc.h:82:0,
from dix/atom.c:55:
/usr/include/pthread.h:682:6: warning: '__regparm__' attribute directive ignored [-Wattributes]
__cleanup_fct_attribute;
^~~~~~~~~~~~~~~~~~~~~~~
or this:
In file included from include/misc.h:139:0,
from dix/atom.c:55:
/usr/include/stdlib.h:133:8: error: '_Float128' is not supported on this target
extern _Float128 strtof128 (const char *__restrict __nptr,
^~~~~~~~~
Fix this by replacing the include directory with the appropriate xproto
dependency required to add the correct include directory to the compile
command for subdirectories that are missing the dependency. As detailed
above, this gives pkg-config the opportunity to prepend the sysroot for
all paths in -I compiler options.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The newline in the middle of the awk expression confuses Meson and
causes it to pass only the string before the newline to awk, which will
subsequently fail because it encounters an unterminated string.
One fix would be to escape the newlines ('\\n'), but that causes the
newline to end up in the pkg-config file and separate the ABI version
lines by blank lines.
Instead, simply drop the newlines to make the generated pkg-config file
look more like the one generated as part of the autotools-based build.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Meson stores relative paths for includedir, libdir and friends. These
have to be concatenated with the ${prefix} or ${exec_prefix} variables
to create a working pkg-config file.
While at it, set a default value for the module_dir option so that it
points to the same location as used in the autotools-based build.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xdmcp is an optional dependency, so make sure the build succeeds if it
is missing.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The autotools build gets this from some macros in fontutil, but they're
just wrappers around pkgconfig.
v2: Use same default as autotools (Keith Packard)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
If dri1/2/3 are configured for auto-detection, libdrm is required, as well
as the corresponding proto. (Practically we will always have the
corresponding protos now, as they are part of xorgproto).
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Jan Beich
Adam Jackson
E5ten
Jon Turney
Michel Dänzer
Emil Velikov
Alan Coopersmith
Simon Ser
Olivier Fourdan
Lyude Paul
Eric Anholt
Aaron Plattner
Thierry Reding