When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.
This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:
- Find a laptop with DRI prime that has outputs connected to the
dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail
Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
So, this did actually work on older kernels at one point in time,
however it seems that this working was a result of some of the Linux
kernel's atomic modesetting helpers not preserving the CRTC's enabled
state in the right spots. This was fixed in:
846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2")
As a result, atomic commits which simply disassociate a DRM connector
with it's CRTC while leaving the CRTC in an enabled state aren't enough
to disable the CRTC, and result in the atomic commit failing. This
currently can cause issues with MST hotplugging where X will end up
failing to disable the MST outputs after they've left the system. A
simple reproducer:
- Start up Xorg
- Connect an MST hub with displays connected to it
- Remove the hub
- Now there should be CRTCs stuck on the orphaned MST connectors, and X
won't be able to reclaim them.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This isn't used for anything, which is just as well, because
/etc/xorg.conf is not in fact a path xserver will try to use.
Bugzilla: https://bugs.freedesktop.org/8890
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
the format is not as expected, preventing from using a rotated output.
Change it to use the new function drmmode_bo_import() which takes care
of calling the drmModeAddFB2() API.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Tomas Pelka <tpelka@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Any DPMS timeout values set in ServerFlags section of the xorg.conf
are being overwritten by DPMS extension initialization. Therefore
change the DPMS initialization of timeout values to be conditional on
not set from config.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106963
Signed-off-by: John Lumby <johnlumby@hotmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If a driver calls AttendClient() from within a timer callback we
need to re-compute the local 'are_ready' to prevent the attended
client from waiting until WaitForSomething() times out.
This is a fix similar to commit 9ed5b263.
Signed-off-by: Damien Leone <dleone@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
The API init_wl_registry() and has_wl_interfaces() are marked as being
optional, but both GBM And EGLStream backends implement them so there is
point in keeping those optional.
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
When retrieving the Wayland buffer from a pixmap, if the buffer already
exists, the GBM backend will return that existing buffer.
However, as seen with the Present issues, if the call had previously
passed a wrong size, that buffer will remain at the wrong size for as
long as the buffer exists, which is error prone.
Considering that the width/height passed to get_wl_buffer() is always the
actual pixmap drawable size, and considering that the EGLStream backend
makes no use of the size either, there is really no point in passing the
width/height around.
Simplify the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by
removing the pixmap size, and use the drawable size instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority"
extension, make sure it's actually available before using it.
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Now that we have separate backends for EGLStream and GBM, we can
explicitly check for the EGLStream backend to disable present support
in that case.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
To be able to check for availability of the Wayland interfaces required
to run a given EGL backend (either GBM or EGLStream for now), we need
to have each backend structures and vfuncs in place before we enter the
Wayland registry dance.
That basically means that we should init all backends at first, connect
to the Wayland compositor and query the available interfaces and then
decide which backend is available and should be used (or none if either
the Wayland interfaces or the EGL extensions are not available).
For this purpose, hold an egl_backend struct for each backend we are to
consider prior to connect to the Wayland display so that, when we get to
query the Wayland interfaces, everything is in place for each backend to
handle the various Wayland interfaces.
Eventually, when we need to chose which EGL backend to use for glamor,
the available Wayland interfaces and EGL extensions available are all
known to Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Move EGL backends initialization to its own function in
xwayland-glamor.c
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Introduces a new egl_backend function to let the EGL backend check for
the presence of the required Wayland interfaces.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
EGL backend availability requires both EGL extensions and Wayland
interfaces to be present, so we will need to consider multiple backends
during initialization.
As a preliminary work, move the egl_backend to its own struct so that we
can have more than one backend at any given time.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
If using a render node, we can skip DRM authentication.
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Surely, we should fail to init GBM backend if "GL_OES_EGL_image" is
missing.
This seems to have been lost with commit 1545e2dba ("xwayland: Decouple
GBM from glamor").
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Both xwl_glamor_init_wl_registry() and the Wayland global registry
handler use the interface id/name in that order, using name/id in the
egl_backend vfunc makes things confusing and error prone.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Functions such as:
xwl_glamor_egl_supports_device_probing()
xwl_glamor_egl_get_devices()
xwl_glamor_egl_device_has_egl_extensions()
Are of no use outside of EGLStream support, move them to the relevant
source file.
Similarly, the other glamor functions such as:
xwl_glamor_init()
xwl_screen_set_drm_interface()
xwl_screen_set_dmabuf_interface()
xwl_glamor_pixmap_get_wl_buffer()
xwl_glamor_init_wl_registry()
xwl_glamor_post_damage()
xwl_glamor_allow_commits()
xwl_glamor_egl_make_current()
Are useless without glamor support enabled, move those within a
a "#ifdef XWL_HAS_GLAMOR" in xwayland.h
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Make xwl_output_get_xdg_output() private, it doesn't need to be
available elsewhere.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
EGLStream requires glamor, but the opposite is not true. So if someone
passes "-eglstream" with a GPU which does not support EGLStream, we
could maybe still try GBM and be lucky.
That allows Wayland compositors to pass "-eglstream" regardless of the
actual hardware, if they want to enable EGLStream on GPU which support
it.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
eglQueryDevicesEXT() would abort if the required extensions are not
available, meaning that enabling “-eglstream” on a non-EGLStream
capable hardware would lead to an abort().
Check that "EGL_EXT_device_base" extension is available and bail out
early if not, so we don't abort() later in eglQueryDevicesEXT().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The command line option "-eglstream" used to enable EGLStream support
for NVidia GPU was made available only when Xwayland was built with
EGLStream support enabled.
Wayland compositors who spawn Xwayland have no easy way to tell whether
or not Xwayland was built with EGLStream support enabled, and adding
"-eglstream" command line option to Xwayland when it wasn't built with
EGLStream support would prevent Xwayland from starting (“Unrecognized
option” error).
Make sure we support the command line option "-eglstream" regardless of
EGLStream support in Xwayland. Obviously, if Xwayland was built without
EGLStream support, this has no effect.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The keySize parameter of the hashing/comparison functions was
incorrectly specified to be sizeof(void*), even though the keys of
this hashtable are CARD32.
Fixes address sanitizer failure on 64-bit builds.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Changes the device name from "xwayland-stylus" to "xwayland-tablet stylus".
This doesn't fully address #26 but it goes a little step into making it more
human-readable.
https://gitlab.freedesktop.org/wayland/wayland/issues/26
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Avoid access to System V shared memory segment on the X server side
for clients forwarded via SSH. Also prevent them from hanging while
waiting for the reply from the ShmCreateSegment request.
v2: Allow ShmQueryVersion request even for remote clients
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=11080
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Change the 'chown' statement in Makefile.am to use the numeric UID
of superuser instead of relying on the name 'root'.
Bugzilla: https://bugs.freedesktop.org/27726
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michał Górny <gentoo@mgorny.alt.pl>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In commit 9db2af6f75 (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.
Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
If the pixmap size does not match the present box size, flickering
occurs.
This can happen when the client changes its size (e.g. switching to
fullscreen), and since the buffer is kept as long as the pixmap is
valid, once the buffer is created, it remains at the wrong (old) size
and causes continuous flickering.
Use the actual pixmap's drawable size instead of the present box to
create the buffer so that it's sized appropriately.
Bugzilla: https://bugs.freedesktop.org/106841
Fixes: 0fb2cca193 "xwayland: Preliminary support for Present's new
window flip mode"
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
The incorrect values could result in the new pixmap's contents
getting corrupted down the line.
v2:
* Guard screen_x/y lines by #ifdef COMPOSITE
Bugzilla: https://bugs.freedesktop.org/106841
Fixes: 029608dd80 "present: Add window flip mode"
Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
Reviewed-by: Keith Packard <keithp@keithp.com> # v1
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com> # v1
This has caused nonsensical values in xinput output.
Signed-off-by: Roman Kapl <code@rkapl.cz>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The byte-swapping code forgot that the xXIButtonInfo is followed by a
button mask, not directly by the button labels. This resulted in client
crashes in cross-endian setups, for example in `xinput list --long`,
since the client got an invalid atom.
A new function was introduced to get the right positions for the label
and mask data.
Signed-off-by: Roman Kapl <code@rkapl.cz>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was left disabled in 1.20.0, it's time to start being sure it
works.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Their pFormat member is NULL, which resulted in a crash in
miRenderColorToPixel.
Fixes: 8171d4c2d6 "render: Store and use all 16bpc of precision for
solid pixels (v2.1)"
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor_fds_from_pixmap returns 0 on error, but we were treating that as
success, continuing with uninitialized stride and fd values.
Also bail if the offset isn't 0, same as in dri3_fd_from_pixmap.
v2:
* Reduce to a simple one-liner fix (Emil Velikov)
Fixes: c8c276c956 "glamor: Implement PixmapFromBuffers and
BuffersFromPixmap"
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This matches what glamor_egl_fds_from_pixmap and dri3_fds_from_pixmap do
and what proc_dri3_buffers_from_pixmap expects.
Fixes: c8c276c956 "glamor: Implement PixmapFromBuffers and
BuffersFromPixmap"
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
We don't want DRM file descriptors to leak to child processes.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
It was passing O_CLOEXEC as permission bits instead of as a flag.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
As we are not freeing elements while iterating the list of timers, we
can forgo using the safe variant, and reduce the number of pointer
dances required for the insertion sort.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently, we use xorg_list_add(new, head->prev) which is functionaly
equivalent to xorg_list_append(), but with more pointer chasing, so
reduce the strain on the reader and compiler by using the simpler
append().
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hi,
I upgraded Xwayland and the assorted libraries from git masters today,
and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
error was:
No provider of glVertexAttribDivisor found. Requires one of:
Desktop OpenGL 3.3
OpenGL ES 3.0
GL extension "GL_ANGLE_instanced_arrays"
GL extension "GL_ARB_instanced_arrays"
GL extension "GL_EXT_instanced_arrays"
GL extension "GL_NV_instanced_arrays"
The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
rendering assumes that glVertexAttribDivisor() is always available on
GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
work fine again on this platform. After chatting with ajax in
#xorg-devel, the following solution was proposed.
This is my first time of submitting a patch, so please excuse me and
advise if I'm doing it wrong ;)
Cheers
Lukas (mntmn)
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Fixes using GL with the modesetting driver for me.
Seems we were way behind on this one, time to look into something
more scalable?
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Instead, substitute the same values as autotools does
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
meson.build has code to set the module_dir variable to
${libdir}/xorg/modules if the module_dir option string is empty.
However, this has several problems:
1. The variable is only used for an unused @moduledir@ substitution in
the man page. The rule for xorg-server.pc uses option('module_dir')
directly instead.
2. The 'module_dir' option has a default value of 'xorg/modules' so the
above rule doesn't do anything by default.
3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so
the effect of #2 is that the default moduledir is different between
autoconf and meson. E.g. if ${prefix} is /X, then you get
autoconf: moduledir=/X/lib/xorg/modules
meson: moduledir=/X/xorg/modules
Fix this by using the module_dir variable when generating xorg-server.pc, and by
using join_paths() to assign module_dir unconditionally.
v2: Keep the 'xorg/modules' default path, but use join_paths() unconditionally (Thierry Reding)
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Modifiers support needs gbm as a dependency. Without setting the dependency
included headers are not found reliably and the build might fail if the
headers are not placed in the default system include paths.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
