This is needed by radeonsi to support multi plane modifier when
using modesetting DDX.
xserver reject any multi plane buffer (in DRI3PixmapFromBuffers)
without the dmabuf_capable debug option. It's OK for single plane
buffer as xserver will fallback to DRI3BufferFromPixmap path.
amdgpu DDX does not expose DRI3PixmapFromBuffers, mesa just use
the single plane path anyway, so amdgpu DDX does not have this
problem.
Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2091>
The old code tried to use a screen pointer that was uninitialized and set to NULL.
This caused it to segfault when this option was set.
When this option was used with the modesetting driver, `glamor_egl_init`
is called indirectly in the driver PreInit proc.
`xf86ScrnToScreen(scrn)` then returns NULL.
This patch moves setting the gl vendor later in the initialization process,
when we already have a non-null pScreen.
Minimal reproducer:
```
$ cat /etc/X11/xorg.conf.d/99-screen.conf
Section "Screen"
Identifier "Default"
Option "GlxVendorLibrary" "Name"
EndSection
```
Backtrace:
```
| #0 in abort ()
| #1 in OsAbort () at os/utils.c:1361
| #2 in AbortServer () at os/log.c:879
| #3 FatalError () at os/log.c:1017
| #4 in OsSigHandler () at os/osinit.c:156
| #5 OsSigHandler () at os/osinit.c:110
| #6 <signal handler called>
| #7 in __pthread_kill_implementation () from /lib64/libc.so.6
| #8 in raise () from /lib64/libc.so.6
| #9 in abort () from /lib64/libc.so.6
| #10 in __assert_fail_base.cold () from /lib64/libc.so.6
| #11 in xf86ScrnToScreen () at hw/xfree86/common/xf86Helper.c:1734
| #12 in glamor_egl_init () at glamor/glamor_egl.c:1108
| #13 in try_enable_glamor () at hw/xfree86/drivers/modesetting/driver.c:984
| #14 PreInit () at hw/xfree86/drivers/modesetting/driver.c:1211
| #15 in InitOutput () at hw/xfree86/common/xf86Init.c:478
| #16 in dix_main () at dix/main.c:190
| #17 main () at dix/stubmain.c:34
```
Fixes: a449bb4c5 - glamor_egl: add support of GlxVendorLibrary option
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2096>
(cherry picked from commit eccee47185)
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_render.c:1577:21:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit 6a4ec30af4)
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_dash.c:152:10:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit c6522229b8)
We know that if gc->tileIsPixel is false, then gc->tile.pixmap must be
a valid pixmap, but gcc's static analyzer doesn't and needs to be told.
Silences false positive reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_core.c:205:19:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit a79bdc495e)
Unlike GetPictureScreen(), GetPictureScreenIfSet() checks if the
private key is registered, and returns NULL if it is not.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor.c:926:5:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘ps’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit 69b48423bd)
The EXT_blend_func_extended extension on ESSL always requires explicit
request to allow two FS out variables because of limitations of the ESSL
language, which is mentioned as the No.6 issue of the extension's
specification.
Fix this by adding the extension request.
The original behavior on GLES3 is slightly against the specification of
GL_EXT_blend_func_extended extension, however Mesa and older version of
PowerVR closed drivers will just ignore this issue. Newest PowerVR
closed driver will bail out on this problem, so it deems a fix now.
Fixes: ee107cd491 ("glamor: support GLES3 shaders")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1750>
(cherry picked from commit eba15f1ba7)
The OpenGL 4.6 specification §14.5.1 "Basic Line Rasterization"
figure 14.2 says:
"""A diamond shaped region of height 1 is placed around each fragment
center; those regions that the line segment **exits** cause
rasterization to produce corresponding fragments."""
As the line does not necessarily exit the last diamond,
it is necessary to explicitly paint a pixel at line ends.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1434
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1755>
(cherry picked from commit 530e80375e)
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
(cherry picked from commit c46e645bad)
The supported color depths is a hardcoded list for now, so we
need to honor the value exposed there otherwise we'll get
inconsistencies between what glXGetFBConfigs and XListDepths
report to applications.
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1764>
(cherry picked from commit 5397854877)
This way the caller knows if the conversion failed.
While at it, check for width/height at the same time.
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1764>
(cherry picked from commit 87afcc7699)
This header includes libxfont2.h, but the dependency isn't stated anywhere,
causing some drivers to FTBS (when libxont2.h is in non-standard location).
Since this header doesn't seem to need including libxfont2.h at all, just
stop including it, instead of adding yet another dependency to server SDK.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1610>
(cherry picked from commit 646831cda2)
We alread have several of these calls, that aren't interested in result value,
explicitly casting to void. Fixing this up for the remaining ones.
This is helpful for the human reader as well as quality analysis tools.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1648>
(cherry picked from commit f26f17c66a)
This rewrites the shader so that we use the same (more flexible) CSC as
we have for I420 and NV12. This also fixes the reverse of odd/even which
caused chroma shift.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1633>
(cherry picked from commit 39c8a6f367)
UYVY videos should be aligned by 2 to avoid breakups in the shader
Fixes: 832b392f7 - glamor: xv: enable UYVY acceleration
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1633>
(cherry picked from commit eb26f32368)
Check actual BPP by render_format in upload_boxes, not by drawable BPP.
It is required when we used different BPP formats for storing and
rendering (for example, in the case of UYVY).
The problem of UYVY size lies inside method of glamor downloading boxes.
When we set GLAMOR_CREATE_FORMAT_CBCR, it actually uses 16-bit GL and
Pixman formats, but before this change in glamor_download_boxes, that
function deduces GL and Pixman formats from BPP, which is wrong in this
case (will be deduced to 32).
When GL and Pixman format BPP is identical to drawable BPP, this change
does nothing, but when it is different - it will prioritize Pixman
format, not the format deduced from BPP.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1730
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1633>
(cherry picked from commit 75f56b7923)
If glamor_link_glsl_prog() fails, we may jump to the failed code path
which frees the variable vs_prog_string and fs_prog_string.
But those variables were already freed just before, so in that case we
end up freeing the memory twice.
Simply move the free at the end of the success code path so we are sure
to free the values only once, either in the successful of failed code
paths.
Fixes: 2906ee5e4 - glamor: Fix leak in glamor_build_program()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1629>
(cherry picked from commit 34ea020344)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit dec57e5796)
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Fixes: ded6147bfb
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
(cherry picked from commit c55ddd072b)
Several places using _X_ATTRIBUTE_PRINTF macro from X11/Xfuncproto.h
but missing to include it, so it depends on other headers whether it's
included by mere accident, which quickly causes trouble if include order
changes. Cleaning that up by adding explicit include statements.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1580>
(cherry picked from commit b30edf326b)
Clears -Wcalloc-transposed-args warnings from gcc 14.1, such as:
../dix/main.c:165:42: warning: ‘calloc’ sizes specified with ‘sizeof’ in the
earlier argument and not in the later argument [-Wcalloc-transposed-args]
165 | serverClient = calloc(sizeof(ClientRec), 1);
| ^~~~~~~~~
../dix/main.c:165:42: note: earlier argument should specify number of
elements, later size of each element
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1606>
(cherry picked from commit 522f469fe9)
This really looks like a leftover from b861aad8e2.
In any case, if that function shall become part of extension/driver API,
it should be declared with _X_EXPORT in some suitable header file - locally
declaring extern really isn't a good idea and just an invitation for subtle bugs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1265>
(cherry picked from commit 113ffdf85c)
It caused an incorrect result of the blend operation.
Use glColorMask to prevent non-1.0 alpha channel values in a depth 32
pixmap backing an effective depth 24 window. For blending operations,
the expectation is that the destination drawable contains valid pixel
values, so the alpha channel should already be 1.0.
Fixes: d1f142891e ("glamor: Ignore destination alpha as necessary for composite operation")
Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3104
With the potential modeset vs. modifiers issue covered by
commit 899c87af1f ("modesetting: unflip before any setcrtc() calls")
we can safely enable modifiers by default, at least on Intel
hardware where we know that things work properly.
I suppose the one open question is whether everything will work
correctly with wonky multi-GPU setups? I don't have one to test
myself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
On certain system deployments, /dev/dri/card* nodes aren't directly
accessible to the currently logged in user, but the display server only
access it by asking systemd-logind to open the device for it. This
causes the X server to fail when trying to re-open the card* device
directly, causing all use of DRI3 to fail.
Fix this by using the render device path instead where possible.
This commit adds RGB565 format to XVideo with reuse of RGBA32 shader
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>
This commit adds RGBA32 format to XVideo along with shader for handling it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>
This commit adds UYVY format in XVideo for Glamor
along with shader support.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
As a preparation to one-plane formats (for example, UYVY), second
texture definition is moved inside a format switch, and all allocations
now also done inside a texture switch.
No functional change.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Xv currently calls glamor_xv_free_port_data at the end of every putImage.
This leads to shader recompilation for every frame, which is a huge performance loss.
This commit changes behaviour of glamor_xv_free_port_data, and its now is called only
if width, height or format is changed for xv port.
Shader management also done in a port now, because if shaders will be
stored in core glamor and try to be reused, this can lead to a bug if we
try to play 2 videos with different formats simultaneously.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
There is a no need to force a low version for XV shaders, it will
work on higher version too.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
The recent commit a563f530 - "glamor/glxprov: Stop exposing non-db
(-capable) configs" was aiming at reducing the number of advertised
visuals for optimizing GLX initialization.
Unfortunately, GL applications which rely exclusively on single-buffered
visuals will fail to find a suitable visual with this.
Revert the commit to expose the single-buffered visuals and restore the
compatibility with applications which rely on single-buffered configs.
This reverts commit a563f530f6
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Xephyr now gained an ability to use glamor glx provider.
Unfortunately, without DRI3, we end up with same llvmpipe as before
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
This allows Xorg to use Glamor GLX when Glamor is requested,
and eliminates usage of DRI2 in case of Glamor.
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Emma Anholt <emma@anholt.net>
