- Nov 22, 2019
-
-
Matt Turner authored
Signed-off-by:
Matt Turner <mattst88@gmail.com>
-
Matt Turner authored
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> (cherry picked from commit e6ab7f9f)
-
- Nov 21, 2019
-
-
Olivier Fourdan authored
Currently, the function `present_wnmd_abort_vblank()` would fail if the given `crtc` is NULL. However, `xwl_present_get_crtc()` can return `NULL` under some circumstances, which would cause an unexpected termination of Xwayland in such a case, caused by the assertion failure being triggered. Remove the assertion, considering that the `crtc` isn't actually used in neither `present_wnmd_abort_vblank()` nor `xwl_present_abort_vblank()`. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Closes: #937 (cherry picked from commit 4f984fc0)
-
- Nov 20, 2019
-
-
Aaron Plattner authored
If a client is in the process of being closed down, then its client->osPrivate pointer will be set to NULL by CloseDownConnection. This can cause a crash if freeing the client's resources results in a call to AttendClient. For example, if the client has a pending sync fence: Thread 1 "X" received signal SIGSEGV, Segmentation fault. AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942 (gdb) bt #0 AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942 #1 0x00005571c3dbb865 in SyncAwaitTriggerFired (pTrigger=<optimized out>) at ../Xext/sync.c:694 #2 0x00005571c3dd5749 in miSyncDestroyFence (pFence=0x5571c5063980) at ../miext/sync/misync.c:120 #3 0x00005571c3dbbc69 in FreeFence (obj=<optimized out>, id=<optimized out>) at ../Xext/sync.c:1909 #4 0x00005571c3d7a01d in doFreeResource (res=0x5571c506e3d0, skip=skip@entry=0) at ../dix/resource.c:880 #5 0x00005571c3d7b1dc in FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1146 #6 FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1109 #7 0x00005571c3d5525f in CloseDownClient (client=0x5571c4aed9a0) at ../dix/dispatch.c:3473 #8 0x00005571c3d55eeb in Dispatch () at ../dix/dispatch.c:492 #9 0x00005571c3d59e96 in dix_main (argc=3, argv=0x7ffe7854bc28, envp=<optimized out>) at ../dix/main.c:276 #10 0x00007fea4837cb6b in __libc_start_main (main=0x5571c3d1d060 <main>, argc=3, argv=0x7ffe7854bc28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe7854bc18) at ../csu/libc-start.c:308 #11 0x00005571c3d1d09a in _start () at ../Xext/sync.c:2378 (gdb) print client->osPrivate $1 = (void *) 0x0 Since the client is about to be freed, its ignore count doesn't matter and AttendClient can simply be a no-op. Check for client->clientGone in AttendClient and remove similar checks from two callers that had them. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> (cherry picked from commit 4308f5d3)
-
- Nov 18, 2019
-
-
Adam Jackson authored
This ensures that any prep work for the drawable we're about to read from is already done before we call down to GetImage. This should be no functional change as most of the callers with a non-trivial SourceValidate are already wrapping GetImage and doing the equivalent thing, but we'll be simplifying that shortly. More importantly this ensures that if any of that prep work would generate events - like automatic compositing flushing rendering to a parent pixmap which then triggers damage - then it happens entirely before we start writing the GetImage reply header. Note that we do not do the same for GetSpans, but that's okay. The only way to get to GetSpans is through miCopyArea or miCopyPlane - where the callers must already call SourceValidate - or miGetImage - which this commit now protects with SourceValidate. Fixes: xorg/xserver#902 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 516e75db)
-
Adam Jackson authored
Slightly simplifies the callers since they don't need to check for non-NULL anymore. I do extremely hate the workarounds here to suppress misprite taking the cursor down though. Surely there's a better way. [1.20: Do not in fact simplify the callers as above, since it would change the ABI. - ajax] Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit ff310903)
-
<sys/io.h> on ARM hasn't worked for a long, long time, so it was removed it from glibc upstream. Remove the include to avoid a compilation failure on ARM with glibc. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: #840 (cherry picked from commit fe4cd0e7)
-
- Nov 13, 2019
-
-
Aaron Plattner authored
During startup, the xfree86 DDX's InitOutput() calls PreInit for protocol screens first, and then GPU screens. On teardown, dix_main() calls CloseScreen in the reverse order: GPU screens first starting with the last one and then working backwards, and then protocol screens also in reverse order. InitOutput() calls ScreenInit in the wrong order: for GPU screens first and then for protocol screens. This causes a problem for drivers that have global state that is tied to the first screen that calls ScreenInit. Fix this by simply re-ordering the for loops to call PreInit for protocol screens first and then for GPU screens second. (cherry picked from commit e5e9a8ca)
-
- Nov 11, 2019
-
-
ms_present_get_crtc() returns an RRCrtcPtr, but derives it from a xf86CrtcPtr found via ms_dri2_crtc_covering_drawable()=>ms_covering_crtc(). As a result, it depends on all associated DIX ScreenRecs having an xf86CrtcConfigPtr DDX private. Some DIX ScreenRecs don't have an xf86CrtcConfigPtr DDX private, but do have an rrScrPrivPtr DDX private. Given that we can derive all of the information we need from RandR, we can support these screens by avoiding the use of xf86Crtc. This change implements an RandR-based path for ms_present_get_crtc(), allowing drawables to successfully fall back to syncing to the primary output, even if the slave doesn't have an xf86CrtcConfigPtr DDX private. Without this change, if a slave doesn't have an xf86CrtcConfigPtr DDX private, drawables will fall back to 1 FPS if they overlap an output on that slave. Signed-off-by:
Alex Goins <agoins@nvidia.com> (cherry picked from commit 562c7888)
-
DIX ScreenRecs don't necessarily have an xf86CrtcConfigPtr DDX private. ms_covering_crtc() assumes that they do, which can result in a segfault. Update ms_covering_crtc() to check the XF86_CRTC_CONFIG_PTR() returned pointer before dereferencing it. This will still mean that ms_covering_crtc() can't fall back to the primary output when a drawable overlaps a slave output (going to the 1 FPS default instead), but it won't segfault. Signed-off-by:
Alex Goins <agoins@nvidia.com> (cherry picked from commit 797e7a0c)
-
ms_covering_crtc() uses RRFirstOutput() to determine a primary output to fall back to if a drawable is overlapping a slave output. If the primary output is a slave output, RRFirstOutput() will return a slave output even if passed a master ScreenPtr. ms_covering_crtc() dereferences the output's devPrivate, which is invalid for non-modesetting outputs, and can crash. Changing RRFirstOutput() could have unintended side effects for other callers, so this change replaces the call to RRFirstOutput() with ms_first_output(). ms_first_output() ignores the primary output if it doesn't match the given ScreenPtr, choosing the first connected output instead. Signed-off-by:
Alex Goins <agoins@nvidia.com> (cherry picked from commit 3ef9029a)
-
During server teardown, mrootdraw is NULL, which can cause segfaults if master->Stop{,Flipping}PixmapTracking() don't do NULL checking. In this case we shouldn't need to do master->Stop{,Flipping}PixmapTracking() anyway, so just skip it. Signed-off-by:
Alex Goins <agoins@nvidia.com> (cherry picked from commit c82f8143)
-
- Nov 05, 2019
-
-
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS, EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers shipped with libglvnd. This fixes the xserver not building with the libglvnd-1.2.0 headers: In file included from /usr/include/EGL/eglplatform.h:128, from /usr/include/epoxy/egl_generated.h:11, from /usr/include/epoxy/egl.h:46, from glamor_priv.h:43, from glamor_composite_glyphs.c:25: /usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC' 222 | *GC; | ^~ In file included from glamor.h:34, from glamor_priv.h:32, from glamor_composite_glyphs.c:25: ../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here 282 | } GC; | ^~ Signed-off-by:
Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 741bd734)
-
Siiiigh. (cherry picked from commit 3340ddf3)
-
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] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba (cherry picked from commit e6ef2b12)
-
- Oct 30, 2019
-
-
The autoconf build for the modesetting driver still relied on xorg-macros.m4 for string replacements and did not include the top-level manpages.am. As a result, no substitutions took place after commit 2e497bf8. This should be a candidate for the 1.20 branch. Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit de0d39f8)
-
- Oct 29, 2019
-
-
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> (cherry picked from commit 334f1107)
-
Matt Turner authored
When compiling with link time optimization, GCC thinks it's discovered undefined behavior: events.c: In function 'XineramaConfineCursorToWindow': events.c:609:13: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations] events.c:609:11: note: within this loop events.c:605:49: warning: array subscript -1 is below array bounds of 'struct _Window *[16]' [-Warray-bounds] events.c:606:31: warning: array subscript -1 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds] events.c:610:39: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds] events.c:617:38: warning: array subscript -2 is below array bounds of 'struct _Window *[16]' [-Warray-bounds] events.c:619:35: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds] This results from i = PanoramiXNumScreens - 1; RegionCopy(&pSprite->Reg1, &pSprite->windows[i]->borderSize); off_x = screenInfo.screens[i]->x; off_y = screenInfo.screens[i]->y; where GCC believes that PanoramiXNumScreens might be 0. Unfortunately GCC is just smart enough to be an annoyance because this case is not actually possible: XineramaConfineCursorToWindow() is only called when noPanoramiXExtension is false, and if noPanoramiXExtension is false then PanoramiXNumScreens must be >1 (see PanoramiXExtensionInit()). So, add an assert(!noPanoramiXExtension), which to my surprise provides GCC with information even in release builds and lets GCC understand that the code is not doing anything that is undefined behavior. I chose this solution instead of the proposed assert(i >= 0) because the same pattern occurs in CheckVirtualMotion() but is inside an 'if (!noPanoramiXExtension)' and does not generate any warnings. Fixes: xorg/xserver#590 Signed-off-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit 61aa40ae)
-
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> (cherry picked from commit f6753c11)
-
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> (cherry picked from commit 19f6cb57)
-
Signed-off-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 804a9b4f)
-
- Oct 14, 2019
- Sep 26, 2019
-
-
With a 32-bit build, putting the initialized field at the end of the struct bumped the struct size from 20 bytes to 24, changing the layout of other structs embedding struct _SyncObject. While this would be acceptable on master, it caused crashes with 1.20. Making the initialized field a char and putting it in the hole before the beingDestroyed field restores the 32-bit ABI as well. Fixes xorg/xserver#892 Reviewed-by:
Aaron Plattner <aplattner@nvidia.com> Reviewed-by:
Alex Goins <agoins@nvidia.com> (cherry picked from commit 0d8cc7bb)
-
- Sep 23, 2019
-
-
Andres Rodriguez authored
This fixes 'non-desktop' displays staying powered on after their lease has been revoked. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111620 Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
Andres Rodriguez <andresx7@gmail.com>
-
- Sep 10, 2019
-
-
If Xwayland gets to realize a window meant for composition before the compositor redirected windows (i.e. redirect mode is not RedirectDrawManual yet), the window would stay "invisible" as we wouldn't create a wl_surface/wl_shell_surface for it at any later point. This scenario may happen if the wayland compositor sets up a X11 socket upfront, but waits to raise Xwayland until there are X11 clients. In this case the first data on the socket is the client's, the compositor can hardly beat that in order to redirect subwindows before the client realizes a Window. In order to jump across this hurdle, allow the late creation of a matching (shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured to be created after the compositor set up redirection. Signed-off-by:
Carlos Garnacho <carlosg@gnome.org> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 78cc8b6f)
-
This is just called from xwl_window_realize() ATM, but will be useful in future commits. Signed-off-by:
Carlos Garnacho <carlosg@gnome.org> (cherry picked from commit c2e8ae96)
-
This will be dissociated in future commits to handle the cases where windows are being realized before there is a compositor handling redirection. In that case, we still want the DamagePtr to be registered upfront on RealizeWindowProc before a corresponding xwl_window might be created. Most notably, it cannot be lazily created on SetWindowPixmapProc as damage accounting gets broken. Signed-off-by:
Carlos Garnacho <carlosg@gnome.org> (cherry picked from commit 4e50440a)
-
- Aug 21, 2019
-
-
Adam Jackson authored
vnd has already verified that the context tag is valid before this gets called, and we only set the context tag private data to non-null for indirect clients. Mesa happens to be buggy and doesn't send MakeCurrent requests nearly as much as it should for direct contexts, but if you fix that, then unbinding a direct context would fail here with GLXBadContextTag. Sadly Mesa will still need to carry a workaround here for broken servers, but we should still fix the server. (cherry picked from commit 95dcc81c)
-
Adam Jackson authored
The initialized field was added in: commit 82f01ad7 Author: Alex Goins <agoins@nvidia.com> Date: Wed Apr 10 13:48:02 2019 -0500 xsync: Add resource inside of SyncCreate, export SyncCreate But it added this field not at the end of SyncObject. It may not have been _usefully_ possible to create those from another extension prior to that commit, but that's still an ABI-incompatible change. (cherry picked from commit 194ba387)
-
- Aug 13, 2019
-
-
Aaron Plattner authored
Commit 56c0a71f incremented the GLXSERVER_VENDOR_ABI_MINOR_VERSION define, but this define was not actually being used to set glxServer.minorVersion. Update the initializer for glxServer to use the correct version numbers. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> (cherry picked from commit b4231d69)
-
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> (cherry picked from commit 56c0a71f)
-
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> (cherry picked from commit 8b67ec7c)
-
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> (cherry picked from commit 37a36a6b)
-
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> (cherry picked from commit 7f962c70)
-
- Jul 26, 2019
-
-
Both `gbm_bo_create()` and `gbm_bo_create_with_modifiers()` can fail and return `NULL`. If that occurs, `xwl_glamor_gbm_create_pixmap()` will not create a pixmap for the (NULL) GBM bo, but would still try to free the bo which leads to a crash in mesa: [...] #7 <signal handler called> #8 in gbm_bo_destroy (bo=0x0) at ../src/gbm/main/gbm.c:439 #9 in xwl_glamor_gbm_create_pixmap () at xwayland-glamor-gbm.c:245 #10 in ProcCreatePixmap () at dispatch.c:1440 #11 in Dispatch () at dispatch.c:478 #12 in dix_main () at main.c:276 To avoid the crash, only free the GBM bo if not `NULL`. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Bugzilla: https://bugzilla.redhat.com/1729925 (cherry picked from commit d9ec5250)
-
There's not really a good way to query this from the wayland server, so just set the maximum to the X11 protocol limits. While we're at it, lower the minimum screen size to something implausibly small too, just in case. Fixes: xorg/xserver#850 Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit d0850241)
-
Running Xwayland non-rootless and resizing the output would lead to a crash while trying to update the larger areas of the root window. Make sure we resize the backing pixmap according to the new output size to avoid the crash. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: xorg/xserver#834 Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit ce9455b5)
-
Copied from Mesa with no modifications. This update brings in a significant number of new platform ID's. Syncs with mesa up to commit e334a595e ("intel/icl: Add new ICL PCI-IDs"). Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit a8d9ebeb)
-