Stop trying to maintain a per-file _POSIX_C_SOURCE. Instead,
require POSIX.1-2008 globally. A lot of core source files depend
on that already.
Some care must be taken on a few select files where we need a bit
more than POSIX. Some files need XSI extensions (_XOPEN_SOURCE) and
some files need BSD extensions (_DEFAULT_SOURCE). In both cases,
these feature test macros imply _POSIX_C_SOURCE. Make sure to not
define both these macros and _POSIX_C_SOURCE explicitly to avoid
POSIX requirement conflicts (e.g. _POSIX_C_SOURCE says POSIX.1-2001
but _XOPEN_SOURCE says POSIX.1-2008).
Additionally, there is one special case in render/vulkan/vulkan.c.
That file needs major()/minor(), and these are system-specific.
On FreeBSD, _POSIX_C_SOURCE hides system-specific symbols so we need
to make sure it's not defined for this file. On Linux, we can
explicitly include <sys/sysmacros.h> and ensure that apart from
symbols defined there the file only uses POSIX toys.
- Add POSIX 1993.09 compliance macro in source files that use
"struct timespec";
- Add POSIX 2001.12 compliance macro in source files that use
"struct sigaction" and the SA_SIGINFO macro, or the fchmod()
function;
- Add POSIX 2008.09 compliance macro in source files that use the
getline() function.
These compliance macros are enough for wlroots to compile with the
git-master version of uClibc-ng.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
wlr_renderer_read_pixels does not need to be called inside a render
pass; rather, it only needs to have the correct buffer bound to
the renderer. This commit optimizes the implementation of
frame_shm_copy(...) by only binding the source buffer instead of
starting a no-op render pass with it.
needs_frame is for backends to trigger frames for reasons that
compositors couldn't see coming. schedule_frame is freaky and I want to
remove it. These protocols aren't backends but in this case they're
close enough, so switch to needs_frame.
CC #3664
Some formats like sub-sampled YCbCr use a block of bytes to
store the color values for more than one pixel. Update our format
table to be able to handle such formats.
Instead of using low-level wl_shm_buffer and wlr_dmabuf_v1_buffer
APIs, use the unified wlr_buffer APIs. That way it doesn't matter
what the exact wlr_buffer implementation is used, any which provides
the necessary capabilities (data_ptr or dmabuf) would work.
Simplifies the logic a bit, and will make the transition to wlr_shm
easier.
They are never used in practice, which makes all of our flag
handling effectively dead code. Also, APIs such as KMS don't
provide a good way to deal with the flags. Let's just fail the
DMA-BUF import when clients provide flags.
If the output is destroyed after capture_output but before
frame_handle_copy, it'll have a dangling output pointer. Add the
output destroy listener in capture_output.
Closes: https://github.com/swaywm/wlroots/issues/3284
Previously, the same struct was used for linux-dmabuf-v1 params
and buffer. This made the whole logic a little bit awkward, because
a wlr_dmabuf_v1_buffer could either be still being constructed, or
be a complete buffer.
Introduce a separate wlr_linux_buffer_params_v1 struct for buffer
params still being constructed. Once the params are complete (ie.
once the create request is sent), the params struct is destroyed
and the buffer struct is created.
This will help with [1] as well.
[1]: https://github.com/swaywm/wlroots/issues/2664
The original motivation is the following crash:
#0 0x00007f0ddeddeef5 in raise () at /usr/lib/libc.so.6
#1 0x00007f0ddedc8862 in abort () at /usr/lib/libc.so.6
#2 0x00007f0ddedc8747 in _nl_load_domain.cold () at /usr/lib/libc.so.6
#3 0x00007f0ddedd7646 in () at /usr/lib/libc.so.6
#4 0x00007f0de033f8de in gles2_get_renderer_in_context (wlr_renderer=0x612000003640) at ../subprojects/wlroots/render/gles2/renderer.c:38
#5 0x00007f0de0341675 in gles2_begin (wlr_renderer=0x612000003640, width=3840, height=2160) at ../subprojects/wlroots/render/gles2/renderer.c:186
#6 0x00007f0de033b100 in wlr_renderer_begin (r=0x612000003640, width=3840, height=2160) at ../subprojects/wlroots/render/wlr_renderer.c:56
#7 0x00007f0de03466ed in gles2_blit_dmabuf (wlr_renderer=0x612000003640, dst_attr=0x60b000150148, src_attr=0x7fff9f9bfde0) at ../subprojects/wlroots/render/gles2/renderer.c:591
#8 0x00007f0de033d717 in wlr_renderer_blit_dmabuf (r=0x612000003640, dst=0x60b000150148, src=0x7fff9f9bfde0) at ../subprojects/wlroots/render/wlr_renderer.c:210
#9 0x00007f0de04cbc3b in frame_handle_output_commit (listener=0x611000220bc8, data=0x7fff9f9c0050) at ../subprojects/wlroots/types/wlr_screencopy_v1.c:303
The GLES2 renderer assumes it'll have a wlr_buffer to render to.
Instead of accomodating for the edge-case of rendering without a
wlr_buffer, drop wlr_renderer_blit_dmabuf calls and instead use
wlr_renderer_bind_buffer just like the rest of the wlr_renderer users.
wlr_renderer_blit_dmabuf is now unused in wlroots.
The upside is that the new blit_dmabuf function in screencopy is
renderer-agnostic.
Only wlr_output_damage works in transformed coordinates,
wlr_output->damage is in output-buffer-local coordinates.
This essentially reverts 1ecc1b5 and fixes 1477401.
Alexander Orzechowski
Simon Ser
Paul Cercueil
eri
Manuel Stoeckl
Rose Hudson
Alexander Orzechowski
Simon Zeni
Andri Yngvason
Isaac Freund