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@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
