[Libva] [PATCH 00/16] libva: wayland support

[Zhao, Halley]

I know the shortcoming of current implementation.
Then could you give an estimation date if we have to wait for your YUV texture support in mesa.

Personally, I don't think the problems ruining the usage:
	- There is few case to change va surface size on the fly.
	- client can use callback of wl_surface_frame to avoid overwrite.


> -----Original Message-----
> From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
> Sent: Wednesday, June 27, 2012 11:43 PM
> To: Zhao, Halley
> Cc: Beauchesne, Gwenole; libva at lists.freedesktop.org
> Subject: Re: [Libva] [PATCH 00/16] libva: wayland support
> 
> Hi,
> 
> 2012/6/27 Zhao, Halley <halley.zhao at intel.com>:
> > It is not a temporary VA surface, but reuse the region of
> render_state ( it is not perfect but works).
> 
> Please don't use render_state, that's generally a bad idea. Besides,
> there are at least two problems with this approach: (i) if consecutive
> source VA surfaces have different size, then you reallocate the buffer,
> (ii) even for two VA surfaces of same size, you would overwrite the
> buffer, so you won't get the expected rendered contents.
> 
> Really, vaGetSurfaceBufferWl() only needs to expose the VA surface
> buffer as is, without conversion whatsoever. If source VA surface is
> YUV, wl_buffer is YUV, if it is RGB, then it is RGB. If the client
> application wants an RGBA format, (i) it knows about it and controls it,
> (ii) it uses VA/VPP to perform the color-conversion to that format, and
> assures the lifetime of the RGBA VA surface.
> 
> Regards,
> Gwenole.