This leaves an EGL context current behind. wlr_gles2_renderer_create was
assuming the EGL context was already current because of this (because it
called a GL function right off the bat).
After swapping buffers, it doesn't make sense to perform more rendering
operations. Unset the context to reflect this.
This commit makes it so the context is always only current between
wlr_egl_make_current and wlr_egl_swap_buffers.
This is an alternative to [1].
[1]: https://github.com/swaywm/wlroots/pull/2212
This function can be called after wlr_egl_make_current to cleanup the
EGL context. This avoids having lingering EGL contexts that make things
work by chance.
Closes: https://github.com/swaywm/wlroots/issues/2197
Some extensions are only advertised by the EGL implementation with a
non-zero EGLDisplay. That's the case when the extension can only be
enabled when the hardware/driver supports it for instance.
Instead of checking for all extensions without a display, check only for
EGL_EXT_platform_base and EGL_KHR_debug which are used before
eglGetDisplay. Check for all other extensions when we have a display.
Closes: https://github.com/swaywm/wlroots/issues/1955
Remove glapi.sh code generation, replace it with hand-written loading
code that checks extension strings before calling eglGetProcAddress.
The GLES2 renderer still uses global state because of:
- {PUSH,POP}_GLES2_DEBUG macros
- wlr_gles2_texture_from_* taking a wlr_egl instead of the renderer
According to the spec:
> If <n_rects> is 0 then <rects> is ignored and the entire
> surface is implicitly damaged and the behaviour is equivalent
> to calling eglSwapBuffers.
When we want to swap with an empty damage region, set the damage to a single
empty rectangle.
The deleted includes are redundant, because other headers will include
the necessary files. Additionally, they cause build failures, because
including EGL/egl.h or EGL/eglext.h directly, instead of through
wlr/render/egl.h or wlr/render/interface.h, will mean that
MESA_EGL_NO_X11_HEADERS will not have been defined, and so the EGL
headers will attempt to pull in unnecessary X11 headers that may not
exist on the system.
For the headers produced by glgen.sh, the includes couldn't simply be
deleted, because no other header would include the EGL headers. Neither
wlr/render/egl.h or wlr/render/interface.h felt appropriate to include,
so I opted instead to copy the MESA_EGL_NO_X11_HEADERS definition before
the EGL includes.
This removes any assumptions about how the libdrm headers are installed,
and uses the pkg-config include directories as we're "supposed to".
This only adds a partial dependency, since we don't actually need to
link against libdrm.
This PR broke a private nixpkgs definition I have for wlroots: https://github.com/swaywm/wlroots/pull/1304
It is fixed by changing `#include <drm_fourcc.h>` to `#include <libdrm/drm_fourcc.h>`, which follows what is already done in the dmabuf example.
If a client uses an older version of the dmabuf protocol, use the
`formats` event instead of `modifiers` (since that didn't exist in older
versions).
With a bit of necessary guessing, support dmabuf importing even when
EGL_EXT_image_dma_buf_import_modifiers isn't present instead of
failing up front.
Detecting whether eglSwapBuffersWithDamageEXT or
eglSwapBuffersWithDamageKHR is used should be based on the extension
string, not only on the availability of the function.
- Textures are now immutable (apart from those created from raw
pixels), no more invalid textures
- Move all wl_drm stuff in wlr_renderer
- Most of wlr_texture fields are now private
- Remove some duplicated DMA-BUF code in the DRM backend
- Add more assertions
- Stride is now always given as bytes rather than pixels
- Drop wl_shm functions
Fun fact: this patch has been written 10,000 meters up in the air.
Tested with
./weston-simple-dmabuf-drm
./weston-simple-dmabuf-drm --import-immediate=1
./weston-simple-dmabuf-drm --y-inverted=1
(and combinations)
Supports only single plane XRGB dmabufs for now.
Due to the strstr prefix match EGL_EXT_foo would be incorrectly matched
if EGL_EXT_foobar would be available but not foo.
This doesn't matter for the currently checked extensions but will matter
for EGL_EXT_image_dma_buf_import_modifiers vs
EGL_EXT_image_dma_buf_import
Code borrowed from weston
