A change during the 1.20 development cycle resulted in fbconfigs being walked
and deallocated individually during __glXScreenDestroy. This change
now avoids a use-after-free caused by that change.
==50859==ERROR: AddressSanitizer: heap-use-after-free on address 0x00010d3819c8 at pc 0x0001009d4230 bp 0x00016feca7a0 sp 0x00016feca798
READ of size 8 at 0x00010d3819c8 thread T5
#0 0x1009d422c in __glXScreenDestroy glxscreens.c:448
#1 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
#2 0x1009d2734 in glxCloseScreen glxscreens.c:169
#3 0x100740a24 in dix_main main.c:325
#4 0x10023ed50 in server_thread quartzStartup.c:65
#5 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
#6 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
0x00010d3819c8 is located 200 bytes inside of 12800-byte region [0x00010d381900,0x00010d384b00)
freed by thread T5 here:
#0 0x101477ba8 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fba8)
#1 0x1009d4240 in __glXScreenDestroy glxscreens.c:449
#2 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
#3 0x1009d2734 in glxCloseScreen glxscreens.c:169
#4 0x100740a24 in dix_main main.c:325
#5 0x10023ed50 in server_thread quartzStartup.c:65
#6 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
#7 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
previously allocated by thread T5 here:
#0 0x101477e38 in wrap_calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fe38)
#1 0x100925a40 in __glXAquaCreateVisualConfigs visualConfigs.c:116
#2 0x10091cb24 in __glXAquaScreenProbe+0x224 (X11.bin:arm64+0x100730b24)
#3 0x1009cd840 in xorgGlxServerInit glxext.c:528
#4 0x10074539c in _CallCallbacks dixutils.c:743
#5 0x100932a70 in CallCallbacks callback.h:83
#6 0x100932478 in GlxExtensionInit vndext.c:244
#7 0x10020a364 in InitExtensions miinitext.c:267
#8 0x10073fe7c in dix_main main.c:197
#9 0x10023ed50 in server_thread quartzStartup.c:65
#10 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
#11 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
Regressed-in: 4b0a3cbab1
CC: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
It violates @autoreleasepool best practices, and this helps collapse quartzCocoa.m into quartz.c
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
There is a place where this code was called on the main thread.
We're using a rather nasty anti-pattern to just call a block inline rather
than synchonously calling it on the main thread if we're already on the main
thread. This code could use a good overhaul, but I don't have time to rip
it apart right now. This will address the immediate issue.
Fixes: https://github.com/XQuartz/XQuartz/issues/40
Fixes: https://github.com/XQuartz/XQuartz/issues/48
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
In Weston, clicking the window decoration of an Xwayland client gives us a
wl_pointer.button event immediately followed by a wl_pointer.leave event.
The leave event does not contain any button state information, so the button
remains logically down in the DIX.
Once the pointer button is released, a wl_pointer.enter event is sent with
the current button state (zero). This needs to trigger a ButtonRelease event
but for that we need to ensure that the device is the same as the one we send
ButtonPress events through.
Fixes a regression introduced in a4095162ca.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Trying to change the acceleration/threshold on Xwayland cannot work, and
the corresponding handler xwl_pointer_control() is a no-op.
Yet, an X11 client trying to change those on the touch device may
possibly cause a crash because the touch device in Xwayland doesn't set
that.
Initialize the touch device's PtrFeedback to make sure that just cannot
happen.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1137
We are using the relative pointer for motion events, but buttons and
axis events still go through the absolute pointer device.
That means additional DeviceChanged events that could be avoided if the
buttons and axis events were coming from the same device as motion
events.
Route those events to the relative pointer if available so that motion,
buttons and axis events come from the same device (most of the time).
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
The relative pointer only has 2 axis, if we want to route the mouse
wheel events to that device, we need to add the axis definition, similar
to what is done for the absolute pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
This is a cleanup patch, no functional change.
Split the function dispatch_pointer_motion_event() into three separate
simpler functions, relative motion with a warp emulator, relative motion
and absolute motion.
This makes the code a lot easier to read for me, rather than having
everything in a single function with nested if/else conditions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Xwayland supports relative motion events from the Wayland compositor via
the relative-pointer protocol, and converts those to the absolute range
in device units for raw events.
Some X11 clients however wrongly assume relative values in the axis
values even for devices explicitly labeled as absolute. While this is a
bug in the client, such applications would work fine in plain Xorg but
not with Xwayland.
To avoid that issue, use the relative values for raw events without
conversion, so that such application continue to work in Xwayland.
Thanks Peter for figuring out the root cause.
v2: Don't duplicate relative and absolute events (Peter)
v3: Use POINTER_RAWONLY (Peter)
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
This add a new flag POINTER_RAWONLY for GetPointerEvents() which does
pretty much the opposite of POINTER_NORAW.
Basically, this tells GetPointerEvents() that we only want the
DeviceChanged events and any raw events for this motion but no actual
motion events.
This is preliminary work for Xwayland to be able to use relative motion
events for raw events. Xwayland would use absolute events for raw
events, but some X11 clients (wrongly) assume raw events to be always
relative.
To allow such clients to work with Xwayland, it needs to switch to
relative raw events (if those are available from the Wayland
compositor).
However, Xwayland cannot use relative motion events for actual pointer
location because that would cause a drift over time, the pointer being
actually controlled by the Wayland compositor.
So Xwayland needs to be able to send only relative raw events, hence
this API.
Bump the ABI_XINPUT_VERSION minor version to reflect that API addition.
v2: Actually avoid sending motion events (Peter)
v3: Keep sending raw emulated events with RAWONLY (Peter)
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
When an X11 client issues an active grab on the keyboard, Xwayland
forward this to the Wayland compositor using the Xwayland specific
protocol "xwayland-keyboard-grab" if it can find the corresponding
Xwayland window.
Some X11 clients (typically older games) however try to issue the
keyboard grab on the X11 root window, which has obviously no matching
Xwayland window. In such a case, the grab is simply ignored and the game
will not work as expected.
To workaround that issue, if an X11 client issues a keyboard grab on the
root window, Xwayland will search for a toplevel window belonging to the
same X11 client that it can use as the grab window instead.
This way, the grab can be forwarded to the Wayland compositor that can
either grant or deny the request based on the window and its internal
policies.
The heuristic picks the first realized toplevel window belonging to the
client so that the Wayland compositor will send it the keyboard events,
and the Xserver grab mechanism will then take care of routing the events
to the expected X11 window by itself.
v2: Make the test more clear (Dor Askayo <dor.askayo@gmail.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/1249
Not all extensions can be enabled or disabled at runtime, list the
extensions which can from the help message rather than on error only.
v2:
* Print the header message in the ListStaticExtensions() (Peter
Hutterer)
* Do not export ListStaticExtensions() as Xserver API
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The definition relies on IOPortBase, which is only ever set in
hw/xfree86/os-support/bsd/arm_video.c
This caused build failures on linux/mips with GCC 10, due to this
change (from https://gcc.gnu.org/gcc-10/changes.html#c):
"GCC now defaults to -fno-common. As a result, global variable accesses
are more efficient on various targets. In C, global variables with
multiple tentative definitions now result in linker errors. With
-fcommon such definitions are silently merged during linking."
As a result anything including compiler.h would get its own definition
of IOPortBase and the linker would error out.
Since commit b3f3d65e, xwayland now supports the command line option
"-listenfd" for passing file descriptors and marked "-listen" as
deprecated for this specific purpose.
Add a new pkg-config variable "have_listenfd" to the xwayland.pc so that
compositors can know this is available and use listenfd in place of the
deprecated option.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
There are currently no callers that make use of the "created" output parameter
of xwl_glamor_pixmap_get_wl_buffer. Remove it, along with the corresponding
argument of the associated EGL backend entrypoint.
Just a small code cleanup, there is no need to allocate a variable only
to check the return value of eglInitialize().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Glamor requires at least big GL 2.1 or GLES2, therefore Xwayland tries
to initialize first GL and then GLES2 if that fails.
It does that all in one single function which makes the code slightly
complicated, move the initialization of big-GL and GLES2 to separate
functions to help with readability of the code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
We currently bail out early for GLES only devices, and call
epoxy_gl_version() too early for GLES only that will make GLES only
devices return NULL for glGetString(GL_RENDERER).
Let's also add a check to see if we need to recreate the context to
avoid pointless warnings for GLES only devices as suggested by
Olivier Fourdan <ofourdan@redhat.com>.
Fixes: a506b4ec - xwayland: make context current to check GL version
Signed-off-by: Tony Lindgren <tony@atomide.com>
The window buffer mechanism would free the pixmap and its corresponding
Wayland buffer as soon as window buffers are disposed.
Typically when the X11 window is unrealized, the current window buffer
is still used by the Wayland compositor and yet Xwayland will destroy
the buffer.
As a matter of fact, Xwayland should not destroy the Wayland buffer
before the wl_buffer.release event is received.
Add a reference counter to the window buffer similar to the to pixmap
reference counter to keep the buffer around until the release callback
is received.
Increase that reference counter on the buffer which will be attached to
the surface, and drop that reference when receiving the release callback
notification.
v2: Use a specific reference counter on the buffer rather than relying
on the pixmap refcnt (Michel Dänzer <mdaenzer@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
The cursor code would destroy the buffer as soon as the cursor is
unrealized on X11 side.
Yet, the Wayland compositor may still be using the buffer as long as a
released callback has not been received.
Increase the reference counter on the pixmap to hold a reference on the
pixmap when attaching it to the surface and use the new pixmap release
callback mechanism to release that reference when the buffer is
released.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The seat and tablet cursor functions are very similar, factorize the
commonalities to simplify the code and reduce the copy/paste.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit 6a5a4e6037 removed the option to
configure useSIGIO option. Indeed, the xfree86 SIGIO support was
reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO.
As a result, useSIGIO is no longer needed and can dropped
Fixes: 6a5a4e60 - Remove SIGIO support for input [v5]
Closes: xorg/xserver#1107
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Prabhu Sundararaj <prabhu.sundararaj@nxp.com>
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
LogMessage logs only when the XLOG_VERBOSITY is >= 1, but by default
XLOG_VERBOSITY is 0, so for example warning about deprected -listen
parameter is never shown when running "Xwayland -listen 32 -help".
Signed-off-by: Mariusz Ceier <mceier+freedesktop@gmail.com>
By default, the macro DebugPresent() is a no-op but it can be enabled
at build time for debugging purpose.
However, doing so prevents the code to build because one debug statement
tries to make use of a non-existent variable:
present.c: In function ‘ms_present_queue_vblank’:
present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
147 | vbl.request.sequence));
| ^~~
present.c:49:32: note: in definition of macro ‘DebugPresent’
49 | #define DebugPresent(x) ErrorF x
| ^
Fix the build with DebugPresent() by removing the vbl variable from the
debug message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
With !155, the device bus ID received via udev is constructed
properly with the "usb:" prefix. But, it is not enough to
make the following line to work in Section "Device":
BusID "usb:0:1.2:1.0"
Introduce BUS_USB, so the prefix can be distinguished from BUS_PCI
and check the supplied BusID value against device->attribs->busid
in xf86PlatformDeviceCheckBusID().
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
Provide an actual definition of noDriExtension where used, rather than a
tentative definition in a header, to fix compilation with -fno-common
(the default with gcc 10).
EGLStream implementation in Xwayland keeps a list of pending streams for
a window.
If the windows's pixmap is destroyed while there is a pending stream,
the pending stream will point to freed memory once the callback is
triggered.
Make sure to cancel the pending stream if there's one when the pixmap is
destroyed.
v2:
* Use xorg_list_for_each_entry() instead of the safe variant (Michel
Dänzer <mdaenzer@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Closes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1096
Commit 77658741 - "xwayland: Add buffer release callback" added an API
to deal with Wayland buffer release callbacks.
The EGLstream implementation has its own wl_buffer callback, move that
to the buffer release API instead so we don't have to deal with Wayland
buffers directly and match the other Xwayland pixmap backend
implementations.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Erik Kurzinger <ekurzinger@nvidia.com>
Resolves warnings from Oracle Parfait static analyser:
Error: Misleading macro
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'|' operator has higher precedence than ternary '?:' operator inside macro body at line 431
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 431
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 442
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 442
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'|' operator has higher precedence than ternary '?:' operator inside macro body at line 443
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 441
Misleading macro [misleading-macro]:
misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
at line 392 of hw/xfree86/int10/generic.c.
'<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Resolves warning from Oracle Parfait static analyser:
Error: Unchecked result
Unchecked result [unchecked-result-call-X]:
Unchecked return value from call to XOpenDisplay. Value display must be ch
ecked to ensure this function was successful.
at line 73 of hw/dmx/examples/xbell.c in function 'main'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
It runs XTS via piglit on (non-rootless) Xwayland on weston using the
headless backend.
Xwayland might use glamor if enabled in the build, but we're making sure
it uses software rendering.
v2:
* Use weston-info to wait for weston to be ready, instead of just a
fixed sleep. (Martin Peres)
v3:
* Build wayland 1.18 & weston 9.0 locally, since the packages in Debian
buster are too old for current Xwayland.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
As Xwayland is usually spawned by the Wayland server/compositor, its
command line options are not always adjustable.
Yet, if EGLStream is not supported in a given Xwayland build, the option
will do nothing (yet we must still accept it otherwise Xwayland would
refuse to run if the Wayland compositor uses it).
If Xwayland was built without support for EGLStream, there is not point
in showing the option in the help message though.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
The command line options "-shm" is used to instruct Xwayland to prefer
shared-memory for passing buffers to the Wayland server, rather than
using glamor and DRI3.
The option was there from the beginning, yet not documented in the
"-help" message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
One general assumption in Xwayland is that the xwl_window remains the
same for all the child windows of the toplevel window.
When mapping a new X11 window, ensure_surface_for_window() checks for an
existing xwl_window by using xwl_window_get() which will just check for
the registered xwl_window for the window.
That means that a client mapping a child window of an existing window
with a xwl_window will get another different xwl_window.
If an X11 client issues a Present request on the parent window, hence
placed underneath its child window of the same size, the Wayland
compositor may not send the frame callback event for the parent's
Wayland surface which is reckoned to be not visible, obscured behind
the other Wayland surface for the child X11 window.
That bug affects some games running in wine which may get 1 fps because
the repaint occurs only on timeout with a long interval (as with, e.g.
https://bugs.winehq.org/show_bug.cgi?id=47066)
Fix ensure_surface_for_window() by using xwl_window_from_window() which
will walk the window tree, so that a child window won't get another
xwl_window than its parent.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1099
See-also: https://bugs.winehq.org/show_bug.cgi?id=47066
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When running non-rootless, Xwayland requires that the Wayland compositor
supports the XDG-WM-Base protocol.
Check for XDG-WM-Base protocol support at startup and exit cleanly if
missing rather than segfaulting later in ensure_surface_for_window()
while trying to use xdg_wm_base_get_xdg_surface().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Instead, bump the pixmap's refcount at the bottom of post_damage to
reflect the compositor's hold on the buffer, and "destroy" the pixmap in
the buffer release callback (which will dec the pixmap's refcount and
free if necessary).
Signed-off-by: Adam Jackson <ajax@redhat.com>
When the "CTM" (color transform matrix) modesetting property is available,
create a corresponding RandR property.
To match the format of the property available in the amdgpu driver, expose it as
an array of 18 32-bit XA_INTEGERs representing a 3x3 matrix in row-major order,
where each entry is a S31.32 sign-magnitude fixed-point number with the
fractional part listed first.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: James Jones <jajones@nvidia.com>
If the kernel exposes GAMMA_LUT and GAMMA_LUT_SIZE properties and the size is
not what the server has pre-configured for the crtc, free the old gamma ramp
memory allocated by the server and replace it with new allocations of the
appropriate size.
In addition, when GAMMA_LUT is available, use drmModeCreatePropertyBlob() and
drmModeObjectSetProperty() to set the gamma ramp rather than using the legacy
drmModeCrtcSetGamma() function.
Add a new option "UseGammaLUT" to allow disabling this new behavior and falling
back to drmModeCrtcSetGamma() unconditionally.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Modeset properties can be set even when ms->atomic_modeset is disabled by using
the drmModeObjectSetProperty() function.
This will be necessary in a later change in order to set the GAMMA_LUT and CTM
properties.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
There was a time when setting a mode on a CRTC would not depend on the
associated connector's state. If a mode had been set successfully once,
it would mean it would work later on.
This changed with the introduction of new connectors type that now
require a link training sequence (DP, HDMI 2.0), and that means that
some events may have happened while the X server was not master that
would then prevent the mode from successfully be restored to its
previous state.
This patch relaxes the requirement that all modes should be restored on
EnterVT, or the entire X-Server would go down by allowing modesets to
fail (with some warnings). If a modeset fails, the CRTC will be
disabled, and a RandR event will be sent for the desktop environment to
fix the situation as well as possible.
Additional patches might be needed to make sure that the user would
never be left with all screens black in some scenarios.
v2 (Martin Peres):
- whitespace fixes
- remove the uevent handling (it is done in a previous patch)
- improve the commit message
- reduce the size of the patch by not changing lines needlessly
- return FALSE if one modeset fails in ignore mode
- add comments/todos to explain why we do things
- disable the CRTCs that failed the modeset
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@intel.com>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Kishore Kadiyala <kishore.kadiyala@intel.com>
Closes: #1010
Normally, we would receive a uevent coming from Linux's DRM subsystem,
which would trigger the check for disappearing/appearing resources.
However, this event is not received when X is not master (another VT
is selected), and so the userspace / desktop environment would not be
notified about the changes that happened while X wasn't master.
To fix the issue, this patch forces a refresh on EnterVT by splitting
the kms-checking code from the uevent handling into its own (exported)
function called drmmode_update_kms_state. This function is then called
from both the uevent-handling function, and on EnterVT right before
restoring the modes.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Kishore Kadiyala <kishore.kadiyala@intel.com>
Tested-by: Kishore Kadiyala <kishore.kadiyala@intel.com>
This is useful for mock input drivers that control the server in
integration tests. Given that input submission happens on a different
thread than processing, it's otherwise impossible for the driver to
synchronize with the completion of the processing of submitted events.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
The EGLStream backend keeps a queue of pending streams for each Xwayland
window.
However, when this pending queue is freed, the corresponding private
data may not be cleared (typically if the pixmap for this window has
changed before the compositor finished attaching the consumer for the
window's pixmap's original eglstream), leading to a use-after-free and a
crash when trying to use that data as the window pixmap.
Make sure to clear the private data when the pending stream is freed.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1055
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Using multiple window buffers crashes with EGLStream, which does not
need it anyway as this is handled through EGL directly.
Add a flag to the EGL backend to indicate whether it would benefit from
multiple buffers and use this in the get_buffer() function.
Thanks to Adam Jackson <ajax@redhat.com> for pointing out that issue
with EGLStream.
v2: Fix logical test (Adam Jackson <ajax@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The present flip does not work with the EGLStream backend. Similarly,
the EGLStream backend does not require the buffer to be flushed as
eglSwapBuffers() should take care of this.
Instead of actually checking the backend in use in the present code,
add a flag in the form of a bitfield to the EGL backend to indicate
its features and requirements.
This should not introduce any functional change.
v2: Fix logical test (Adam Jackson <ajax@redhat.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Major/minor numbers are a.. major (ha) source of pain in FreeBSD porting.
In this case, Xwayland was thinking that /dev/dri/card0 is already a render node,
because the st_rdev on FreeBSD was passing the Linux-style check,
and because of the assumption, acceleration would fail because
various ioctls like AMDGPU_INFO would be denied on the non-render node.
Switch to libdrm's function that already works correctly on all platforms.
Signed-off-by: Greg V <greg@unrelenting.technology>
Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org>
Fetch VariableRefresh option value from X conf file for
modesetting backend DDX driver. This option defaults to false,
and must be set to "true" in conf file for variable refresh
support in the DDX driver.
Signed-off-by: Uday Kiran Pichika <pichika.uday.kiran@intel.com>
Window wrappers gets the notification when the window
properties changes. These wrappers are mainly used to
keep track of per-window _VARIABLE_REFRESH property values.
These changes have been ported from AMDGPU
Signed-off-by: Uday Kiran Pichika <pichika.uday.kiran@intel.com>
These changes have been ported from AMD GPU DDX driver.
This patch adds support for setting the CRTC variable refresh property
for suitable windows flipping via the Present extension.
In order for a window to be suitable for variable refresh it must have
the _VARIABLE_REFRESH property set by the MESA and inform Modesetting
DDX driver with window property updates.
Then the window must pass the checks required to be suitable for
Present extension flips - it must cover the entire X screen and no
other window may already be flipping. And also DRM connector should
be VRR capable.
With these conditions met every CRTC for the X screen will have their
variable refresh property set to true.
Kernel Changes to support this feature in I915 driver is under development.
Tested with DOTA2, Xonotic and custom GLX apps.
Signed-off-by: Uday Kiran Pichika <pichika.uday.kiran@intel.com>
We can only flip if the window pixmap matches that of the toplevel
window. Doing so regardless could cause the toplevel window pixmap to
get destroyed while it was still referenced by the window, resulting in
use-after-free and likely a crash.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1033
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
The need_rotate variable is only used once anymore and had semantics which lead
to errors in the past. In particular when negated we are dealing with a double
negation.
The variable gets replaced with a simple check on the xdg-output directly.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
This reverts commit 427f8bc009.
When receiving an output update for the mode size we need to rotate the stored
width and height values if and only if we have an xdg-output for this output
since in this case the stored values describe the output's size in logical
space, i.e. rotated.
The here reverted commit made a code change with which we would not rotate though
when an xdg-output was available since in this case the need_rotate variable was
set to False what caused in the check afterwards the first branch to execute.
That is just a small style-change to the output_get_new_size function. The
function before did take first the height and then the width argument, what
is unusual since resolutions are normally named the other way around, for
example 1920x1080. Also compare the update_screen_size function.
Therefore change the order of arguments for output_get_new_size.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
We can just read out the xdg_output field of the provided xwl_output to check
if a rotation is necessary or not.
This makes the function easier to understand. Additionally some documentation
is added.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Xwayland is just a Wayland client, no X11 screensaver should be
expected to work reliably on Xwayland when running rootless because
Xwayland cannot grab the input devices so it has no way to actually
lock the screen managed by the Wayland compositor.
Turn off the screensaver on Xwayland when running rootless by setting
the screensaver timeout and interval and their default values to zero
and disable the MIT-SCREEN-SAVER extension.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1051
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
