It turns out xdmx currently crashes when any client attempts to use GL
and it has been in such state for about 14 years. There was a patch to
fix the problem [1] 4 years ago, but it never got merged. The last
activity on any bugs referring to xdmx has been more than 4 years ago.
Given such situation, I find it unlikely that anyone is still using xdmx
and just having the code is a drain of resources.
[1]: https://lists.x.org/archives/xorg-devel/2017-June/053919.html
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
The cvt utility is now replaced by the standalone version found in
libxcvt, no need to build the one in xfree86 anymore.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.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>
Instead of getting the current msc value from the window crtc,
which not exist take the last saved msc value saved in
the window_priv struct
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
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>
With autoconf, hashtable support is built along with Xres support.
Yet, glvnd also use it, so when disabling Xres from configure, the
build will fail at link time because hashtable functions are not
available.
Untie the build of hashtable from Xres support, just like meson build
does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1091
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>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
None of the current BSD is actually using this code.
(checked DragonFly 5.8.1, FreeBSD 11.2, NetBSD 9.0 and OpenBSD 6.7)
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
All helper client code now uses xcb, so calling XSetAuthorization() is
no longer needed.
This is the last reference to libX11 from helper clients, so linking
with x11-xcb and libX11 is no longer required.
Also drop (unneeded?) linking with libXau.
Also drop installing these prerequistes on AppvVeyor.
Also move prototypes for functions in winauth.c from win.h into a new
header, winauth.h, and include that where needed.
Convert clipboard integration code from libX11 to xcb
This drops support for COMPOUND_TEXT. Presumably some ancient
(pre-2000) clients exist which support that, but not UTF8_STRING, but we
don't have an example to test with. (Given the nature of the thing, the
users of those clients probably work in CJK languages)
Supporting COMPOUND_TEXT would also involve writing (or extracting from
Xlib) support for the ISO 2022 encoding.
v2:
Fix the length of text property set by a SelectionRequest
The length of the text property is not neccessarily the same as the
length of the clipboard text before it is d2u converted (specifically,
if that contains any '\r\n' sequences, it will be shorter as they are
now just '\n')
Commit 195c2ef8f9 added this to the Meson
build but neglected to add it to autotools.
v2: Also update dix-config.h.in
Fixes: 195c2ef8f ("glamor: Add a function to get the driver name via EGL_MESA_query_driver")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> [v1]
Reviewed-by: Eric Engestrom <eric@engestrom.ch> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com>
isastream() was never more than a stub in glibc, and was removed in
glibc-2.30 by commit a0a0dc83173c ("Remove obsolete, never-implemented
XSI STREAMS declarations").
Bug: https://bugs.gentoo.org/700838
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
This fixes modesetting driver build failure which can be triggered with
the following configure options:
$ ./configure --disable-dri --disable-dri2 --disable-dri3
--disable-config-udev --enable-xorg
Bugzilla: https://bugs.gentoo.org/689768
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
When using mesa with libglvnd support, mesa will no longer install the
gl, glx, egl pkg-config files but instead let libglvnd provide them.
libglvnd maintainers decided to change the versioning as it was
mesa-specific previously. Now the libraries have versions of the API
they expose[1].
This causes problems when building the X server:
checking for glproto >= 1.4.17 gl >= 9.2.0... no
configure: error: Package requirements (glproto >= 1.4.17 gl >= 9.2.0) were not met:
Requested 'gl >= 9.2.0' but version of gl is 1.2
Lower the version requirement to 1.2 to allow building against libglvnd
provided libraries
[1] 0dfaea2bcb
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 without neither DRI nor GLamor support enabled
with the autotools 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>
The PresentOptionSuboptimal support code is not optional (once you've
enabled building Present at all), so require a protocol package version
that defines what we need.
Fixes: xorg/xserver#821
Rather than drawing the window contents from the shadow framebuffer, use
Composite extension redirection to cause the server to maintain a bitmap
image of each top-level X window, and draw the window contents from
that, so that window contents which are occluded in the framebuffer show
correctly in the task bar and task switcher previews.
v2:
Fix incorrect use of memset() found by gcc5
hw/xwin/winshadgdi.c: In function ‘winBltExposedWindowRegionShadowGDI’:
hw/xwin/winshadgdi.c:861:9: warning: ‘memset’ used with constant zero length parameter; this could be due to transposed parameters [-Wmemset-transposed-args]
v3:
Turn on -compositewm by default
v4:
Ignore -swcursor if -compositewm
-swcursor is not compatible with -compositewm (because the window
contents are drawn from an off-screen pixmap, not from the screen
pixmap, where the software cursor will be drawn).
v5:
Update meson.build also
Add -compositewm option to help output
Update CI to install prerequisites
MinGW defines SIG_BLOCK, but doesn't have signal masks, so rather than
checking for SIG_BLOCK, add a configure check for sigprocmask.
v2:
Also add check to meson.build
I don't think an input thread can ever be useful on Windows.
There is a pthread emulation, so having the thread itself isn't much of
a problem.
However, there is no device to wait on for Windows events, and even if
we were to replace select() with WFMO, Windows wants to send events for
a window to the thread which created that window.
So, disable input thread by default for MinGW
v2:
Also add similar to meson.build
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
It doesn't require shared memory dir and thus allows
to avoid cases when this dir is detected incorrectly,
as in https://bugreports.qt.io/browse/QTBUG-71440
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Prodding the builder's filesystem for tmp dirs doesn't necessarily
tell you anything about what the actual host's filesystem is going to
look like, so we should just try the dirs at runtime.
Signed-off-by: Eric Anholt <eric@anholt.net>
I don't think this is useful information to have in the log, and it's
a bunch of autotools and meson logic to produce it.
Signed-off-by: Eric Anholt <eric@anholt.net>
We already have pm_noop.c being built most of the time for the
no-OS-PM case, so just switch to always using it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
CONFIG_UDEV and CONFIG_UDEV_KMS are the actual defines that are used
in the C code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't used for anything, which is just as well, because
/etc/xorg.conf is not in fact a path xserver will try to use.
Bugzilla: https://bugs.freedesktop.org/8890
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
In commit 9db2af6f75 (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.
Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Povilas Kanapickas
Olivier Fourdan
Matt Turner
Łukasz Spintzyk
Simon Ser
Jeremy Huddleston Sequoia
Fabrice Fontaine
Alan Coopersmith
Matthieu Herrb
Jon Turney
Kenneth Graunke
Alexander Tsoy
Marvin Schmidt
Adam Jackson
Alexander Volkov
Eric Anholt
vadym.shovkoplias