Quoting Ville Syrjälä (2018-02-14 20:06:17)
> 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@xxxxxxxxxxxxxxx>
> > >
> > > Use the new "COLOR_ENCODING" plane property to implement the
> > > XV_COLORSPACE port attribute for sprite Xv adaptors.
> > >
> > > Cc: Jyri Sarha <jsarha@xxxxxx>
> > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > ---
> > > +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.
Agreed.
> 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 :)
If we wanted nice, we wouldn't start with the X11 protocol! Oh well, if
all the shiny new features are going to be hidden being atomic, probably
going to have to bite the bullet sooner or later.
> > 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).
I knew you were going to mention the lack of ReputImage! :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
