Re: [PATCH xf86-video-intel] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors

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

On Wed, Feb 14, 2018 at 07:42:59PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-02-14 19:21:08)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Use the new "COLOR_ENCODING" plane property to implement the
> > XV_COLORSPACE port attribute for sprite Xv adaptors.
> > 
> > Cc: Jyri Sarha <jsarha@ti.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > +void sna_crtc_set_sprite_colorspace(xf86CrtcPtr crtc,
> > +                                   unsigned idx, int colorspace)
> > +{
> > +       struct plane *p;
> > +
> > +       assert(to_sna_crtc(crtc));
> 
> assert(colorspace < ARRAY_SIZE(p->color_encoding.values));
> 
> > +
> > +       p = lookup_sprite(to_sna_crtc(crtc), idx);
> > +
> > +       if (!p->color_encoding.prop)
> > +               return;
> > +
> > +       drmModeObjectSetProperty(to_sna(crtc->scrn)->kgem.fd,
> > +                                p->id, DRM_MODE_OBJECT_PLANE,
> > +                                p->color_encoding.prop,
> > +                                p->color_encoding.values[colorspace]);
> 
> Does changing the property trigger an immediate update, or is that
> deferred until the next SetPlane (or atomic update)?

Legacy setprop so it'll trigger an update. So if the plane is
already enabled I suppose we'll get an extra frame of lag here.
Same deal as for the colorkey ioctl actually.

I think generally one can assume the the attribute won't be changed
very often with the plane already enabled. Generally I'd expect the
client to set this up before the first putimage.

Converting this to atomic would avoid that extra lag. But we'd need
to convert the colorkey ioctl to properties as well. And the next step
after that would tearfree+atomic for making it actually nice :)

> 
> It makes no difference to this patch, except we might redisplay the
> image immediately rather than wait for the client?

We call this from the putimage hook, so we need the client to
actually repaint before anything happens. And since we don't have
reputimage manipulating the window/clipping won't update the
sprite unless the client repaints (which eg. mplayer won't do
when paused unless it gets expose events).

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx