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>
It always had it's own lifecycle (not been part of Xorg releases),
doesn't make sense to maintain a competing implementation that we
won't use anyways.
Once that's gone, we can also drop few things in core/dix that had
been added just for xwayland only.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The supported platforms already have asprintf() and vasprintf(),
so there's no need for having our own implementation anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always enabled for very long time now (at least since meson transition),
there doesn't seem to be any need to ever disable it again. So we can reduce
code complexity by removing all the ifdef's.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field hasn't been actually used, so no need to keep it any longer.
Fixes: 60f14d60f6
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
calloc() can always fail, so we need to prepared for this,
instead of just blindly segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If this happens, we really have a bug, so better spit out a warning
instead of just segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Usually shouldn't happen trying to accessing pixmap's glamor private
data w/o having it initialized first. But just in case there's some
subtle bug, adding extra checks, which don't cost us much.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
GetPictureScreenIfSet() is designed that NULL can be returned.
Even though it should not happen in this particular case,
better be prepared for that, instead of just segfault'ing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It could potentially be called with NULL pointer, but can't handle it,
so when that happens, it's a bug. Adding a BUG_RETURN_VAL() call here,
so it's giving us a hint where to look at.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
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>
Right now, we're assuming that even when deep nesting involved, the proc
vector is always set to a valid function. One the one hand it requires
extra dummy procs in some cases, OTOH it's making upcoming refactoring
of the code flow unnecessarily complex.
The big plot (of subsequent commits) is splitting out the extension's
(and possibly subsystem's) special logic out of the wrapping chain and
let them be executed independently from the DDX/drivers - when applicable
even only when the pixmap is really destroyed (not just unref'ed).
(At some later point, it might even become be actually a valid situation
that DestroyPixmap vector really being NULL.)
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1755
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1709>
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>
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>
The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
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>
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>
Icenowy Zheng
Enrico Weigelt, metux IT consult
Jan Engelhardt
Pierre-Eric Pelloux-Prayer
Nicolas Dufresne