[RFC] Exposing plane type mask and handling 'all' planes

[Emil Velikov <emil.l.velikov@gmail.com>]

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