[Intel-gfx] [PATCH 10/10] drm/i915: Support variable cursor height on ivb+

[Chris Wilson]

On Wed, Mar 08, 2017 at 12:40:53PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 07, 2017 at 10:32:14PM +0000, Chris Wilson wrote:
> > On Tue, Mar 07, 2017 at 05:27:09PM +0200, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
> > > height down to 8 lines from the otherwise square cursor dimensions.
> > > Implement support for it. CUR_FBC_CTL can't be used when the cursor
> > > is rotated.
> > > 
> > > Commandeer the otherwise unused cursor->cursor.size to track the
> > > current value of CUR_FBC_CTL to optimize away redundant CUR_FBC_CTL
> > > writes, and to notice when we need to arm the update via CURBASE if
> > > just CUR_FBC_CTL changes.
> > 
> > For userspace to discover this, they should just use trial and error
> > during startup (using the legacy SetCursor)? Though the easiest way
> > would cause the cursor to flicker - just hope the cursor is
> > off/invisible on startup.
> 
> I don't have any decent answer for how to discover this feature. Atomic
> would allow the trial and error approach without flickers. Otherwise I
> guess one could defer the check until the cursor size actually changes.
> Although maybe that won't really work for Xorg. ISTR it wants to know
> things about the cursor size upfront?

We resize the cursor on the fly, so we could do a trial-and-error after
a resize. But yes, the old cursor code used a static one-size fits all.

(gem bo alloc is signalsafe, but malloc isn't -- so we just need to make
sure we have a spare slot to create a new cursor in.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre