On FreeBSD the ALIGN macro already exists in the standard headers,
so we sholdn't redefine it here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This allows us to pass flags to the function, avoiding the forced
implicit GBM_BO_USE_SCANOUT which happens with the older version.
Backport from Xwayland:
f31ca9238f
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
If we're using implicit modifiers, we'll pass NULL and zero modifiers.
Lets just use the legacy API directly instead.
Backport from Xwayland:
08b0ea09de
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
This likely wasn't a problem, as *num_modifiers was 0, so likely no
data was read from a potentially uninitilaized pointer, but it's
still better to explicitly set it to NULL.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Nvidia needs dma-buf for glamor acceleration to work
when using the modesetting ddx driver.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Port https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/751
to xlibre
Fixes glamor with modesetting on nvidia
This is needed for glamor to work with modesetting
on nvidia, according to the nvidia docs:
https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gbm.html
From the mr above:
The X server was passing GBM bos directly to
eglCreateImageKHR using the EGL_NATIVE_PIXMAP_KHR
target. Given the EGL GBM platform spec claims it
is invalid to create a EGLSurface from a native
pixmap on the GBM platform, implying there is no
mapping between GBM objects and EGL's concept of
native pixmaps, this seems a bit questionable.
This change modifies the bo import function to
extract all the required data from the bo and then
imports it as a dma-buf instead when the dma-buf +
modifiers path is available.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
This lets Zink take advantage of DRM modifiers on GPUs letting it properly handle tiled buffers.
Signed-off-by: notbabaisyou <though-went-some-simple@proton.me>
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>
