GLAMOR needs that, and the function returns TRUE unless GLAMOR is not
used.
Drop the function xwl_glamor_needs_buffer_flush() and call
glamor_block_handler() when glamor is used.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that we have only one backend, there is no need to initialize or
select between different backends.
Drop the corresponding functions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that we have only one GBM backend, either it is available and
usable, or we cannot use GLAMOR.
Therefore we can drop the flag "is_available".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
And call xwl_glamor_gbm_init_egl() directly instead.
Yet, keep the function separate rather than merging it back into
xwl_glamor_init() for clarity of the code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
That will be used between the generic Xwayland GLAMOR functions and the
GBM implementation.
Move the definition of xwl_glamor_init_gbm() to that new header rather
than in the generic Xwayland GLAMOR header.
This is preparation work to eventually replace the xwl_egl_backend now
that we have only one backend left.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that the NVIDIA proprietary driver has grown support for GBM, the
EGLStream backend for NVIDIA GPUs is now superseded by the standard
GBM backend in Xwayland.
This code path is therefore not used and hardly ever tested.
Remove support for EGLStream in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Since no evidency of anybody actually using it (nor it ever been used within
recorded git history), it's time to drop this old relic from times before
the great flood.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1403>
The dmabuf support code is scattered across different source files,
making it hard to follow and bloating unrelated sources.
Move the dmabuf related source code to its own source files.
This is just a cleanup aimed at helping with code readability, no
functional change intended.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1111>
After executing a PresentPixmap request using the copy path, Xwayland
will clear the vblank's pixmap field and re-queue it for the next msc so
that on the next frame a PresentCompleteNotify event will be delivered
to the client by present_execute_post.
While this does work, since the pixmap field of the vblank will be NULL
when present_execute_post is called, the mode reported in the event will
always be PresentCompleteModeSkip, even if the request *was* actually
executed with a copy.
To fix this, we introduce a new "copy_executed" flag in the
xwl_present_event struct. If xwl_present_execute sees that this flag is
set, it will fall straight through to present_execute_post like it does
if the window or pixmap is NULL. So, after executing a request with
present_execute_copy, instead of clearing the pixmap field we will set
the copy_executed flag to true. This will cause present_execute_post to
report the correct completion mode to the client when the
PresentCompleteNotify event is delivered on the next frame.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1254>
Since it's storing an locally defined (ddx-internal) data, it's better
not to abuse some globally defined key for this.
It just happened to work before, since CursorScreenKey is only used by DDX
(and there's only one DDX per executable) and they currently (!) have the
same size (pointer) - but that's a fragile programming style, so clean it up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
Since it's storing an locally defined (ddx-internal) struct, it's better
not to abuse some globally defined key for this.
It just happened to work before, since CursorScreenKey is only used by DDX
(and there's only one DDX per executable) and they currently (!) have the
same size (pointer) - but that's a fragile programming style, so clean it up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
It's naming is a bit unprecise: it actually is used for storing
xnestCursorFuncPtr inside a Screen. Thus rename it to
xnestScreenCursorFuncKeyRec to make it bit more clear.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
This header isn't installed, so no external modules could use the
functions declared there. Thus we can unexport it all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1358>
This function isn't used by any driver and doesn't seem to be useful for them,
thus move it out of the public module API, in order to tidy it up a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1366>
We must not modify the contents of a client pixmap.
If there's an available window buffer, we re-use that for the window
pixmap. Otherwise we just allocate a new one.
This also avoids Present client hangs due to xwl_present_buffer_release
not getting called for the buffer release event.
v2:
* Use xwl_pixmap_get_buffer_release_cb instead of keeping track of the
flip pixmap in xwl_window.
* Dispose of xwl_window_buffer in xwl_window_swap_pixmap called from
damage_report.
v3:
* Use xwl_window->surface_pixmap in damage_report.
v4:
* Don't re-use client pixmaps as window buffers.
* Clear xwl_window_buffer->pixmap before calling
xwl_window_buffer_maybe_dispose in xwl_window_swap_pixmap, to prevent
it from clearing the buffer release callback.
v5:
* Keep using xwl_window_buffers_get_pixmap in xwl_window_attach_buffer.
* Always keep a reference to the old window pixmap in _swap_pixmap,
drop it in damage_report.
Fixes: 6779ec5bf6 ("xwayland: Use window pixmap as a window buffer")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1633
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1644
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
There will be another caller in a later commit.
v2:
* Bump xwl_window_buffer->refcnt in xwl_window_swap_pixmap, to prevent
xwl_window_set_pixmap from disposing of it.
v3:
* Go back to bumping xwl_window_buffer->refcnt in
xwl_window_buffers_get_pixmap. xwl_window_set_pixmap should no longer
dispose of it now that xwl_glamor_gbm_create_pixmap_for_window is
fixed, and xwl_window_swap_pixmap forgot to bump it if
xwl_window_buffer_get_available returned NULL.
v4:
* Unlink xwl_window_buffer from xwl_window->window_buffers_available
before calling xwl_window_set_pixmap in xwl_window_swap_pixmap, or
that might dispose of it.
v5:
* xwl_window_swap_pixmap does everything xwl_window_buffer_get_available
did before, except for just using the window pixmap if
!xwl_glamor_needs_n_buffering.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
Each function can get the damage region from the xwl_window instead.
Add xwl_window_get_damage_region helper for this.
v2:
* Use xwl_window_get_damage_region in xwl_window_attach_buffer as well
(Olivier Fourdan)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
These aren't used by any drivers/modules, just DDX'es, so no need to export.
Note: tigervnc does use it, but it has it's own DDX, therefore directly
linked in, just like the in-tree DDX'es which doesn't need exporting.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1349>
This conditional practically only controls whether we have an pointer,
where DDX can plug in it's own VErrorF() handler (currently only xwin
doing that). The cost of having it even when DDX doesn't use it, is
really negligible: it's just one pointer and an extra non-null check
on it per VErrorF() call - a very cold path. Strangely, xwin has extra
Getting rid of this unnecessary complexity that really hasn't any
practical gain.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1329>
[374/383] Compiling C object hw/xwin/Xming.exe.p/winmultiwindowicons.c.obj
791In file included from /usr/i686-w64-mingw32/include/X11/Xwinsock.h:57,
792 from /usr/i686-w64-mingw32/include/xcb/xcb_windefs.h:34,
793 from /usr/i686-w64-mingw32/include/xcb/xcb.h:41,
794 from ../hw/xwin/winmultiwindowicons.c:43:
795/usr/share/mingw-w64/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
796 15 | #warning Please include winsock2.h before windows.h
797 | ^~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1295>
../hw/xwin/InitOutput.c: In function ‘winFixupPaths’:
747../hw/xwin/InitOutput.c:578:9: warning: ‘strncpy’ output truncated before terminating nul copying 5 bytes from a string of the same length [-Wstringop-truncation]
748 578 | strncpy(buffer, "HOME=", 5);
749 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1295>
[324/383] Compiling C object hw/xwin/winclipboard/xwinclip.exe.p/debug.c.obj
666../hw/xwin/winclipboard/debug.c:31:1: warning: no previous prototype for ‘winDebug’ [-Wmissing-prototypes]
667 31 | winDebug(const char *format, ...)
668 | ^~~~~~~~
669../hw/xwin/winclipboard/debug.c: In function ‘winDebug’:
670../hw/xwin/winclipboard/debug.c:37:3: warning: function ‘winDebug’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
671 37 | count += vfprintf(stderr, format, ap);
672 | ^~~~~
673../hw/xwin/winclipboard/debug.c: At top level:
674../hw/xwin/winclipboard/debug.c:44:1: warning: no previous prototype for ‘ErrorF’ [-Wmissing-prototypes]
675 44 | ErrorF(const char *format, ...)
676 | ^~~~~~
677../hw/xwin/winclipboard/debug.c: In function ‘ErrorF’:
678../hw/xwin/winclipboard/debug.c:49:3: warning: function ‘ErrorF’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
679 49 | count = vfprintf(stderr, format, ap);
680 | ^~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1295>
Over 1.5 decades ago, pixmap handling was moved to using pixman library,
but there's still a bit fallout from that left. Cleaning it up now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
None of the public module API functions use the types defined in here,
this file isn't even included anywhere (in the public headers). Thus it
doesn't seem to be needed in the public API at all - so make it private.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1281>
The typdef and defines from dgaproc.h are used by drivers, so it needs to
remain part of the public API. But no need to clutter the public header
with non-exported function declarations.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1323>
It's just a dumb wrapper around PrivsElevated(), and also just called in few
places, while others call PrivsElevated() directly - thus not needed and
can be dropped.
Note that it's also not called by drivers, so the export was unnecessary.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1324>
The symbols HAVE_SIGACTION and BUSFAULT are set under the same conditions,
so can be consolidated into one. Also define dummies when HAVE_SIGACTION
is not set, so a few #ifdef's less clutterig the code.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1297>
This breaks the xf86-input-synaptics driver:
synaptics.c: In function 'clickpad_guess_clickfingers':
synaptics.c:2638:5: error: implicit declaration of function 'BUG_RETURN_VAL' [-Werror=implicit-function-declaration]
2638 | BUG_RETURN_VAL(hw->num_mt_mask > sizeof(close_point) * 8, 0);
This reverts commit 442aec2219.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1316>
GCC reports:
[1/2] Compiling C object hw/xwayland/Xwayland.p/xwayland.c.o
../hw/xwayland/xwayland.c: In function ‘try_raising_nofile_limit’:
../hw/xwayland/xwayland.c:161:72: warning: format ‘%li’ expects argument of type ‘long int’, but argument 4 has type ‘rlim_t’ {aka ‘long long unsigned int’} [-Wformat=]
161 | LogMessageVerb(X_INFO, 3, "Raising the file descriptors limit to %li\n",
| ~~^
| |
| long int
| %lli
162 | rlim.rlim_max);
| ~~~~~~~~~~~~~
| |
| rlim_t {aka long long unsigned int}
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1257>
GCC repors:
../hw/xfree86/drivers/modesetting/drmmode_display.c:4135:49: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
4135 | "Gamma ramp set to %ld entries on CRTC %d\n",
| ~~^
| |
| long int
| %lld
4136 | size, num);
| ~~~~
| |
| uint64_t {aka long long unsigned int}
../hw/xfree86/drivers/modesetting/drmmode_display.c:4139:57: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
4139 | "Failed to allocate memory for %ld gamma ramp entries "
| ~~^
| |
| long int
| %lld
4140 | "on CRTC %d.\n",
4141 | size, num);
| ~~~~
| |
| uint64_t {aka long long unsigned int}
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1257>
The MIT authentication handling isn't really OS specific, and only few sites
actually need to call it, so at least it's prototypes are better off in some
separate header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1311>
With transition from autoconf to meson, these aren't actually supported
anymore, and re-adding it isn't planned. Thus the now dead code pathes
can be completely removed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1286>
Potentially, the pointer to the mode name could be unset, this can
occur with the xf86-video-nv DDX, in that case there isnt much we can do
except check if the next mode is any better.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
[585/699] Compiling C object hw/xfree86/int10/libint10.so.p/generic.c.o
../hw/xfree86/int10/generic.c:103:1: warning: ‘readIntVec’ defined but not used [-Wunused-function]
103 | readIntVec(struct pci_device *dev, unsigned char *buf, int len)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
glamor needs to be disabled if neither gbm nor eglstream is available,
otherwise build breaks.
Closes: xorg/xserver#1631
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to define XKBSRV_NEED_FILE_FUNCS, for about 15 years now
(since XKBsrv.h isn't used anymore), so drop it.
Fixes: e5f002edde
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Yet another step of uncluttering includes: move out the BUG_* macros
into a separate header, which then is included as-needed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
And other 32-bit architectures, where uint32_t and CARD32 are
not the same type. Otherwise the build will fail with GCC 14
with errors like:
../hw/xwayland/xwayland-glamor.c: In function ‘xwl_glamor_get_formats’:
../hw/xwayland/xwayland-glamor.c:291:43: error: passing argument 3 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types]
291 | num_formats, formats);
| ^~~~~~~~~~~
| |
| CARD32 * {aka long unsigned int *}
../hw/xwayland/xwayland-glamor.c:238:38: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’}
238 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~^~~~~~~~~~~
../hw/xwayland/xwayland-glamor.c:291:56: error: passing argument 4 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types]
291 | num_formats, formats);
| ^~~~~~~
| |
| CARD32 ** {aka long unsigned int **}
../hw/xwayland/xwayland-glamor.c:238:62: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’}
238 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~~^~~~~~~
../hw/xwayland/xwayland-glamor.c:295:28: error: passing argument 3 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types]
295 | num_formats, formats);
| ^~~~~~~~~~~
| |
| CARD32 * {aka long unsigned int *}
../hw/xwayland/xwayland-glamor.c:217:26: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’}
217 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~^~~~~~~~~~~
../hw/xwayland/xwayland-glamor.c:295:41: error: passing argument 4 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types]
295 | num_formats, formats);
| ^~~~~~~
| |
| CARD32 ** {aka long unsigned int **}
../hw/xwayland/xwayland-glamor.c:217:50: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’}
217 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~~^~~~~~~
This allows e.g.
xfwm4 --vblank=xpresent
to hit the page flip path instead of copies.
In the future, Mesa might also use the Present extension with software
rendering.
Multiple benefits, in particular:
* Fullscreen windows can hit the page flip path
* X client presentation is properly synchronized to the Wayland
compositor refresh cycle via frame events
By default, Xwayland (as any Wayland client) uses the keymap set by the
Wayland compositor using the standard Wayland protocol.
There are some specific uses cases where a user would want to let the
X11 clients control the keymap. However, the Wayland compositor may
(re)send the keymap at any time, overriding whatever change was made
using the X11 mechanisms.
Add a new "-nokeymap" option to Xwayland to instruct Xwayland to simply
ignore the standard Wayland mechanism to set the keymap, hence leaving
the control entirely to the X11 clients.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If the old window pixmap was the screen pixmap.
Fixes screen->GetScreenPixmap() returning a stale pointer to a destroyed
pixmap with rootful Xwayland. It would result in a crash after resizing
the Xwayland window, or at the latest when shutting down.
Fixes: 6779ec5bf6 ("xwayland: Use window pixmap as a window buffer")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1621
The cursor in DIX is actually split in two parts, the cursor itself and
the cursor bits, each with their own devPrivates.
The cursor itself includes the cursor bits, meaning that the cursor bits
devPrivates in within structure of the cursor.
Both Xephyr and Xwayland were using the private key for the cursor bits
to store the data for the cursor, and when using XSELINUX which comes
with its own special devPrivates, the data stored in that cursor bits'
devPrivates would interfere with the XSELINUX devPrivates data and the
SELINUX security ID would point to some other unrelated data, causing a
crash in the XSELINUX code when trying to (re)use the security ID.
CVE-2024-0409
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a new command line option "-output" to specify on which output
Xwayland should be starting fullscreen when rootful.
That allows to run multiple instances of Xwayland rootful fullscreen on
multiple outputs.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When putting the (root) window fullscreen, first search for an output
with the specified name, if any.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
At startup, the names of the Wayland outputs are not yet known,
therefore we cannot rely on those when running fullscreen rootful.
Make sure to check the fullscreen state once the Wayland output name
changes.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add a output name to the xwl_screen.
This is preparation work for fullscreen rootful on a specific output,
no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add a convenient function to search for an xwl_output based on its
XRandR name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When running rootful, we do not need to apply the output changes, these
are there just to track the names and show up as disconnected in XRandR.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When running rootful, Xwayland would simply skip the creation of the CRTC
for the "real" outputs.
Instead, create the CRTC regardless of all outputs in rootful mode, but
mark them as disconnected when running rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The fixed output is called "XWAYLAND0", yet if the compositor does not
support Wayland output names, the "real" output names may collide with
the fixed output name.
Use the same output serial as with the (default) real output names to
avoid reusing the same names.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Use the simpler form `{ 0 }` instead of `{ '\0', }` for the
initialization of the output name buffer.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Move the code which may update the fullscreen state of the rootful
window to a dedicated helper function.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
If there's no available window buffer.
This allows keeping xwl_window_buffer->damage_region empty for a newly
allocated xwl_window_buffer in xwl_window_buffers_get_pixmap, instead
of first populating it in xwl_window_buffer_add_damage_region and then
emptying it again.
Assuming the same number of window buffers, this results in one less
pixmap per toplevel window, saving pixmap storage.
v2:
* Preserve xwl_window_buffer_get_available behaviour (Olivier Fourdan)
v3:
* Leave RegionEmpty call where it was in xwl_window_buffers_get_pixmap,
so it takes effect for a newly allocated struct xwl_window_buffer.
* Consolidate xwl_window_buffer->pixmap assignment in the same place.
Use xwl_window_buffers_dispose instead. The pixmaps will need to be
re-created anyway, so keeping around the xwl_window_buffers doesn't
buy much. And dropping this makes the next commit simpler.
Also fold xwl_window_buffer_destroy_pixmap into its only remaining
caller, xwl_window_buffer_maybe_dispose.
v2: (Olivier Fourdan)
* Fix up indentation in xwl_window_set_window_pixmap
* Leave xwl_window_buffer_destroy_pixmap helper
GetScratchGC can't really fail without a bug elsewhere. Just FatalError
in that case, so we'd get a bug report if it ever happens, instead of
trying to limp along.
A clip should represent the area that is covering the current FB associated
with the CRTC. So making sure each input rect covers any area in the FB is
the first thing to do. If that is the case, the size and coordinates should
be adjusted based on the partial area in the FB the each rect covers. The size
elements need to be truncated if the rect's size exceeds FB's for the CRTC.
Then offsets should be applied to coordinates if the CRTC's offsets aren't 0.
And coordinate transposing and inversion are needed in case the rotated image
is assigned to the FB.
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
xserver fails to generate useable resolutions with 90Hz framerate
panels(encounter the same issue with 3 different 2.5k resolution
panels). All the resolutions shown by xrandr lead to blank screen except
the one written in EDID.
Ville Syrjälä from Intel provides a method to calculate the preferred
clock and refresh rate from the existing resolution table and this
works for the issue.
v2. xf86ModeVRefresh might return 0, need to check it before use it.
v3. reported by Markus on launchpad that the issue is not devided by 0,
it's the "preferred" being accessed unconditionally.
BugLink: https://launchpad.net/bugs/1999852
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1388
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Xwayland uses OEFFIS_DEVICE_ALL_DEVICES to get all possible device types
enabled.
Be more selective and specify explicitly keyboard and pointer instead of
relying on what "all devices" translates to in the stack.
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3194
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
After resizing Xephyr's window RRGetCrtcInfo returns the changed size,
but the RRCrtcChangeNotify event is not sent.
Call RRGetInfo(pScreen, TRUE) to update the current mode and send
notifications to clients.
Add a workaround to accept devices of the kernel's ofdrm driver.
Makes Xorg work on Open Firmware's pre-configured display with the
DRM graphics stack.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Resolve symbolic links before the PCI device check in fbdev_open.
Otherwise, opening device files that are symbolic links will fail.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1419
Signed-off-by: Moritz Bruder <muesli4@gmail.com>
TearFree support has been available in the modesetting driver for a year
with no issues reported. The code is mature and robust, with error handling
that's been vetted across many hardware configurations.
Notably, TearFree is also the only way to achieve a tear-free desktop with
mismatched displays and transformed CRTCs.
Enable TearFree by default for a smooth desktop experience out of the box.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Stop putting stack garbage into the gamma LUT blob reserved
fields.
Fixes: 245b9db03a ("modesetting: Use GAMMA_LUT when available")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Try to minimize the used hw cursor size in order to
minimize power consumption. There is no kernel query
for the minimum so we'll just probe around with
setcursor2 (using an invisible cursor image so
there will be no visual artifacts).
To avoid having to deal with absolutely every size stick
to power-of-two numbers. And with a bit of extra effort
we can determine whether non-square dimesions will also
work, which they do to some degree on current Intel GPUs.
On my Alderlake laptop I'm seeing a massive (up to .5W)
difference in power consumption between 64x64 vs. 256x256
cursors. While some of that is undoubtedly something that
needs to be fixed in i915's display data buffer allocation
code, it still makes sense to use as small as possible
cursor to minimize the wastege.
In case the crtc is rotated just punt to the max cursor size
for now since midlayer has already done the coordinate
transformations based on that. To make smaller cursors work
with rotation we'd either need to make the midlayer(s) aware
of the final cursor size, or just handle the whole roation
business in modesetting. I suspect the latter option would
be easier.
v2: Only allow square cursors in most cases for now as eg.
on modern Intel hardware non-square only works with
wide+short but not with narrow+tall cursors. Non-square
size may still be used when maximum limits aren't
square and the squared+POT'd dimensions would exceed
one of the max limits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Make sure we're not scanning out any fbs with fancy modifiers when
we try to light up new displays. This is already the case in cases
where the screen gets resized, but in cases where that doesn't happen
it might be possible for the modeset(s) to fail due to watermark/etc.
constraints imposed by the fancy modifiers. We can avoid that by
making sure everything gets unflipped before the modeset.
v2: make poll timeout infinite
s/in_modeset/pending_modeset/
deal with tearfree fallout (goto no_flip)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
X11 clients tend to assume that pointers have buttons. This
assumption means they often fail to handle the X error that
is generated when querying the button mapping of a pointer
device that lacks buttons.
This failure to handle the X error leads to those client
applications to abruptly exit.
This commit assigns vestigial buttons to the gesture pointer
device for the sole purpose of backward compatibility with
legacy X11 clients.
That technique is already employed for a different pointer,
the relative pointer device, for similar reasons, so this
just makes the legacy client compatibility more complete.
See https://gitlab.gnome.org/GNOME/mutter/-/issues/2353
When creating the output with the default "XWAYLAND<n>" name, we use
the MAX_OUTPUT_NAME value to allocate a lot more memory than necessary
to accommodate for future output names once they get updated, but by
doing so, we also send XRandR way too much (zeroed) data since the
"nameLength" value is (purposely) set too big.
So, instead, let's just update the name after creating the RR output,
this way we set both the name and nameLength to their correct values
while keeping the initial large allocation.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 3c07a01c42 - xwayland: Use xdg-output name for XRandR
Reviewed-by: Simon Ser <contact@emersion.fr>
At creation, Xwayland uses a generic output name ("XWAYLAND0", etc.) for
the XRandR outputs, and later, once the name is known from the Wayland
protocols, updates the output names using the actual names from the
Wayland compositor.
However, when doing so, it simply updates the string, the "nameLength"
isn't updated, so the name passed to the clients might either end up
being truncated or contain portions of the previous (initial) output
name.
Note, this is using a fixed size buffer initialized with zeros, so this
cannot leak any data other than the previous output name, so this is
mainly a cosmetic issue.
Update the output's "nameLength" when updating the output name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 3c07a01c42 - xwayland: Use xdg-output name for XRandR
Reviewed-by: Simon Ser <contact@emersion.fr>
This reverts commit 947d1c7ecf.
lnx_platform.c doesn't exist in this branch since commit 54681238
renamed it to shared/drm_platform.c and added it to the BSD build.
Fixes build failures in CI of:
../hw/xfree86/os-support/meson.build:163:18: ERROR: File linux/lnx_platform.c does not exist.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The Wayland interfaces have a "name" field that we can use instead of
hardcoding their name.
Change the code to use that name instead of the static strings.
This was inspired by a similar change in mutter by Robert Mader
<robert.mader@collabora.com>.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Xwayland offers a way for the window and compositing manager to hold the
surface commits through an X11 property _XWAYLAND_ALLOW_COMMITS.
Xwayland, however, does not actually check if the X11 client changing
the value of that property is indeed the X11 window manager, so any X11
client can potentially interfere with the Wayland surface mechanism.
Restrict access to the _XWAYLAND_ALLOW_COMMITS property to read-only,
except for the X11 window manager and the Xserver itself.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is preparation work to restrict access to Xwayland properties.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When running fullscreen, if an X11 client has changed the resolution,
Xwayland is using a viewport to emulate the expected resolution.
When changing focus, the Wayland compositor will send a configure event
with the actual surface size, not the size of the emulated XRandR
resolution.
As a result, changing focus while XRandR emulation (and hence the
viewport) is active in Xwayland will revert the resolution to the actual
output size, defeating the XRandR emulation.
To avoid that issue, only change the size when not running fullscreen.
Fixes: 53b6d4db7 - xwayland: Apply root toplevel configure dimensions
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Kenny Levinsen <kl@kl.wtf>
Whenever the output configuration changes, if Xwayland is running
fullscreen, we may need to update the viewport in use or even update the
output on which Xwayland is currently running fullscreen.
Add a new helper function xwl_window_rootful_update_fullscreen() that
will recompute the fullscreen state and the viewport setup so that the
fullscreen Xwayland rootful window matches the new setup.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Kenny Levinsen <kl@kl.wtf>
Xephyr now gained an ability to use glamor glx provider.
Unfortunately, without DRI3, we end up with same llvmpipe as before
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
This allows Xorg to use Glamor GLX when Glamor is requested,
and eliminates usage of DRI2 in case of Glamor.
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Emma Anholt <emma@anholt.net>
This code is almost entirely ddx-agnostic already, and I'd like to use
it from the other EGL glamor consumers. Which, right now that's just
Xorg, but soon it'll be Xephyr too.
This commit adds an ability to store a glvnd vendor in Glamor
structures, which can be used for initialize some vendor-based values
without hooking into DDX internals. Also this adds setting this value
into Xorg and Xwayland
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Emma Anholt <emma@anholt.net>
This replaces int glamor parameter with a new enum to be more clean
and prepare for more glamor options.
No functional change.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
When you set the auto repeat rate trough xset to something like 250 40:
`xset r rate 250 40`
Is setting the first delay to 250ms and set the rate to 40hz (25ms)
However, if you were to apply this configuration from a xorg config file,
the result would be the first delay being applied correctly,
but the repeat rate would be set to 25Hz instead. This is because the config
option is using a rate of repeats per second but XKB stores it as interval.
Make sure this is converted correctly.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1558
Signed-off-by: EXtremeExploit <pedro.montes.alcalde@gmail.com>
On Mesa, when we request GBM_FORMAT_XRGB8888, driver set surface storage
format to GL_RGB8, which breaks GL ES rendering (on any GL ES version).
If we force set gbm_format to GBM_FORMAT_ARGB8888, then rendering
will happen and working.
Fixes#1288Fixes#1356
Xwayland maintains a connection to EI up for 10 minutes after an X11
client has vanished, to avoid going through the connection phase every
time a short lived X11 client comes and goes.
However, if the EI client gets freed (through some other event, e.g. the
user decides to terminate the EI session), Xwayland would still keep the
callback alive and end up trying to free an already freed EI client:
Invalid read of size 4
at 0x4C5E6F9: object_unref (util-object.h:89)
by 0x4C5E6F9: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x429A6E: disconnect_timer_cb (xwayland-xtest.c:404)
by 0x5E63FF: DoTimer (WaitFor.c:276)
by 0x5E6463: DoTimers (WaitFor.c:290)
by 0x5E6164: check_timers (WaitFor.c:133)
by 0x5E61E9: WaitForSomething (WaitFor.c:195)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Address 0x15cc6ee8 is 8 bytes inside a block of size 240 free'd
at 0x48452AC: free (vg_replace_malloc.c:974)
by 0x4C5E729: object_destroy (util-object.h:73)
by 0x4C5E729: object_unref (util-object.h:91)
by 0x4C5E729: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x42A946: xwl_handle_ei_event (xwayland-xtest.c:804)
by 0x5EA977: HandleNotifyFd (connection.c:809)
by 0x5EE8E3: ospoll_wait (ospoll.c:657)
by 0x5E624D: WaitForSomething (WaitFor.c:208)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Block was alloc'd at
at 0x484782C: calloc (vg_replace_malloc.c:1554)
by 0x4C5E777: ei_create (libei.c:73)
by 0x4C5E777: ei_create_context (libei.c:97)
by 0x42994B: setup_ei (xwayland-xtest.c:366)
by 0x42A383: xwayland_xtest_send_events (xwayland-xtest.c:658)
by 0x54ED4C: ProcXTestFakeInput (xtest.c:441)
by 0x54EE56: ProcXTestDispatch (xtest.c:475)
by 0x4AD6E6: Dispatch (dispatch.c:546)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
To avoid that issue, make sure to cancel the timer as soon as a EI
client is freed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
See-also: https://bugzilla.redhat.com/2243076
If we fail to setup EI, give up on using EI for XTEST and restore the
default XTEST handlers.
This happens when neither the portal nor the socket backends are usable.
This does not affect the portal operation though, if the user choose not
to allow a particular client, Xwayland would continue to use EI.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
With EI support wired to XTEST, and oeffis being enabled unconditionally
means that Xwayland will always go through the XDG portal for XTEST when
supported.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Xwayland itself, as a regular Wayland client, has no way to tell that it
is running on a nested compositor.
So to keep backward compatibility with existing (and also common) use
cases such as nested compositors, best is to disable support for the XDG
portal by default, and add a new command line option "-enable-ei-portal"
for the Wayland compositors (who spawn Xwayland rootless) to explicitly
enable support for the input emulation XDG portal in Xwayland.
A Wayland compositor running nested should not use that command line
option with Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Fixes: a1333342 - xwayland: Add XTEST support using EIS
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
Some drivers might not support explicit format modifiers. On these
drivers `gbm_bo_create_with_modifiers()` will fail and the
`gbm_bo_create()` code path will be used instead.
In this case, if the LINEAR modifier is advertised (and the INVALID
modifier is not) add the `GBM_BO_USE_LINEAR` flag.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1438
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito's avatarJosé Expósito <jexposit@redhat.com>
This can happen if the window has never completed a Present operation.
Fixes: 4230176080 ("xwayland/present: Embed present_vblank_rec in xwl_present_event")
We specify a sensible default geometry for decorated rootful windows,
but not for undecorated ones. Make the default geometry apply to rootful
windows in general.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
While we now have support for resize of the root window through
libdecor, we still ignore toplevel configure dimensions when libdecor is
not in use. This ignores user intent in many Wayland servers, and some
xdg_toplevel states when active have strong requirements for adherence
to configure dimensions.
Resize in response to xdg_toplevel configure dimensions like we do for
libdecor configure events.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
The upcoming handling of plain xdg_toplevel.configure events will need
to use the xwl_window resize helper. Move it outside XWL_HAS_LIBDECOR,
move the remaining dimension logic from handle_libdecor_configure into
it and update the name accordingly.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
When handling libdecor configure, we first update our xwl output and
screen if dimensions differ from the current xwl_screen, and then commit
a new libdecor frame which acknowledges the xdg_surface.configure event.
If the initial configure events contains non-zero dimensions, we will
update the xwl output before acknowledging the initial configure. As we
attach a buffer and commit the surface when updating the output, this
leads to a protocol error.
Instead, move the surface commit till the end of the configure handler
so it always happens after the ack.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Similar to commit 94deed272 - " xwayland: Use sensible defaults for
rootful size", mark fullscreen mode as fixed so that the actual monitor
layout is not reflected in the single fullscreen rootful window.
Without this, if "-fullscreen" is used without "-geometry", the XRandR
configuration is taken from the compositor via wl_output/xdg-output and
cannot be changed by the X11 clients.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Enforce sensible min/max values for the window size when using libdecor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This is to avoid repeating the same code in two places.
This is essentially a cosmetic change, not a functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Allow passing an optional libdecor configuration pointer to
xwl_window_update_libdecor_size() so that we can reuse it from more than
one place and avoid duplicating that code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The configure handler in libdecor is triggered any time a new
configuration is received.
According to the documentation from libdecor, an application should
respond to that event by creating a suitable libdecor_state, and apply
it using libdecor_frame_commit().
So we ought to attach a new buffer matching the new size and commit
the Wayland surface.
The actual content of the window does not need to be explicitly
repainted, that occurs through the call to SetRootClip():
xwl_output_set_mode_fixed()
-> update_screen_size()
-> SetRootClip()
-> miHandleValidateExposures()
-> miWindowExposures()
-> miPaintWindow()
This fixes an issue with mutter where maximizing a window and then
switching to another window would sometimes resize the Xwayland window
back to its pre-maximized size, or with Weston where the Xwayland window
would initially show up black until the pointer moves to the window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This moves the code which updates the XRandR modes and sets the root
window size to its own function.
This preparation work for the next commit, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The configure handler for libdecor, namely handle_libdecor_configure(),
is where both the content and the decorations get resized (when needed).
If for any reason, the actual size of the Xwayland screen fails to be
updated, we would still appy the expected size rather than the actual
one for the libdecor state.
To avoid this, use the actual xwl_screen width/height for the libdecor
state.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
For libdecor, we will have to attach a new buffer and commit from two
different handlers (libdecor configure and commit).
Having xwl_window_attach_buffer() separate from xwl_window_post_damage()
is to allow for that.
This commit should not introduce any functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
Second attempt, after fixing a few regressions from the first attempt.
If "-decorate" is used but no "-geometry" is specified, Xwayland rootful
would take its size from the actual Wayland outputs combined.
That is not practical, especially when using multiple outputs, as the
resulting Xwayland window would be much larger than a single monitor.
To avoid that, set a sensible default size for the Xwayland decorate
window, using 640x480 to match what Xephyr does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
libdecor support seems quite stable, no need to mark that experimental.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
By default, the Xwayland window in rootful mode was not resizable.
Make the Xwayland window resizable using libdecor in rootful mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is preparation work for making Xwayland rootful resizeable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
This will be needed with the next commit: If a child window completely
obscures a toplevel ancestor of different depth, the child window can
use page flipping only if the depth of the presented pixmap matches that
of the window's backing pixmap, or the former may contain pixel values
which are not suitable for the toplevel window's depth.
With optional EI support in Xwayland, we would route XTEST events to EI
so that they get actually emulated in the Wayland compositor.
However, this implies that EI is actually supported in various places,
including the Wayland compositor of course. If, for whatever reason, we
fail to use EI, the actual XTEST events will be dropped.
That might be seen as a regression, as previously those would go through
the usual X11 processing of events and might have worked with X11 native
clients.
So, to keep backward compatibility, fallback to the plain old XTEST
method if EI is not available or not usable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This adds support for XTEST in Xwayland using EIS, the emulated input
library [1].
To differentiate between X11 clients using XTEST, initiate a EI context
for each client and use the actual client name, from its command
line.
When an X11 client first tries to use XTEST to generate emulated input
events, a new connection to libEI is initiated by Xwayland on behalf
of the X11 client.
During that connection phase, the EI server will not be accepting
events until the emulated device is actually created, meaning that any
XTEST request from the X11 client will be discarded until the EI server
is willing to accept events.
To avoid that issue, add an event queue in Xwayland per X11 client that
will keep those requests, and dequeue them as soon as the EI server is
ready, i.e. once the EI device is added.
If the X11 client disconnects from the Xserver before the EI server is
ready, or if the connection is closed by the EI server, those events are
discarded and the queue cleared from any pending events.
For 10 minutes after the client disconnects, keep the internal struct
alive. If a client with the same commandline arguments connects again,
re-use the same struct. This means we are faster with the events the
second time around but it also allows the EIS server to pause individual
clients that keep sending intermittent events and disconnect immediately
(e.g. it'd be possible to pause xdtotool while an authentication prompt
is active).
[1] https://gitlab.freedesktop.org/libinput/libei
Thanks to Jan Beich <jbeich@FreeBSD.org> for fixing the build on BSD.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
Co-authored-by: David Redondo <kde@david-redondo.de>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This allows manual handling of IdleAction and IdleHint rather than automatically
calling the IdleAction every IdleSecs, due to inactivity on the underlying tty.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1194
Signed-off-by: aarondill <aaronsacks2006@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Nothing should be relying on this anymore, so use a counter like other
places in the tree instead. This ensures that the event_id doesn't get
cast back into a pointer again in future, and also may be slightly less
confusing in cases where calloc reuses an address as debug logs would
show the same event_id for those but now they will be distinct.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
On traditional 32-bit and 64-bit architectures, uint64_t can be abused
to hold a uintptr_t and be cast back to a valid pointer. However, on
CHERI, and thus Arm's Morello prototype, pointers are capabilities,
which contain a traditional address alongside additional metadata,
including a tag bit that ensures it cannot be forged (the only way to
get a capability with the tag bit set is by using instructions that take
in another valid capability with sufficient bounds/permissions/etc for
the request, and any other operation, like overwriting individual bytes
in memory, will give a capability whose tag is clear). Casting a pointer
to a uintptr_t is fine as uintptr_t is represented as a capability, but
casting to a uint64_t yields just the address, losing the metadata and
tag. Thus, when cast back to a uintptr_t, the capability remains invalid
and faults on any attempt to dereference.
As with various other places in the tree, address this by searching for
the pointer in a list so that we no longer rely on this undefined
behaviour.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
All these arguments other than damage come from the vblank itself so
passing the vblank simplifies the caller. Moreover, we pass the event_id
solely so we can get back to the event, which is just the (extended)
vblank, so passing the vblank avoids that round trip.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
By adding a new xwl_present_event_from_vblank function we can avoid
turning the vblank into an event_id, and also abstract away the exact
encoding for event_id from most places.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
The current code, as changed by commit ad2d461de „Do not round
non-standard modes“ is reported to be logically incongruent.
We should either drop libxcvt entirely or simply fix the size, keeping
the CVT timings unchanged.
For backward compatibility and simplicity, I'd rather simply fix the
hdisplay/vdisplay to match the given size.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: ad2d461de - xwayland: Do not round non-standard modes
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1549
Commit ad2d461de „xwayland: Do not round non-standard mode“ introduced a
spelling error in the names of the local functions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: ad2d461de - xwayland: Do not round non-standard modes
ki->name has already initialized in KdNewKeyboard() with strdup().
But initialized in KdParseKeyboard() again.
Signed-off-by: Tamura Dai <kirinode0@gmail.com>
Now that our CVT function is able to deal with non-standard modes, we
can safely use it for the fixed mode as well.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, Xwayland uses libxcvt to generate the mode info and then
passes that to RRModeGet() to generate a RRMode.
However, libxcvt may round down the width to match the horizontal
granularity (8), and that's a problem when the Wayland compositor is
running a non-standard size (like, e.g. running nested with a custom
size) because XRandR would report a width smaller than the actual size.
To avoid that, check whether the CVT computed size differs from the
expected size, and fallback to a simpler computation not doing any
rounding if that's the case.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1540
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Compositors may use XWAYLAND_ALLOW_COMMITS to communicate when Xwayland
may or may not commit new buffers to a wl_surface. If commits are
denied, then later allowed, we'll only get a buffer attached if there is
actual damage posted, which might be long after.
This fixes an issue where the window manager would reparent a window
while denying commits, then after reparenting, allow commits. The window
in question belonged to a game and took several seconds produce the next
frame, resulting in an empty window appearing as if it had just
disappeared.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
If the format and modifiers are from a tranche which supports scanout,
we can set the corresponding flag to gbm_bo_create_with_modifiers2() to
benefit from scanout buffers where applicable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add a new API similar to xwl_glamor_get_drawable_modifiers() but also
returning whether the format and modifiers are from a tranche which
supports scanout.
This is preparation work for adding scanout support with
gbm_bo_create_with_modifiers2() when supported.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This allows us to pass flags to the function, avoiding the forced
implicit GBM_BO_USE_SCANOUT which happens with the older version.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The present code in Xwayland cannot be used without GBM, so if GBM is
not available (or too old), the build would fail.
Make sure we do not use the present code without GBM support.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The Wayland library may log warnings, we do not need to make that fatal
to the Xserver.
By killing the Xserver whenever a warning is raised, we hide other log
messages that might be also interesting.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Whenever the linux-dmabuf v4 feedback changes, we need to recreate the
existing buffers so they use the current linux-dmabuf v4 feedback.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When creating the window buffer's backing pixmap, try the Xwayland
glamor hook first and fallback to the regular CreatePixmap() code path
otherwise.
That allows to enable direct scanout if possible, either through the
regular dmabuf v4 code path, or from the implicit fallback code path.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Before linux_dmabuf v4 support was added, the BO were created using
gbm_bo_create_with_modifiers() which incidentally creates scanout
capable buffers.
We now need to replicate that explicitly when using the fallback path,
with buffers window, otherwise direct scanout will not be possible in
that case.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1535
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add the implementation for create_pixmap_for_window() in the GBM glamor
backend.
To do so, we just rename the existing xwl_glamor_gbm_create_pixmap() as
internal and add an optional drawable parameter, so that it can be used
either from the regular CreatePixmap code path, or from the new direct
Xwayland glamor's hook.
v2: Fallback to xwl_glamor_get_modifiers() if
xwl_glamor_get_drawable_modifiers() returned 0 modifiers. (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With linux dmabuf v4 support, for direct scanout support, we need more
context that just what CreatePixmap() provides, as we need the actual
drawable to invoke xwl_glamor_get_drawable_modifiers().
Add a specific hook in Xwayland's glamor implementation that we can use
for that purpose.
This is preparation work for the direct scanout fixes.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With implicit modifiers, DRM_FORMAT_MOD_INVALID is an allowed modifier,
to indicate that the server can support the format.
When looking for a scanout capable tranche with implicit modifiers, we
ought to check for the availability of a tranche with an invalid
modifier for the given format.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The helper function xwl_feedback_is_modifier_supported() walks all the
formats of a feeedback tranche and checks for format/modifier support
availability.
Add scanout support to that so that a caller can easily restrict the
tranches to those which support scanout.
This is preparation work for the implicit scanout support, no functional
change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Separate the callbacks for the default's feedback from the one for
regular windows.
This is preparation work to recreate the window buffer of feedback
updates, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
It could happen with the following call path:
frame_callback
xwl_present_frame_callback
xwl_present_msc_bump
xwl_present_execute
xwl_present_flip
xwl_window_create_frame_callback
The nested loop called xwl_present_reset_timer, which may end up calling
xorg_list_del for the entry after the one frame_callback started the
chain for. This resulted in the outer loop never terminating, because
its next element wasn't hooked up to the list anymore.
We avoid this by calling xwl_present_reset_timer as needed in
frame_callback, and bailing from xwl_window_create_frame_callback if it
was called from the former.
We also catch nested calls and FatalError if they ever happen again due
to another bug.
v2:
* Leave xwl_present_reset_timer call in xwl_present_frame_callback,
needed if xwl_present_msc_bump didn't hook up the window to the frame
callback list again.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442
Commit 3c07a01c4 (xwayland: Use xdg-output name for XRandR) changed the
logic to use a fixed sized buffer allocated on the stack to pass to
RROutputCreate() which would then copy it.
Valgrind complains about this:
== Conditional jump or move depends on uninitialised value(s)
== at 0x49954B: MakeAtom (atom.c:87)
== by 0x5108B3: RRMonitorCrtcName (rrmonitor.c:33)
== by 0x510BBB: RRMonitorSetFromServer (rrmonitor.c:92)
== by 0x511882: RRMonitorMakeList (rrmonitor.c:373)
== by 0x512175: ProcRRGetMonitors (rrmonitor.c:634)
== by 0x508091: ProcRRDispatch (randr.c:748)
== by 0x4A860E: Dispatch (dispatch.c:546)
== by 0x4B692F: dix_main (main.c:271)
== by 0x431C90: main (stubmain.c:34)
== Uninitialised value was created by a stack allocation
== at 0x42122C: xwl_output_create (xwayland-output.c:816)
This is actually harmless, but also simple to avoid by just initializing
the content of the array with zeros, so let's just fix that.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: commit 3c07a01c4 - xwayland: Use xdg-output name for XRandR
If we allocated with implicit modifiers, then we shouldn't use the
modifier returned by gbm_bo when checking whether the modifier is
supported or not, since it won't be if the compositor only advertises
implicit modifiers, nor should we use the modifier when creating the
Wayland buffer object, as it wasn't explicitly advertised.
Fixes: c6f2598a4 ("xwayland: don't fall back to wl_drm with explicit modifier")
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
If we're using implicit modifiers, we'll pass NULL and zero modifiers.
Lets just use the legacy API directly instead.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The linux_dmabuf_v1 protocol doesn't guarantee any DRM node type:
the compositor may send a primary node or a render node. Use
drmDevice so that device comparisons are node-type-insensitive.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1447
With wl_pointer.axis_v120 support, the wl_seat supported version has
been bumped to 8, but Xwayland is still using MAP_SHARED which is
prohibited, wl_seat version 7 and above enforces the use of MAP_PRIVATE
for keymaps.
Use MAP_PRIVATE for the keymaps mmap().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1512
Fixes: 3a02f56b4 - hook up wl_pointer.axis_v120 events
It's incorrect to strip an explicit modifier. Daniels' docs [1]
states:
> when importing a buffer, the user may supply `DRM_FORMAT_MOD_INVALID` as the
> buffer modifier (or not supply a modifier) to indicate that the modifier is
> unknown for whatever reason; this is only acceptable when the buffer has
> not been allocated with an explicit modifier
[1]: https://lore.kernel.org/dri-devel/20210905122742.86029-1-daniels@collabora.com/
Signed-off-by: Simon Ser <contact@emersion.fr>
When the modifier is not supported by the compositor, and the
DMA-BUF contains multiple planes, xwl_pixmap->buffer is NULL.
Avoid crashing when calling wl_buffer_add_listener().
Signed-off-by: Simon Ser <contact@emersion.fr>
With the addition of linux_dmabuf v4, the code adds dev_t in various
places but did not include <sys/types.h>.
While that works on glibc, it may fail to build on other libc
implementations such as musl libc.
Make sure to explicitly include <sys/types.h> where we use dev_t.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1445
Fixes: bddfe190de - Implement linux_dmabuf_feedback event handlers
When using TearFree, DRI clients have no way of accurately knowing when
their copied pixmaps appear on the display without utilizing the kernel
driver's notification indicating that the TearFree flip containing their
pixmap is complete. This is because the target CRTC's MSC can change while
the predicted completion MSC is calculated and even while the page flip
IOCTL is sent to the kernel due to scheduling delays and/or unfortunate
timing. Even worse, a page flip isn't actually guaranteed to be finished
after one vblank; it may be several MSCs until a flip actually finishes
depending on delays and load in hardware.
As a result, DRI clients may be off by one or more MSCs when they naively
expect their pixmaps to be visible at MSC+1 with TearFree enabled. This,
for example, makes it impossible for DRI clients to achieve precise A/V
synchronization when TearFree is enabled.
This change therefore adds a way for DRI clients to receive a notification
straight from the TearFree flip-done handler to know exactly when their
pixmaps appear on the display. This is done by checking for a NULL pixmap
pointer to modesetting's DRI flip routine, which indicates that the DRI
client has copied its pixmap and wants TearFree to send a notification when
the copied pixmap appears on the display as part of a TearFree flip. The
existing PageFlip scaffolding is reused to achieve this with minimal churn.
The Present extension will be updated in an upcoming change to utilize this
new mechanism for DRI clients' presentations.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
It is possible for vblank events to run out of order with respect to one
another because the event which was queued to the kernel has the privilege
of running before all other events are handled. This allows kernel-queued
events to run before other, older events which should've run first.
Although this isn't a huge problem now, it will become more problematic
after the next change which ties DRI client notifications to TearFree page
flips. This increases the likelihood of DRI clients erroneously receiving
presentation-completion notifications out of order; i.e., a client could
receive a notification for a newer pixmap it submitted *before* receiving a
notification for an older pixmap.
Ensure vblank events always run in sequential order by removing the bias
towards kernel-queued events, and therefore forcing them to run at their
sequential position in the queue like other events.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
There is more than one place with the confusing TearFree state check for a
CRTC. Instead of open-coding the TearFree check everywhere, introduce a
helper, ms_tearfree_is_active_on_crtc, to cover the TearFree state checks.
Suggested-by: Martin Roukala <martin.roukala@mupuf.org>
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Check that the VT is owned and that the CRTC is on before exporting info to
Present stating that TearFree is available. Also, since `trf->buf[0].px` is
checked, the `ms->drmmode.tearfree_enable` check is redundant and can
therefore be removed.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The event allocation for ms_do_pageflip is leaked on error because callers
of ms_do_pageflip have no way of knowing whether or not a page flip
succeeded for any CRTCs. If a page flip succeeded for at least one CRTC,
then it's not safe for the caller to free the event allocation, and the
allocation won't be leaked. The event allocation is only leaked when not a
single CRTC's page flip succeeded.
Since all callers of ms_do_pageflip allocate the event pointer, and all of
them intentionally leak the event allocation when ms_do_pageflip returns an
error, just free the event pointer inside ms_do_pageflip when a page flip
doesn't succeed for any CRTC.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The CRTC pointer will soon be needed in the TearFree flip handlers, so pass
it in instead of passing in drmmode_tearfree_ptr.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Rather than passing the reference CRTC's vblank pipe to ms_do_pageflip,
just pass the pointer to the reference CRTC directly instead. This is
clearer and more useful than the vblank pipe, since the vblank pipe is only
used to identify whether or not a given CRTC is the reference CRTC.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This #ifdef is redundant since ms_do_pageflip is already enclosed within a
larger GLAMOR_HAS_GBM #ifdef.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This moves lnx_platform.c to the shared directory and adds it to
the BSD build. This is needed for PRIME render offload.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This allows developers to setup Xwayland as a subproject of a
Wayland compositor, and have it correctly pick up the features
advertised in the dependency variables.
Signed-off-by: Simon Ser <contact@emersion.fr>
Remove the xwayland.pc.in file:
- This avoids writing down each pkg-config variable twice: once in
the Meson files to set the configuration data, once in the .pc.in
file to print it.
- We'll be able to re-use the same variables for use as a
subproject.
Signed-off-by: Simon Ser <contact@emersion.fr>
If wl_output provides us with an output name, use that as well.
If we have both xdg_output.name and wl_output.name (from version >= 4),
prefer the latter.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>#
See-also: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/189
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With the wl_output protocol, the actual bind to the interface is done in
xwl_output_create().
Pass the version number from the registry so we can bind to the minimum
version.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, Xwayland assigns sequential output names for XRandR. When an
output is hotplugged, a new name is assigned sequentially (XWAYLAND0,
XWAYLAND1, etc.). This is a problem because if a monitor is unplugged
and plugged again, it will get a new name each time.
Luckily, xdg-output provides us with a name for the outputs.
Even though the protocol states that the name is not a reflection of the
underlying DRM connector name, it is to remain consistent across
sessions with the same hardware and software configuration.
So we could use the xdg-output name for the XRandR reported name for the
output.
Doing so is a bit tricky though, because the output name is set at
creation and is not supposed to change. The xdg-output event that
provides us with the name will come at a later time.
So we just allocate a default fixed size for the output name at creation
and just replace the default output name with the xdg-output name when
that is known.
Also, historically, some X11 clients were expecting output names in
Xwayland to be named XWAYLAND<x> and used that to check whether they
were running on Xwayland. Those clients should now use the Xwayland X11
extension which is designed specifically for that purpose.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1353
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/954
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Since commit 204f10c2, we notify XRandR clients that the randr
configuration has changes as soon as an new output is created.
Yet, this might be premature, considering that at that point, we are
still to receive the wl_output and xdg-output events that will most
likely change the setup.
So instead of calling RRTellChanged() from xwl_output_create(), wait
until we get to call apply_output_change(), which occurs after the done
events from both xdg-output and wl_output are received.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Some drivers (e.g. AMD GFX8-) don't support explicit format
modifiers. On these drivers, gbm_bo_create_with_modifiers()
will fail. This results in "Error getting buffer" in the logs
later on with all X11 windows staying invisible.
Fallback to the modifier-less API gbm_bo_create() in that case.
Signed-off-by: Simon Ser <contact@emersion.fr>
The window might be retained in the damage list after
`xwl_screen_post_damage` in certain conditions. This means we need to
check if the window is already in the list to avoid adding the same
window twice which will lead to list corruption resulting in server freeze
in `xwl_screen_post_damage`.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
With Wayland 1.21 being our baseline, we do not need to compile
wl_pointer.axis_v120 conditionally.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
With libdecor, when the state changes (in the configure handler), we
need to commit the libdecor frame but also the wl_surface, otherwise
the surface is left in a uncommitted state until a wl_surface commit
eventually occurs later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: c74c6add3e - xwayland: add optional support for libdecor
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If the dmabuf protocol's feedback object gave us a new list of
modifiers, send PresentCompleteModeSuboptimalCopy to the client
to inform them that they need to call GetSupportedModifiers.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This adds to xwl_glamor_is_modifier_supported, where if feedback
is in use we will check that the format/mod is allowed in any
device advertised by the compositor.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Move dev_formats declaration to where it's used in
xwl_feedback_is_modifier_supported
* Add curly braces around multi-line statement in
xwl_glamor_is_modifier_supported ]
If protocol version 4 of linux_dmabuf is in use, then the compositor
may not return anything with the modifiers event. We instead
will return the formats/mods reported for the main device.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Move main_dev declaration to where it's used in
xwl_glamor_get_formats
* Add empty line between variable declaration and comment ]
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Sort protocol #includes lexically.
* memcpy to &xwl_feedback->main_dev directly in
xwl_dmabuf_feedback_main_device. ]
This creates xwl_add_format_and_mod_to_list, which is a helper
that adds a format/mod combo to a xwl_format* list. This will
be used by both the modifier event handling and the tranche
format handling.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
There are systems where softpipe is the default renderer,
e.g. when llvmpipe is not is not available. Using glamor
on such systems is never a good idea.
This mirrors what commit 0a9415cf79
did for llvmpipe.
Closes: #1417
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
For details on the protocol itself see the Wayland merge request:
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
The v120 event has a value base of 120, so one wheel detent is 120, half a
wheel is 60, etc. This is the API Windows has been using since Vista but it
requires HW support from the device. Logitech mice and many Microsoft mice of
the last decade or so have support and it's enabled in the kernel since v5.0.
The new events replace wl_pointer.axis_discrete events, once you bind to
wl_pointer >= 8 you only get the v120 events. So backwards compatibility
is simple, we just multiply the discrete events if we get them and
treat everything as 120 event internally.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leasable displays do not have any actual associated Wayland output and
are not available to regular X11 clients and left entirely to the
application who requests the lease.
As these are not actually managed by the Wayland compositor and left
entirely to the "lessee" application, the viewporter protocol required
for the XRandR emulation is not usable on such devices.
We should therefore not advertise the XRandR emulated modes for those
leasable displays.
This also solves a problem with implementations of glXGetMscRateOML()
which is used notably by Chromium/Electron. Applications using this
which will begin lagging/stuttering exponentially over
time, trying to look up a non-existent mode with 0x0 as returned by
XF86VidModeGetModeLine() with XRandR emulation for such devices.
See-also: https://github.com/labwc/labwc/issues/553
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Make sure info->active and info->vt_active are false after
dropping drm master.
Normally, this is done when pausing the first input device, so it
breaks when there are no input device at all.
Fixes: da9d012a9 ("xf86/logind: Fix drm_drop_master before vt_reldisp")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1387
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
The X server swapping code is a huge attack surface, much of this code
is untested and prone to security issues. The use-case of byte-swapped
clients is very niche, so let's disable this by default and allow it
only when the respective config option or commandline flag is given.
For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "on".
For all DDX, this adds the commandline options +byteswappedclients and
-byteswappedclients to enable or disable, respectively.
Fixes#1201https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 5145742fb6 accidentally bumped the videodrv ABI version from 26.0
to 26.6 in one go.
Change it back to 26.1 as per the documented process for minor additions.
Fixes: 5145742fb6 - randr: introduce rrCrtcGetInfo DDX function
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This fixes an issue with GLFW-based games failing to set the resolution
when the user request to switch back to the native display mode.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo
reply. One use case is to allow Xwayland to return the current emulated
mode for the specific client instead of the global mode.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Implements the xwayland_shell protocol which makes the surface
association happen via a shared serial, rather than sharing a wl_surface
resource ID across an X atom.
This solves a race that can happen if the wl_surface
associated with a WL_SURFACE_ID for a window was destroyed before the
update of the atom was processed by the compositor and another surface
(or other object) had taken its id due to recycling.
Closes: #1157
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
If atomic modesetting is to be enabled in the configuration file, log
whether this is supported and eventually enabled or disabled.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The modesetting driver has atomic modesetting disabled by default but
can be enabled (if supported) using a configuration option.
Add this option in the man page.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This adds support for TearFree page flips to eliminate tearing without the
use of a compositor. It allocates two shadow buffers for each CRTC, a back
buffer and a front buffer, and uses damage tracking to minimize excessive
copying between buffers and skip unnecessary flips when the screen's
contents remain unchanged. It works on transformed screens too, such as
rotated and scaled CRTCs.
When PageFlip is enabled, TearFree won't force fullscreen DRI clients to
synchronize their page flips to the vblank interval.
TearFree is disabled by default.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
The DRM event queue in the kernel is quite small and can be easily
exhausted by DRI clients. When the event queue is full, that means nothing
can be queued onto it anymore, which can lead to incorrect presentation
times for DRI clients and failure when attempting to queue a page flip.
To make matters worse, once an event is placed onto the kernel's event
queue, there's no straightforward way to prematurely remove it from the
kernel's event queue in userspace, which means that aborting a sequence
number doesn't free up space in the event queue.
Since vblank events from DRI clients are the largest consumers of the
event queue, and since it's often easy to know the desired target MSC of
their vblank events without querying the kernel for a CRTC's current MSC,
we can coalesce vblank events occurring at the same MSC such that only one
of them is placed onto the kernel's event queue, instead of allowing
duplicate vblank events to pollute the event queue.
This is achieved by tracking the next kernel-queued event's MSC on a
per-CRTC basis and then running all of that CRTC's vblank event handlers
which have reached their target MSC when the queued MSC is signaled.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
do_queue_flip_on_crtc() is about to be used to flip buffers other than the
primary scanout (`ms->drmmode.fb_id`), so make it generic to accept any
frame buffer ID, as well as x and y coordinates in the frame buffer, to
flip on a given CRTC. Move the retry logic from queue_flip_on_crtc() into
it as well, so that it's robust for all callers.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Shadow buffers are about to be used for TearFree, so make the shadow buffer
helpers generic such that they can be used to create arbitrary per-CRTC
shadows aside from just the per-CRTC rotated buffer.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
xf86RotateCrtcRedisplay() is about to be used outside of xf86Rotate.c in
order to copy transformed pixmaps, so fix up its interface by specifying
the source drawable and destination pixmap rather than assuming the root
drawable and rotated pixmap, respectively. In addition, add an argument to
make xf86RotateCrtcRedisplay() not perform any transformations, which is an
indicator that it should only copy a transformed pixmap rather than
actually transform a pixmap.
These changes make it possible to use xf86RotateCrtcRedisplay() to not
only copy transformed pixmaps, but also actually transform pixmaps, making
it very useful outside of xf86Rotate.c.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Updated the for-loop that iterates over the received EGLConfigs to
include the very first EGLConfig with index 0.
Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Fixes: 8469241592 - xwayland: Add EGL-backed GLX provider
The virgl driver exposes the name of the host renderer which might be llvmpipe.
In this case we still need glamor to be initialized.
Only check if the renderer starts with llvmpipe (which is what llvmpipe exposes).
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The current X server infrastructure sets modesetting driver as default driver
to handle PCI-hotplug of a GPU device. This prevents the respective DDX driver
(like AMDGPU DDX driver) to take control of the card.
This patch:
- Adds a few functions and fine-tunes the GPU hotplug infrastructure to allow
the DDX driver to be loaded, if it is configured in the X config file
options as "hotplug-driver".
- Scans and updates the PCI device list before adding the new GPU device
in platform, so that the association of the platform device and PCI device
is in place (dev->pdev).
- Adds documentation of this new option
An example usage in the config file would look like:
Section "OutputClass"
Identifier "AMDgpu"
MatchDriver "amdgpu"
Driver "amdgpu"
HotplugDriver "amdgpu"
EndSection
V2:
Fixed typo in commit message (Martin)
Added R-B from Adam.
Added ACK from Alex and Martin.
V3:
Added an output class based approach for finding the DDX driver (Aaron)
Rebase
V4:
Addressed review comment from Aaron:
GPU hot-plug handling driver's name to be read from the DDX config file options.
In this way only the DDX drivers interested in handling GPU hot-plug will be
picked and loaded, for others modesetting driver will be used as usual.
V5:
Addressed review comments from Aaron:
- X config option to be listed in CamelCase.
- Indentation fix at one place.
- Code readability related optimization.
V6:
Addressed review comments from Aaron:
- Squash the doc in the same patch
- Doc formatting changes
Cc: Alex Deucher <alexander.deucher@amd.com>
Suggested-by: Aaron Plattner aplattner@nvidia.com (v3)
Acked-by: Martin Roukala martin.roukala@mupuf.org(v1)
Acked-by: Alex Deucher alexander.deucher@amd.com (v1)
Reviewed-by: Adam Jackson ajax@redhat.com(v1)
Signed-off-by: Shashank Sharma shashank.sharma@amd.com
Current error:
ld: error: undefined symbol: xf86EnableIO
>>> referenced by xf86Configure.c
>>> libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Events.c
>>> libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Init.c
>>> libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a
>>> referenced 1 more times
Commit 8a5f3ddb2 ("set tag on our surface") introduced the use of tags
to differentiate our own surfaces, and commit a1d14aa8c ("Clear the
"xwl-window" tag on unrealize") removed the tags before the surfaces are
actually destroyed.
Xwayland would then rely on these tags on the surface to decide whether
to ignore or to process the Wayland event in various places.
However, in doing so, it also checked for the tag on keyboard leave
events.
As a result, if the keyboard leave events is received after the X11
window is unrealized, keyboard_handle_leave() would not queue the
LeaveNotify events for the DIX to proceed, and the key repeat would
kick in and repeat the key event indefinitely.
To avoid the issue, process events regardless of the tag as before
in keyboard_handle_leave().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 8a5f3ddb2 - "xwayland: set tag on our surface"
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1395
Tested-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Multiplanar GBM buffers can point to different objects from each plane.
Use the _for_plane API when possible to retrieve the correct prime FD
for each plane.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Simon Ser <contact@emersion.fr>
Tested-by: Guido Günther <agx@sigxcpu.org>
Check the fd for validity before giving a success return code.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Simon Ser <contact@emersion.fr>
Tested-by: Guido Günther <agx@sigxcpu.org>
Now that we keep the Wayland surface around for longer than the
xwl_window, we might get events for that surface after the X11 window
is unrealized.
Make sure we untag the Wayland surface when the Wayland surface is
delayed, to break the wl_surface/xwl_window relationship, so that events
for that surface are discarded by Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: e37f18ee9 - xwayland: Delay wl_surface destruction
a77d95af61 intended to do this, but the
check for “is this rootless or rootful XWayland” was inverted.
Fixes: a77d95af61 ("xwayland: Prevent Xserver grabs with rootless")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
hw/xwayland/xwayland.c:306:10: fatal error: 'X11/extensions/xwaylandproto.h' file not found
#include <X11/extensions/xwaylandproto.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 2700bc6045 ("xwayland: add support for the XWAYLAND extension")
X11 and Wayland requests are unordered, causing a race in the X11 window
and wl_surface association.
To mitigate that race, delay the wl_surface destruction by 1 second,
so that the compositor has time to establish the association before the
wl_surface is destroyed: to see both the wl_surface created and the
WL_SURFACE_ID X11 property set.
This is only a mitigation though, a more robust solution requires a
future dedicated Wayland protocol.
v2: Clean up pending wl_surface destroy on exit as well.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1157
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Joshua Ashton <joshua@froggi.es>
Tested-by: Sterophonick <sterophonick@gmail.com>
See-also: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/163
Changes check for trying modesetting driver from if defined(__linux__)
to use meson check for if we built the driver for this platform.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Because of the design of most Wayland compositors, where the compositor
is both a Wayland server and an X11 window manager, any X11 client
issuing a server grab (i.e. XGrabServer()) can possibly hang the whole
desktop when Xwayland is running rootless.
This can happen with e.g. ImageMagick's import command with mutter.
1. "import" is launched and issues an XServerGrab(),
2. Xwayland restricts access to that "import" X11 client alone,
3. mutter continues to process events until it needs to sync with
Xwayland (there's variability in time before the hang occurs),
4. When mutter does an XSync() (explicitly or implicitly through some
other Xlib call), it will stop waiting for Xwayland to reply,
5. Xwayland waits for the XServerGrab() to be released by import,
6. "import" waits for a user input to release the XServerGrab(),
7. mutter is stuck waiting on Xwayland and does not process input
events...
To prevent this, re-route the GrabServer/UngrabServer requests and
pretend the grab works but actually does nothing at all for all clients
but the X11 window manager (which can still issue X11 server grabs, at
its own risks).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://bugzilla.redhat.com/1914021
I wanted to simplify the logic, and thought this is a good opportunity
to eliminate local diffs.
I don't want to list OSes without wsfb, because I understand that is a
netbsd/openbsd driver, and always have it as a fallback for us.
Additionally, I understand "fbdev" is linux-specific, so have the logic
match this intent.
Fixes accidentally taking the WL_POINTER_AXIS_HORIZONTAL_SCROLL case as
well after the WL_POINTER_AXIS_VERTICAL_SCROLL case, which resulted in
vertical wheel events triggering both vertical and horizontal scrolling.
Fixes: e37eeb7af2 ("xwayland: Aggregate scroll axis events to fix kinetic scrolling")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1367
This extension exists to serve one purpose: reliably identifying
Xwayland. Previous attempts at doing so included querying root window
properties, output names or input device names. All these attempts are
somewhat unreliable. Instead, let's use an extension - where that
extension is present we have an Xwayland server.
Clients should never need to do anything but check whether the extension
exists through XQueryExtension or search through XListExtensions.
This extension provides a single QueryVersion request only, and
that is only to provide future compatibility if we ever need anything
other than "this extension exists" functionality.
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/54
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not that it actually matters since the typedef is int32_t anyway, but
this theoretically avoids an erroneous call to wl_fixed_to_double() on
that value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 7cdcdfea0 introduced a new command line option
"-force-xrandr-emulation", however it is missing from the
ddxProcessArgument().
As a result, trying to use that command option would result in a error:
(EE) Unrecognized option: -force-xrandr-emulation
Make sure "-force-xrandr-emulation" is accounted for in Xwayland's
ddxProcessArgument().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 7cdcdfea0 - xwayland: Add -force-xrandr-emulation switch
Pointer scroll events are collected in xwl_seat->pending_pointer_event
as they are received in the pointer_handle_axis and
pointer_handle_axis_discrete callbacks. They are dispatched together as a
single event when pointer_handle_frame is called which "Indicates the end of a
set of events that logically belong together" [1]. This patch also sends an
event with dx=0, dy=0 when pointer_handle_axis_stop is called, which is what
allows XWayland clients to recognise the end of a touchpad scroll.
[1] https://wayland.app/protocols/wayland#wl_pointer:event:frame
Signed-off-by: David Jacewicz <david.jacewicz27@protonmail.com>
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/926
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When running rootful, the Xwayland window is not decorated (as all
Wayland surfaces), which makes it quite inconvenient to move on screen.
libdecor is "a client-side decorations library for Wayland clients"
which can be used precisely for adding decorations to Wayland surfaces.
Add optional support for libdecor in Xwayland to gain decorations when
running rootful and a new command line option "-decorate".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1332
That allows to differentiate Xwayland's own surfaces from others.
This is preparation work for optional libdecor support.
v2: Check for surface not being NULL (Jonas Ådahl <jadahl@gmail.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The app_id is used to identify applications (and group windows), some
desktops (such as GNOME Shell) use it in their top bar.
Set the XDG toplevel "app_id" to "org.freedesktop.Xwayland" and install
a desktop file for Xwayland rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
So that when running rootful, the compositor can close the Xwayland
window using the xdg-toplevel protocol.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Set a meaningful title for the xdg_surface, it's nicer when running
rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Currently, when running rootful, the toplevel root surface is created in
the same function as the rest of the Wayland surfaces.
Move it to its own function to improve readability - No function change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a new command line option "-host-grab" to disable the keyboard
shortcuts and confine the pointer on the host so that Xwayland can
receive all keyboard events.
This is useful when running a complete desktop environment within
Xwayland rootful.
Use [CTRL]+[SHIFT] to release the keyboard and pointer.
This option is not compatible with rootless mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland tries to be smart and guess the intention of the X11 clients
sometimes, like issuing a pointer lock when a client hides the pointer
when confined.
While this is a good thing when running rootless, this is problematic
when running rootful as the pointer will be automatically locked unless
the "retro" mode is used (which doesn't hide the cursor, unlike the
default).
Make sure we don't trigger the automatic pointer lock when the cursor is
hidden when running rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a new command line option "-fullscreen" to make the rootful Xwayland
window appear fullscreen.
This requires viewport support in the compositor and when used with
"-geometry" can emulate the full range of XRandR resolutions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When updating the overall screen size, Xwayland would first walk the
window tree then update both the xwl_screen and screen size.
As a result, if any ResizeWindow() handler tries to use the xwl_screen
size, it would get the old (wrong) size instead of the new one.
Make sure to update the xwl_screen size first, prior to traverse the
window tree.
This is preparation work for Xwayland fullscreen mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When using xrandr emulation, the emulated mode is passed as a pointer to
the XRandR mode from the xwl_output associated with the X11 client.
In preparation for fullscreen mode, we want to be able to reuse that
code but use a separate emulated mode.
Simply change the internal API to pass a reference to the emulated mode.
This introduces no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The xdg_toplevel object was used solely when creating the window
surface, and the value of the object discarded.
To be able to make the surface fullscreen using the xdg_toplevel
protocol, we need to have access that object, so keep it around along
with the xwl_window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keep track of the output the surface enters/leaves.
This is fairly basic tracking though, we do not keep a full list of
outputs a surface may be covering partially, we just keep the output
the surface entered last.
This is sufficient as a preparation work for fullscreen though.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a convenient function to get the xwl_output from a given wl_output.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When running rootless as well as rootful, Xwayland gets its outputs
configuration from the Wayland compositor.
When running rootful, it means that we end up with a large black
surface the size of all monitors combined, that's not very convenient
and there is no way for set the desired size of the Xwayland window.
Add a new command line option "-geometry" to force a specific mode when
running rootful for the user to specify the root window size to use for
Xwayland.
That option has no effect when Xwayland is running rootless.
v2: Not using libxcvt as the mode may not be a valid CVT mode.
v3: Add a set of XRandR modes and the RR hooks to make that work.
Update the man page for Xwayland.
v4: Add RandR 1.0 support for older clients
v5: Fix XVidMode failing with a BadMatch
v6: Add a separate xwl_output specifically for fixed mode, instead of
using the existing output list - that will allow for further
improvements like a fullscreen mode eventually.
v7: Sort the RR modes
v8: Fix RandR 1.0
v9: Add physical size
v10: Cleanup
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1338
update_screen_size() takes an xwl_output argument, mostly for historical
reasons, whereas it actually applies to a screen (as its name implies).
Reshuffle the code to take an xwl_screen instead, in preparation for
the geometry mode in Xwayland - No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland uses an output serial number it increments each time a new
Wayland output is added.
On server regeneration, that static value is not cleared, and therfore
the output numbers keep increasing each time the Xserver restarts.
To avoid that issue, make the output serial part of the xwl_screen,
which gets recreated on server regeneration, so that index is reset to 0
automatically on server regeneration.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland's own SetWindowPixmap() handler would be ignored when running
rootful.
This is fine as long as we do not plan to resize the root window,
however this is becoming problematic if we plan to resize the root
window dynamically when running rootful.
Just add the xwl_window_set_window_pixmap() handler regardless of
rootful/rootless mode.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The function xwl_output_remove() is called when removing a monitor, but
the actual status of the RandR output does not change.
So, when RRTellChanged() is called from update_screen_size(), it won't
have the output connection status up to date in the RandR event
RROutputChangeNotifyEvent and X11 applications relying on that event
like Qt will fail to emit their signal QGuiApplication::screenRemoved.
To avoid that issue, make sure to mark the RandR output as disconnected
prior to call xwl_output_remove().
Fix commit 204f10c29 ("xwayland: Call RRTellChanged if the RandR configuration may have changed")
Signed-off-by: zhoulei <zhoulei@kylinos.cn>
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Move the xcb_aux_sync into the shm path, where we do still need it to
synchronize access with the host. In the non-shm path the image is
copied to the host anyway so the sync just adds latency and keeps you
from using all your network bandwidth.
Only the non-shm-putimage path benefits from this, but the benefit is
significant even on the local machine (here a 3.2GHz Core i7-8700, using
XEPHYR_NO_SHM=1):
before after Operation
------------ -------------------- -------------------------
228000000.0 225000000.0 (0.987) Dot
40900000.0 41600000.0 (1.017) 1x1 rectangle
10400000.0 10700000.0 (1.029) 10x10 rectangle
477000.0 471000.0 (0.987) 100x100 rectangle
30900.0 31800.0 (1.029) 500x500 rectangle
760000.0 981000.0 (1.291) PutImage 10x10 square
14700.0 19200.0 (1.306) PutImage 100x100 square
320.0 382.0 (1.194) PutImage 500x500 square
749000.0 984000.0 (1.314) ShmPutImage 10x10 square
268000.0 304000.0 (1.134) ShmPutImage 100x100 square
16600.0 18500.0 (1.114) ShmPutImage 500x500 square
Reviewed-by: Emma Anholt <emma@anholt.net>
When the pointer leaves an X11 window, and enters a Wayland native
window, Xwayland has no idea about Wayland native windows and may
generate the wrong crossing events to another X11 window instead.
To avoid that issue, Xwayland implements its own XYToWindow() handler to
compare the Wayland focused surface with the X11 window found in the
window tree.
Commit 59ad0e6a ("xwayland: Fix use after free of cursors") changed the
logic in sprite_check_lost_focus() to use IsParent() to compare the
windows, which works when the X11 window is reparented by the window
manager, but fails in the case of an override redirect window.
To fix the issue, also check whether last_xwindow is the window itself.
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Fixes: 59ad0e6a - xwayland: Fix use after free of cursors
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
../hw/xfree86/ddc/print_edid.c:511:20: error: format specifies type 'unsigned short' but the argument has type 'int' [-Werror,-Wformat]
det_mon->type - DS_VENDOR);
^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Adds a -force-xrandr-emulation cmdline switch that always exposes extra
modes when viewporter isn't exposed by the Wayland compositor.
Having the additional modes exposed by the X server is important for
games to function and be configured
Compositors, such as Gamescope (the compositor for Steam Deck),
support only a single window that is rendered in the centre of the
screen that is scaled up to fill the screen by the compositor based
on some user scaling settings.
Exposing viewporter, wouldn't make sense here, and could mislead native
Wayland clients, so exposing dummy modesets in X is preferred here.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Adds the following 16:10 modes primarily for scaling up on Steam Deck:
- 1152x720
- 960x600
- 928x580
- 800x500
- 768x480
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Xwayland does not change the actual XRANDR setup for real, it just
emulates the resolution changes using viewports in Wayland.
With a single output, if an X11 applications tries to change the CRTC
back to the native mode, RRCrtcSet() will simply ignore the request as
no actual change is induced by this.
Set the property "RANDR Emulation" on all Xwayland outputs to make sure
the optimizations in RRCrtcSet() get skipped and Xwayland can receive
and act upon the client request.
Also make sure we do not allow that property to be changed by X11
clients.
v2: Prevent X11 clients from changing the property value
(Pekka Paalanen <pekka.paalanen@collabora.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1305
drm_lease_device_handle_released uses the wrong pointer type in the
callback. This will cause crash when compositor removes drm lease device
object.
Fixes: 089e7f98f - Xwayland: implement drm-lease-v1
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Weng Xuetian <wengxt@gmail.com>
Finishes the work started in commit cd0d4c1bb5
to remove checks for the variable that never varied from 0 after the code
to change it was removed by commit 511c60bc73
in 2006 (xorg-server-1.2.0).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Fixes LGTM warnings:
* Import of 'cProfile' is not used.
* Import of 'pdb' is not used.
* Import of 'string' is not used.
* Import of 'time' is not used.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Fixes LGTM warning "This parameter of type drmModeModeInfo is 68 bytes -
consider passing a const pointer/reference instead."
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Correctness is ensured be checking md5sum result before and after the
commit (it's the same).
Fixes LGTM warning "Comparison is always false because numTimings <= 0."
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Makes the 4-byte cases match those for 1- & 2-byte handling,
moving the break from being unconditionally hit the first time
through the to loop to after the loop is done.
Fixes Solaris Studio compiler warnings:
"prim_ops.c", line 2626: warning: end-of-loop code not reached
"prim_ops.c", line 2692: warning: end-of-loop code not reached
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
switch_to() is only used from #ifdef HAS_USL_VTS code, place it inside
ifdefs to to avoid unused static warning and compile error on systems
without VT_ACTIVATE and VT_WAITACTIVE defines.
Even if there's no pending frame callback yet.
Without this, if there was no pending frame callback yet in
xwl_present_queue_vblank, xwl_present_msc_bump would only get called
from xwl_present_timer_callback, resulting in the MSC ticking at ~58
Hertz.
Doing this requires some adjustments elsewhere:
1. xwl_present_reset_timer needs to check for a pending frame callback
as well.
2. xwl_window_create_frame_callback needs to call
xwl_present_reset_timer for all child windows hooked up to
frame_callback_list, to make sure the timer length takes the pending
frame callback into account.
3. xwl_present_flip needs to hook up the window to frame_callback_list
before calling xwl_window_create_frame_callback, for 2. to work.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1309
Fixes: 9b31358c52 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Without this, xwl_present_reset_timer would call
xwl_present_timer_callback if the timer was originally armed over a
second ago. xwl_present_timer_callback would call xwl_present_msc_bump,
which could end up hooking up the window to
xwl_window->frame_callback_list again. This would lead to use-after-free
in xwl_present_cleanup:
Invalid write of size 8
at 0x42B65C: __xorg_list_del (list.h:183)
by 0x42B693: xorg_list_del (list.h:204)
by 0x42C041: xwl_present_cleanup (xwayland-present.c:354)
by 0x423669: xwl_destroy_window (xwayland-window.c:770)
by 0x4FDDC5: compDestroyWindow (compwindow.c:620)
by 0x5233FB: damageDestroyWindow (damage.c:1590)
by 0x501C5F: DbeDestroyWindow (dbe.c:1326)
by 0x4EF35B: FreeWindowResources (window.c:1018)
by 0x4EF687: DeleteWindow (window.c:1086)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Address 0x12f44980 is 144 bytes inside a block of size 160 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x423115: xwl_unrealize_window (xwayland-window.c:621)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
by 0x5E27EE: ClientReady (connection.c:599)
by 0x5E6CB7: ospoll_wait (ospoll.c:657)
by 0x5DE6CD: WaitForSomething (WaitFor.c:208)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x4229CE: ensure_surface_for_window (xwayland-window.c:439)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
by 0x4FCD1D: compRealizeWindow (compwindow.c:274)
by 0x4F36EC: RealizeTree (window.c:2606)
by 0x4F39F5: MapWindow (window.c:2683)
Fixes: 288ec0e046 ("xwayland/present: Run fallback timer callback after more than a second")
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
When a window is unrealized, Xwayland would destroy the Wayland surface
prior to unrealizing the present window.
xwl_present_flip() will then do a wl_surface_commit() of that surface,
hence causing a use-after-free:
Invalid read of size 8
at 0x49F7FD4: wl_proxy_marshal_array_flags (wayland-client.c:852)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x42B877: wl_surface_commit (wayland-client-protocol.h:3914)
by 0x42CAA7: xwl_present_flip (xwayland-present.c:717)
by 0x42CD0E: xwl_present_execute (xwayland-present.c:783)
by 0x42C26D: xwl_present_msc_bump (xwayland-present.c:416)
by 0x42C2D1: xwl_present_timer_callback (xwayland-present.c:433)
by 0x42BAC4: xwl_present_reset_timer (xwayland-present.c:149)
by 0x42D1F8: xwl_present_unrealize_window (xwayland-present.c:945)
by 0x4230E2: xwl_unrealize_window (xwayland-window.c:616)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
Address 0x1390b8d8 is 24 bytes inside a block of size 80 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x49F8029: wl_proxy_destroy_caller_locks (wayland-client.c:523)
by 0x49F8029: wl_proxy_marshal_array_flags (wayland-client.c:861)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x421984: wl_surface_destroy (wayland-client-protocol.h:3672)
by 0x423052: xwl_unrealize_window (xwayland-window.c:599)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x49F7F29: zalloc (wayland-private.h:233)
by 0x49F7F29: proxy_create (wayland-client.c:422)
by 0x49F7F29: create_outgoing_proxy (wayland-client.c:664)
by 0x49F7F29: wl_proxy_marshal_array_flags (wayland-client.c:831)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x4218CA: wl_compositor_create_surface (wayland-client-protocol.h:1291)
by 0x422A0D: ensure_surface_for_window (xwayland-window.c:445)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
To avoid that, call xwl_present_unrealize_window() before destroying the
Wayland surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The composite overlay window (COW) can be queried from any X11 client,
not just the X11 compositing manager.
If a client tries to get the composite overlay window, the Xserver will
map the window and block all pointer events (the window being mapped and
on top of the stack).
To avoid that issue, unset the "mapped" state of the composite overlay
window once realized when Xwayland is running rootless.
Note: All Xservers are actually affected by this issue, but with most
regular X servers, the compositing manager will take care of dealing
with the composite overlay window, and an X11 client using
GetOverlayWindow() won't break pointer events for all X11 clients.
Wayland compositors however usually run Xwayland rootless and have no
use for the COW.
v2: Avoid registering damage for the COW (Michel)
v3: Remove the "mapped" test to avoid calling register_damage() if the
COW is not mapped (Michel)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1314
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This fixes address sanitizer errors when running unit tests. The
additional copying may reduce performance by a small amount, but we
don't care about that because this driver is used for testing only.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
When using colored X11 cursors, the colors would appear wrong, yellow
would show white, green would show as cyan, and blue would show black
whereas red would show fine.
This is because the code expanding the cursor data accounts for green
for both green and blue channels. Funnily this bug has been there from
the beginning.
Fix the issue by correctly account for the color channels.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1303
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
After a change for the xserver to automatically determine the seat
based on the XDG_SEAT variable, xephyr stopped working. This was
because of an old feature where xephyr used to handle evdev
directly. This was dropped some time ago, and now this check is
not needed
Put in a workaround to accept devices of the kernel's hyperv_drm
driver. Makes Xorg work on HyperV Gen 1/2 with the DRM graphics
stack.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Xwayland may open a fair amount of file descriptors for passing Wayland
buffers, even more so when using the `wl_shm` either for the pointer
cursors or for when GLAMOR is not usable.
As a result, Xwayland may hit the (soft) limit of file descriptors
leading to a Wayland protocol error and the termination of Xwayland.
To mitigate that risk, raise the limit to the maximum (hard) limit of
file descriptors (unless of course the limit was set explicitly from the
command line with "-lf").
Note that for completeness, the Wayland compositor may have to do the
same, otherwise the limit might get reached on the compositor side as
well.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1283
If the Wayland compositor doesn't send a pending frame event, e.g.
because the Wayland surface isn't visible anywhere, it could happen that
the timer kept getting pushed back and never fired. This resulted in an
enormous list of pending vblank events, which could take minutes to
process when the frame event finally arrived.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1110
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman <jaapbuurman@gmail.com>
If there is one platform device, which is not paused nor resumed,
systemd_logind_vtenter() will never get called.
This break suspend/resume, and switching to VT on system with Nvidia
proprietary driver.
This is a regression introduced by f5bd039633
So now call systemd_logind_vtenter() if there are no paused
platform devices.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1271
Fixes: f5bd0396 - xf86/logind: fix call systemd_logind_vtenter after receiving drm device resume
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is minor, but that error message says a wrong function name.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Initially reported downstream in Gentoo. Manifests with errors like:
```
gnu/bin/ld: hw/xfree86/common/libxorg_common.a(xf86fbBus.c.o): in function `xf86ClaimFbSlot':
xf86fbBus.c:(.text+0x20): undefined reference to `sbusSlotClaimed'
/usr/lib/gcc/sparc-unknown-linux-gnu/11.2.0/../../../../sparc-unknown-linux-gnu/bin/ld: xf86fbBus.c:(.text+0x2c): undefined reference to `sbusSlotClaimed'
```
While we use the headers in meson.build, we don't reference xf86sbusBus.c
which defines the missing symbols like sbusSlotClaimed.
Bug: https://bugs.gentoo.org/828513
Signed-off-by: Sam James <sam@gentoo.org>
This commit allows X11 clients running through Xwayland to lease
non-desktop connectors from the Wayland compositor by implementing
support for drm-lease-v1.
In order to not deadlock with the Wayland compositor if its response
to a lease request is delayed, the new interface in _rrScrPriv
introduced in the last commit is used, which makes it possible to
block the X11 client while a response is pending.
Leasing normal outputs is not yet supported, all connectors offered
for lease will be advertised as non-desktop.
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add a new interface to _rrScrPriv to make it possible for the server to
delay answering a lease request, at the cost of blocking the client. This
is needed for implementing drm-lease-v1, as the Wayland protocol has no
defined time table for responding to lease requests.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
This was overlooked when converting the function to use libxcvt.
Bring back name initialization from old code.
This was causing a segfault in xf86LookupMode() if modes where
name is NULL are present the modePool list.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
The compositor may send us wl_seat and its capabilities before sending
e.g. relative_pointer_manager or pointer_gesture interfaces. This would
result in devices being created in capabilities handler, but listeners
not, because the interfaces weren't available at the time. So we
manually attempt to setup listeners again.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
The implementation is relatively straightforward because both wayland
and Xorg use libinput semantics for touchpad gestures.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Currently, when given the choice, Xwayland will pick the GBM backend
over the EGLstream backend if both are available, unless the command
line option “-eglstream” is specified.
The NVIDIA proprietary driver had no support for GBM until driver series
495, but starting with the driver series 495, both can be used.
But there are other requirements with the rest of the stack, typically
Mesa, egl-wayland, libglvnd as documented in the NVIDIA driver.
So if the NVIDIA driver series 495 gets installed, Xwayland will pick
the GBM backend even if EGLstream is available and may fail to render
properly.
To avoid that issue, prefer EGLstream if EGLstream and all the Wayland
interfaces are available, and fallback to GBM automatically unless
“-eglstream” was specified.
With this, the compositor, given the choice, can decide which actual
backend Xwayland would use by advertising (or not) the Wayland
"wl_eglstream_controller" interface.
This change has no impact on compositors which do not have support for
EGLstream in the first place.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add (verbose) statements to trace the actual backend used with glamor.
That can be useful for debugging.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
On a normal startup sequence, the Xwayland glamor backend would log
an error whenever a required Wayland protocol is missing.
Those are not really errors though, more informational messages along
the glamor backend selection process.
Demote those errors to verbose messages to reduce the verbosity of
Xwayland at startup by default.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If no EGLstream capable device is found at startup, Xwayland's EGLstream
backend will log an error message "glamor: No eglstream capable devices
found".
However, considering that the vast majority of drivers do not implement
EGLstream, the lack of EGLstream capable device is more of the norm than
the exception.
Change the error message to a log verbose message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
When switching to VT, the ioctl DRM_DROP_MASTER must be done before
the ioctl VT_RELDISP. Otherwise the kernel can't change the modesetting
reliably, and this leads to the console not showing up in some cases, like
after unplugging a docking station with a DP or HDMI monitor.
Before doing the VT_RELDISP, send a dbus message to logind, to
pause the drm device, so logind will do the ioctl DRM_DROP_MASTER.
With this patch, it changes the order logind will send the resume
event, and drm will be sent last instead of first.
so there is a also fix to call systemd_logind_vtenter() at the right time.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
logind send the resume event for input devices and drm device,
in any order. if we call vt_enter before logind resume the drm device,
it leads to a driver error, because logind has not done the
DRM_IOCTL_SET_MASTER on it.
Keep the old workaround to make sure we call systemd_logind_vtenter at
least once if there are no platform device
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Quite a lot of applications currently expect the screen DPI exposed by
the X server to be 96 even when the real display DPI is different.
Additionally, currently Xwayland completely ignores any hardware
information and sets the DPI to 96. Accordingly the new behavior, even
if it fixes a bug, should not be enabled automatically to all users.
A better solution would be to make the default DPI stay as is and enable
the correct behavior with a command line option (maybe -dpi auto, or
similar). For now let's just revert the bug fix.
This reverts commit 05b3c681ea.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
We were storing the pointer to struct glamor_context. However, glamor
itself is storing the EGLContext pointer since the commit below. Since
the two values could never be equal, this resulted in constant
superfluous eglMakeCurrent calls. The implicit glFlush triggered by
those couldn't be good for performance.
Fixes: 7c88977d33 "glamor: Store the actual EGL/GLX context pointer in lastGLContext"
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
The code to clear a cursor pending frame callback was duplicated in
multiple places in the code.
Introduce a new xwl_cursor_clear_frame_cb() function and remove the
duplicated code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
It just make more sense to keep xwl_cursor_release() with the rest of
the cursor code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Two different functions in xwayland-cursor.c and xwayland-input.c use
the same name xwl_seat_update_cursor() which is confusing when reading
the code.
Rename xwl_seat_update_cursor() to xwl_seat_update_all_cursors() in
xwayland-cursor.c to help with readability of the code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Passing -noTouchPointerEmulation results in an error about the
flag not being recognized.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7d34b1f2b7 ("xwayland: add -noTouchPointerEmulation")
If the tablet tool is moved out of proximity before the cursor's pending
frame callback is received, any further attempts to update the cursor
will fail because the frame callback is still pending.
Make sure to clear any cursor pending frame when the tool gets in
proximity again, similar to what we do when the pointer re-enters a
surface, so that the cursor updates aren't discarded.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/1969
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Some clients (typically Java, but maybe others) rely on ConfigureNotify
or RRScreenChangeNotify events to tell that the XRandR request is
successful.
When emulated XRandR is used in Xwayland, compute the emulated root size
and send the expected ConfigureNotify and RRScreenChangeNotify events
with the emulated size of the root window to the asking X11 client.
Note that the root window size does not actually change, as XRandR
emulation is achieved by scaling the client window using viewports in
Wayland, so this event is sort of misleading.
Also, because Xwayland is using viewports, emulating XRandR does not
reconfigure the outputs location, meaning that the actual size of the
root window which encompasses all the outputs together may not change
in a multi-monitor setup. To work around this limitation, when using an
emulated mode, we report the size of that emulated mode alone as the
root size for the configure notify event.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
SimpleDRM 'devices' are a fallback device, and do not have a busid
so they are getting skipped. This will allow simpledrm to work
with the modesetting driver
The "sync crtc" is the crtc used to drive the display timing of a
drawable under DRI2 and DRI3/Present. If a drawable intersects
multiple video outputs, then normally the crtc is chosen which has
the largest intersection area with the drawable.
If multiple outputs / crtc's have exacty the same intersection
area then the crtc chosen was simply the first one with maximum
intersection. Iow. the choice was random, depending on plugging
order of displays.
This adds the ability to choose a preferred output in such a tie
situation. The RandR output marked as "primary output" is chosen
on such a tie.
This new behaviour and its implementation is consistent with other
video ddx drivers. See amdgpu-ddx, ati-ddx and nouveau-ddx for
reference. This commit is a straightforward port from amdgpu-ddx.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
In a setup with both VRR capable and non-VRR capable displays,
it was so far inconsistent if the driver would allow use of
VRR support or not, as "is_connector_vrr_capable" was set to
whatever the capabilities of the last added drm output were.
Iow. the plugging order of monitors determined the outcome.
Fix this: Now if at least one display is VRR capable, the driver
will treat an X-Screen as capable for VRR, plugging order no
longer matters.
Tested with a dual-display setup with one VRR monitor and one
non-VRR monitor. This is also beneficial with the new Option
"AsyncFlipSecondaries".
When we are at it, also add some so far missing description of
the "VariableRefresh" driver option, copied from amdgpu-ddx.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
A lut size of 4096 slots has been verified to work correctly,
as tested with amdgpu-kms. Intel Tigerlake Gen12 hw has a very
large GAMMA_LUT size of 262145 slots, but also issues with its
current GAMMA_LUT implementation, as of Linux 5.14.
Therefore we keep GAMMA_LUT off for large lut's. This currently
excludes Intel Icelake, Tigerlake and later.
This can be overriden via the "UseGammaLUT" boolean xorg.conf option
to force use of GAMMA_LUT on or off.
See following link for the Tigerlake situation:
https://gitlab.freedesktop.org/drm/intel/-/issues/3916#note_1085315
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
With the GBM backend becoming usable with different drivers such as
NVIDIA, set the GLVND vendor to the same value as the GBM backend name.
Mesa implementation however returns "drm" so we need to special case
this value - Basically, for anything other than "drm" we simply assume
that the GBM backend name is the same as the vendor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: James Jones <jajones@nvidia.com>
Tested-by: James Jones <jajones@nvidia.com>
Xwayland was passing GBM bos directly to
eglCreateImageKHR using the EGL_NATIVE_PIXMAP_KHR
target. Given the EGL GBM platform spec claims it
is invalid to create a EGLSurface from a native
pixmap on the GBM platform, implying there is no
mapping between GBM objects and EGL's concept of
native pixmaps, this seems a bit questionable.
This change modifies the bo import function to
extract all the required data from the bo and then
imports it as a dma-buf instead when the dma-buf +
modifiers path is available.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Xwayland's xwl_shm_create_pixmap() computes the size of the shared
memory pool to create using a size_t, yet the Wayland protocol uses an
integer for that size.
If the pool size becomes larger than INT32_MAX, we end up asking Wayland
to create a shared memory pool of negative size which in turn will raise
a protocol error which terminates the Wayland connection, and therefore
Xwayland.
Avoid that issue early by return a NULL pixmap in that case, which will
trigger a BadAlloc error, but leave Xwayland alive.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This reverts commit 617f591fc4.
The problem described in that commit exists, but the two
preceeding commits with improvements to the servers RandR
code should avoid the mentioned problems while allowing the
use of GAMMA_LUT's instead of legacy gamma lut.
Use of legacy gamma lut's is not a good fix, because it will reduce
color output precision of gpu's with more than 1024 GAMMA_LUT
slots, e.g., AMD, ARM MALI and KOMEDA with 4096 slot luts,
and some Mediathek parts with 512 slot luts. On KOMEDA, legacy
lut's are completely unsupported by the kms driver, so gamma
correction gets disabled.
The situation is especially bad on Intel Icelake and later:
Use of legacy gamma tables will cause the kms driver to switch
to hardware legacy lut's with 256 slots, 8 bit wide, without
interpolation. This way color output precision is restricted to
8 bpc and any deep color / HDR output (10 bpc, fp16, fixed point 16)
becomes impossible. The latest Intel gen gpu's would have worse
color precision than parts which are more than 10 years old.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
The assumption in the upsampling code was that the crtc->gamma_size
size of the crtc's gamma table is a power of two. This is true for
almost all current driver + gpu combos at least on Linux, with typical
sizes of 256, 512, 1024 or 4096 slots.
However, Intel Gen-11 Icelake and later are outliers, as their gamma
table has 2^18 + 1 slots, very big and not a power of two!
Try to make upsampling behave at least reasonable: Replicate the
last gamma value to fill up remaining crtc->gamma_red/green/blue
slots, which would normally stay uninitialized. This is important,
because while the intel display driver does not actually use all
2^18+1 values passed as part of a GAMMA_LUT, it does need the
very last slot, which would not get initialized by the old code.
This should hopefully create reasonable behaviour with Icelake+
but is untested on the actual Intel hw due to lack of suitable
hw.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
If randrp->palette_size is zero, the memcpy() path can read past the
end of the randr_crtc's gammaRed/Green/Blue tables if the hw crtc's
gamma_size is greater than the randr_crtc's gammaSize.
Avoid this by clamping the to-be-copied size to the smaller of both
sizes.
Note that during regular server startup, the memcpy() path is only
taken initially twice, but then a suitable palette is created for
use during a session. Therefore during an actual running X-Session,
the xf86RandR12CrtcComputeGamma() will be used, which makes sure that
data is properly up- or down-sampled for mismatching source and
target crtc gamma sizes.
This should avoid reading past randr_crtc gamma memory for gpu's
with big crtc->gamma_size, e.g., AMD/MALI/KOMEDA 4096 slots, or
Intel Icelake and later with 262145 slots.
Tested against modesetting-ddx and amdgpu-ddx under screen color
depth 24 (8 bpc) and 30 (10 bpc) to make sure that clamping happens
properly.
This is an alternative fix for the one attempted in commit
617f591fc4.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
We turn this on if the GL underneath us can enable GL_FRAMEBUFFER_SRGB.
We do try to generate both capable and incapable configs, which is to
keep llvmpipe working until the client side gets smarter about its srgb
capabilities.
xwl_present_reset_timer checks if the pending flip is synchronous, so
we need to call it after adding the pending flip to the flip queue.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1219
Fixes: b2a06e0700 "xwayland/present: Drop sync_flip member of struct xwl_present_window"
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Rotation is broken for all drm drivers not providing hardware rotation
support. Drivers that give direct access to vram and not needing dirty
updates still work but only by accident. The problem is caused by
modesetting not sending the correct fb_id to drmModeDirtyFB() and
passing the damage rects in the rotated state and not as the crtc
expects them. This patch takes care of both problems.
Signed-off-by: Patrik Jakobsson <pjakobsson@suse.de>
This is not actually a change for xwayland with gbm, or for xfree86 with
big-GL, but we do change them as well to use EGL_NO_CONFIG_KHR
explicitly.
Reviewed-by: Emma Anholt <emma@anholt.net>
There's no real benefit to using GLX, and the other DDXes are using EGL
already, so let's converge on EGL so we can concentrate the fixes in one
place.
We go to some effort to avoid being the thing that requires libX11 here.
We prefer EGL_EXT_platform_xcb over _x11, and if forced to use the
latter we'll ask the dynamic linker for XGetXCBConnection and
XOpenDisplay rather than link against xlib stuff ourselves. Xephyr is
now a pure XCB application if it can be.
Reviewed-by: Emma Anholt <emma@anholt.net>
Due to a typo in tablet_pad_group(), we would allocate a variable
("group") and test another one ("pad") for allocation success.
Spotted by covscan.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: commit 8475e63 - "xwayland: add tablet pad support"
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
On screen init, if any of the private type registration fails we would
return FALSE without actually freeing the xwl_screen we just allocated.
This is not a serious leak as failure at that point would lead to the
premature termination of Xwayland at startup, but covscan complains and
it's easy enough to fix.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The Linux version of xf86EnableIO calls a helper function called hwEnableIO().
Except on Alpha, this function reads /proc/ioports looking for the 'keyboard'
and 'timer' ports, extracts the port ranges, and enables access to them. It does
this by reading 4 bytes from the string for the start port number and 4 bytes
for the last port number, passing those to atoi(). However, it doesn't add a
fifth byte for a NUL terminator, so some implementations of atoi() read past the
end of this string, triggering an AddressSanitizer error:
==1383==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff71fd5b74 at pc 0x7fe1be0de3e0 bp 0x7fff71fd5ae0 sp 0x7fff71fd5288
READ of size 5 at 0x7fff71fd5b74 thread T0
#0 0x7fe1be0de3df in __interceptor_atoi /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520
#1 0x564971adcc45 in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:138
#2 0x564971adce87 in xf86EnableIO ../hw/xfree86/os-support/linux/lnx_video.c:174
#3 0x5649719f6a30 in InitOutput ../hw/xfree86/common/xf86Init.c:439
#4 0x564971585924 in dix_main ../dix/main.c:190
#5 0x564971b6246e in main ../dix/stubmain.c:34
#6 0x7fe1bdab6b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#7 0x564971490e9d in _start (/home/aaron/git/x/xserver/build.asan/hw/xfree86/Xorg+0xb2e9d)
Address 0x7fff71fd5b74 is located in stack of thread T0 at offset 100 in frame
#0 0x564971adc96a in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:118
This frame has 3 object(s):
[32, 40) 'n' (line 120)
[64, 72) 'buf' (line 122)
[96, 100) 'target' (line 122) <== Memory access at offset 100 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520 in __interceptor_atoi
Shadow bytes around the buggy address:
0x10006e3f2b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006e3f2b60: 00 00 f1 f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2[04]f3
0x10006e3f2b70: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10006e3f2b90: f1 f1 f8 f2 00 f2 f2 f2 f8 f3 f3 f3 00 00 00 00
0x10006e3f2ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
0x10006e3f2bb0: f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==1383==ABORTING
Fix this by NUL-terminating the string.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1193#note_1053306
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
GAMMA_LUT sizes other than 1024 cause a crash during startup if the memcpy()
calls in xf86RandR12CrtcSetGamma() read past the end of the legacy X11 /
XVidMode gamma ramp.
This is a problem on Intel ICL / GEN11 platforms because they report a GAMMA_LUT
size of 262145. Since it's not clear that the modesetting driver will generate a
proper gamma ramp at that size even if xf86RandR12CrtcSetGamma() is fixed, just
disable use of GAMMA_LUT for sizes other than 1024 for now. This will cause the
modesetting driver to disable the CTM property and fall back to the legacy gamma
LUT.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1193
Tested-by: Mark Herbert
Whenever an unredirected fullscreen window uses pageflipping for a
DRI3/Present PresentPixmap() operation and the X-Screen has more than
one active output, multiple crtc's need to execute pageflips. Only
after the last flip has completed can the PresentPixmap operation
as a whole complete.
If a sync_flip is requested for the present, then the current
implementation will synchronize each pageflip to the vblank of
its associated crtc. This provides tear-free image presentation
across all outputs, but introduces a different artifact, if not
all outputs run at the same refresh rate with perfect synchrony:
The slowest output throttles the presentation rate, and present
completion is delayed to flip completion of the "latest" output
to complete. This means degraded performance, e.g., a dual-display
setup with a 144 Hz monitor and a 60 Hz monitor will always be
throttled to at most 60 fps. It also means non-constant present
rate if refresh cycles drift against each other, creating complex
"beat patterns", tremors, stutters and periodic slowdowns - quite
irritating!
Such a scenario will be especially annoying if one uses multiple
outputs in "mirror mode" aka "clone mode". One output will usually
be the "production output" with the highest quality and fastest
display attached, whereas a secondary mirror output just has a
cheaper display for monitoring attached. Users care about perfect
and perfectly timed tear-free presentation on the "production output",
but cares less about quality on the secondary "mirror output". They
are willing to trade quality on secondary outputs away in exchange
for better presentation timing on the "production output".
One example use case for such production + monitoring displays are
neuroscience / medical science applications where one high quality
display device is used to present visual animations to test subjects
or patients in a fMRI scanner room (production display), whereas
an operator monitors the same visual animations from a control room
on a lower quality display. Presentation timing needs to be perfect,
and animations high-speed and tear-free for the production display,
whereas quality and timing don't matter for the monitoring display.
This commit gives users the option to choose such a trade-off as
opt-in:
It adds a new boolean option "AsyncFlipSecondaries" to the device section
of xorg.conf. If this option is specified as true, then DRI3 pageflip
behaviour changes as follows:
1. The "reference crtc" for a windows PresentPixmap operation does a
vblank synced flip, or a DRM_MODE_PAGE_FLIP_ASYNC non-synchronized
flip, as requested by the caller, just as in the past. Typically
flips will be requested to be vblank synchronized for tear-free
presentation. The "reference crtc" is the one chosen by the caller
to drive presentation timing (as specified by PresentPixmap()'s
"target_msc", "divisor", "remainder" parameters and implemented by
vblank events) and to deliver Present completion timestamps (msc
and ust) extracted from its pageflip completion event.
2. All other crtc's, which also page-flip in a multi-display configuration,
will try to flip with DRM_MODE_PAGE_FLIP_ASYNC, ie. immediately and
not synchronized to vblank. This allows the PresentPixmap operation
to complete with little delay compared to a single-display present,
especially if the different crtc's run at different video refresh
rates or their refresh cycles are not perfectly synchronized, but
drift against each other. The downside is potential tearing artifacts
on all outputs apart from the one of the "reference crtc".
Successfully tested on a AMD gpu with single-display, dual-display and
triple-display setups, and with single-X-Screen as well as dual-X-Screen
"ZaphodHeads" configurations.
Please consider merging this commit for the upcoming server 1.21 branch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
It turns out xdmx currently crashes when any client attempts to use GL
and it has been in such state for about 14 years. There was a patch to
fix the problem [1] 4 years ago, but it never got merged. The last
activity on any bugs referring to xdmx has been more than 4 years ago.
Given such situation, I find it unlikely that anyone is still using xdmx
and just having the code is a drain of resources.
[1]: https://lists.x.org/archives/xorg-devel/2017-June/053919.html
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
When using DRI3+Present with PRIME render offload, sometimes there is
a mismatch between the stride of the to-be-presented Pixmap and the
frontbuffer. The current code would reject a pageflip present in this
case if atomic modesetting is not enabled, ie. always, as atomic
modesetting is disabled by default due to brokeness in the current
modesetting-ddx.
Fullscreen presents without page flipping however trigger the copy
path as fallback, which causes not only unreliable presentation timing
and degraded performance, but also massive tearing artifacts due to
rendering to the framebuffer without any hardware sync to vblank.
Tearing is extra awful on modesetting-ddx because glamor afaics seems
to use drawing of a textured triangle strip for the copy implementation,
not a dedicated blitter engine. The rasterization pattern creates extra
awful tearing artifacts.
We can do better: According to a tip from Michel Daenzer (thanks!),
at least atomic modesetting capable kms drivers should be able to
reliably change scanout stride during a pageflip, even if atomic
modesetting is not actually enabled for the modesetting client.
This commit adds detection logic to find out if the underlying kms
driver is atomic_modeset_capable, and if so, it no longer rejects
page flip presents on mismatched stride between new Pixmap and
frontbuffer.
We (ab)use a call to drmSetClientCap(ms->fd, DRM_CLIENT_CAP_ATOMIC, 0);
for this purpose. The call itself has no practical effect, as it
requests disabling atomic mode, although atomic mode is disabled by
default. However, the return value of drmSetClientCap() tells us if the
underlying kms driver is atomic modesetting capable: An atomic driver
will return 0 for success. A legacy non-atomic driver will return a
non-zero error code, either -EINVAL for early atomic Linux versions
4.0 - 4.19 (or for non-atomic Linux 3.x and earlier), or -EOPNOTSUPP
for Linux 4.20 and later.
Testing on a MacBookPro 2017 with Intel Kabylake display server gpu +
AMD Polaris11 as prime renderoffload gpu, X-Server master + Mesa 21.0.3
show improvement from unbearable tearing to perfect, despite a stride
mismatch between display gpu and Pixmap of 11776 Bytes vs. 11520
Bytes. That this is correct behaviour was also confirmed by comparing the
behaviour and .check_flip implementation of the patched modesetting-ddx
against the current intel-ddx SNA Present implementation.
Please consider merging this patch before the server-1.21 branch point.
This patch could also be cherry-picked into the server 1.20 branch to
fix the same limitation.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
In some scenarios, the Wayland compositor might have more knowledge
than the X11 server and may be able to perform pointer emulation for
touch events better. Add a command-line switch to allow compositors
to turn Xwayland pointer emulation off.
Signed-off-by: Simon Ser <contact@emersion.fr>
A misplaced error check can cause this failure scenario, and does
so reliably as tested on Ubuntu 21.04 with KDE Plasma 5 desktop
within the first few seconds of login session startup, rendering
VRR under modesetting-ddx unusable:
1. Some X11 client application changes some window property.
2. ms_change_property() is called as part of the property change
handling call chain (client->requestVector[X_ChangeProperty]).
It removes itself temporarily from the call chain - or so it
thinks, hooking up saved_change_property instead.
3. ret = saved_change_property(client) is called and fails
temporarily for some non-critical reason.
4. The misplaced error check returns early (error abort), without
first restoring ms_change_property() as initial X_ChangeProperty
handler in the call chain again.
-> Now ms_change_property() has removed itself permanently from the
property handler call chain for the remainder of the X session
and VRR property changes on windows are no longer handled, ie.
VRR no longer gets enabled/disabled in response to window VRR
property changes.
Place the error check at the proper place, just as it is correctly
done by amdgpu-ddx, and in modesetting-ddx ms_delete_property()
function.
Verified to fix VRR handling with an AMD gpu under KDE desktop
session.
Please consider merging before branching the server 1.21 branch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
The xf86CVTMode() was implemented in a standalone source file because it
was being used for both the xfree86 API and the standalone cvt utility.
Now that the cvt utility is removed (as part of libxcvt) we can move the
small xf86CVTMode() function with the rest of the xf86Modes sources.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The cvt utility is now replaced by the standalone version found in
libxcvt, no need to build the one in xfree86 anymore.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Replace the local implementation of the VESA CVT standard timing
modelines generator with the one from libxct to avoid code duplication.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Xwayland is using a copy of the CVT generator found in Xorg.
Rather than duplicating the code within the xserver tree, use the
libxcvt implementation instead.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
If there is an explicit configuration, assign the RandR provider
of the GPUDevice to the screen it was specified for.
If there is no configuration (default case) the screen number is
still 0 so it doesn't change behaviour.
The result is e.g:
# DISPLAY=:0.2 xrandr --listproviders
Providers: number : 2
Provider 0: id: 0xd2 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting
Provider 1: id: 0xfd cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 0 name:Intel
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
We are handling two cases here: the active flip or the pending flip.
For the pending flip (event->pending == TRUE), we called
xwl_present_release_pixmap.
For the active flip (event->pending == FALSE), we called
xwl_present_release_event. However, xwl_present_flip_notify_vblank
already unhooked event->vblank.event_queue. So this was effectively the
same as calling xwl_present_release_pixmap.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Use present_vblank_rec::event_queue instead.
The changes in xwl_present_execute shouldn't really be needed, since
we should never hit queue_vblank in present_execute_wait. But let's be
safe rather than sorry, plus this simplifies the code.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Can just call xwl_present_execute directly.
This allows dropping the window member from struct xwl_present_window as
well.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We clear the vblank->pixmap field, so next time xwl_present_execute
falls through to present_execute_post.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This allows for various simplifications.
Use the pointer to the struct memory as the event ID. In contrast to
the SCMD code for Xorg (where pending DRM events cannot be cancelled),
this is safe here, because we can destroy pending Wayland callbacks. So
we can't get a callback with a stale pointer to freed memory.
Remove xwl_present_window::release_list in favour of
present_vblank_rec::window_list.
Remove xwl_present_event::xwl_present_window in favour of
present_vblank_rec::window.
xwl_present_free_event is never called for a NULL pointer anymore, no
need to check.
v2:
* Restore DestroyWindow wrapping order to make sure
present_destroy_window doesn't call xwl_present_abort_vblank.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We can call xwl_present_free_event unconditionally from
xwl_present_abort_vblank, since the sync_callback is already destroyed
in xwl_present_cleanup.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Olivier Fourdan
Simon Ser
Enrico Weigelt, metux IT consult
Erik Kurzinger
Michel Dänzer
Peter Hutterer
Yusuf Khan
Matthieu Herrb
Alan Coopersmith
Florian Weimer
José Expósito
Luke Dashjr
Dongwon Kim
Izumi Tsutsui
xurui
Chia-Lin Kao (AceLan)
Alexander Volkov
Twaik Yont
Thomas Zimmermann
Moritz Bruder
Sultan Alsawaf
Ville Syrjälä
Warren Togami
Konstantin Pugin
Adam Jackson
Pedro Montes Alcalde
John Kennedy
Austin Shafer
Peter Grehan
Gleb Popov
Niclas Zeising
Kenny Levinsen
Russell Chou
Xaver Hugl
Aaron Dill
Jessica Clarke
Tamura Dai
Jonas Ådahl
Austin Shafer
Minh Phan
Ivan A. Melnikov
Jeremy Huddleston Sequoia
Joshua Ashton
Jocelyn Falempe
John D Pell
Doğukan Korkmaztürk
Corentin Noël
Shashank Sharma
pkubaj
Lucas Stach
Demi Marie Obenour
Jan Beich
coypu@sdf.org
David Jacewicz
zhoulei
Morose
Weng Xuetian
Konstantin Kharlamov
Brian Ruthven
Claes Nästén
Povilas Kanapickas
nerdopolis
Andrea Monaco
Sam James
Drew DeVault
Dave Airlie
Jon Turney
Matthieu Herrb
nerdopolis
Mario Kleiner
James Jones
Patrik Jakobsson
Aaron Plattner
Zoltán Böszörményi
Łukasz Spintzyk