The dix-config.h file is not installed, but dix.h is. The include makes the
compilation of external drivers fail (for example the libinput driver).
The Xserver compilation also works without the include, so just remove it.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
It is copied using memcpy() and not modified so we can add const. This
fixes a -Wincompatible-pointer-types-discards-qualifiers compiler warning
that was failing a -Werror XVnc build for me.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Meson does not like comparing things of different types which is a
problem when reading back values of feature flags as they may contain
either false (bool) or 1 (string).
Since there is a strong reason why we use false when the feature does
not exist, we work around this issue by always converting the returned
value to int via to_int().
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1190
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
When the command line option "-terminate" is used, it could be
interesting to give it an optional grace period to let the Xserver
running for a little longer in case a new connection occurs.
This adds an optional parameter to the "-terminate" command line option
for this purpose.
v2: Use a delay in seconds instead of milliseconds
(Martin Peres <martin.peres@mupuf.org>)
v3: Clarify man page entry, ensure terminateDelay is always >= 0,
simplify TimerFree(). (Peter Hutterer <peter.hutterer@who-t.net>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Checking for function "getpeereid" : YES
Checking for function "getpeerucred" : NO
[...]
include/meson.build:182:7: ERROR: Argument to "not" is not a boolean.
Fixes: 68c2cfadd6 ("meson: Make sure defines are either set to 1 or not defined")
FreeBSD < 12.2 and OpenBSD only have pthread_set_name_np.
As libpthread isn't in scope use -Werror to trip the check.
Header <pthread.h> has symbol "PTHREAD_MUTEX_RECURSIVE" : YES
Checking if "pthread_setname_np(tid, name)" compiles: YES
os/inputthread.c:326:5: error: implicit declaration of function 'pthread_setname_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pthread_setname_np (pthread_self(), "InputThread");
^
os/inputthread.c:447:5: error: implicit declaration of function 'pthread_setname_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pthread_setname_np (pthread_self(), "MainThread");
^
Fixes: c20e7b5e22 ("meson: Automatically detect HAVE_PTHREAD_SETNAME_NP")
This will make the behavior of meson consistent with autotools. The
configuration macros are exposed to public headers so any inconsistency
is likely to break code for anyone who's not careful to use #ifdef
instead of #if.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This effectively changes the versioning to be as if xserver 21.0 was
xserver 1.21.0. This should keep any client-side version checks that
know about the Xorg 7.0 -> xserver 1.0 epoch from getting confused.
This changes the operating system identifier tested against
host_machine.system() in meson build files from "dragonflybsd"
to the officially stable "dragonfly".
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
This add a new flag POINTER_RAWONLY for GetPointerEvents() which does
pretty much the opposite of POINTER_NORAW.
Basically, this tells GetPointerEvents() that we only want the
DeviceChanged events and any raw events for this motion but no actual
motion events.
This is preliminary work for Xwayland to be able to use relative motion
events for raw events. Xwayland would use absolute events for raw
events, but some X11 clients (wrongly) assume raw events to be always
relative.
To allow such clients to work with Xwayland, it needs to switch to
relative raw events (if those are available from the Wayland
compositor).
However, Xwayland cannot use relative motion events for actual pointer
location because that would cause a drift over time, the pointer being
actually controlled by the Wayland compositor.
So Xwayland needs to be able to send only relative raw events, hence
this API.
Bump the ABI_XINPUT_VERSION minor version to reflect that API addition.
v2: Actually avoid sending motion events (Peter)
v3: Keep sending raw emulated events with RAWONLY (Peter)
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
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>
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>
Extending the decade old f0124ed93, to increase the number of input
devices from 40 to 256. 40 translates at most 9 MD, while 256 will allow
63 MD. It is an arbitrary number, but people are hitting the current
limit under reasonable conditions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64793
Signed-off-by: Arthur Williams <taaparthur@gmail.com>
Request-handlers as registered in the requestVector array, always get
passed the clientPtr for the client which sent the request.
But the implementation of many request-handlers typically consists of
a generic handler calling implementation specific callbacks and / or
various helpers often multiple levels deep and in many cases the clientPtr
does not get passed to the callbacks / helpers.
This means that in some places where we would like to have access to the
current-client, we cannot easily access it and fixing this would require
a lot of work and often would involve ABI breakage.
This commit adds a GetCurrentClient helper which can be used as a
shortcut to get access to the clienPtr for the currently being processed
request without needing a lot of refactoring and ABI breakage.
Note using this new GetCurrentClient helper is only safe for code
which only runs from the main thread, this new variable MUST NOT be used
by code which runs from signal handlers or from the input-thread.
The specific use-case which resulted in the creation of this patch is adding
support for emulation of randr / vidmode resolution changes to Xwayland.
This emulation will not actually change the monitor resolution instead it
will scale any window with a size which exactly matches the requested
resolution to fill the entire monitor. The main use-case for this is
games which are hard-coded to render at a specific resolution and have
sofar relied on randr / vidmode to change the monitor resolution when going
fullscreen.
To make this emulation as robust as possible (e.g. avoid accidentally scaling
windows from other apps) we want to make the emulated resolution a per client
state. But e.g. the RRSetCrtc function does not take a client pointer; and is
a (used) part of the Xorg server ABI (note the problem is not just limited
to RRSetCrtc).
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@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>
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
Add a new function, GlxServerExports::setClientScreenVendor, which will change
the vendor that handles GLX requests for a screen, but only for requests from
a specific client.
v2: Increment the GLXVND minor version number.
v3: Note the GLXVND version requirement for setClientScreenVendor.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@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.
A workaround for https://github.com/mesonbuild/meson/issues/3672
MinGW-w64 gcc has a built-in strndup, but it's not in the C library and
MinGW-w64 headers don't prototype it.
Don't try to use it, as that will cause an undefined reference if gcc
decides that an out-of-line call is appropriate.
Currently, this can error if dri.pc isn't found, as we can't then get
the value of pkgconfig variable from it:
include/meson.build:199:10: ERROR: 'dri' is not a pkgconfig dependency
I think we need DRI_DRIVER_PATH (only) when building GLX, even if dri2/3
isn't enabled, so we know where to load swrast_dri.so from.
(For autotools, configure.ac directly calls `pkg-config
--variable=dridriverdir dri`, the backticks swallowing any error,
causing the value of this define to be empty if dri.pc isn't present)
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>
If the server resets, most client workqueues are cleaned up as the
clients are killed.
The one exception is the server's client, which is exempt from
the killing spree.
If that client has a queued work procedure active, it won't get
cleared on reset.
This commit ensures it gets cleared too.
glibc 2.25 has dropped sys/sysmacros.h from sys/types.h, so add
it explicitly in config/udev.c.
This is similar to the commit 84e3b96b53
Signed-off-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
___CLIENTSIGNAL_DEFINED___ is a hack to work around the declaration of
ClientSignal both in our own headers and in <X11/include/fontproto.h>,
the latter of which is properly part of libXfont (1, only) but packaged
in xorgproto because we have made some mistakes. ClientSignalAll needs
no such workaround.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Despite being packaged in xorgproto (formerly fontsproto), fontproto.h
is actually a list of the ABI libXfont version 1 expected of the X
server. We switched to libXfont2 three years ago, this is unnecessary.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Lifted from vfb. xfree86 had almost the same thing but unparameterized,
port it to the vfb style.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This hasn't done anything besides return TRUE in a long long time.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
These are so close to identical that most DDXes implement one in terms
of the other. All the relevant cases can be distinguished by the error
code, so merge the functions together to make things simpler.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
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>
60ec8ead broke the autotools build:
sdksyms.o:(.data+0x58): undefined reference to `InitConnectionLimits'
sdksyms.o:(.data+0x2ec8): undefined reference to `xf86ServerName'
collect2: error: ld returned 1 exit status
Makefile:811: recipe for target 'Xorg' failed
Likewise 3a4d7c79 for InitConnectionLimits.
Signed-off-by: Adam Jackson <ajax@redhat.com>
This variable was no longer being read anywhere. MAXCLIENTS the macro is
the compile-time maximum limit, LIMITCLIENTS the macro is the default
limit, LimitClients the variable is the limit for the current server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The client ID is only needed for XRes, and autotools build ignores the
--clientids= arg if xres is disabled. We haven't made a meson option
for disabling tracking client ids (is it actually worth a build
option?), so just make this depend on xres.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes us match the featureset of autotools, and also fixes the
non-Linux default value to match.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>