Earlier this week, there was a bit of confusion about those new
capabilities, to the point I think it's better to document the intention
and API contract.
The comment documents the current situation:
- the radeon driver returns the only valid size for the hw
- i915 returns the maximun cursor size
- other drivers fall back to returning 64x64
The common contract is to return a valid cursor size.
Cc: Sagar Kamble <sagar.a.kamble at intel.com>
Cc: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Alex Deucher <alexander.deucher at amd.com>
Cc: Imre Deak <imre.deak at intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>
---
include/uapi/drm/drm.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b06c8ed..ec6b259 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -619,6 +619,15 @@ struct drm_gem_open {
#define DRM_PRIME_CAP_EXPORT 0x2
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
+/*
+ * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid widthxheight
+ * combination for the hardware cursor. The intention is that a hardware
+ * agnostic userspace can query a cursor plane size to use.
+ *
+ * Note that the cross-driver contract is to merely return a valid size;
+ * drivers are free to attach another meaning on top, eg. i915 returns the
+ * maximum plane size.
+ */
#define DRM_CAP_CURSOR_WIDTH 0x8
#define DRM_CAP_CURSOR_HEIGHT 0x9
--
1.8.3.1
