Commits on Source (59)
-
Ray Strode authored
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. (cherry picked from commit 8738ce85) Fixes: xorg/xserver#670
-
Michel Dänzer authored
This reverts commit 8694395f. Some scenarios have come to light where this failed to ensure the docker image exists: * If the master branch of a forked repository is used for an MR which doesn't modify .gitlab-ci.yml, the docker-image job may not run. * If the docker-image job of the first pipeline in a forked repository is cancelled or fails for any reason, and .gitlab-ci.yml isn't modified for the next pipeline run. (Cherry picked from commit 0ec9a13c)
-
Michel Dänzer authored
xwl_present_cleanup frees the struct xwl_present_window memory, so if there's a pending callback, we have to destroy it to prevent use-after-free in xwl_present_sync_callback. Should fix issue #645. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> (Cherry picked from commit 2e18eec6)
-
Michel Dänzer authored
If they don't, flipping will result in corrupted display. Test case: * Run Xorg at 1920x1080 with no window manager * glxgears -geometry 2048x1080 (Cherry picked from commit ef91da27)
-
Olivier Fourdan authored
wl_drm's protocol "device" event provides the path to the DRM device, which may not be a render node, thus causing Xwayland to fall back to DRM authentication which may fail if the user has switched to another VT while Xwayland is starting. Search for a render node corresponding to the given DRM device and try to use it instead, as render nodes do not need DRM authentication and Xwayland can make use of them if it can find one. Closes: https://bugs.freedesktop.org/108038 Signed-off-by:
-
Peter Hutterer authored
Found by coverity Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> (Cherry picked from commit 7c25439f)
-
Olivier Fourdan authored
If `_glamor_create_tex()` fails to allocate the FBO because of GL_OUT_OF_MEMORY error, the `pixmap_priv->fbo` is NULL. However, `glamor_get_pixmap_texture()` doesn't actually check whether the `pixmap_priv->fbo` is NULL and will segfault with a NULL pointer dereference trying to access the `pixmap_priv->fbo->tex`. Signed-off-by:
-
Peter Hutterer authored
Terms: dev->last.valuator[] is the last value given to us by the driver dev->valuator.axisVal[] is the last value sent to the client dev->last.scroll[] is the abs value of the scroll axis as given by the driver, used for button emulation calculation (and the remainder) This function updates the device's last.valuator state based on the current master axis state. This way, relative motion continues fluidly when switching between devices. Before mouse 2 comes into effect, it's valuator state is updated to wherever the pointer currently is so the relative event applies on top of that. This can only work for x/y axes, all other axes aren't guaranteed to have the same meaning and/or may not be present: - xtest device: no valuator 2 - mouse: valuator 2 is horizontal scroll axis - tablet: valuator 2 is pressure Scaling the current value from the pressure range into the range for horizontal scrolling makes no sense. And it causes scroll jumps: - scroll down, last.valuator == axisVal == 20 - xdotool click 1, the XTest device doesn't have that valuator - scroll up - updateSlaveDeviceCoords reset last.valuator to 0 (axisVal == 20) - DeviceClassesChangedEvent includes value 20 for the axis - event is processed, last.value changes from 0 to -1 - axisVal is updated to -1, causing a jump of -21 The same applies when we switch from tablet to mouse wheel if the pressure value is 0 on proximity out (basically guaranteed). So let's drop this code altogether and only leave the scaling for the relative x/y motion. Signed-off-by: -
Adam Jackson authored
Signed-off-by:Adam Jackson <ajax@redhat.com>
-
Olivier Fourdan authored
On pointer enter notification, Xwayland checks for an existing pointer warp with a `NULL` sprite. In turn, `xwl_pointer_warp_emulator_maybe_lock()` checks for an existing grab and the destination window using `XYToWindow()` which does not check for the actual sprite not being `NULL`. So, in some cases, when the pointer enters the surface and there is an existing X11 grab which is not an ownerEvents grab, Xwayland would crash trying to dereference the `NULL` sprite pointer: #0 __GI_raise () #1 __GI_abort () at abort.c:79 #2 OsAbort () at utils.c:1351 #3 AbortServer () at log.c:879 #4 FatalError () at log.c:1017 #5 OsSigHandler () at osinit.c:156 #6 OsSigHandler () at osinit.c:110 #7 <signal handler called> #8 XYToWindow (pSprite=0x0, x=0, y=0) at events.c:2880 #9 xwl_pointer_warp_emulator_maybe_lock () at xwayland-input.c:2673 #10 pointer_handle_enter () at xwayland-input.c:434 Avoid the crash by simply checking for the sprite being not `NULL` in `xwl_pointer_warp_emulator_maybe_lock()` Signed-off-by:
-
Olivier Fourdan authored
The current code in `xwl_glamor_gbm_create_pixmap_for_bo()` may fail in several cases that are not checked for: - `eglCreateImageKHR()` may have failed to create the image, - `glEGLImageTargetTexture2DOES()` may fail and set an error, - `glamor_set_pixmap_texture()` may fail for very large pixmaps because the corresponding FBO could not be created. Trying to upload content to a pixmap with no texture will crash Mesa, glamor and Xwayland, e.g.: XXX fail to create fbo. (EE) (EE) Backtrace: (EE) 0: Xwayland (OsSigHandler+0x29) (EE) 1: libpthread.so.0 (funlockfile+0x50) (EE) 2: libc.so.6 (__memmove_avx_unaligned_erms+0x215) (EE) 3: dri/i965_dri.so (_mesa_format_convert+0xab3) (EE) 4: dri/i965_dri.so (_mesa_texstore+0x205) (EE) 5: dri/i965_dri.so (store_texsubimage+0x28c) (EE) 6: dri/i965_dri.so (intel_upload_tex+0x13b) (EE) 7: dri/i965_dri.so (texture_sub_image+0x134) (EE) 8: dri/i965_dri.so (texsubimage_err+0x150) (EE) 9: dri/i965_dri.so (_mesa_TexSubImage2D+0x48) (EE) 10: Xwayland (glamor_upload_boxes+0x246) (EE) 11: Xwayland (glamor_copy+0x4d1) (EE) 12: Xwayland (miCopyRegion+0x96) (EE) 13: Xwayland (miDoCopy+0x43c) (EE) 14: Xwayland (glamor_copy_area+0x24) (EE) 15: Xwayland (damageCopyArea+0xba) (EE) 16: Xwayland (compCopyWindow+0x31c) (EE) 17: Xwayland (damageCopyWindow+0xd3) (EE) 18: Xwayland (miResizeWindow+0x7b7) (EE) 19: Xwayland (compResizeWindow+0x3a) (EE) 20: Xwayland (ConfigureWindow+0xa96) (EE) 21: Xwayland (ProcConfigureWindow+0x7d) (EE) 22: Xwayland (Dispatch+0x320) (EE) 23: Xwayland (dix_main+0x366) (EE) 24: libc.so.6 (__libc_start_main+0xf3) (EE) 25: Xwayland (_start+0x2e) (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) Check for the possible cases of failure above and fallback to the regular glamor pixmap creation when an error is detected. Signed-off-by: -
Olivier Fourdan authored
If a pixmap is not exportable, `glamor_gbm_bo_from_pixmap()` would fail and the modesettings driver would consequently fail to do its page flip, which both prevents Present from working and also fill up the logs with error messages such as: (EE) modeset(0): Failed to get GBM bo for flip to new front. (EE) modeset(0): present flip failed Refactor the code so that `glamor_gbm_bo_from_pixmap()` takes care of making the pixmap exportable. Signed-off-by:
Yuxuan Shui <yshui@hadean.com> See-also: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/131 Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/68 Fixes: 86b2d874 "glamor: Reallocate pixmap storage without modifiers if necessary" (cherry picked from commit 26fe29f4)
-
Carlos Garnacho authored
Hiding the tablet tool cursor results in it being hidden forever after. This is due to the stale frame callback that will neither be disposed or replaced. This can be reproduced in krita (X11) as the pointer cursor is hidden while over the canvas. Clearing the frame callback ensures the correct behavior in future xwl_tablet_tool_set_cursor() calls (i.e. a new cursor surface being displayed, and a new frame callback created), and is 1:1 with xwl_seat_set_cursor() for pointers. Signed-off-by:
Carlos Garnacho <carlosg@gnome.org> (cherry picked from commit dea4a746)
-
Michel Dänzer authored
This reverts commit ef91da27. I thought this couldn't work under any circumstances, but I was wrong, and drivers are already checking for cases that really cannot work. Fixes issue #839. (cherry picked from commit 2f0dd181)
-
Marco Trevisan authored
When Retrieving touch delivery data we need to check if we have an active grab on such device, and in that case use it to delivery events. If we don't do this, when rejecting the touch events in DeactivatePointerGrab, we will end-up in creating an implicit grab that will change the device deviceGrab's state, causing a recursion during TouchEndTouch. Fixes #7 https://bugs.freedesktop.org/show_bug.cgi?id=96536 (cherry picked from commit 35e5a76c)
-
Matt Roper authored
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)
-
Olivier Fourdan authored
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:
Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit ce9455b5)
-
Adam Jackson authored
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:
-
Olivier Fourdan authored
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:
-
Alex Goins authored
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)
-
Kyle Brenneman authored
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:
-
Kyle Brenneman authored
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:
-
Kyle Brenneman authored
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 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:
-
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) -
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)
-
Carlos Garnacho authored
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 authored
This is just called from xwl_window_realize() ATM, but will be useful in future commits. Signed-off-by:
-
Carlos Garnacho authored
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:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
-
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>
-
Michel Dänzer authored
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 https://gitlab.freedesktop.org/xorg/xserver/issues/892 Reviewed-by:
-
Since group_info and width are used for the key actions allocations, when modifying them we need to take care of reallocation key actions if needed. (cherry picked from commit fabc4219)
-
Some devices may not have keyboard information. Fixes #574 (cherry picked from commit 8469bfea)
-
Emma Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 804a9b4f)
-
Emma Anholt authored
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:
-
Alexander Volkov authored
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)
-
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)
-
Alexander Tsoy authored
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)
-
Sven Joachim authored
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:
-
Marvin Schmidt authored
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)
-
Adam Jackson authored
Previous commit e6ef2b12 missed a spot. (cherry picked from commit c7486613)
-
Adam Jackson authored
Siiiigh. (cherry picked from commit 3340ddf3)
-
Hans de Goede authored
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)
-
Alex Goins authored
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 authored
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 authored
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 authored
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:
-
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)
-
Olivier Fourdan authored
<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:
-
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:
-
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:
-
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:
-
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:
-
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 authored
Signed-off-by: -
Timo Aaltonen authored
-
Timo Aaltonen authored
-
Timo Aaltonen authored
-
Timo Aaltonen authored
