paths returned by get_option('foodir') are potentially relative to prefix
Noticed when comparing manpages generated by a meson build with those
generated by an autotools build
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 49283e238a)
This lets an application open a suitable DRM device and pass the file
descriptor to the mode setting driver through an X server command line
option, '-masterfd'.
There's a companion application, xlease, which creates a DRM master by
leasing an output from another X server. That is available at
git clone git://people.freedesktop.org/~keithp/xlease
v2:
Always print usage, but note that it can't be used if
setuid/gid
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
(cherry picked from commit 38ff29ec8e)
This really sucked to find out :(
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
(cherry picked from commit c41d4ff48f)
KMS drivers are not required to support GEM. In particular, vmwgfx
doesn't support flink and handles and names are identical.
Getting a bo name should really be part of a lower level API, if needed,
but in the mean time work around this by setting the name identical to
the handle if GEM isn't supported.
This fixes modesetting driver dri2 on vmwgfx.
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
(cherry picked from commit 9f02855e7a)
This seems like a problem worth screaming about.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit dc90b1c3c3)
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")
(cherry picked from commit 186a21c4ba)
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>
(cherry picked from commit c12f1bd4b7)
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>
(cherry picked from commit a85e94a50c)
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>
(cherry picked from commit f5aace7a27)
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>
(cherry picked from commit f33cb42643)
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>
(cherry picked from commit 92daeb31fa)
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>
(cherry picked from commit 792359057b)
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>
(cherry picked from commit bdadaa25f5)
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>
(cherry picked from commit 5d843f6947)
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>
(cherry picked from commit d7185a84b6)
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>
(cherry picked from commit 48f037a27c)
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>
(cherry picked from commit f2fcb4877e)
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>
(cherry picked from commit b74b0f18b8)
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>
(cherry picked from commit de004eefc6)
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>
(cherry picked from commit b823b43dca)
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>
(cherry picked from commit 78ce4aa979)
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>
(cherry picked from commit f6b2109c1b)
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>
(cherry picked from commit d31a7be15e)
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>
(cherry picked from commit e16a6da79d)
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>
(cherry picked from commit dbde3fec32)
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>
(cherry picked from commit 06c31e782e)
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>
(cherry picked from commit 707d0f912b)
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>
(cherry picked from commit ec7e2b54c5)
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>
(cherry picked from commit 5c95be38e5)
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>
(cherry picked from commit 1993f147d0)
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
(cherry picked from commit 10eec2ccb1)
Pointed out on irc by q66.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 6300049a9a)
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>
(cherry picked from commit 40586cc4f8)
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>
(cherry picked from commit cefbc6a935)
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>
(cherry picked from commit 3ebef6ab85)
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>
(cherry picked from commit 4d5950ce14)
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>
(cherry picked from commit 3da999a039)
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>
(cherry picked from commit 315c63c41d)
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>
(cherry picked from commit ab53e2859f)
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>
(cherry picked from commit 7437b6dbde)
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>
(cherry picked from commit 3ab32a5378)
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>
(cherry picked from commit 27eff10bfa)
Omitted from a1e8dc05
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
(cherry picked from commit 08a3583b5b)
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>
Because this is an automakefile, things inside @@ get expanded, which
means your sed ends up saying s|/var/log|/var/log| and your manual pages
still have @logdir@ in them. Fix this by hiding the @s inside a trivial
character range, which keeps the pattern preserved all the way into the
Makefile.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
