Signed-off-by: Austin Yuan <shengquan.yuan@intel.com>

Signed-off-by: Austin Yuan <shengquan.yuan@intel.com>

Apply the patch to split va and display/x11 from Gwenole Beauchesne [mailto:gbeauchesne@splitted-desktop.com]

Bellow is his explanation:

> Finally, looking further at <va_x11.h>, I think it should be enough to have
> vaInitialize() in display-dependent headers/libs. The va_x11_getDriverName()
> suggestion was to factor out the thing at the implementation (source
> code/files) level.
>
> Or we could keep vaInitialize() in common lib and rather have vaGetDisplay()
> in the display-specific part? And, while being at it, also rename the
> function to vaCreateDisplay(), to be meaningful about the API change?
>
> Besides, for a different windowing system, we probably would need more than
> just the Display (as we have in X11 land) anyway. e.g. what about OpenGL,
> OpenGL E|S? I don't know, it's just an idea.
>
> I read that Canmore/Sodaville are using the same engines as the Poulsbo
> (SGX535 and VXD370). However, the former platforms only support OpenGL E|S.
> So, how does video acceleration work here? I know it works, I saw it but
> since we still haven't received the machines, I just don't know about the
> actual API. You'd probably want libVA there too.
>
> Splitting libVA between a Core API and a Display API would make it possible
> to reduce code duplication from a player point of view. i.e. I don't think
> it's necessary to have client applications implement
> vaBeginPicture()..vaEndPicture() sequences themselves. I think it should be
> the role of the codec library (ffmpeg, in my case), and it should be able to
> do so without an explicit dependency on X11.
>
> On the other hand, the Core API won't be useful/functional alone. So, that
> could be confusing too.
>
> In practise, I would like to have it working as follows. It's my ideal
> vision, not necessarily the right/correct one. ;-)
>
> Roles of a codec implementation library:
> - Create buffers
> - Render the pictures, in the vaBeginPicture()..vaEndPicture(),
> vaRenderPicture() sense
>
> Roles of a player application:
> - Create display, surfaces, and decode pipeline for the codec library
> - Render the picture, visually, i.e. in the vaPutSurface() sense
>
> Example use:
> VApplication|initialize display
> CodecLibrary|characterise bitstream (codec and other useful info)
> VApplication|create decode pipeline
> VApplication|create surfaces
> CodecLibrary|create buffers	(1)
> CodecLibrary|render picture	(2)
> VApplication|display picture	(3)
> repeat (1) -> (3) while the end of stream is not reached
> VApplication|destroy everything
>
> Have CodecLibrary linked against libva-core-VERSION.so.MAJOR, without any
> dependency on windowing system library.
>
> Have VApplication linked against libva-x11-VERSION.so.MAJOR, itself linked
> against libva-core-VERSION.so.MAJOR and other windowing system libraries.
>
> Regards,
> Gwenole.
>
Signed-off-by: Austin Yuan <shengquan.yuan@intel.com>

Signed-off-by: Austin Yuan <shengquan.yuan@intel.com>

Signed-off-by: Austin Yuan <shengquan.yuan@intel.com>

1. SkipFrame for vaQuerySurfaceStatus
2. disable_deblocking_filter_idc for VAEncSliceParameterBuffer

under rotation mode, but a issue is found that after vaTerminate, XCloseDisplay
will meet a SIGSEGV, and debuging shows libXdamage is unloaded from application
address space after vaTerminate, and keeping libXdamage all along can workaround
this issue. So always link libva with libXdamage here

* Bump version to 0.29

* VC1: reference_distance can have values of 0 - 16 inclusive and needs 5 bits

- Combine vaCreateBuffer and vaBufferData

* Expand mv_mode from 2 to 3 bits