screenp->displays[count] (passed to configDisplay() in
configScreen()) is NULL if there is no Virtual setting
in the configuration.
Fixes: f8a6be04d0 ("xfree86: Change
displays array to pointers array to fix invalid pointer issues
after table reallocation")
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Physical dimmension of display can be obtained not just by configuration or
DDC, but also directly from kernel via drmModeGetConnector(). Until now
xserver silently discarded these values even when no configuration nor EDID
were present and fallbacked to default DPI.
There are rare cases when xf86SetDepthBpp is resizing displays array in confScreen.
As that array is shared between set of ScrnInfoRec's then realloc might invalidate chached DispPtr display values in
otheres ScrnInfoRec objects.
If we will change displays array as an array of pointers to DispRec then cached DispRec pointers in ScrnInfoRec
won't be invalid after reallocation of displays array.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
In certain circumstances we will have a lot of flip errors without a
reasonable way to prevent them. In such case we reduce the number of
logged messages to at least not fill the error logs.
The details are as follows:
At least on i915 hardware support for async page flip support depends on
the used modifiers which themselves can change dynamically for a screen.
This results in the following problems:
- We can't know about whether a particular CRTC will be able to do an
async flip without hardcoding the same logic as the kernel as there's no
interface to query this information.
- There is no way to give this information to an application, because
the protocol of the present extension does not specify anything about
changing of the capabilities on runtime or the need to re-query them.
Even if the above was solved, the only benefit would be avoiding a
roundtrip to the kernel and reduced amount of error logs. The former
does not seem to be a good enough benefit compared to the amount of work
that would need to be done. The latter is solved in this commit.
Reviewed-by: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
In xwl_glamor_eglstream_get_wl_buffer_for_pixmap. This can likely be hit
now with an SHM pixmap via the Present flip path. There might be other
corner cases.
Fixes: f3eb1684fa "xwayland: enable MIT-SHM shared pixmaps"
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This mode for displays running on evdi/udl as side effect of failed glamor_egl_init
reverse_prime_offload_mode was initialized to FALSE
After Mesa upgrade to 21.0.0 GL_RENDERER is not llvmpipe that results in successful glamor_egl_init
and reverse_prime_offload_mode enabled.
This commit is explicitly disabling reverse_prime_offload_mode for evdi and udl drivers
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
When the command line option "-terminate" is used, it could be
interesting to give it an optional grace period to let the Xserver
running for a little longer in case a new connection occurs.
This adds an optional parameter to the "-terminate" command line option
for this purpose.
v2: Use a delay in seconds instead of milliseconds
(Martin Peres <martin.peres@mupuf.org>)
v3: Clarify man page entry, ensure terminateDelay is always >= 0,
simplify TimerFree(). (Peter Hutterer <peter.hutterer@who-t.net>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
That will dramatically affect performance, might as well log when we
cannot use GL_OES_EGL_image with the NVIDIA closed-source driver.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
If the EGLStream backend is able to use hardware acceleration with the
NVIDIA closed source driver, we should use the "nvidia" GLX
implementation instead of the one from Mesa to take advantage of the
NVIDIA hardware accelerated rendering.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
If Xwayland's EGLstream backend supports hardware acceleration with the
NVIDIA closed-source driver, the GLX library also needs to be one
shipped by NVIDIA, that's what GLVND is for.
Add a new member to the xwl_screen that the backend can optionally set
to the preferred GLVND vendor to use.
If not set, "mesa" is assumed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When eglSwapBuffers inserts a new frame into a window's stream, there may be a
delay before the state of the consumer end of the stream is updated to reflect
this. If the subsequent wl_surface_attach, wl_surface_damage, wl_surface_commit
calls are received by the compositor before then, it will (typically) re-use
the previous frame acquired from the stream instead of the latest one.
This can leave the window displaying out-of-date contents, which might never be
updated thereafter.
To fix this, after calling eglSwapBuffers, xwl_glamor_eglstream_post_damage
should call eglStreamFlushNV. This call will block until it can be guaranteed
that the state of the consumer end of the stream has been updated to reflect
that a new frame is available.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1171
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Allow X11 clients to create shared pixmaps via the MIT-SHM
extension under Xwayland. Tested with a wlroots patch [1].
Also add a few assertions to make sure we have wl_buffers where we
need them.
[1]: https://github.com/swaywm/wlroots/pull/2875
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
As of commit 098e0f52 xwl_glamor_eglstream_allow_commits will not allow commits
if the xwl_pixmap does not have an EGLSurface. This is valid for pixmaps backed
by an EGLStream, however pixmaps backed by a dma-buf for OpenGL or Vulkan
rendering will never have an EGLSurface. Unlike EGLStream backed pixmaps,
though, glamor will render directly to the buffer that Xwayland passes to the
compositor. Hence, they don't require the intermediate copy in
xwl_glamor_eglstream_post_damage that EGLStream backed pixmaps do, so there is
no need for an EGLSurface.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The EGLstream backend's post damage function uses a shader and
glDrawArrays() to copy the data from the glamor's pixmap texture prior
to do the eglSwapBuffers().
However, glDrawArrays() can be affected by the GL state, and therefore
not reliably produce the expected copy, causing the content of the
buffer to be corrupted.
Make sure to set the ALU to GXCopy prior to call glDrawArrays() to get
the expected result.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, the EGLstream backend would increment the pixmap refcount for
each commit, and decrease that refcount on the wl_buffer release
callback.
But that's relying on the compositor sending us a release callback for
each commit, otherwise the pixmap refcount will keep increasing and the
pixmap will be leaked.
So instead, increment the refcount on the pixmap only when we have not
received a release notification for the wl_buffer, to avoid increasing
the pixmap refcount more than once without a corresponding release
event.
This way, if the pixmap is still in use when released on the X11 side,
the EGL stream will be kept until the compositor releases it.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
EGLstream's post_damage() would unconditionally return success
regardless of the actual status of the eglSwapBuffers().
Yet, if eglSwapBuffers() fails, we should not post the corresponding
damage as they wouldn't match the actual content of the buffer.
Use the eglSwapBuffers() return value as the return value for
post_damage() and do not take a refrence on the pixmap if it fails.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Use calloc() instead of malloc() like the rest of the code.
Also fix the arguments of calloc() calls to match the definition which
is calloc(size_t nmemb, size_t size).
This is a cleanup patch, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The EGL surface for the xwl_pixmap is created once the stream is ready
and valid.
If the pixmap's EGL surface fails, for whatever reason, the xwl_pixmap
will be unusable and will end up as an invalid wl_buffer.
Make sure we do not allow commits in that case and recreate the
xwl_pixmap/stream.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Now that the pending stream is associated with the xwl_pixmap for
EGLStream and the xwl_pixmap itself is associated to the pixmap, we have
a reliable way to get to those data from any pending stream.
As a result, the list of pending streams that we keep in the EGLStream
global structure becomes useless.
So we can drop the pending stream's xwl_pixmap and also the list of
pending streams altogether, and save us a walk though that list for each
callback.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit affc47452 - "xwayland: Drop the separate refcount for the
xwl_pixmap" removed the separate reference counter for the xwl_pixmap
which holds the EGLStream.
While that works fine for the common case, if the window's pixmap is
changed before the stream is ready, the older pixmap will be destroyed
and the xwl_pixmap along with it, even if the compositor is still using
the stream.
The code that was removed with commit affc47452 was taking care of that
by increasing the separate reference counter for the xwl_pixmap, but it
no longer the case.
As a result, we may end up with the EGL stream in the wrong state when
trying to use it, which will cascade down into all sort of issues.
To avoid the problem, increase the reference count on the pixmap when it
is marked as invalid in EGLStream's SetWindowPixmap().
This way, the xwl_pixmap and the EGLStream are kept until released by
the compositor, even when the pixmap changes before stream is ready.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: affc47452 xwayland: Drop the separate refcount for the xwl_pixmap
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Previously, we would have pending streams associated with top level X11
windows, keeping temporary accounting for the pending streams before
they get fully initialized for the xwl_pixmap which would be associated
with X11 pixmaps.
If the window content changes before the stream is ready, the
corresponding pending stream would be marked as invalid and the pending
stream would be eventually removed once the stream becomes ready.
Since commit affc47452 - "xwayland: Drop the separate refcount for the
xwl_pixmap", we no longer keep a separate reference counter for the
xwl_pixmap, but rather tie it to the X11 pixmap lifespan. Yet, the
pending stream would still be associated with the X11 toplevel window.
Dissociate the pending streams from the X11 toplevel window, to keep it
tied only to the xwl_pixmap so that we can have:
- pixmap <-> xwl_pixmap
- xwl_pixmap <-> pending stream
Of course, the pending streams remain temporary and get removed as soon
as the ready callback is triggered, but the pending streams are not
linked to the X11 window anymore which can change their content, and
therefore their X11 pixmap at any time.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
eglCreateStreamKHR() can fail and return EGL_NO_STREAM_KHR, in which
case there is no point in trying to create a buffer from it.
Similarly, eglCreateStreamProducerSurfaceKHR() also fail and return
EGL_NO_SURFACE, which in turn will be used in eglMakeCurrent() as
draw/read surface, and therefore would mean no draw/read buffer.
In those cases, log the error, and bail out early. That won't solve the
issue but will help with investigating the root cause of issues with
EGLStream backend.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
Some functions are called "callback" whereas they are not longer
callback functions or "unref" while they no longer deal with a reference
counter anymore, which is quite confusing. Rename those functions to be
more explicit.
Also, the pending streams can be destroyed in different places, move the
common code to separate function to avoid duplicating code and help with
readability of the code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The EGLStream backend would sometime generate GL errors trying to draw
to the framebuffer, which gives an invalid buffer, which in turn would
generate a Wayland error from the compositor which is fatal to the
client.
Check the framebuffer status and bail out early if it's not complete,
to avoid getting into trouble later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
If the glamor backend failed to post damage, the caller should do the
same to avoid a failure to attach the buffer to the Wayland surface.
Change the API of Xwayland's glamor backend post_damage() to return a
status so that xwl_window_post_damage() can tell whether the callee
failed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
If the buffer is NULL, do not even try to attach it, and risk a Wayland
protocol error which would be fatal to us.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
EGLStream wl_eglstream_display_create_stream() may fail, yet Xwayland
would try to attach the buffer which may cause a fatal Wayland protocol
error raised by the compositor.
Check if the buffer creation worked, and fail gracefully otherwise (like
wayland-eglsurface does).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1156
If a window is being used for direct rendering with OpenGL or Vulkan, and is
using the flipping path for presentation, it's pixmap will be set to a dma-buf
backed pixmap created by the client-side GL driver. However, this means that
xwl_glamor_eglstream_post_damage won't work since it requires that the pixmap
has an EGLSurface that it can render to, which dma-buf backed pixmaps do not.
In this case, though, xwl_glamor_eglstream_post_damage is not necessary since
glamor will have rendered directly to the pixmap, so we can simply pass it
directly to the compositor. There's no need for the intermediate copy we
normally do in that function.
Therefore, this change adds an early-return case to post_damage for dma-buf
backed pixmaps, and removes the corresponding asserts from that function and
allow_commits.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Copied TGL PCI ID from MESA iris_pci_ids.h
This update brings in a significant number of new platform ID's
Sync up until commit f02ae698
Signed-off-by: Mazlan, Hazwan Arif <hazwan.arif.mazlan@intel.com>
On FreeBSD 13.0-CURRENT for PowerPC64 big-endian (BE), X was
crashing in some cases. For instance, when twm was started
and the background was clicked to open its menu, X crashed
with a segmentation fault, trying to dereference a null pointer
at CreatePicture().
There were 2 issues with xorg-server handling of RGB masks that
caused the pointer above to be null and thus the crash:
- wrong use of ffs() to get the RGB offsets from the masks
- overflow when shifting a 16-bit integer
This change fixes both issues. They happen when the system is BE
but has a video adapter using a little-endian (LE) ARGB32
framebuffer. In order to display the correct colors, this setup
requires a BE RGBA32 color format to be used by X, by setting
the RGB masks appropriately, that didn't work properly because of
the issues above.
A lot of that code is the same as in xf86-amdgpu and xf86-nouveau drivers. By removing that functions from
ms namespace we can move that code to common implementation.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
Instead of getting the current msc value from the window crtc,
which not exist take the last saved msc value saved in
the window_priv struct
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
Provides an implementation for the pixmap_from_buffers DRI3 function for
xwayland's eglstream backend. This will be used by the NVIDIA GLX driver
to pass buffers from client applications to the server. These can then
be presented using the PRESENT extension.
To hopefully make this less error-prone, we also introduce a "type"
field for this struct to distinguish between xwl_pixmaps for the new
DRI3-created pixmaps and those for the existing glamor-created pixmaps.
Additionally, the patch enables wnmd present mode with the eglstream backend.
This involves creating a wl_buffer for the provided dma-buf before importing it
into EGL and passing this to the compositor so it can be scanned out directly
if possible.
Since both backends now support this present mode, the HAS_PRESENT_FLIP flag is
no longer needed, so it can be removed.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.
This exposes a new glamor backend function, check_flip, which can be
used to control whether flipping is supported for the given pixmap.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.
This moves the modifiers and formats functions previously only available
to the GBM backend to the common glamor code so that it can be used by
both the GBM and EGLStream backends.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.
The EGLStream backend can possibly also use the dmabuf interface, so
move the relevant code from the GBM specific source to the common bits.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
According to the "VESA Enhanced EDID Standard", all GTF compliant
displays are continuous frequency.
The GTF support flags in 'Display Range Limits Descriptor' cannot be
used if the display is a non-continuous frequency multi-mode display.
Closes#1105
Signed-off-by: Pascal VITOUX <vitoux.pascal@gmail.com>
Fixes: 6a79a737 ("xfree86: add drm modes on non-GTF panels")
Reviewed-by: Aaron Ma aaron.ma@canonical.com
Rather than trying to create a gamma ramp array of the appropriate size in
drmmode_crtc_init when the GAMMA_LUT property should be used, just flag the crtc
as wanting to use the GAMMA_LUT property and then replace the gamma ramp later,
right before calling xf86HandleColormaps. This avoids a problem during initial
startup where xf86RandR12CreateObjects12 hard-codes a gamma ramp size of 256,
causing xf86RandR12CrtcSetGamma to read past the end of the DIX layer's RandR
gamma ramp array:
PreInit
drmmode_pre_init
drmmode_crtc_init
crtc->gamma_size = 1024
ScreenInit
xf86CrtcScreenInit
xf86RandR12Init
xf86RandR12Init12
xf86RandR12CreateObjects12
RRCrtcCreate
randr_crtc->gammaSize = 0
xf86RandR12InitGamma(pScrn, 256)
RRCrtcGammaSetSize
randr_crtc->gammaSize = 256
xf86RandR12InitGamma
xf86RandR12CrtcInitGamma
RRCrtcGammaSet
xf86RandR12CrtcSetGamma
// crtc->gamma_size is 1024 here, while randr_crtc->gammaRed
// is a 256-element array.
memcpy(crtc->gamma_red, randr_crtc->gammaRed, crtc->gamma_size * sizeof(crtc->gamma_red[0]));
drmmode_setup_colormap
xf86HandleColormaps
xf86RandR12InitGamma
RRCrtcGammaSetSize
randr_crtc->gammaSize = 1024
Fixes: 245b9db0 - modesetting: Use GAMMA_LUT when available
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1126
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
This brings the behavior closer than what we currently have with
autotools-based build system.
Meson does not currently have native support for symlinks.
See https://github.com/mesonbuild/meson/issues/1602.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Meson gets confused when there are two targets of the same name within
the same directory, so we use a different intermediate name.
This is a problem with the Xorg SUID wrapper which has the same filename
as the real Xorg executable and is configured in the same meson.build
file. This commit works around this by using a different filename in
build stage and renaming only when installing.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This bumps the minimum Wayland version to 1.5 (released in 2014).
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
When using autoconf/automake to build Xwayland, the actual path to
Xwayland is not fully qualified and refers to the "exec_prefix".
As a result, the path provided by the generated pkg-config file is wrong
when using autoconf to build the Xserver.
Fix the xwayland.pc file to also set the variable "prefix" and
"exec_prefix" so that the path to Xwayland is fully resolved.
Add those variables to the meson build as well for good measure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Since commit 20c78f38, we use the relative pointer for enter/leave
events.
However, sprite_check_lost_focus() which verifies whether the pointer has
left an Xwayland surface still explicitly check for the absolute
pointer.
As a result, no LeaveNotify event is emitted anymore now when the
pointer crosses from an Xwayland surface to a Wayland native one.
Make sure to check the last slave device against get_pointer_event() as
well, not just the absolute pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
Acked-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes: 20c78f38 - xwayland: use get_pointer_device() for enter/leave
handling too
The code path added by commit 69e4b8e6 (xfree86: attempt to autoconfig
gpu slave devices (v3)) assumes that it will only be run if the primary
device on the screen is the first device in xf86configptr->conf_device_lst.
While this is true most of the time, there are two specific cases where
this assumption fails.
First, if the first device in conf_device_lst is assigned to a different
seat than the running X server, it will be skipped by the previous
FIND_SUITABLE macro usage. Second, if the primary device was explicitly
assigned to the screen but auto_gpu_device is still set and no secondary
devices were explicitly listed, that device may not be the first device
in conf_device_lst.
When the first device in conf_device_lst is not the primary device
assigned to the screen, two problems emerge. First, the first device in
conf_device_lst will never be assigned to the screen as a secondary
device. Second, the primary device is additionally assigned to the
screen as a secondary device. The combination of these problems causes
certain otherwise valid configurations to be invalid. For example, if a
primary device is assigned to a screen and a secondary device is listed
in the config but not explicitly assigned to the screen, then one order
of the device sections results in a usable PRIME or Reverse PRIME setup
and the other order does not.
This commit removes the assumption that the primary device is the first
device in conf_device_lst by starting the loop from the start of
conf_device_lst and skipping the primary device when it is encountered.
Signed-off-by: Jacob Cherry <jcherry@nvidia.com>
Xwayland won't emulate XWarpPointer requests if the cursor is visible,
this is to avoid having the cursor jumping on screen and preventing
random X11 clients from controlling the pointer in Wayland, while
allowing games which use that mechanism with a hidden cursor to work in
Xwayland.
There are, however, games which tend to do it in the wrong order, i.e.
show the cursor before moving the pointer, and because Xwayland will not
allow an X11 client to move the pointer while the cursor is visible, the
requests will fail.
Add a workaround for such X11 clients, when the cursor is being shown,
keep it invisible until the cursor is actually moved. This way, X11
clients which show their cursor just before moving it would still have a
chance to succeed.
v2: Add a timeout to show the cursor for well behaved clients.
v3: Some cleanup (Michel)
v4: Do not cancel cursor delay when updating the cursor to avoid
delaying cursor visibility indefinitely if the client keeps
settings different cursors (Michel)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman jaapbuurman@gmail.com
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/734
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>
Zoltán Böszörményi
Daniel Strnad
Łukasz Spintzyk
Povilas Kanapickas
Michel Dänzer
Lukasz Spintzyk
Olivier Fourdan
Erik Kurzinger
Simon Ser
Mazlan, Hazwan Arif
luporl
Edouard Gaulué
Jeremy Huddleston Sequoia
Pascal VITOUX
Aaron Plattner
Jacob Cherry
Peter Hutterer
Jim DeLaHunt
Misha Gusarov
Julien Cristau
Tony Lindgren
Prabhu Sundararaj
Mariusz Ceier
Jon Turney
Alan Coopersmith
Adam Jackson
Kishore Kadiyala
Martin Peres
Greg V