aboutsummaryrefslogtreecommitdiff
path: root/include/backend/drm/util.h
AgeCommit message (Collapse)Author
2023-02-28backend/drm: use libdisplay-info for CVT mode generationSimon Ser
2023-02-28backend/drm: use libdisplay-info to parse EDIDSimon Ser
2022-12-13backend/drm: add drm_connector_status_str()Simon Ser
Helper to stringify a connector status.
2022-11-09backend/drm: use pnp.ids to fetch EDID datailliliti
2022-09-22backend/drm: pass through mode picture aspect ratioSimon 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-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-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-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
2020-04-28backend/drm: introduce wlr_drm_fbScott Anderson
This is a type which manages gbm_surfaces and imported dmabufs in the same place, and makes the lifetime management between the two shared. It should lead to easier to understand code, and fewer special cases. This also contains a fair bit of refactoring to start using this new type. Co-authored-by: Simon Ser <contact@emersion.fr>
2019-06-07backend/drm: fallback to drmModeAddFB2Simon Ser
2019-01-29backend/drm: fix GBM format mismatchemersion
We create the EGL config with GBM_FORMAT_ARGB8888, but then initialize GBM BOs with GBM_FORMAT_XRGB8888. This mismatch confuses Mesa. Instead, we can always use GBM_FORMAT_ARGB8888, and use DRM_FORMAT_XRGB8888 when calling drmModeAddFB2. Fixes https://github.com/swaywm/wlroots/issues/1438
2018-12-16backend/drm: don't insert duplicate custom modes, fix refresh rateemersion
2018-04-25Make sure we don't use others' prefixesemersion
2018-02-12Reformat all #include directivesemersion
2017-09-30Rename files to remove pointless drm prefixScott Anderson