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>
When GlxGetXIDMap looks up an unknown XID, it will now look up a vendor based
on the screen number for the XID and the client that sent the current request.
In GlxGetXIDMap, if the XID is for a regular X window, then it won't be in the
(XID -> vendor) mapping, so we have to look up a vendor by screen number.
With this change, GlxGetXIDMap will use the (screen -> vendor) map for
whichever client sent the current request, instead of using the global
(screen -> vendor) map.
Since GlxGetXIDMap doesn't take a ClientPtr argument, GlxDispatchRequest will
store the client for the current request in a global variable. That way, the
ABI for GLXVND doesn't need to change.
v2: Fix an error check in GlxDispatchRequest.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Each client now has its own (screen, vendor) mapping.
Currently, it's just a copy of the global mapping, but later changes will allow
it to change.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glxc->drawPriv will be NULL if the context is direct, or if it is
current but without a bound drawable. Mesa's libGL won't normally emit
protocol for direct contexts for these calls, but a malign client could
still crash the server.
It can take some time for Xorg to start. If Xorg runs as a systemd
service and other services are based on it, they have no way to
determine when Xorg is really ready to accept requests. Let's use
sd_notify() provided by libsystemd to signal systemd for readiness.
If Xorg has not been started as a systemd service, this won't do
anything.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
Separate each statement of the form "assert(a && b);" into "assert(a);"
and "assert(b);" for more precise diagnostics, except for this clever
use in drmmode_display.c where it was used to pass a hint to developers:
assert(num_infos <= 32 && "update return type");
Trying to build fat binaries for multiple arches tickles a bug [1] in
the framework detector in meson 0.50. Workaround this by not bothering
building for x86, which is probably no great loss :S
https://github.com/mesonbuild/meson/issues/5290
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.
None of this was getting compiled because we hadn't defined the macro
(and aren't getting them from <GL/glxext.h> because reasons). Fix that.
Fixes: xorg/xserver#684
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
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.
In the meson build, functions to make up for the shortcomings of libc
are compiled into a separate library. We don't bother making the pixman
headers available (reasonably enough) to this compilation, but they are
required indirectly by dix.h. Just remove this unneeded include.
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)
Commit d8ec33fe05 added libglxvnd.la to
Xwayland_LDFLAGS but GLX can be disabled through --disable-glx.
In this case, build fails on:
make[3]: *** No rule to make target '../../glx/libglxvnd.la', needed by 'Xwayland'. Stop.
make[3]: *** Waiting for unfinished jobs....
Fixes:
- http://autobuild.buildroot.org/results/397f8098c57fc6c88aa12dc8d35ebb1b933d52ef
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Drop installing packages which were used by the autotools build (or
maybe even monolithic build!) but are no longer required by the meson
build
Also, alphabetically sort within tools, protocol headers, devel
libraries, miscellaneous groups to match [1]
[1] https://x.cygwin.com/docs/cg/prog-build-prerequisites.html
Also, update to require xkbcomp-devel, split from xkbcomp
Using YAML line-folding doesn't seem possible, as setup doesn't tolerate
spaces between package names, so instead drop some unneeded double quotes,
double quote the whole thing and escape newlines
As shown by DRI3 adding the SyncCreateFenceFromFD() function, extensions may
want to create a fence, then initialize it in their own way. This currently
can't be done without adding a function directly to Xext/sync.c due to the fact
that the RTFence resource type is private and there is no external interface to
add to it.
To facilitate other X extensions creating fences and initializing them, this
change exports SyncCreate() and adds the resource directly within it. Callers no
longer need to call AddResource() after SyncCreate(), they only need to
initialize the SyncObject.
To prevent FreeFence() and FreeCounter() from segfaulting if the call to
AddResource() fails before the sync object is initialized, this adds a new
'initialized' parameter to SyncObject that, when FALSE, causes FreeFence() and
FreeCounter() to skip de-initialization and simply free the object.
Initialization after adding the resource shouldn't otherwise be a problem due to
the single-threaded nature of X.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: James Jones <jajones@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
We had various helper functions trying to come up with the
internalformat/format/type/render formats for pixmaps, and it's much
nicer to just detect what those should be once at startup. This gives
us a chance to do the right thing for GLES.
It also, notably, fixes our format/type for depth 15 and 16 setup for
desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
drivers instead of 32bpp (GL_RGB/UBYTE).
GLES still has regressions over desktop (2 regressions in llvmpipe
XTS, many in rendercheck), but I think this is a good baseline.
Signed-off-by: Eric Anholt <eric@anholt.net>
For GLES, we're going to need a lot more logic for picking the
iformat/format/type of texture setup, so we'll want the pixmap's depth
and is_cbcr flag.
Signed-off-by: Eric Anholt <eric@anholt.net>
"format" is a bit of a confused term (internalformat vs GL format),
and all we really needed was "is this GL_RED?"
Signed-off-by: Eric Anholt <eric@anholt.net>
../hw/kdrive/src/kdrive.c:999:1: warning: no previous prototype for ‘xf86_find_platform_device_by_devnum’ [-Wmissing-prototypes]
Place the same guards around this stub as are around including the
hotplug.h header which declares the prototype.
If SYSTEMD_LOGIND is not defined, systemd_logind_take_fd is defined as a
macro evaluating to -1 by systemd-logind.h, leaving paused
uninitialized.
../hw/xfree86/common/xf86Xinput.c: In function ‘xf86NewInputDevice’:
../hw/xfree86/common/xf86Xinput.c:919:16: warning: ‘paused’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../hw/xfree86/common/xf86Xinput.c:877:10: note: ‘paused’ was declared here
