This makes sure RandR events are sent to interested clients as needed.
This was happening implicitly in some cases, but not in others, e.g. if
the root window size didn't change.
If this were to call RRTellChanged more often than necessary in some
cases, that should be harmless, as it only sends events if something
has actually changed since last time.
Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1979892 .
v2:
* Call RRTellChanged at the very end of update_screen_size, just in
case.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
To avoid an EGL stream in the wrong state, if the window pixmap changed
before the stream was connected, we would still keep the pending stream
but mark it as invalid. Once the callback is received, the pending would
be simply discarded.
But all of this is actually to avoid a bug in egl-wayland, there should
not be any problem with Xwayland destroying an EGL stream while the
compositor is still using it.
With that bug now fixed in egl-wayland 1.1.7, we can safely drop all
that logic from Xwayland EGLstream backend.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1189
If the pixmap does not actually change in set_window_pixmap(), there is
no need to invalidate the pending stream, if there's one.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When building xserver with slibtool (https://dev.midipix.org/cross/slibtool)
the build will fail.
/usr/bin/ld: cannot find -ldmxconfig
This is because xserver creates libdmxconfig.a internally and then links with
the linker flag -ldmxconfig. However according to automake documentation the
-lfoo linker flags should only be used for external dependencies and all
internal libraries should be linked with the libtool archive file (.la) or
the static archive (.a) when the former is not available.
GNU libtool is far more permissive and happens to silently obscure this issue
while slibtool fails because it instead sees '-L./.libs -ldmxconfig'.
xf86_platform_devices[i].pdev may be NULL in cases we fail to parse the
busid in config_udev_odev_setup_attribs() (see also [1], [2]) such as
when udev does not give use ID_PATH. This in turn leads to
platform_find_pci_info() being not called and pdev being NULL.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/993
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1076
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This is the only place where we don't check whether
primaryBus.id.plat->pdev is not NULL before accessing its members.
It may be NULL in cases we fail to parse the busid in
config_udev_odev_setup_attribs() (see also [1], [2]) such as when udev
does not give use ID_PATH. This in turn leads to
platform_find_pci_info() being not called and pdev being NULL in one of
the items within the xf86_platform_devices array. For this to cause a
crash we only need it to become the primaryBus device.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/993
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1076
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
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>
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>
Instead of optionally return early when an event is aborted and potentially
clean it up in there we can only optionally inform Present if not aborted and
afterwards clean it up if required.
Saves some lines of code and conditional branches.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
With the newly introduced separate API method for idling a presented Pixmap in
window mode we can simplify the logic by allowing calls to it at any point in
time.
This is done by setting the flip_idler flag if the Pixmap was idled before
being presented.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Notifying Present about events' states was done prior with the single function
present_wnmd_event_notify just like in screen mode. But it is more intelligible
if at least in window mode we make use of three different functions with names
that directly indicate what their purpose is:
* present_wnmd_event_notify only for queued events feedback.
* present_wnmd_flip_notify for when a presentation occured (flip).
* present_wnmd_idle_notify for when the Pixmap of the event can be reused.
This is an API-breaking change in regards to window mode. DDX written against
the previous version won't work anymore. It is assumed that there only exists
the XWayland DDX at the moment using the window mode such that this is not an
issue for the overall ecosystem.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Rename the lists release_queue to release_list and event_list to
wait_list.
The prior names release_queue and event_list were ambiguous: in both are event-
like vblanks which can be removed from the lists in random order. In the
release_queue can be flips that are already released but still wait for the
sync or frame callback but normally the release comes later. In the event_list
are queued events waiting for a later msc.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Commit 1e3f9ea1 removed some NULL checks from xf86RandR12.c, on the premise that
they can't be reached unless RandR has already been initialized. For threesuch
calls, that's not true:
xf86Crtc.c::xf86CrtcScreenInit():
if (c == config->num_crtc) {
xf86RandR12SetRotations(screen, RR_Rotate_0 | RR_Rotate_90 |
RR_Rotate_180 | RR_Rotate_270 |
RR_Reflect_X | RR_Reflect_Y);
xf86RandR12SetTransformSupport(screen, TRUE);
}
else {
xf86RandR12SetRotations(screen, RR_Rotate_0);
xf86RandR12SetTransformSupport(screen, FALSE);
}
xf86Crtc.c::xf86CrtcCloseScreen():
xf86RandR12CloseScreen(screen);
This change adds checks back to xf86RandR12Set{Rotations,TransformSupport}() and
xf86RandR12CloseScreen(), checking that xf86RandR12KeyRec has been registered.
Without this, X will hit an assert that causes it to abort.
Signed-off-by: Alex Goins <agoins@nvidia.com>
This (so-far) Linux-only API lets users create file descriptors purely
in memory, without any backing file on the filesystem and the race
condition which could ensue when unlink()ing it.
It also allows seals to be placed on the file, ensuring to every other
process that we won’t be allowed to shrink the contents, potentially
causing a SIGBUS when they try reading it.
This patch is best viewed with the -w option of git log -p.
This is a port of this commit from Weston:
deae98ef45Fixes#848.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
When a slave device causes the master virtual pointer device to change
device types, the device's private data pointer
(device->public.devicePrivate) is also changed to match the type of the
slave device. This can be a problem though, as tablet pad devices will
set the device's private data pointer to their own xwl_tablet_pad
struct. This can cause us to dereference the pointer as the wrong type,
and result in a segfault:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792
792 va_start(ap, opcode);
(gdb) bt
0 wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at
src/wayland-client.c:792
1 0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0,
hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized
out>) at /usr/include/wayland-client-protocol.h:4610
2 xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at
xwayland-cursor.c:137
3 0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>,
screen=<optimized out>, cursor=<optimized out>, x=<optimized out>,
y=<optimized out>) at xwayland-cursor.c:249
4 0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at
mipointer.c:468
5 miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410
6 0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740,
pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206
7 miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410,
pCursor=0x5610b4b35740) at mipointer.c:194
8 0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>,
pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168
9 0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30,
pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197
10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30,
cursor=0x5610b4b35740) at events.c:938
11 0x00005610b28ec99f in WindowHasNewCursor
(pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362
12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0,
vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc,
client=client@entry=0x5610b4b2c900) at window.c:1561
13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900)
at dispatch.c:746
14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497
15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68,
envp=<optimized out>) at main.c:276
16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>,
argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized
out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at
../csu/libc-start.c:308
17 0x00005610b27ae96e in _start () at cursor.c:1064
Simple reproducer in gnome-shell: open up an Xwayland window, press some
tablet buttons, lock and unlock the screen. Repeat if it doesn't crash
the first time.
So, let's fix this by registering our own device-specific private key
for storing a backpointer to xwl_tablet_pad, so that all input devices
have their private data pointers set to their respective xwl_seat.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Lyude Paul <lyude@redhat.com>
In 9141196d positional coordinates were added to the damage call of pixmap
flips. The damage box coordinates are in screen space though and we need
to convert them first to surface-relative ones by substracting the origin
of the window.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Xwayland is usually spawned by the Wayland compositor which sets the
command line options.
If a command line option is not supported, Xwayland will fail to start.
That somehow makes the Xwayland command line option sort of ABI, the
Wayland compositor need to know if a particular option is supported by
Xwayland at build time.
Also, currently, Xwayland is being installed along with the rest of the
common executable programs that users may run, which is sub-optimal
because, well, Xwayland is not a common executable program, it's meant
to be a proxy between the Wayland compositor and the legacy X11 clients
which wouldn't be able to run on Wayland otherwise.
Xwayland would be better installed in `libexec` but that directory is
(purposedly) not in the user `PATH` and therefore the Wayland compositor
may not be able to find Xwayland in that case.
To solve both problems (which options are supported by Xwayland and
where to look for it), add a `pkg-config` file specifically for Xwayland
which gives the full path to Xwayland (`xwayland`) and which options it
supports (using `pkg-config` variables).
The `pkg-config` file also provides the `Version` so the build scripts
can check for a particular version if necessary.
Obviously, Wayland compositors are not required to use the `pkg-config`
file and can continue to use whatever mechanism they deem preferable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The way Xwayland works (like all Wayland clients), it first queries the
Wayland registry, set up all relevant protocols and then initializes its
own structures.
That means Xwayland will get the Wayland outputs from the Wayland
compositor, compute the physical size of the combined outputs and set
the corresponding Xwayland screen properties accordingly.
Then it creates the X11 screen using fbScreenInit() but does so by using
a default DPI value of 96. That value is used to set the physical size
of the X11 screen, hence overriding the value computed from the actual
physical size provided by the Wayland compositor.
As a result, the DPI computed by tools such as xdpyinfo will always be
96 regardless of the actual screen size and resolution.
However, if the Wayland outputs get reconfigured, or new outputs added,
or existing outputs removed, Xwayland will recompute and update the
physical size of the screen, leading to an unexpected change of DPI.
To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can
be set using the standard command lime option "-dpi") and compute a
physical screen size to match that DPI setting.
Note that only affects legacy core protocols, X11 clients can still get
the actual physical output size as reported by the Wayland compositor
using the RandR protocol, which also allows for the size to be 0 if the
size is unknown or meaningless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/731
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it
returns TRUE. Without this, we're sending uninitialised values to
clients.
Fixes: xorg/xserver#1040
When running with a weston session without a pointer device (thus with
the wl_seat not having a pointer) xwayland pointer warping and pointer
confining should simply be ignored to avoid crashes.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Since the introduction of "modesetting: Remove unnecessary fb addition from
drmmode_xf86crtc_resize" the fb_id isn't initialited at
drmmode_xf86crtc_resize.
Rotate operation of XRandR uses rotate_bo. So in this case the fb_id
associated to the front_bo is not initialized at drmmode_set_mode_major.
So fd_id remains 0.
As every call to drmmode_xf86crtc_resize allocates a new front_bo we should
destroy unconditionally the old_front_bo if operation success. So we free
the allocated GBM handles.
This avoids crashing xserver with a OOM in the RPI4 1Gb at 4k resolution
after 3 series xrandr rotations from normal to left and vice versa reported at
https://github.com/raspberrypi/firmware/issues/1345
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1024
Fixes: 8774532121 "modesetting: Remove unnecessary fb addition from
drmmode_xf86crtc_resize"
These events aren't reachable after xwl_present_cleanup, so they're
leaked if we don't free them first.
This requires storing the pixmap pointer in struct xwl_present_window.
Luckily, the buffer pointer isn't used for anything, so just replace
that.
v2:
* Bump pixmap reference count in xwl_present_flip and drop it in
xwl_present_free_event, fixes use-after-free in the latter due to the
pixmap already being destroyed.
Reviewed-by: Dave Airlie <airlied@redhat.com>
During a VT-Switch a raw pointer to the shared cursor object
is saved which is then freed (in case of low refcount) by a call to
xf86CursorSetCursor with argument pCurs = NullCursor.
This leads to a dangling pointer which can follow in a use after free.
This fix ensures that there is a shared handle saved for the VT-Switch cycle.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display.
Check the "Display Range Limits Descriptor" for GTF support.
If panel doesn't support GTF, then add gtf modes.
Otherwise X will only show the modes in "Detailed Timing Descriptor".
V2: Coding style changes.
V3: Coding style changes, remove unused variate.
V4: remove unused variate.
BugLink: https://gitlab.freedesktop.org/drm/intel/issues/313
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When the linux-dmabuf protocol is available, prefer it over the old
wl_drm protocol. Previously wl_drm was used when modifiers aren't
supported, however linux-dmabuf supports formats without modifiers too.
In this case, linux-dmabuf will send a DRM_FORMAT_MOD_INVALID modifier
for each supported format [1].
This allows compositors to better handle these buffers, getting a
DMA-BUF and implementing features like direct scan-out.
A similar logic has been implemented for EGL [2].
DRM_FORMAT_MOD_INVALID is now stored in the xwl_screen->formats list.
glamor_get_modifiers still returns FALSE with zero modifiers if the
only advertised modifier is DRM_FORMAT_MOD_INVALID.
[1]: fb9b2a8731
[2]: c376865f5e
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Previously, linux-dmabuf was used unconditionally if the buffer had a
modifier. However creating a linux-dmabuf buffer with a format/modifier
which hasn't been advertised will fail.
Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when
the format/modifier has been advertised only.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This flag should only be used when the caller intends to display the
buffer on a hardware plane. Xwayland isn't a DRM client, so it doesn't
make sense to use this flag.
This change will allow the driver to potentially use buffer parameters
that are more optimized.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Without this the client library will flail around looking for a default
provider, probably one named "indirect", and that defeats the point of
having the EGL provider for direct context support in the first place.
This assumes that "mesa" will work, of course, and in general it should.
Mesa drivers will DTRT through the DRI3 setup path, and if our glamor is
atop something non-Mesa then you should fall back to llvmpipe like 1.20.
In the future it might be useful to differentiate the vendor here based
on whether glamor is using gbm or streams.
Fixes: xorg/xserver#1032
None of the current BSD is actually using this code.
(checked DragonFly 5.8.1, FreeBSD 11.2, NetBSD 9.0 and OpenBSD 6.7)
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
In file included from ../glx/glxdri2.c:35:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
In file included from ../glx/glxdriswrast.c:39:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
Xwayland uses the device private to point to the `xwl_seat`.
Device may be removed at any time, including on suspend.
On resume, if the DIX code ends up calling a function that requires the
`xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random
data.
Make sure the clear the device private data on removal so that we don't
try to use it and crash later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/xorg/xserver/issues/709
Drop GBM_BO_USE_SCANOUT from the GBM_BO_IMPORT_FD import, add
GBM_BO_USE_RENDERING to the GBM_BO_IMPORT_FD_MODIFIER import.
If the DMA-BUF cannot be scanned out, gbm_bo_import with
GBM_BO_USE_SCANOUT will fail. However Xwayland doesn't need to scan-out
the buffer and can work fine without scanout. Glamor only needs
GBM_BO_USE_RENDERING.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
In this pretty Wine/Proton specific kludge, we try to handle confining grabs
on InputOnly windows by trying to find the InputOutput window that the pointer
would get visually confined to.
The grabbing window and the visible window come from different clients, so
we used to simply resort to the pointer focus. This is troublesome though, as
the call may happen very soon at a time that the toplevel wasn't yet mapped by
the Wayland compositor, so the pointer focus may well be out of date soon.
In these situations, it does seem that even though the confining grab happens
too early to have the wayland surface mapped, the xserver view of the WindowPtr
does already reflect the size. Use this to find out the better window to
assign the confining grab to, one whose geometry fully contains the InputOnly
window's.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of
cursor_confinement_window is not NULL, yet there is no code path
that could lead to this.
Remove the test for cursor_confinement_window being set, it's useless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client issues a ConfinePointer wit ha hidden cursor,
Xwayland may translate that as a pointer lock.
However, if the pointer is located on another window at the time,
the request may be ignored, even if the pointer later enters the window.
To avoid that issue, check again if locking the pointer with a hidden
cursor is needed when pointer enters a surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client has an active grab on the pointer, all events are
reported relative to the window with the grab.
For Xwayland, if an X11 client has a grab with a pointer confinement
active, while pointer focus is on another window, motion events should
not be reported to the client with the grab, because that sets the X11
client appart, the events would be reported when the pointer is on any
X11 window but not on Wayland native surfaces.
Therefore, if the pointer is confined on a window and that window
differs from the actual pointer focus window, just pretend we lost
pointer focus to another window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/962
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If a client issues a grab on the pointer while the cursor is on another
X11 window, and then hides the cursor, we may end up locking the pointer
onto that other window.
Then a button click might end up moving the focus away from the window
which issued the grab, leaving the whole setup in a mixed up state.
Typically, if the pointer is on another X11 window, we should not try to
lock the pointer, so that it can be moved back to the window which
actually issues the grab (and hence the pointer confinement). Typically,
this is the same as an X11 client issuing a pointer grab while the
cursor is on another Wayland native window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/962
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Mostly http->https conversions, but also replaces gitweb.fd.o
with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
On systems with ACPI but disabled APM (e.g. --disable-linux-apm)
the code does not compile due to preprocessor directives.
If APM is disabled, the final return statement is considered to
be part of ACPI's last if-statement, leading to a function which
has no final return statement at all.
I have refactored the code so ACPI and APM are independent of each
other.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Mutter recently added headless tests, and when running those tests the
Wayland compositor runs for a very short time.
Xwayland is spawned by the Wayland compositor and upon startup will
query the various Wayland protocol supported by the compositor.
To do so, it will do a roundtrip to the Wayland server waiting for
events it expects.
If the Wayland compositor terminates before Xwayland has got the replies
it expects, it will loop indefinitely calling `wl_display_roundtrip()`
continuously.
To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for
the returned value from `wl_display_roundtrip()` and fails if it is
negative.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
All helper client code now uses xcb, so calling XSetAuthorization() is
no longer needed.
This is the last reference to libX11 from helper clients, so linking
with x11-xcb and libX11 is no longer required.
Also drop (unneeded?) linking with libXau.
Also drop installing these prerequistes on AppvVeyor.
Also move prototypes for functions in winauth.c from win.h into a new
header, winauth.h, and include that where needed.
Convert clipboard integration code from libX11 to xcb
This drops support for COMPOUND_TEXT. Presumably some ancient
(pre-2000) clients exist which support that, but not UTF8_STRING, but we
don't have an example to test with. (Given the nature of the thing, the
users of those clients probably work in CJK languages)
Supporting COMPOUND_TEXT would also involve writing (or extracting from
Xlib) support for the ISO 2022 encoding.
v2:
Fix the length of text property set by a SelectionRequest
The length of the text property is not neccessarily the same as the
length of the clipboard text before it is d2u converted (specifically,
if that contains any '\r\n' sequences, it will be shorter as they are
now just '\n')
Always use CF_UNICODETEXT clipboard format. Windows will automatically
down-convert to CF_TEXT for clients which request that.
This is subtly different in one way: if CF_TEXT is requested, we now
post CF_UNICODETEXT and it is converted to CF_TEXT *in the locale of the
requesting process*. Previously, we would convert to CF_TEXT *in our
locale* and post that.
It looks like the code in the !X_HAVE_UTF8_STRING case didn't actually
work correctly, but fortunately that has never been true...
The original Win32 clipboard API is widely regarded as terrible, since
it relies on clients co-operatively managing the clipboard viewer chain,
and a single buggy client can break it for all other clients.
The last Windows version only supporting that API was Windows XP (5.1),
EOLed in 2014.
(This requires MinGW-w64 w32api 6.0.0 or later for
Add/RemoveClipboardListener correctly exported by the x86_64 user32
implib)
Also, relax the timeout mechanism so it allows 1 second between events,
rather than 1 second for the entire transfer, as transfers of large
pastes can take more than 1 second.
Also, prefer UTF8_STRING encoding to COMPOUND_TEXT encoding
This option was implemented before the drivers were split in ≈2006,
and e.g. XWin still supports it.
With this commit, Xorg regains support, so that the following configuration can
be used to set the repeat rate for all keyboard devices without having to modify
Xorg command-line flags or having to automate xset(1):
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "de"
Option "XkbVariant" "neo"
Option "AutoRepeat" "250 30"
EndSection
Signed-off-by: Michael Stapelberg <stapelberg@google.com>
We were only calling xwl_present_unrealize_window for the toplevel
window, but the list can contain entries from child windows as well,
in which case we were leaving dangling pointers to freed memory.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/1000
Fixes: c5067feaee "xwayland: Use single frame callback for Present
flips and normal updates"
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Recently, rooted Xwayland crashes on wlroots-based compositors, because
wlroots removed the deprecated wl_shell protocol.
This MR fixes this by changing the code in question to the xdg-shell
protocol. My motivation do this: on etnaviv-based embedded platforms,
rooted Xwayland is much faster and doesn't cause UI rendering bugs
compared to rootless Xwayland.
Signed-off-by: Lukas F. Hartmann <lukas@mntre.com>
Since the recent fix to call xwl_output_set_window_randr_emu_props() from
ensure_surface_for_window(), it is now only called on a toplevel window,
so the is-toplevel check is not necessary for the
xwl_output_set_window_randr_emu_props() case.
This commit moves the check to xwl_output_set_randr_emu_prop_callback()
so that we only do it when we are walking over all Windows of a client
to update the property on a change of the emulated resolution.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For window-manager managed windows, xwl_realize_window is only called for
the window-manager's decoration window and not for the actual client window
on which we should set the _XWAYLAND_RANDR_EMU_MONITOR_RECTS prop.
Usualy this is not a problem since we walk all client windows to update
the property when the resolution is changed through a randr call.
But for apps which first do the randr change and only then create their
window this does not work, and our xwl_output_set_window_randr_emu_props
call in xwl_realize_window is a no-op as that is only called for the wm
decoration window and not for the actual client's window.
This commit fixes this by making ensure_surface_for_window() call
xwl_output_set_window_randr_emu_props on the first and only child of
window-manager managed windows.
Note this also removes the non-functional xwl_output_set_window_randr_emu_props
call from xwl_realize_window, which was intended to do this, but does not
work.
This fixes apps using the ogre3d library always running at the
monitors native resolution.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some clients, which use vidmode to change the resolution when going fullscreen,
create an override-redirect window and never trigger the screen->ResizeWindow
callback we rely on to do the xwl_window_check_resolution_change_emulation().
This causes us to not apply a viewport to them, causing the fullscreen window
to not fill the entire monitor.
This commit adds a call to xwl_window_check_resolution_change_emulation()
at the end of ensure_surface_for_window() to fix this. Note that
ensure_surface_for_window() exits early without creating an xwl_window
for new windows which will not be backed by a wayland surface and which
thus will not have an xwl_window.
This fixes ClanLib-0.6.x and alleggl-4.4.x using apps not properly
fullscreening.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The code building the mode-list does the following to deal with screen
rotation:
if (need_rotate || xwl_output->rotation & (RR_Rotate_0 | RR_Rotate_180)) {
mode_width = xwl_output->width;
mode_height = xwl_output->height;
} else {
mode_width = xwl_output->height;
mode_height = xwl_output->width;
}
This means we need to do something similar in xwl_output_set_emulated_mode()
to determine if the mode being set is the actual (not-emulated) output mode
and we this should remove any emulated modes set by the client.
All callers of xwl_output_set_emulated_mode always pass a mode pointer
to a member of xwl_output->randr_output->modes, so we do not need to
duplicate this code, instead we can simply check that the passed in mode
is modes[0] which always is the actual output mode.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Not only hook the ResizeWindow method of the screen (which really is
MoveAndResize) but also hook the MoveWindow method for checking if we
need to setup a viewport for resolution change emulation.
Our resolution change emulation check if the windows origin matches
the monitors origin and the windows origin can also be changed by just
a move without being resized.
Also checking on a move becomes esp. important when we move to checking
on changes to the top-level non-window-manager client (X11)Window instead
of on changes to the xwl_window later on in this patch series.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The recent change to use the top-level non-window-manager Window drawable
coordinates from xwl_window_check_resolution_change_emulation() in
combination with only calling it on a resize when the top-level window
is moved breaks things with mutter/gnome-shell.
When fullscreening a X11 window, mutter moves its window-decoration Window
wrapping the top-level Window to the monitor's origin coordinates (e.g. 0x0)
last. This updates the top-level's drawable coordinates, but as the
actual MoveWindow is called on the wrapper Window and not on the toplevel
we do not call xwl_window_check_resolution_change_emulation() and we never
enable the viewport.
This commit fixes this by also calling
xwl_window_check_resolution_change_emulation() if the Window being moved
is an xwl_window itself.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a reparented window is resized directly check the emulation instead of
doing this only when the window manager parent window is resized, what might
never happen.
For that to work we need to make sure that we compare the current size of the
client toplevel when looking for an emulated mode.
Changes by Hans de Goede:
- Remove xwl_window x, y, width and height members as those are no longer used.
- Add check for xwl_window_from_window() returning NULL.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Make window_get_none_wm_owner return the first non-wm-window instead of the
owner (client) of the first non-wm-window and rename it to
window_get_client_toplevel to match its new behavior.
This is a preparation patch for switching to using the drawable coordinates
in xwl_window_should_enable_viewport()
Changes by Hans de Goede:
- Split this change out into a separate patch for easier reviewing
- Rename window_get_none_wm_owner to window_get_client_toplevel to match
its new behavior
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
An X11 window manager might add a chain of parent windows when reparenting to a
decoration window.
That is for example the case for KWin, which reparents client windows to one
decoration and another wrapper parent window.
Account for that by a recursion into the tree. For now assume as before that
all X11 window managers reparent with one child only for these parent windows.
Changes by Hans de Goede:
- Move the xwl_window_is_toplevel() from a later patch in this series here
as it really belongs together with these changes
- Drop no longer necessary xwl_window argument from window_get_none_wm_owner
parameters
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a viewport is already created we can reuse this object instead of
destroying it and getting a new one for updating the source rectangle and
destination size.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Instead of iterating over all clients which are listening for events on the
root window and checking if the client we are dealing with is the one
listening for SubstructureRedirectMask | ResizeRedirectMask events and thus
is the window-manager, cache the client-id of the window-manager in
xwl_screen and use that when checking if a client is the window-manager.
Note that we cache and compare the client-id rather then the ClienPtr,
this saves reading the ClientPtr from the global clients array when doing
the comparison.
Suggested-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Xorg supports the '-version' command line option, add something similar
to Xwayland.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/976
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
xf86platformProbeDev didn't check the device path, fix it.
This is a problem when trying to set up a non-PCI device via
explicit xorg.conf.d configuration.
An USB DisplayLink device, being non-PCI was always set up
as a GPU device assigned to screen 0 instead of a regular
framebuffer, potentially having its own dedicated screen,
despite such configuration as below. Only the relevant parts
of the configuration are quoted, it's part of a larger context
with an Intel chip that has 3 outputs:
* DP1 connected to an LCD panel,
* VGA1 connected to an external monitor,
* HDMI1 unconnected and having no user visible connector
Section "ServerFlags"
Option "AutoBindGPU" "false"
EndSection
...
Section "Device"
Identifier "Intel2"
Driver "intel"
BusID "PCI:0:2:0"
Screen 2
Option "Monitor-HDMI1" "HDMI1"
Option "ZaphodHeads" "HDMI1"
EndSection
Section "Device"
Identifier "UDL"
Driver "modesetting"
Option "kmsdev" "/dev/dri/card0"
#BusID "usb:0:1.2:1.0"
Option "Monitor-DVI-I-1" "DVI-I-1"
Option "ShadowFB" "on"
Option "DoubleShadow" "on"
EndSection
...
Section "Screen"
Identifier "SCREEN2"
Option "AutoServerLayout" "on"
Device "UDL"
GPUDevice "Intel2"
Monitor "Monitor-DVI-I-1"
SubSection "Display"
Modes "1024x768"
Depth 24
EndSubSection
EndSection
Section "ServerLayout"
Identifier "LAYOUT"
Option "AutoServerLayout" "on"
Screen 0 "SCREEN"
Screen 1 "SCREEN1" RightOf "SCREEN"
Screen 2 "SCREEN2" RightOf "SCREEN1"
EndSection
On the particular machine I was trying to set up an UDL device,
I found the following structure was being used to match
the device to a platform device while I was debugging the issue:
xf86_platform_devices[0] == Intel, /dev/dri/card1, primary platform device
xf86_platform_devices[1] == UDL, /dev/dri/card0
devList[0] == "Intel0", ZaphodHeads: DP1
devList[1] == "Intel1", ZaphodHeads: VGA1
devList[2] == "UDL"
devList[3] == "Intel2", ZaphodHeads: HDMI1 (intended GPU device to UDL)
When xf86platformProbeDev() matched the UDL device, the BusID
check failed in both cases of:
* BusID "usb:0:1.2:1.0" was specified
* Option "kmsdev" "/dev/dri/card0" was specified
As a result, xf86platformProbeDev() went on to call probeSingleDevice()
with xf86_platform_devices[0] and devList[2], resulting in the
UDL device being set up as a GPU device assigned to the first screen
instead of as a framebuffer on the third screen as the configuration
specified.
Checking Option "kmsdev" in code code may be a layering violation.
But the modesetting driver is actually part of the Xorg sources
instead of being an external driver, so he "kmsdev" path knowledge
may be used here.
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
In between the two phases introduced by the previous change. This makes
sure all pending drawing to the new buffers is flushed before they're
committed to the Wayland server.
The first phase sets the new surface properties for all damaged
windows, then the second phase commits all surface updates.
This is preparatory for the next change, there should be no observable
change in behaviour (other than the order of Wayland protocol
requests).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Resulted in a build failure with -Werror:
../hw/xfree86/drivers/modesetting/drmmode_display.c: In function ‘drmmode_crtc_set_mode’:
../hw/xfree86/drivers/modesetting/drmmode_display.c:759:15: error: unused variable ‘screen’ [-Werror=unused-variable]
759 | ScreenPtr screen = crtc->scrn->pScreen;
| ^~~~~~
Fixes: c66c548eab "modesetting: Call glamor_finish from
drmmode_crtc_set_mode"
Reviewed-by: Adam Jackson <ajax@redhat.com>
I introduced this error with the MST hotplug code, but it can trigger
on zaphod setups, and is perfectly fine. There is no support for
MST/hotplug on zaphod setups currently, so we can just skip over
the dynamic connector handling here. However we shouldn't skip
over the lease handling so move it into the codepath.
Fixes: 9257b1252d ("modesetting: add dynamic connector hotplug support (MST) (v3)")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It flushes any pending drawing to the kernel, to make sure it'll be
visible to the Wayland server.
Without this, it was possible for the Wayland server to process surface
commits before Xwayland got around to flushing the corresponding
drawing, which could result in stale or even completely random window
contents being visible.
v2:
* Make EGL backend post_damage hook mandatory, don't check for NULL in
xwl_glamor_post_damage. (Olivier Fourdan)
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/951
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Avoids a crash in xf86RotatePrepare -> DamageRegister during
CreateScreenResources if rotation or another transform is configured for
any connected RandR output in xorg.conf. The generic rotation/transform
code generally can't work without the root window currently.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/969
Fixes: 094f42cdfe "xfree86/modes: Call xf86RotateRedisplay from
xf86CrtcRotate"
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
xcb_aux_parse_color takes a non-const pointer, even though it doesn't
modify the string or take ownership of its memory.
Avoids the following warning from GCC:
../hw/kdrive/ephyr/hostx.c: In function ‘hostx_init’:
../hw/kdrive/ephyr/hostx.c:683:30: warning: passing argument 1 of ‘xcb_aux_parse_color’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
683 | if (!xcb_aux_parse_color("red", &red, &green, &blue)) {
| ^~~~~
In file included from ../hw/kdrive/ephyr/hostx.c:50:
/usr/include/xcb/xcb_aux.h:194:27: note: expected ‘char *’ but argument is of type ‘const char *’
194 | xcb_aux_parse_color(char *color_name,
| ~~~~~~^~~~~~~~~~
There's a free(name) at the end of the function.
GCC warned about this:
../hw/xfree86/loader/loadmod.c: In function ‘LoadModule’:
../hw/xfree86/loader/loadmod.c:702:18: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
702 | m = name = "int10";
| ^
For the miClearDrawable prototype. Apparently it doesn't get pulled in
for some build configurations, breaking the build.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since commit d8ec33fe05, an include on
glxvndabi.h has been added to hw/xfree86/common/xf86Init.c
However, if glx is disabled through --disable-glx and GLX headers are
not installed in the build's environment, build fails on:
In file included from xf86Init.c:81:
../../../include/glxvndabi.h:64:10: fatal error: GL/glxproto.h: No such file or directory
64 | #include <GL/glxproto.h>
| ^~~~~~~~~~~~~~~
Fix this failure by removing this include which does not seem to be
needed (an other option would have been to keep it under an ifdef GLXEXT
block)
Fixes:
- http://autobuild.buildroot.org/results/de838a843f97673d1381a55fd4e9b07164693913
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Fixes build failure.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/954
Fixes: 89e32d00f6 "xwayland: Move Xwayland windows to its own sources"
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Calling rrGetScrPriv when RandR isn't initialized causes an assertion
failure that aborts the server:
Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.
Thread 1 "Xorg" received signal SIGABRT, Aborted.
0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff7892897 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/libc.so.6
#3 0x00007ffff78a1526 in __assert_fail () from /usr/lib/libc.so.6
#4 0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121
#5 0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136
#6 0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166
#7 0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335
#8 0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744
#9 0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214
#10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34
This can happen, for example, if the server is configured with Xinerama
and there is more than one X screen:
Section "ServerLayout"
Identifier "crash"
Screen 0 "modesetting"
Screen 1 "dummy" RightOf "modesetting"
Option "Xinerama"
EndSection
Section "Device"
Identifier "modesetting"
Driver "modesetting"
EndSection
Section "Screen"
Identifier "modesetting"
Device "modesetting"
EndSection
Section "Device"
Identifier "dummy"
Driver "dummy"
EndSection
Section "Screen"
Identifier "dummy"
Device "dummy"
EndSection
The problem does not reproduce if there is only one X screen because of
this code in xf86RandR12Init:
#ifdef PANORAMIX
/* XXX disable RandR when using Xinerama */
if (!noPanoramiXExtension) {
if (xf86NumScreens == 1)
noPanoramiXExtension = TRUE;
else
return TRUE;
}
#endif
Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before
calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu
driver does:
fd66f5c0be/src/amdgpu_kms.c (L388)
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit cb1b1e184 modified msSharePixmapBacking() to derive modesettingPtr from
the 'screen' argument. Unfortunately, the name of the argument is misleading --
the screen is the slave screen. If the master is modesetting,
and the slave is not modesetting, it will segfault.
To fix the problem, this change derives modesettingPtr from
ppix->drawable.pScreen. This method is already used when calling
ms->glamor.shareable_fd_from_pixmap() later in the function.
To avoid future issues, this change also renames the 'screen' argument to
'slave'.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Now that each source and header should be in order, we can safely cleaup
the last remaining bits from the main `xwayland.h` which is not needed
anymore and can be removed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland GLX declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland vidmode declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland CVT declaration to its own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland screen related code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland cursor declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland output declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland input declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move the Xwayland Present declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Move Xwayland generic pixmap code to a separate source file and header.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Over time, Xwayland main source file `xwayland.c` has grown in size
which makes it look cluttered and harder to read.
Move the code dealing with Xwayland window to its own source and header
files.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the GLAMOR relevant declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the SHM relevant declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, `xwayland.h` contains all the declarations, which is a bit
awkward and hard to follow.
Move the Xwayland structures declarations to their own header file.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Similar to what is done in Xorg. Not doing this prevented apps from
using GLX with a Composite visual, e.g. Firefox WebRender or Chromium.
v2:
* Fix inverted direct_color test, fixes Chromium as well.
* Drop Composite extension guards, since other Xwayland code calls
compRedirectWindow/compUnredirectWindow unconditionally anyway.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/921
Fixes: 8469241592 "xwayland: Add EGL-backed GLX provider"
Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
Instead of only the fallback timer.
Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/854
v2:
* Drop unused frame_callback member of struct xwl_present_window
(Olivier Fourdan)
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Using a list of Present windows that need to be called back.
This prepares for the following change, there should be no change in
observed behaviour.
v2:
* Use xwl_window_create_frame_callback instead of making the
frame_listener struct non-static (Olivier Fourdan)
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Damage coordinates are relative to the drawable, (0,0) being the top
left corner inside the border.
Therefore, when applying damages or accumulating damages between window
buffers, we need to take the window border width into account as well,
otherwise the updates might be only partial or misplaced.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/951
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Right now, we would recycle the window buffers whenever the window the
window is resized.
This, however, is not sufficient to guarantee that the buffers are up
to date, since changing the window border width for example would not
trigger a `WindowResize` (the border being outside the window).
Make sure we recycle the buffers on `SetWindowPixmap` to ensure that
the buffers will be recycled whenever the pixmap size is changed.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/951
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
GetShift(int mask) can be called with mask==0, causing
it to go into an infinite loop.
Note: GetShift(mask) will return 0 for a mask of
both 0 and -1. The assumption is that if mask == 0,
then the corresponding bits for which we're calculating
the shift, are also 0.
The Present code sends the idle notification event to the client after
xwl_present_flush returns. If we don't flush our GPU work here, the
client may race to draw another frame to the same buffer, so we may end
up copying (parts of) that new frame instead of the one we meant to.
Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/835
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Xwayland takes care of not attaching a new buffer if a frame callback is
pending.
Yet, the existing buffer (which was previously attached) may still be
updated from the X11 side, causing unexpected visual glitches to the
buffer.
Add multiple buffering to the xwl_window and alternate between buffers,
to leave the Wayland buffer untouched between frame callbacks and avoid
stuttering or tearing issues.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/835
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add a mechanism to create, recycle and destroy window buffers when
needed.
Typically, this adds a new `xwl_window_buffer` structure which
represents a buffer for a given Xwayland window.
Each Xwayland window has two different pools of buffers:
- The available buffers pool:
Those are buffers which where created previously and that have either
not been submitted to the compositor or submitted and released.
- The unavailable buffers pool:
Those are typically the buffers which are being used by the
compositor, awaiting a release.
Initially, an Xwayland window starts with both pools empty. As soon as a
new buffer is needed, it's either created (if there is none available)
or picked from the pool of available buffers.
Once submitted to the compositor, the buffer is moved to the pool of
unavailable buffers. When the corresponding `wl_buffer` is released by
the compositor, it is moved back to pool of available buffers again to
be reused when needed.
To avoid keeping too many buffers around doing nothing, a garbage
collection of older, unused buffers also takes care of disposing the
buffers being unused for some time.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The API `wl_buffer_add_listener` is misleading in the sense that there
can be only one `wl_buffer` release callback, and trying to add a new
listener when once is already in place will lead to a protocol error.
The Xwayland EGL backends may need to set up their own `wl_buffer`
release listener, meaning that there is no way to our own `wl_buffer`
release callback.
To avoid the problem, add our own callback API to be notified when the
`wl_buffer` associated with an `xwl_pixmap` is released, triggered from
the different `xwl_pixmap` implementations.
Also update the Present code to use the new buffer release callback API.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
New now ask Glamor to use EGL_MESA_query_driver to obtain the DRI driver
name; if successful, we use that as the DRI driver name. Following the
existing dri2.c logic, we also use the same name for the VDPAU driver,
except for i965 (and now iris), where we switch to the "va_gl" fallback.
This allows us to bypass the PCI ID lists in xserver and centralize the
driver selection mechanism inside Mesa. The hope is that we no longer
have to update these lists for any future hardware.
If a new rotate buffer was allocated. This makes sure the new buffer
has valid transformed contents when it starts being displayed.
Reviewed-by: Adam Jackson <ajax@redhat.com>
This makes sure any pending drawing to a new scanout buffer will be
visible from the start.
This makes the finish call in drmmode_copy_fb superfluous, so remove it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
isastream() was never more than a stub in glibc, and was removed in
glibc-2.30 by commit a0a0dc83173c ("Remove obsolete, never-implemented
XSI STREAMS declarations").
Bug: https://bugs.gentoo.org/700838
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Now that we've fixed LoaderSymbolFromModule this should work properly.
This reverts commit 5c7c6d5cff.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The thing you get back from xf86LoadSubModule is a ModuleDescPtr, not a
dlsym handle. We don't expose ModuleDescPtr to the drivers, so change
LoaderSymbolFromModule to cast its void * argument to a ModuleDescPtr.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, when a X11 client (usually the X11 window manager from a
Wayland compositor) changes the value of the X11 property
`_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame
callbacks on the window are discarded so that the commit occurs
immediately.
Weston uses that mechanism to prevent the content of the window from
showing before it's ready when mapping the window initially, but
discarding the pending frame callbacks has no effect on the initial
mapping of the X11 window since at that point there cannot be any frame
callback on a surface which hasn't been committed yet anyway.
However, discarding pending frame callbacks can be problematic if we
were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent
damages to be posted before the X11 toplevel is updated completely
(including the window decorations from the X11 window manager).
Remove the portion of code discarding the pending frame callback,
Xwayland should always wait for a pending frame callback if there's one
before posting new damages.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/333
During startup, the xfree86 DDX's InitOutput() calls PreInit for
protocol screens first, and then GPU screens. On teardown, dix_main()
calls CloseScreen in the reverse order: GPU screens first starting with
the last one and then working backwards, and then protocol screens also
in reverse order.
InitOutput() calls ScreenInit in the wrong order: for GPU screens first and then
for protocol screens. This causes a problem for drivers that have global state
that is tied to the first screen that calls ScreenInit.
Fix this by simply re-ordering the for loops to call PreInit for
protocol screens first and then for GPU screens second.
ms_present_get_crtc() returns an RRCrtcPtr, but derives it from a xf86CrtcPtr
found via ms_dri2_crtc_covering_drawable()=>ms_covering_crtc(). As a result, it
depends on all associated DIX ScreenRecs having an xf86CrtcConfigPtr DDX
private.
Some DIX ScreenRecs don't have an xf86CrtcConfigPtr DDX private, but do have an
rrScrPrivPtr DDX private. Given that we can derive all of the information we
need from RandR, we can support these screens by avoiding the use of xf86Crtc.
This change implements an RandR-based path for ms_present_get_crtc(), allowing
drawables to successfully fall back to syncing to the primary output, even if
the slave doesn't have an xf86CrtcConfigPtr DDX private.
Without this change, if a slave doesn't have an xf86CrtcConfigPtr DDX private,
drawables will fall back to 1 FPS if they overlap an output on that slave.
Signed-off-by: Alex Goins <agoins@nvidia.com>
DIX ScreenRecs don't necessarily have an xf86CrtcConfigPtr DDX private.
ms_covering_crtc() assumes that they do, which can result in a segfault.
Update ms_covering_crtc() to check the XF86_CRTC_CONFIG_PTR() returned pointer
before dereferencing it. This will still mean that ms_covering_crtc() can't fall
back to the primary output when a drawable overlaps a slave output (going to the
1 FPS default instead), but it won't segfault.
Signed-off-by: Alex Goins <agoins@nvidia.com>
ms_covering_crtc() uses RRFirstOutput() to determine a primary output to fall
back to if a drawable is overlapping a slave output.
If the primary output is a slave output, RRFirstOutput() will return a slave
output even if passed a master ScreenPtr. ms_covering_crtc() dereferences the
output's devPrivate, which is invalid for non-modesetting outputs, and can
crash.
Changing RRFirstOutput() could have unintended side effects for other callers,
so this change replaces the call to RRFirstOutput() with ms_first_output().
ms_first_output() ignores the primary output if it doesn't match the given
ScreenPtr, choosing the first connected output instead.
Signed-off-by: Alex Goins <agoins@nvidia.com>
For some reason, indentation for EGL backend hooks was broken.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, Xwayland pixmap SHM code uses `malloc()` to allocate the
xwl_pixmap.
Use `calloc()` instead, as the EGLstream backend does, as it is safer
(initializing the allocated data to 0).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Currently, glamor GBM backend uses `malloc()` to allocate the
xwl_pixmap.
Use `calloc()` instead, as the EGLstream backend does, as it is safer
(initializing the allocated data to 0).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The definition by the manual is `calloc(size_t nmemb, size_t size)`.
Swap the arguments of calloc() calls to match the definition.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When a pixmap is created with a backing FBO, the FBO should be cleared
to avoid rendering uninitialized memory. This could happen when the
pixmap is rendered without being filled in its entirety.
One example is when a top-level window without a background is
resized. The pixmap would be reallocated to prepare for more pixels,
but uninitialized memory would be rendered in the resize offset until
the client sends a frame that fills these additional pixels.
Another example is when a new top-level window is created without a
background. Uninitialized memory would be rendered after the pixmap is
allocated and before the client sends its first frame.
This issue is only apparent in OpenGL implementations that don't zero
the VRAM of allocated buffers by default, such as RadeonSI.
Signed-off-by: Dor Askayo <dor.askayo@gmail.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/636
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
`glGetString(GL_VERSION)` will return NULL without a current context.
Commit dabc7d8b (“xwayland: Fall back to GLES2 if we don't get at least
GL 2.1 in glamor”) would check the context is created, but it is made
current just after, so the call to `epoxy_gl_version()` would return 0,
hence defeating the version check.
Make the context current prior to call `epoxy_gl_version()`.
Fixes: dabc7d8b - xwayland: Fall back to GLES2 if we don't get at least
GL 2.1 in glamor
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/932https://gitlab.freedesktop.org/xorg/xserver/merge_requests/324
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Some particularly unfortunate hardware (Intel gen3, mostly) will give
you GLES2 but not GL 2.1. Fall back to GLES2 for such cases so you still
get accelerated GLX.
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS,
EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers
shipped with libglvnd.
This fixes the xserver not building with the libglvnd-1.2.0 headers:
In file included from /usr/include/EGL/eglplatform.h:128,
from /usr/include/epoxy/egl_generated.h:11,
from /usr/include/epoxy/egl.h:46,
from glamor_priv.h:43,
from glamor_composite_glyphs.c:25:
/usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC'
222 | *GC;
| ^~
In file included from glamor.h:34,
from glamor_priv.h:32,
from glamor_composite_glyphs.c:25:
../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here
282 | } GC;
| ^~
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Slightly simplifies the callers since they don't need to check for
non-NULL anymore.
I do extremely hate the workarounds here to suppress misprite taking the
cursor down though. Surely there's a better way.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Populate outout possible_crtcs as the union of possible_crtcs from
the encoders rather than the intersection. Otherwise we're easily left
with possible_crtcs==0 when all the possible encoders have
non-overlapping possible_crtcs.
No idea what the magic 0x7f is about, but keep it around in case
it matters.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Apps using randr to change the resolution when going fullscreen, in
combination with _NET_WM_STATE_FULLSCREEN to tell the window-manager (WM)
to make their window fullscreen, expect the WM to give the fullscreen window
the size of the emulated resolution as would happen when run under Xorg (*).
We need the WM to emulate this behavior for these apps to work correctly,
with Xwaylands resolution change emulation. For the WM to emulate this,
it needs to know about the emulated resolution for the Windows owning
client for each monitor.
This commit adds a _XWAYLAND_RANDR_EMU_MONITOR_RECTS property, which
contains 4 Cardinals (32 bit integers) per monitor with resolution
emulation info. Window-managers can use this to get the emulated
resolution for the client and size the window correctly.
*) Since under Xorg the resolution will actually be changed and after that
going fullscreen through NET_WM_STATE_FULLSCREEN will size the window to
be equal to the new resolution.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Games based on the allegro gaming library or on ClanLib-1.0 do not size
their window to match the fullscreen resolution, instead they use a
window covering the entire screen, drawing only the fullscreen resolution
part of it.
This commit adds a check for these games, so that we correctly apply a
viewport to them making fullscreen work properly for these games under
Xwayland.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for fake mode changes using viewport, for apps which want to
change the resolution when going fullscreen.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
crtc->mode reflects the mode set through the xrandr extension, once we
add support for also changing the mode through the vidmode extension this
will no longer correctly reflect the emulated resolution.
Add a new xwlVidModeGetCurrentRRMode helper which determines the mode by
looking at the emulated_mode instead.
Likewise add a xwlVidModeGetRRMode helper and use that in
xwlVidModeCheckModeForMonitor/xwlVidModeCheckModeForDriver to allow any
mode listed in the randr_output's mode list.
This is a preparation patch for adding emulated mode/resolution change
support to Xwayland's XF86 vidmode extension emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation patch for adding emulated mode/resolution change
support to Xwayland's XF86 vidmode extension emulation, using the
Wayland viewport extension.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for per client randr-resolution change emulation using viewport,
for apps which want to change the resolution when going fullscreen.
Partly based on earlier work on this by Robert Mader <robert.mader@posteo.de>
Note SDL2 and SFML do not restore randr resolution when going from
fullscreen -> windowed, I believe this is caused by us still reporting the
desktop resolution when they query the resolution. This is not a problem
because when windowed the toplevel window size includes the window-decorations
so it never matches the emulated resolution.
One exception would be the window being resizable in Windowed mode and the
user resizing the window so that including decorations it matches the
emulated resolution *and* the window being at pos 0x0. But this is an
extreme corner case. Still I will submit patches upstream to SDL2
and SFML to always restore the desktop resolution under Xwayland,
disabling resolution emulation all together when going windowed.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for storing per output randr/vidmode emulated resolution
into the per client data.
Since we do not have a free/delete callback for the client this uses
a simple static array. The entries are tied to a specific output by the
server_output_id, with a server_output_id of 0 indicating a free slot
(0 is the "None" Wayland object id).
Note that even if we were to store this in a linked list, we would still
need the server_output_id as this is *per client* *per output*.
This is a preparation patch for adding randr/vidmode resolution
change emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add per client private data, which for now is empty.
This is a preparation patch for adding randr/vidmode resolution
change emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This adds the RandR 1.2 interface to xwayland and allows modes
advertised by the compositor to be set in an undistructive manner.
With this patch, applications that try to set the resolution will usually
succeed and work while other apps using the same xwayland
instance are not affected at all.
The RandR 1.2 interface will be needed to implement fake-mode-setting and
already makes applications work much cleaner and predictive when a mode
was set.
[hdegoede@redhat.com: Make crtc_set only succeed if the mode matches
the desktop resolution]
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation patch for adding support for apps which want to
change the resolution when they go fullscreen because they are hardcoded
to render at a specific resolution, e.g. 640x480.
Follow up patches will fake the mode-switch these apps want by using
WPviewport to scale there pixmap to cover the entire output.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a viewport is set, damage will only work properly when using
wl_surface_damage_buffer instead of wl_surface_damage.
When no viewport is set, there should be no difference between
surface and buffer damage.
This is a preparation patch for using viewport to add support for fake
mode-changes through xrandr for apps which want to change the resolution
when going fullscreen.
Changes by Hans de Goede <hdegoede@redhat.com>:
-Split the damage changes out into their own patch
-Add xwl_surface_damage helper
-Also use buffer_damage / the new helper for the present and cursor code
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This commit adds support for the wayland wp_viewport extension, note
nothing uses this yet.
This is a preparation patch for adding support for fake mode-changes through
xrandr for apps which want to change the resolution when going fullscreen.
[hdegoede@redhat.com: Split the code for the extension out into its own patch]
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This commit adds DRI3/glamor support, effectively translating into
hardware GPU support.
Theoretically it should be possible to use DRM/GPU drivers such as
virtio or vgem, although only the intel i915 driver is currently tested.
Since Xvfb does no modeset, it opens the render node. Currently that is
fixed to "/dev/dri/renderD128" and will be tweaked with future commits.
Specific use-cases are left for the reader - testing glamor, GL driver
or others.
v2: Drop GLAMOR_NO_XV, use GLAMOR_FOR_XORG instead (Michel Dänzer)
v3: Fix build w/o glamor
v4:
- Split out glamor dependency patch for meson (Pekka)
- Enhance commit message (Pekka)
- Use O_CLOEXEC with open() (Pekka)
- Enhance error path, memory leak comments (Pekka)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently we parse through xf86Info.debug to check if we the modifiers
should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS
into the glamor_init() flags.
This allows individual DDX control over the setting - say when modifiers
are woking OK with one implementation and not the other.
Most importantly, this removes the final xf86 piece from the codebase.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Move from the xf86 specific ScrnInfoRec::privates, to the dix private
handling. Since there's no FreeScreen function in ScreenPtr, fold the
former within the existing CloseScreen.
Users, such as modesetting are updated, and out of tree drivers will
need equivalent, yet trivial, patch.
Note: we need to ensure that the screen private is unset and the screen
callbacks are restored in our CloseScreen function.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The autoconf build for the modesetting driver still relied on
xorg-macros.m4 for string replacements and did not include the
top-level manpages.am. As a result, no substitutions took place after
commit 2e497bf887.
This should be a candidate for the 1.20 branch.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
There's not really a good reason to keep these separate, the vbe code
requires int10 and is not very large. This change eliminates the
build-time options for vbe; if you build int10, you get vbe.
Gitlab: https://gitlab.freedesktop.org/xorg/xserver/issues/692
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
i965 and radeonsi, respectively, are the drivers that have been
receiving new hardware support. It's really silly to need to update the
server side to know specific new devices IDs every time a new ASIC comes
out.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This might be an error or not, for example refusing to work on llvmpipe
is normal and expected. glamor_egl_init() will print X_ERROR messages if
appropriate, so we don't need to here.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This fixes 'non-desktop' displays staying powered on after their lease
has been revoked.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111620
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
In non-rootless mode, not all pixmaps need a wl_buffer backing.
Suggested-by: Twaik Yont (@twaik) in #834
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The compositor may send DRM_FORMAT_MOD_INVALID instead of a list of
modifiers for various reasons. Handle this gracefully by ignoring it.
Without this, if a compositor would send DRM_FORMAT_MOD_INVALID, it'd
result in empty windows provided by Xwayland.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add an -icon option to set the screen window icon in windowed mode
Allow cygwin paths in an icon-specification
Update man pages and system.XWinrc appropriately
Also, log an error if the icon specified for TRAYICON cannot be loaded
Also, fix a bug in appending a '\' to IconDirectory only if it doesn't
already end with one, which was fortunately benign.
Note: LoadImageComma would be simpler if we just stated that XWinrc
paths are Cygwin paths on Cygwin, Windows paths on MinGW, but that could
break existing .XWinrc files
Note: Given that we can specify paths in an icon-specifier, I'm not sure
what IconDirectory wins us.
v2:
Fix formatting problems in man page additions
v3:
Fix some more s/_/@/g in man pages
This FD also triggers the "wait for WM_S0" paths, so that the
compositor may set up a "maintenance line" for Xwayland, for
services that are essential to run before any client (eg. xrdb).
Those services would use this FD, disguised as an extra display
connection.
This -initfd can be seen as a generalization of -wm, a Wayland
compositor may use -initfd to launch its WM and any other clients
that should start up, or it may use -wm as a dedicated connection for
the WM and optionally use -initfd for the misc. startup clients.
If either of -wm or -initfd is passed, Xwayland will expect a selection
notification on WM_S0 before incorporating the FDs in -listen to the
poll list.
Also, correct a minor typo in the listenfd argument output,
give → given.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
If Xwayland gets to realize a window meant for composition before the
compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
yet), the window would stay "invisible" as we wouldn't create a
wl_surface/wl_shell_surface for it at any later point.
This scenario may happen if the wayland compositor sets up a X11 socket
upfront, but waits to raise Xwayland until there are X11 clients. In this
case the first data on the socket is the client's, the compositor can hardly
beat that in order to redirect subwindows before the client realizes a
Window.
In order to jump across this hurdle, allow the late creation of a matching
(shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
to be created after the compositor set up redirection.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Michel Dänzer
Olivier Fourdan
orbea
Łukasz Spintzyk
Povilas Kanapickas
Zoltán Böszörményi
Daniel Strnad
Lukasz Spintzyk
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
Uday Kiran Pichika
Roman Gilg
Ignacio Casal Quinteiro
Alex Goins
Emmanuel Gil Peyrot
Lyude Paul
Dave Airlie
SimonP
Sjoerd Simons
Jose Maria Casanova Crespo
Martin Weber
Aaron Ma
Matthieu Herrb
Jan Beich
Carlos Garnacho
Christopher Chavez
Alexander Volkov
Tobias Stoeckmann
Michael Stapelberg
Yuriy Vasilev
mntmn
Hans de Goede
Zoltán Böszörményi
David Seifert
Fabrice Fontaine
dslater38
Kenneth Graunke
Matt Turner
Dor Askayo
Ville Syrjälä
Keith Packard
Robert Mader
Emil Velikov
Sven Joachim
Andres Rodriguez
Jonas Ådahl