Proposal of the z-order patch

[Yu Dai <yu.dai@intel.com>]

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