GitLab

Primarily to fix the skopeo copy issue that causes pipelines to fail right
now, see ci-templates commit 0a9bdd33a98f05af67.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The Present code sends the idle notification event to the client after
xwl_present_flush returns. If we don't flush our GPU work here, the
client may race to draw another frame to the same buffer, so we may end
up copying (parts of) that new frame instead of the one we meant to.

Fixes xorg/xserver#835Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

Xwayland takes care of not attaching a new buffer if a frame callback is
pending.

Yet, the existing buffer (which was previously attached) may still be
updated from the X11 side, causing unexpected visual glitches to the
buffer.

Add multiple buffering to the xwl_window and alternate between buffers,
to leave the Wayland buffer untouched between frame callbacks and avoid
stuttering or tearing issues.

Closes: xorg/xserver#835Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Add a mechanism to create, recycle and destroy window buffers when
needed.

Typically, this adds a new `xwl_window_buffer` structure which
represents a buffer for a given Xwayland window.

Each Xwayland window has two different pools of buffers:

 - The available buffers pool:
   Those are buffers which where created previously and that have either
   not been submitted to the compositor or submitted and released.

 - The unavailable buffers pool:
   Those are typically the buffers which are being used by the
   compositor, awaiting a release.

Initially, an Xwayland window starts with both pools empty. As soon as a
new buffer is needed, it's either created (if there is none available)
or picked from the pool of available buffers.

Once submitted to the compositor, the buffer is moved to the pool of
unavailable buffers. When the corresponding `wl_buffer` is released by
the compositor, it is moved back to pool of available buffers again to
be reused when needed.

To avoid keeping too many buffers around doing nothing, a garbage
collection of older, unused buffers also takes care of disposing the
buffers being unused for some time.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

The API `wl_buffer_add_listener` is misleading in the sense that there
can be only one `wl_buffer` release callback, and trying to add a new
listener when once is already in place will lead to a protocol error.

The Xwayland EGL backends may need to set up their own `wl_buffer`
release listener, meaning that there is no way to our own `wl_buffer`
release callback.

To avoid the problem, add our own callback API to be notified when the
`wl_buffer` associated with an `xwl_pixmap` is released, triggered from
the different `xwl_pixmap` implementations.

Also update the Present code to use the new buffer release callback API.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

New 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.

This maps to eglGetDisplayDriverName if EGL_MESA_query_render is
supported, otherwise it returns NULL.

Should be slightly more efficient.
Reviewed-by: Adam Jackson <ajax@redhat.com>

Fixes random garbage being visible intermittently.
Reviewed-by: Adam Jackson <ajax@redhat.com>

If a new rotate buffer was allocated. This makes sure the new buffer
has valid transformed contents when it starts being displayed.
Reviewed-by: Adam Jackson <ajax@redhat.com>

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: Adam Jackson <ajax@redhat.com>

This will simplify backporting the following fix to the 1.20 branch.
Reviewed-by: Adam Jackson <ajax@redhat.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/700838Reviewed-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#933Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Now that we've fixed LoaderSymbolFromModule this should work properly.

This reverts commit 5c7c6d5c.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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: Michel Dänzer <mdaenzer@redhat.com>

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>

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: Michel Dänzer <mdaenzer@redhat.com>
xorg/xserver!333

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: xorg/xserver#937

This reverts commit dd63f717.

Caused a crash at least on some systems.

Closes: xorg/xserver#934

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

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.

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: Alex Goins <agoins@nvidia.com>

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>

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>

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=64793Signed-off-by: Arthur Williams <taaparthur@gmail.com>

For some reason, indentation for EGL backend hooks was broken.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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 <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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 <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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: Dor Askayo <dor.askayo@gmail.com>
Closes: xorg/xserver#636Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

`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!324Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

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.

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>

v2: Set the define for xha1.c programatically, rather than using loads
of conditionals.

SourceValidate handles this for us consistently now.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

SourceValidate handles this for us consistently now.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>