[PATCH 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support

[Ville Syrjälä]

On Tue, Feb 25, 2014 at 12:35:21PM +0100, Thierry Reding wrote:
> On Tue, Feb 18, 2014 at 03:13:33PM +0200, Ville Syrjälä wrote:
> [...]
> > Once we have drm_planes for cursors, I was thinking we might add some kind
> > of enum property that lists all the supported sizes for the plane.
> 
> This comment was intriguing, so I was wondering whether you could
> elaborate a little on this. The reason why I ask is that we have a
> fairly similar issue on Tegra, where recent hardware supports 128x128
> and 256x256 hardware cursors, whereas older generations support only
> 32x32 and 64x64. Also very early generations don't support ARGB cursors,
> but a somewhat funky pixel format (2 bpp, background, foreground,
> transparent, invert).

Yeah there a a bunch of legacy cursor modes on most hardware which
might be supportable. Whether or not they would actually get used is
another matter though. I think these days everyone expects the
cursor to have alpha at least. I guess userspace could figure out if
the legacy formats are enough to represent the cursor image, and maybe
even decide to take a small quality hit by converting the ARGB image
to one of the legacy formats if it's "close enough".

I think for i915 we'll just not bother with that since all our hardware
has ARGB cursor support.

> 
> With the current set of cursor IOCTLs it isn't really practical to
> support the legacy kind of cursors, but representing the cursor as a
> plane would have the benefit of attaching a number of supported formats
> as well as resolutions to it. That would make it a whole lot easier to
> support these additional modes.
> 
> As for the supported sizes enumeration, how do you intend to handle the
> correlation between horizontal and vertical sizes, since an enumeration
> property is only a single 32-bit value. I suppose if we limit ourselves
> to supporting only cursors with 64Kx64K we could stash horizontal and
> vertical dimensions into a single 32-bit value.

Prop values are 64bit so you could stick a 32x32 dimensions into a
single value. Or you could even ignore the actual value, and just
stick the dimensions to the enum name as "%ux%u". But userspace
would need to parse that, so maybe doing both is the best option.

The only issue here is that enum properties must have a current
value. That doesn't really make sense in this case. So maybe we
actually want to come up with some kind of plane caps mechanism
that would be more fitting for this purpose. OTOH I'm not sure
adding yet another mechanism is worth it.

> 
> Also, is there a plan to add a type field to the planes so that
> userspace can determine if it's a proper overlay or a cursor?

First you have to define what's the differnece between a cursor
and a proper overlay.

-- 
Ville Syrjälä
Intel OTC