aboutsummaryrefslogtreecommitdiff
path: root/include/backend/drm
AgeCommit message (Collapse)Author
2023-05-11wlr_drm_format: Rework wlr_drm_format_intersectAlexander Orzechowski
Now it takes a reference to a destination format
2023-02-28backend/drm: use libdisplay-info for CVT mode generationSimon Ser
2023-02-28backend/drm: use libdisplay-info to parse EDIDSimon Ser
2023-02-21backend/drm: drop wlr_drm_layer.pending_{width,height}Simon Ser
No need to store this info in struct wlr_drm_layer. We can just extract the size when we need it.
2023-02-20backend/drm: send output layer feedback eventsSimon Ser
2023-02-20backend/drm: add support for output layersSimon Ser
2023-02-20backend/drm: add libliftoff composition layerSimon Ser
This will be useful for implementing the output layers API.
2023-02-20backend/drm: add libliftoff interfaceSimon Ser
2023-02-20backend/drm: init wlr_drm_plane for all plane typesSimon Ser
2023-01-31backend/drm: set "max bpc" property based on pixel formatSimon Ser
Since 1d581656c756 ("backend/drm: set "max bpc" to the max") we set the "max bpc" property to the maximum value. The kernel driver is supposed to clamp this value depending on hardware capabilities. All kernel drivers lower the value depending on the GPU capabilities. However, none of the drivers lower the value depending on the DP-MST link capabilities. Thus, enabling a 4k@60Hz mode can fail on some DP-MST setups due to the "max bpc" property. Additionally, it's not a good idea to unconditionally set "max bpc" to the max. A high bpc consumes more lanes and more clock speed, which means higher power consumption and the busy lanes cannot be used for something else (e.g. other data transfers on a USB-C cable). For now, let's tie the "max bpc" to the pixel format of the buffer. Introduce a heuristic to make "high bit-depth buffer" a synonym of "I want the best quality". This is not perfect: a "max bpc" higher than 8 might be desirable for pixel formats with a color depth of 8 bits, for instance when the color management KMS properties are used. But we don't really support that yet, so let's leave this for later. Closes: https://github.com/swaywm/sway/issues/7367
2022-12-15backend/drm: remove wlr_drm_crtc.legacy_crtcSimon Ser
We only need it for one thing: gamma size. Moreover, some bits in the drmModeCrtc will become out-of-date, for instance the current mode, so let's avoid caching the whole struct and only keep what we know won't change.
2022-12-13backend/drm: rename wlr_drm_backend.outputs to connectorsSimon Ser
This list contains wlr_drm_connector entries, and there is no guarantee that the wlr_output fields are initialized.
2022-12-13backend/drm: add drm_connector_status_str()Simon Ser
Helper to stringify a connector status.
2022-12-07backend/drm: store pending FB in stateSimon Ser
Instead of having a pending_fb field on the struct wlr_drm_plane, move it to struct wlr_drm_connector_state. That way, there's no risk having a stale pending FB around: the state doesn't survive across tests and commits. The cursor is a special case because it's disconnected from the atomic state: the wlr_backend_impl.set_cursor hook sets the cursor for the next commit. Move the field to wlr_drm_connector.cursor_pending_fb.
2022-12-07backend/drm: use separate field to store pending cursor FBSimon Ser
We'll move the pending primary FB into the connector state in the next commit, dropping wlr_drm_plane.pending_fb in the process. Introduce a dedicated field for the cursor, which has to be managed in a special way due to our set_cursor API.
2022-11-09backend/drm: use pnp.ids to fetch EDID datailliliti
2022-11-08Revert "backend/drm: fetch EDID manufacturer from udev_hwdb"Simon Ser
This reverts commit e646d882cf4949d290fff2ba3b7ae4c124f6f13d. This commit has added a dependency on udev_hwdb. This API isn't available on all platforms (e.g. FreeBSD), and further deepens our udev dependency. A better solution is being worked on in [1]. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3638
2022-10-07backend/drm: nuke wlr_drm_connector.desired_enabledSimon Ser
This field becomes stale too easily: for instance, see 6adca4089cf4 ("backend/drm: don't unconditionally set desired_enabled"). Additionally, drm_connector_alloc_crtc() needs to do some weird dance, restoring its previous value. Instead, add a connector arg to realloc_crtcs() to indicate a new connector we want to enable.
2022-09-22backend/drm: pass through mode picture aspect ratioSimon Ser
2022-08-10backend/drm: drop enum wlr_drm_connector_statusSimon Ser
We can just use libdrm's drmModeConnection enum instead.
2022-08-10backend/drm: drop WLR_DRM_CONN_NEEDS_MODESETSimon Ser
- Add wlr_output.enabled checks to CONNECTED checks - Replace NEEDS_MODESET with CONNECTED
2022-08-10backend/drm: remove unused WLR_DRM_CONN_CLEANUPSimon Ser
2022-07-25backend/drm: use drmModeGetConnectorTypeNameSimon Ser
No need to manually maintain this table now. The wlroots names and the libdrm (= kernel) names all match. References: https://gitlab.freedesktop.org/mesa/drm/-/commit/50f8d517733d24fce6693ffae552f9833e2e6aa9
2022-06-19backend/drm: set "max bpc" to the maxSimon Ser
"max bpc" is a maximum value, the driver is free to choose a smaller value depending on the bandwidth available. Some faulty monitors misbehave with higher bpc values. We'll add a workaround if users get hit by these in practice. References: https://gitlab.freedesktop.org/wayland/weston/-/issues/612
2022-06-07backend/drm: unconditionally set "content type" to graphicsSimon Ser
CTA-861-G says that "graphics" is used to indicate non-analog (ie, digital) content. With that bit set, the sink should turn off analog reconstruction and other related filtering.
2022-05-25backend/drm: remove wlr_drm_surface.{width,height}Simon Ser
This information is stored in wlr_swapchain, no need to duplicate it.
2022-05-11backend/drm: fetch EDID manufacturer from udev_hwdbSimon Ser
Maintaining our internal table up-to-date is tedious: one needs to manually go through the PnP ID registry [1] and check whether we're missing any entry. udev_hwdb already has an API to fetch a manufacturer name from its PnP ID. Use that instead. [1]: https://uefi.org/pnp_id_list
2021-12-14backend/drm: use drmCloseBufferHandleSimon Ser
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
2021-12-13backend/drm: add wlr_drm_backend_monitorChris Chamberlain
This helper is responsible for listening for new DRM devices and create new child DRM backends as necessary.
2021-11-19backend/drm: scan leases on ueventSimon Ser
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3181
2021-11-19backend/drm: introduce wlr_drm_leaseSimon Ser
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3183
2021-11-02backend/drm: handle per-connector hotplug eventsSimon Ser
When a connector ID is specified in a hotplug event, don't scan all connectors. Only scan the connector that has changed.
2021-10-29backend/drm: get rid of BO handle tableSimon Ser
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
2021-09-21backend/drm: add support for panel orientationSimon Ser
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
2021-09-08backend/drm: implement drm lease functionSimon Zeni
2021-09-07backend/drm: drop wlr_drm_connector.desired_modeSimon Ser
Previously used by attempt_enable_needs_modeset, but this has been dropped in the previous commit.
2021-09-07backend/drm: introduce wlr_drm_connector_stateSimon Ser
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.
2021-09-07backend/drm: rename enum wlr_drm_connector_state to statusSimon Ser
"state" is easily confused with wlr_output_state.
2021-08-25backend/drm: introduce wlr_drm_bo_handle_tableSimon Ser
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
2021-08-18backend/drm: add support for FB_DAMAGE_CLIPSSimon Ser
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
2021-08-17backend/drm: use addon for wlr_drm_fbSimon Ser
2021-07-28backend/drm: stop initializing renderer for parent backendSimon Ser
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.
2021-07-28backend/drm: drop drm_surface_{make,unset}_currentSimon Ser
2021-07-28backend/drm: remove primary swapchainSimon Ser
We can't nuke it completely, we still need it for multi-GPU.
2021-07-20backend/drm: stop restoring CRTCs on exitSimon Ser
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
2021-07-09backend/drm: remove backend arg from wlr_drm_interface.crtc_commitSimon Ser
The callee can just get it from the wlr_drm_connector.
2021-07-09backend/drm: add test_only arg to wlr_drm_interface.crtc_commitSimon Ser
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).
2021-06-02backend/drm: move cursor fields to wlr_drm_connectorSimon Ser
Doesn't make a lot of sense to split the cursor fields between wlr_drm_plane and wlr_drm_connector. Let's just move everything to wlr_drm_connector.
2021-06-02output: take a wlr_buffer in set_cursorSimon Ser
Instead of passing a wlr_texture to the backend, directly pass a wlr_buffer. Use get_cursor_size and get_cursor_formats to create a wlr_buffer that can be used as a cursor. We don't want to pass a wlr_texture because we want to remove as many rendering bits from the backend as possible.
2021-06-02backend/drm: remove format arg from drm_plane_init_surfaceSimon Ser
This was always set to ARGB8888.