Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
Leave it up to the compositor to decide what to do when a backend
becomes unavailable.
|
|
This makes wlroots build in C23 mode.
C23 is more strict and rejects implicit conversions from bool to a
pointer.
|
|
This slightly improves type safety.
The culprits were found with:
git grep -E '\([a-z0-9_ ]+ \*\)\W?[a-z]'
|
|
|
|
We sometimes used HAS_, sometimes polluted the LIBINPUT_ namespace,
etc.
|
|
|
|
The destroy member in wlr_keyboard_impl has been removed. The function
`wlr_keyboard_finish` has been introduce to clean up the resources owned by a
wlr_keyboard.
`wlr_input_device_destroy` no longer destroys the wlr_keyboard, attempting to
destroy a wlr_keyboard will result in a no-op.
The field `name` has been added to the wlr_keyboard_impl to be able to identify
a given wlr_keyboard device.
|
|
|
|
|
|
wlr_keyboard owns its base wlr_input_device. It will be initialized when the
keyboard is initialized, and finished when the keyboard is destroyed.
|
|
vendor and product id are set when needed by the libinput backend
|
|
See [1] for the motivation.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/75
|
|
Most (and possibly all) compositors using wlroots only ever render
fully opaque content. To provide better performance, this change
switches the default format used by wlr_output buffers from
ARGB8888 to the opaque XRGB8888.
Compositors like mutter, kwin, and weston already default to
XRGB8888, so this change is unlikely to expose any new bugs in
underlying drivers and hardware.
This does not affect the hardware cursor's buffer format, which is
still ARGB8888 by default.
As part of this change, the X11 backend (which does not support
changing format at runtime) now picks a true color, 24 bit depth
visual (i.e. XRGB8888) instead of a 32 bit depth (ARGB8888) one.
|
|
This reverts commit ea7357b70366588069c83f158e6a4eb2d3a702b3.
|
|
See [1] for the motivation.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/75
|
|
Instead of ensuring the renderer and allocator are initialized in each
backend, do it in wlr_backend_autocreate. This allows compositors to
create backends without any renderer/allocator if they side-step
wlr_backend_autocreate.
Since the wlr_backend_get_renderer and backend_get_allocator end up
calling wlr_renderer_autocreate and wlr_allocator_autocreate, it sounds
like a good idea to centralize all of the opimionated bits in one place.
|
|
Add render/allocator/ and include/render/allocator/ to hold
everything allocator-related.
|
|
|
|
Custom backends and renderers need to implement
wlr_backend_impl.get_buffer_caps and
wlr_renderer_impl.get_render_buffer_caps. They can't if enum
wlr_buffer_cap isn't made public.
|
|
Rely on wlr_output's generic swapchain handling.
We still need a renderer for cursor readback, sadly.
|
|
|
|
When picking a format, the backend needs to know whether the
buffers allocated by the allocator will be DMA-BUFs or shared
memory. So far, the backend used the renderer's supported
buffer types to guess this information.
This is pretty fragile: renderers in general don't care about the
SHM cap (they only care about the DATA_PTR one). Additionally,
nothing stops a renderer from supporting both DMA-BUFs and shared
memory, but this would break the backend's guess.
Instead, use wlr_allocator.buffer_caps. This is more reliable since
the buffers created with the allocator are guaranteed to have these
caps.
|
|
Instead of managing our own renderer and allocator, let the common
code do it.
|
|
This new functions cleans up the common backend state. While this
currently only emits the destroy signal, this will also clean up
the renderer and allocator in upcoming patches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wlroots' dependency on this library doesn't change the features
exposed to compositors. It's purely a wlroots implementation detail.
Thus downstream compositors shouldn't really care about it.
Introduce an "internal_features" dictionary to store the status of
such internal dependencies.
|
|
We don't need it anymore now that we've stopped using the EGL Xlib
platform.
|
|
Fixes #2659
|
|
When we receive an Expose event, that means that we must redraw that
region of the X11 window. Keep track of these regions with pixman
regions, and merge them with the additional output damaged regions.
Fixes #2670
|
|
These are ones I see log messages about in my setup.
|
|
This actually simplifies the logic since we no longer have to wait for
enter/leave events, and also improves the UX when e.g. handling a crash
with gdb attached.
See #2659
|
|
Add fallbacks when DRI3 1.2 isn't supported.
Closes: https://github.com/swaywm/wlroots/issues/2586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This isn't used anymore by any backend.
Some examples still provide an EGL config to wlr_egl_init, so we can't
drop it yet there.
|
|
|
|
If we get an authenticated primary node from the X11 server, don't use
it because we can't authenticate our Wayland clients with it. Instead,
open a render node.
Closes: https://github.com/swaywm/wlroots/issues/2576
|
|
This callback allowed compositors to customize the EGL config used by
the renderer. However with renderer v6 EGL configs aren't used anymore.
Instead, buffers are allocated via GBM and GL FBOs are rendered to. So
customizing the EGL config is a no-op.
|