| Age | Commit message (Collapse) | Author |
|---|
|
wlr_touch now owns its wlr_input_device. It will be initialized when the
tablet tool is initialized, and finished when the touch is destroyed.
|
|
wlr_tablet_tool owns its wlr_input_device. It will be initialized when the
tablet tool is initialized, and finished when the tablet tool is destroyed.
|
|
wlr_tablet_pad owns its wlr_input_device. It will be initialized when the
tablet pad is initialized, and finished when the tablet pad is destroyed.
|
|
wlr_switch owns its wlr_input_device. It will be initialized when the
switch is initialized, and finished when the switch is destroyed.
|
|
wlr_pointer owns its wlr_input_device. It will be initialized when the
pointer is initialized, and finished when the pointer is destroyed.
|
|
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
|
|
|
|
The libinput backend is now optional. However, this means that a
user building wlroots without the correct libinput dependencies
will end up with a compositor which doesn't respond to input events.
wlr_backend_autocreate is supposed to return a sensible setup, so in
this case let's just error out and explain what happened. Users can
suppress the check by setting WLR_LIBINPUT_NO_DEVICES=1 (already used
to suppress the zero input device case inside the libinput backend).
Compositors which really want to create a bare DRM backend can easily
create it manually instead of using wlr_backend_autocreate.
|
|
All of these projects use meson.override_dependency() so we can
stop referencing their internal variable name to grab the
depndencies we need.
|
|
This patch makes it so we bind to zwp_linux_dmabuf_v1 version 4 and
we use it to grab the main device. v4 sends supported formats via a
table so we need to handle this as well.
v4 allows wlroots to remove the requirement for Mesa's internal
wl_drm interface.
|
|
This has been added in [1] and allows us to close buffer handles
without manually calling drmIoctl.
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/192
|
|
This avoids open-coding our own logic. The resulting code is more
readable.
References: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/146
|
|
This helper is responsible for listening for new DRM devices and
create new child DRM backends as necessary.
|
|
The multi backend was returned instead of the primary DRM backend.
|
|
%zd is for ssize_t. For size_t we should use %zu.
|
|
wlroots picks names for all outputs, but it might be desirable for
compositor to override it.
For instance, Sway will use a headless output as a fallback in
case no outputs are connected. Sway wants to clearly label the
fallback output as such and label "real" headless outputs starting
from HEADLESS-1.
|
|
wayland-client isn't really used by wlroots core, so let's move the
dep to where it's needed in the Wayland backend.
|
|
When using `meson --buildtype=release`, `-Wextra -Werror` is passed.
This includes `-Werror=maybe-uninitialized`, which complains about
the instances fixed in this commit.
|
|
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3332
This makes input device names include it's type name
|
|
Rather than repeatedly trying to import DMA-BUFs which cannot be
scanned out, mark the failed ones with a special "poison" marker.
Inspired from [1].
[1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/731
|
|
|
|
drmModeAddFB2 doesn't support explicit modifiers. Only accept INVALID
which indicates an implicit modifier and LINEAR which may indicate
that GBM_BO_USE_LINEAR has been used.
|
|
See [1] for the motivation.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/75
|
|
|
|
The headless backend no longer needs a parent renderer: it no longer
needs to return it in wlr_backend_impl.get_renderer, nor does it
need to return its DRM FD in wlr_backend_impl.get_drm_fd. Drop this
function altogether since it now behaves exactly like
wlr_headless_backend_create.
|
|
Sometimes the headless backend is used standalone with the Pixman
renderer, sometimes it's used together with another backend which
has already picked a DRM FD. In both of these cases it doesn't make
sense to pick a DRM FD.
Broadly speaking the headless backend doesn't really care which DRM
device is used for the buffers it receives. So it doesn't really
make sense to tie it to a particular DRM device.
Let the backend users (e.g. wlr_renderer_autocreate) open an arbitrary
DRM FD as needed instead.
|
|
This field's ownership is unclear: it's in wlr_input_device, but
it's not managed by the common code, it's up to each individual
backend to use it and clean it up.
Since this is a backend implementation detail, move it to the
backend-specific structs.
|
|
There's no guarantee that the parent Wayland compositor uses
CLOCK_MONOTONIC for reporting presentation timestamps, they could
be using e.g. CLOCK_MONOTONIC_RAW or another system-specific clock.
Forward the value via wlr_backend_impl.get_presentation_clock.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3254#note_1143061
|
|
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3181
|
|
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3183
|
|
This will allow the DRM backend to reload its lessee list.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Removing an input device requires unlinking it from the list of all headless
input devices. For that implement a destroy function.
|
|
When a connector ID is specified in a hotplug event, don't scan all
connectors. Only scan the connector that has changed.
|
|
This struct contains additional information for session device
change events, such as the DRM connector ID that has changed.
|
|
|
|
drmModeCreatePropertyBlob cannot create zero-sized blobs, that
fails with EINVAL.
Closes: https://github.com/swaywm/wlroots/issues/3297
|
|
The BO handle table exists to avoid double-closing a BO handle,
which aren't reference-counted by the kernel. But if we can
guarantee that there is only ever a single ref for each BO handle,
then we don't need the BO handle table anymore.
This is possible if we create the handle right before the ADDFB2
IOCTL, and close the handle right after. The handles are very
short-lived and we don't need to track their lifetime.
Because of multi-planar FBs, we need to be a bit careful: some
FB planes might share the same handle. But with a small check, it's
easy to avoid double-closing the same handle (which wouldn't be a
big deal anyways).
There's one gotcha though: drmModeSetCursor2 takes a BO handle as
input. Saving the handles until drmModeSetCursor2 time would require
us to track BO handle lifetimes, so we wouldn't be able to get rid
of the BO handle table. As a workaround, use drmModeGetFB to turn the
FB ID back to a BO handle, call drmModeSetCursor2 and then immediately
close the BO handle. The overhead should be minimal since these IOCTLs
are pretty cheap.
Closes: https://github.com/swaywm/wlroots/issues/3164
|
|
Found via scan-build
|
