[Libva] Master sync with libva31 branch

[Gwenole Beauchesne]

Hi,

On Thu, 27 Aug 2009, Yuan, Shengquan wrote:

> Now five patches from Gwenole 
> (http://www.splitted-desktop.com/~gbeauchesne/libva/patches/ 104, 
> 301,302,303,304) were added into master branch. I also combined 
> vaPutImage/vaPutImage2, vaAssociatedSubpicture/vaAssociatedSubpicture2 
> and bumped VAAPI version to 0.31 (the new SONAME is libva.so.1 now). The 
> old libva30 was put into "libva30" branch. Please help to see if my 
> change will break something.

Thanks, I will try to have a look ASAP.

> Besides these changes, I also want to remove "context" from 
> vaSyncSurface API, since I think sometimes a surface may not associate 
> with a context, but we want to get its status. If nobody disagree with 
> it, I will check in the change.

I have checked all my drivers and each surface already links to its parent 
context when it is passed to vaCreateContext(). This shouldn't be a 
problem to me.

BTW, what are the use cases for no context/surface association?

> Now comparing "master" with "libva31" branch, master doesn't integrate
> Gwenole's patch 202_split_libva.patch which splits libva.so into
> libva-core.so and libva-x11.so. Personally I like one single libva.so
> because currently every VA API relies on a "DISPLAY" which depends on
> libva-x11, that means libva-core.so can't be used individually.  Is
> there a strong reason we must splite them, code complexity? or is
> there any idea to support decode/encode even without a DISPLAY/X
> environment (libva-null, libva-fb?), and only need a X when display
> something?

In decreasing order of likelihood:

(a) I have drivers that support rendering to an OpenGL texture without 
going through TFP, so we can't use vaPutSurface(Pixmap,...). That's why I 
am trying to design GLX extensions that could cover both cases. This is 
done for two drivers now, probably requires a third iteration of the API 
extensions.

(b) I have not checked yet whether this is possible or not, but I would 
also like to have a VA driver to accelerators implementing OpenMAX. 
Planned next.

(c) IIRC, there are also hardware accelerators that can work in an OpenGL 
ES environment, without X11. No visibility, I am finally not working on 
that platform.

Regards,
Gwenole.