All,
Thanks for the review of z-order patch. Based on that, we had some
internal discussion within our Display driver team. Here is the summary.
1. Re: define plane z-order combinations as an enum property
User mode needs extra work to understand the definition. The number of
combinations expands dramatically with the increasing of planes. Says
for 4 planes, the total combo is 24.
2. Re: per-plane z-order property
We prefer the atomic setup of z-order for all planes. So driver can
validate the property value in the SetProperty call. Otherwise, if for
each plane the separated SetProperty call is made to update the z-order,
it could be difficult to handle and validate. For example, when set a
plane to zorder 2, there might be another plane with zorder 2 already.
In the end, we still need another check point to validate this.
3. We also discussed the possibility of using blob property
Some generic blob property calls are needed to handle a property with a
list of plane id and zorder etc. But currently it is lack of support in
libdrm to pass down user data via blob property. The current
drm_mode_obj_set_property really doesn't handle blob. It might be useful
to implement a property that can handle complicated data structure from
user. But this is long term goal.
The new proposal we have is still based on previous solution (64bits
property) but it tries to make the code platform agnostic and eliminate
the magic number like PASASBCA.
Define the supported plane name tag in i915_drm.h. For i915, it might be
#define DRM_I915_PLANE_PRIMARY 0
#define DRM_I915_PLANE_SPRITE_A 1
#define DRM_I915_PLANE_SPRITE_B 2
#define DRM_I915_PLANE_CURSOR 3
Limits the above setting within 0~15. So we need 4 bits to save it into
z-order property. The 64bits of z-order will indicate the order of
planes from bottom (lower bits) to top (higher bits) by every 4 bits.
Bit 3:0 is the plane at bottom; Bit 7:4 is the one right on top of it
and so on. In this way, we can support up to 16 planes total. And it is
very straightforward for user mode to use. The SetProperty call will
reject any invalid setting. The HW specific code will be wrapped up in
kernel SetProperty callback. Be note on Intel platform, the
PLANE_SPRITE_A/B will be mapped to HW Sprite C/D for pipe 2. And this is
crtc property - we don't have to pass around pipe id.
Please let us know your opinion on this.
Thanks,
Alex
GCM Core uArch, Intel VGP
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
