Hi all, Recently I have been looking at i915 and its rather interesting planes.
In particular newer hardware is capable of using 3 universal planes and a separate cursor-only plane. At the same time only 1 top-most plane can be enabled - lets calls those plane3 or cursor. Hence currently the hardware has an extra plane which we do not use. The current DRM design does not allow us to fully utilise the HW and I would love to address that. Here are three approaches that come to mind: 1) Extend the DRM plane UAPI to: - expose a mask of supported types, and - allow userspace to select the type 2) Keep the exposed planes as-is and let the driver orchestrate which one gets used. - flip between cursor/plane3 based on the use-case/API used, or - opt for plane3/cursor for atomic and legacy modeset code path, or - other 3) Expose plane3 and cursor, whereby using one of them "marks" the other as used. - is this allowed by the modeset semantics/policy? - does existing user-space have fallback path? Personally, I would love existing user-space to just work without modification. At the same time opting for 2 this will cause a serious amount of complication, and in case of 3 the whole thing will be very fragile. So my current inclination is towards 1. Open questions: - Do we know of other hardware with this or related design which does not fit the current DRM design? - Vendor KMS specific UAPI, is frowned upon. So if we are to extend the UAPI, does the current approach sound useful for other HW? - Does this approach sound reasonable, can other share their view on a better approach, that achieves the goal? Input and ideas from the Intel team and DRM community are very much appreciated. Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
