| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The wlr_libinput_input_device now owns its wlr_tablet_pad, instead of creating
a new wlr_libinput_input_device for it.
|
|
The wlr_libinput_device owns its wlr_tablet and its associated wlr_tablet_tools
|
|
The wlr_libinput_input_device now owns its wlr_touch, instead of creating
a new wlr_libinput_input_device for it.
|
|
The wlr_libinput_input_device now owns its wlr_switch, instead of creating
a new wlr_libinput_input_device for it.
|
|
The wlr_libinput_input_device now owns its wlr_pointer, instead of creating
a new wlr_libinput_input_device for it
|
|
The wlr_libinput_input_device now owns its wlr_keyboard, instead of creating
a new wlr_libinput_input_device for it.
|
|
This commit prepares the ground for a wlr_libinput_input_device refactoring.
|
|
|
|
|
|
|
|
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_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.
|
|
|
|
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 helper is responsible for listening for new DRM devices and
create new child DRM backends as necessary.
|
|
|
|
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
|
|
|
|
|
|
When a connector ID is specified in a hotplug event, don't scan all
connectors. Only scan the connector that has changed.
|
|
|
|
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
|
|
Receive hold gesture events using a Wayland listiner and emit the
appropiate wlr_pointer signal.
|
|
Receive hold gesture events from libinput and emit the appropiate
wlr_pointer signal.
|
|
Expose the panel orientation with wlr_drm_connector_get_panel_orientation.
Leave it to the compositor to consume this information and configure the
output accordingly.
Closes: https://github.com/swaywm/wlroots/issues/1581
|
|
|
|
Previously used by attempt_enable_needs_modeset, but this has been
dropped in the previous commit.
|
|
Previously, we were copying wlr_output_state on the stack and
patching it up to be guaranteed to have a proper drmModeModeInfo
stored in it (and not a custom mode). Also, we had a bunch of
helpers deriving DRM-specific information from the generic
wlr_output_state.
Copying the wlr_output_state worked fine so far, but with output
layers we'll be getting a wl_list in there. An empty wl_list stores
two pointers to itself, copying it on the stack blindly results in
infinite loops in wl_list_for_each.
To fix this, rework our DRM backend to stop copying wlr_output_state,
instead add a new struct wlr_drm_connector_state which holds both
the wlr_output_state and additional DRM-specific information.
|
|
"state" is easily confused with wlr_output_state.
|
|
Using GBM to import DRM dumb buffers tends to not work well. By
using GBM we're calling some driver-specific functions in Mesa.
These functions check whether Mesa can work with the buffer.
Sometimes Mesa has requirements which differ from DRM dumb buffers
and the GBM import will fail (e.g. on amdgpu).
Instead, drop GBM and use drmPrimeFDToHandle directly. But there's
a twist: BO handles are not ref'counted by the kernel and need to
be ref'counted in user-space [1]. libdrm usually performs this
bookkeeping and is used under-the-hood by Mesa.
We can't re-use libdrm for this task without using driver-specific
APIs. So let's just re-implement the ref'counting logic in wlroots.
The wlroots implementation is inspired from amdgpu's in libdrm [2].
Closes: https://github.com/swaywm/wlroots/issues/2916
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
[2]: https://gitlab.freedesktop.org/mesa/drm/-/blob/1a4c0ec9aea13211997f982715fe5ffcf19dd067/amdgpu/handle_table.c
|
|
This allows the kernel to access our buffer damage. Some drivers
can take advantage of this, e.g. for PSR2 panels (Panel Self
Refresh) or for transfer over USB.
Closes: https://github.com/swaywm/wlroots/issues/1267
|
|
|
|
Unless we're dealing with a multi-GPU setup and the backend being
initialized is secondary, we don't need a renderer nor an allocator.
Stop initializing these.
|
|
|
|
We can't nuke it completely, we still need it for multi-GPU.
|
|
This is the cause of the spurious "drmHandleEvent failed" messages
at exit. restore_drm_outputs calls handle_drm_event in a loop without
checking whether the FD is readable, so drmHandleEvent ends up with a
short read (0 bytes) and returns an error.
The loop's goal is to wait for all queued page-flip events to complete,
to allow drmModeSetCrtc calls to succeed without EBUSY. The
drmModeSetCrtc calls are supposed to restore whatever KMS state we were
started with. But it's not clear from my PoV that restoring the KMS
state on exit is desirable.
KMS clients are supposed to save and restore the (full) KMS state on VT
switch, but not on exit. Leaving our KMS state on exit avoids unnecessary
modesets and allows flicker-free transitions between clients. See [1]
for more details, and note that with Pekka we've concluded that a new
flag to reset some KMS props to their default value on compositor
start-up is the best way forward. As a side note, Weston doesn't restore
the CRTC by does disable the cursor plane on exit (see
drm_output_deinit_planes, I still think disabling the cursor plane
shouldn't be necessary on exit).
Additionally, restore_drm_outputs only a subset of the KMS state.
Gamma and other atomic properties aren't accounted for. If the previous
KMS client had some outputs disabled, restore_drm_outputs would restore
a garbage mode.
[1]: https://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html
|
|
This is now provided by the generic wlr_output implementation.
|
|
The callee can just get it from the wlr_drm_connector.
|
|
Right now callers of drm_crtc_commit need to check whether the
interface is legacy or atomic before passing the TEST_ONLY flag.
Additionally, the fallbacks for legacy are in-place in the common
code.
Add a test_only arg to the crtc_commit hook. This way, there's no
risk to pass atomic-only flags to the legacy function (add an assert
to ensure this) and all of the legacy-specific logic can be put back
into legacy.c (done in next commit).
|
|
|
|
|
|
|
|
Rely on wlr_output's generic swapchain handling.
|
|
Rely on wlr_output's generic swapchain handling.
We still need a renderer for cursor readback, sadly.
|
