Commit bfe8b573 authored by Lespiau, Damien's avatar Lespiau, Damien Committed by Dave Airlie

drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH, HEIGHT} caps

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@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
parent 05c63c2f
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment