- 26 Nov, 2019 2 commits
-
-
Kenneth Graunke authoredNew now ask Glamor to use EGL_MESA_query_driver to obtain the DRI driver name; if successful, we use that as the DRI driver name. Following the existing dri2.c logic, we also use the same name for the VDPAU driver, except for i965 (and now iris), where we switch to the "va_gl" fallback. This allows us to bypass the PCI ID lists in xserver and centralize the driver selection mechanism inside Mesa. The hope is that we no longer have to update these lists for any future hardware.
-
Kenneth Graunke authored
This maps to eglGetDisplayDriverName if EGL_MESA_query_render is supported, otherwise it returns NULL.
-
- 25 Nov, 2019 5 commits
-
-
Should be slightly more efficient. Reviewed-by:Adam Jackson <ajax@redhat.com>
-
Fixes random garbage being visible intermittently. Reviewed-by: -
If a new rotate buffer was allocated. This makes sure the new buffer has valid transformed contents when it starts being displayed. Reviewed-by: -
This makes sure any pending drawing to a new scanout buffer will be visible from the start. This makes the finish call in drmmode_copy_fb superfluous, so remove it. Reviewed-by: -
This will simplify backporting the following fix to the 1.20 branch. Reviewed-by:
-
- 22 Nov, 2019 2 commits
-
-
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>
-
This also removes an unnecesary call to glDrawBuffer. Signed-off-by:
Dor Askayo <dor.askayo@gmail.com> Fixes: 0e9a0c20 - "xwayland: clear pixmaps after creation in rootless mode" Closes: xorg/xserver#933 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
- 21 Nov, 2019 2 commits
-
-
Adam Jackson authored
Now that we've fixed LoaderSymbolFromModule this should work properly. This reverts commit 5c7c6d5c . Reviewed-by:
-
Adam Jackson authored
The thing you get back from xf86LoadSubModule is a ModuleDescPtr, not a dlsym handle. We don't expose ModuleDescPtr to the drivers, so change LoaderSymbolFromModule to cast its void * argument to a ModuleDescPtr. Reviewed-by:
-
- 19 Nov, 2019 2 commits
-
-
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/...
-
Currently, when a X11 client (usually the X11 window manager from a Wayland compositor) changes the value of the X11 property `_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame callbacks on the window are discarded so that the commit occurs immediately. Weston uses that mechanism to prevent the content of the window from showing before it's ready when mapping the window initially, but discarding the pending frame callbacks has no effect on the initial mapping of the X11 window since at that point there cannot be any frame callback on a surface which hasn't been committed yet anyway. However, discarding pending frame callbacks can be problematic if we were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent damages to be posted before the X11 toplevel is updated completely (including the window decorations from the X11 window manager). Remove the portion of code discarding the pending frame callback, Xwayland should always wait for a pending frame callback if there's one before posting new damages. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by:
-
- 18 Nov, 2019 1 commit
-
-
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:
-
- 15 Nov, 2019 1 commit
-
-
This reverts commit dd63f717. Caused a crash at least on some systems. Closes: xorg/xserver#934
-
- 13 Nov, 2019 4 commits
-
-
Prerequisite for building all of xserver with -z now. Gitlab: xorg/xserver#692
-
Prerequisite for building all of xserver with -z now. Gitlab: xorg/xserver#692
-
Bare LoaderSymbol() isn't really a great API, this is more of a direct map to dlsym like you want. Gitlab: xorg/xserver#692
-
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.
-
- 11 Nov, 2019 4 commits
-
-
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>
-
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: -
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: -
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:
-
- 10 Nov, 2019 1 commit
-
-
Arthur Williams authored
Extending the decade old f0124ed9, 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>
-
- 08 Nov, 2019 4 commits
-
-
Olivier Fourdan authored
For some reason, indentation for EGL backend hooks was broken. Signed-off-by:
-
Olivier Fourdan authored
Currently, Xwayland pixmap SHM code uses `malloc()` to allocate the xwl_pixmap. Use `calloc()` instead, as the EGLstream backend does, as it is safer (initializing the allocated data to 0). Signed-off-by:
-
Olivier Fourdan authored
Currently, glamor GBM backend uses `malloc()` to allocate the xwl_pixmap. Use `calloc()` instead, as the EGLstream backend does, as it is safer (initializing the allocated data to 0). Signed-off-by:
-
Olivier Fourdan authored
The definition by the manual is `calloc(size_t nmemb, size_t size)`. Swap the arguments of calloc() calls to match the definition. Signed-off-by:
-
- 07 Nov, 2019 1 commit
-
-
When a pixmap is created with a backing FBO, the FBO should be cleared to avoid rendering uninitialized memory. This could happen when the pixmap is rendered without being filled in its entirety. One example is when a top-level window without a background is resized. The pixmap would be reallocated to prepare for more pixels, but uninitialized memory would be rendered in the resize offset until the client sends a frame that fills these additional pixels. Another example is when a new top-level window is created without a background. Uninitialized memory would be rendered after the pixmap is allocated and before the client sends its first frame. This issue is only apparent in OpenGL implementations that don't zero the VRAM of allocated buffers by default, such as RadeonSI. Signed-off-by:
-
- 06 Nov, 2019 1 commit
-
-
Olivier Fourdan authored
`glGetString(GL_VERSION)` will return NULL without a current context. Commit dabc7d8b (“xwayland: Fall back to GLES2 if we don't get at least GL 2.1 in glamor”) would check the context is created, but it is made current just after, so the call to `epoxy_gl_version()` would return 0, hence defeating the version check. Make the context current prior to call `epoxy_gl_version()`. Fixes: dabc7d8b - xwayland: Fall back to GLES2 if we don't get at least GL 2.1 in glamor Closes: xorg/xserver#932 xorg/xserver!324 Signed-off-by:
-
- 05 Nov, 2019 1 commit
-
-
Some particularly unfortunate hardware (Intel gen3, mostly) will give you GLES2 but not GL 2.1. Fall back to GLES2 for such cases so you still get accelerated GLX.
-
- 04 Nov, 2019 1 commit
-
-
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>
-
- 30 Oct, 2019 8 commits
-
-
v2: Set the define for xha1.c programatically, rather than using loads of conditionals.
-
SourceValidate handles this for us consistently now. Reviewed-by: -
SourceValidate handles this for us consistently now. Reviewed-by: -
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: #902 Reviewed-by:
-
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. Reviewed-by: -
-
-
-
