Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Feb 14, 2023 at 01:17:45PM +0200, Pekka Paalanen wrote:
> On Tue, 14 Feb 2023 12:27:45 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote:
> > > On Thu, 9 Feb 2023 13:51:05 +0200
> > > Pekka Paalanen <pekka.paalanen@collabora.com> wrote:
> > >   
> > > > Maybe we could refine this so that userspace uses the stride and height
> > > > implied by the caps for allocation, and then use the exact cursor image
> > > > size for AddFB2? And have drivers pick any size between those two they
> > > > can use. The kernel would need the userspace to promise that the
> > > > padding is always zero-initialized, so the driver can simply scan out
> > > > any area of the buffer it needs.
> > > > 
> > > > Then we don't need SIZE_HINTS.  
> > > 
> > > Would there be any problem with this?
> > > 
> > > If this works, it would seem the superior solution to me, because
> > > userspace does not need to guess or test for the exact right size.
> > > Simply allocate at the CAP size, pad the cursor image with transparent
> > > pixels, and let the kernel scan out the optimal area.  
> > 
> > No, the hardware cannot scan out a smaller area because the
> > stride will be wrong.
> 
> In another email of yours you said that hardware requires stride to be
> equivalent to the width. So it's not that hardware supports only
> specific strides, it must equal to width. That's really unfortunate and
> surprising.

Yeah, probably some Windows legacy hangover that refuses to die.

Ye olde Intel gen2 desktop chipsets (i845/i865) had a somewhat
programmable stride for cursors (still POT, but could exceed 
the width), but the mobile chipsets (i830/i85x) did not.
Unfortunately the mobile lineage won out and we've been stuck
with this limitation ever since.

-- 
Ville Syrjälä
Intel