Discussion:
How to implement a EGL or DRM display in VA-API driver
(too old to reply)
Randy Li
2016-10-24 07:59:27 UTC
Permalink
Hello:
I am going to implement a EGL and DRM display for Rockchip VA-API
driver. We do have a EGL implementation in Rockchip VA-API driver, but
it is implemented in the standard way, we did that as a X11 display.
I didn't see the usage of struct VADriverVTableEGL in gstreamer, and
I have no idea about where should I implement something functions like
eglExportDRMImageMESA().
The DRM seems more complex, the reason I want to use the DRM is that,
GPU would not work with the 4K video rendering, so the DRM means that
directly output the video into video controller in our platform. But
still have no idea what kind of thing I should implement in the VA-API
driver. It seems that the VA-API base library would open a DRM instance
for the driver, but leaving those configure for connector, encoder,
planes to VA-API driver?
Could you guys give me same sample code or example of those kind of
display in VA-API or the documents would help(I would not image there is
a VA-API documents)
--
Randy Li
The third produce department
Xiang, Haihao
2016-10-27 15:03:42 UTC
Permalink
-----Original Message-----
Of Randy Li
Sent: Monday, October 24, 2016 3:59 PM
Subject: How to implement a EGL or DRM display in VA-API driver
I am going to implement a EGL and DRM display for Rockchip VA-API driver.
We do have a EGL implementation in Rockchip VA-API driver, but it is
implemented in the standard way, we did that as a X11 display.
I didn't see the usage of struct VADriverVTableEGL in gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more efficient way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.com/01org/libyami-utils.git) for
how to use vaapi and egl.
The DRM seems more complex, the reason I want to use the DRM is that,
GPU would not work with the 4K video rendering, so the DRM means that
directly output the video into video controller in our platform. But still have no
idea what kind of thing I should implement in the VA-API driver. It seems that
the VA-API base library would open a DRM instance for the driver, but leaving
those configure for connector, encoder, planes to VA-API driver?
configure for connector, encoder, planes aren't a part of va-api driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm (git.freedesktop.org/git/mesa/drm)
Could you guys give me same sample code or example of those kind of
display in VA-API or the documents would help(I would not image there is a
VA-API documents)
--
Randy Li
The third produce department
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Randy Li
2016-10-28 02:05:29 UTC
Permalink
Post by Xiang, Haihao
-----Original Message-----
Of Randy Li
Sent: Monday, October 24, 2016 3:59 PM
Subject: How to implement a EGL or DRM display in VA-API driver
I am going to implement a EGL and DRM display for Rockchip VA-API driver.
We do have a EGL implementation in Rockchip VA-API driver, but it is
implemented in the standard way, we did that as a X11 display.
I didn't see the usage of struct VADriverVTableEGL in gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more efficient way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.com/01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
Post by Xiang, Haihao
The DRM seems more complex, the reason I want to use the DRM is that,
GPU would not work with the 4K video rendering, so the DRM means that
directly output the video into video controller in our platform. But still have no
idea what kind of thing I should implement in the VA-API driver. It seems that
the VA-API base library would open a DRM instance for the driver, but leaving
those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-api driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm (git.freedesktop.org/git/mesa/drm)
Could you guys give me same sample code or example of those kind of
display in VA-API or the documents would help(I would not image there is a
VA-API documents)
--
Randy Li
The third produce department
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================
Sean V Kelley
2016-10-28 20:09:27 UTC
Permalink
Post by Randy Li
Post by Xiang, Haihao
-----Original Message-----
Of Randy Li
Sent: Monday, October 24, 2016 3:59 PM
; linux-
el.com>;
om>;
Subject: How to implement a EGL or DRM display in VA-API driver
  I am going to implement a EGL and DRM display for Rockchip VA-
API driver.
We do have a EGL implementation in Rockchip VA-API driver, but it is
implemented in the standard way, we did that as a X11 display.
  I didn't see the usage of struct VADriverVTableEGL in
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
Post by Xiang, Haihao
  The DRM seems more complex, the reason I want to use the DRM is
that,
GPU would not work with the 4K video rendering, so the DRM means that
directly output the video into video controller in our platform. But still have no
idea what kind of thing I should implement in the VA-API driver. It seems that
the VA-API base library would open a DRM instance for the driver, but leaving
those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X
output, I 
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented. "Pretending an X output" is independent of KMS configuration
for your display port.

Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-api
driver.  You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
  Could you guys give me same sample code or example of those
kind of
display in VA-API or the documents would help(I would not image there is a
VA-API documents)
--
Randy Li
The third produce department
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Randy Li
2016-11-02 11:32:25 UTC
Permalink
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
-----Original Message-----
Of Randy Li
Sent: Monday, October 24, 2016 3:59 PM
; linux-
el.com>;
om>;
Subject: How to implement a EGL or DRM display in VA-API driver
I am going to implement a EGL and DRM display for Rockchip VA-
API driver.
We do have a EGL implementation in Rockchip VA-API driver, but it is
implemented in the standard way, we did that as a X11 display.
I didn't see the usage of struct VADriverVTableEGL in
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
I looks like the currently VA-API only need vaDeriveImage() and
vaAcquireBufferHandle(), leaving the rendering output buffer to display
to VA-API client. vaapisink from gstreamer would play no role in this?
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
The DRM seems more complex, the reason I want to use the DRM is that,
GPU would not work with the 4K video rendering, so the DRM means that
The guys from algorithm department told me that the main problem is
VA-API can't process video parallelly and it won't process the next
frame until vaEndPicture() and a output function(like vaDeriveImage(),
vaGetImage and vaPutSurface()).
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
directly output the video into video controller in our platform. But still have no
idea what kind of thing I should implement in the VA-API driver. It seems that
the VA-API base library would open a DRM instance for the driver, but leaving
those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented. "Pretending an X output" is independent of KMS configuration
for your display port.
No, what I do is pretended as a VA_DISPLAY_X11 display. I have read the
examples/grid.cpp from libyami-utils. It seems that those job have been
moved into VA-API client. The whole display system looks like departured.
So the element plugin vaapisink from gstreamer would be drop in the
future? As those job have been done by kmssink and glimagesink.
Post by Sean V Kelley
Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-api
driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
Could you guys give me same sample code or example of those kind of
display in VA-API or the documents would help(I would not image there is a
VA-API documents)
--
Randy Li
The third produce department
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================
Xiang, Haihao
2016-11-11 03:45:44 UTC
Permalink
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
-----Original Message-----
rg]
On Behalf
Of Randy Li
Sent: Monday, October 24, 2016 3:59 PM
.org
; linux-
@int
el.com>;
ps.c
om>;
Subject: How to implement a EGL or DRM display in VA-API driver
  I am going to implement a EGL and DRM display for Rockchip
VA-
API driver.
We do have a EGL implementation in Rockchip VA-API driver,
but it
is
implemented in the standard way, we did that as a X11
display.
  I didn't see the usage of struct VADriverVTableEGL in
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more
efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.
com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
I looks like the currently VA-API only need vaDeriveImage() and
vaAcquireBufferHandle(), leaving the rendering output buffer to display
to VA-API client. vaapisink from gstreamer would play no role in this?
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
  The DRM seems more complex, the reason I want to use the
DRM is
that,
GPU would not work with the 4K video rendering, so the DRM
means
that
The guys from algorithm department told me that the main problem is
VA-API can't process video parallelly and it won't process the next
frame until vaEndPicture() and a output function(like
vaDeriveImage(),
vaGetImage and vaPutSurface()).
What do you mean when you said 'VA-API' can't  process video parallelly
? The examples/grid.cpp can processes multiple videoes  parallelly.
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
directly output the video into video controller in our
platform.
But still have no
idea what kind of thing I should implement in the VA-API
driver.
It seems that
the VA-API base library would open a DRM instance for the
driver,
but leaving
those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented.  "Pretending an X output" is independent of KMS
configuration
for your display port.
No, what I do is pretended as a VA_DISPLAY_X11 display. I have read the
examples/grid.cpp from libyami-utils. It seems that those job have been
moved into VA-API client. The whole display system looks like
departured.
So the element plugin vaapisink from gstreamer would be drop in the
future? As those job have been done by kmssink and glimagesink.
Post by Sean V Kelley
Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-
api
driver.  You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
  Could you guys give me same sample code or example of those
kind of
display in VA-API or the documents would help(I would not
image
there is a
VA-API documents)
--
Randy Li
The third produce department
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Randy Li
2016-11-11 04:02:41 UTC
Permalink
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more
efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.
com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
I looks like the currently VA-API only need vaDeriveImage() and
vaAcquireBufferHandle(), leaving the rendering output buffer to display
to VA-API client. vaapisink from gstreamer would play no role in this?
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
The DRM seems more complex, the reason I want to use the
DRM is
that,
GPU would not work with the 4K video rendering, so the DRM
means
that
The guys from algorithm department told me that the main problem is
VA-API can't process video parallelly and it won't process the next
frame until vaEndPicture() and a output function(like
vaDeriveImage(),
vaGetImage and vaPutSurface()).
What do you mean when you said 'VA-API' can't process video parallelly
? The examples/grid.cpp can processes multiple videoes parallelly.
If I understand the process sequence correctly, the next frame won't be
processed at vaBeginPicture() until the previous frame is end with
vaEndPicture()?
What I mean is about frame.
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
directly output the video into video controller in our
platform.
But still have no
idea what kind of thing I should implement in the VA-API
driver.
It seems that
the VA-API base library would open a DRM instance for the
driver,
but leaving
those configure for connector, encoder, planes to VA-API
driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented. "Pretending an X output" is independent of KMS
configuration
for your display port.
No, what I do is pretended as a VA_DISPLAY_X11 display. I have read the
examples/grid.cpp from libyami-utils. It seems that those job have been
moved into VA-API client. The whole display system looks like
departured.
So the element plugin vaapisink from gstreamer would be drop in the
future? As those job have been done by kmssink and glimagesink.
Post by Sean V Kelley
Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-
api
driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
--
Randy Li
The third produce department
Zhao Yakui
2016-11-11 04:31:29 UTC
Permalink
Post by Randy Li
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more
efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.
com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
I looks like the currently VA-API only need vaDeriveImage() and
vaAcquireBufferHandle(), leaving the rendering output buffer to display
to VA-API client. vaapisink from gstreamer would play no role in this?
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
The DRM seems more complex, the reason I want to use the
DRM is
that,
GPU would not work with the 4K video rendering, so the DRM
means
that
The guys from algorithm department told me that the main problem is
VA-API can't process video parallelly and it won't process the next
frame until vaEndPicture() and a output function(like
vaDeriveImage(),
vaGetImage and vaPutSurface()).
What do you mean when you said 'VA-API' can't process video parallelly
? The examples/grid.cpp can processes multiple videoes parallelly.
If I understand the process sequence correctly, the next frame won't be
processed at vaBeginPicture() until the previous frame is end with
vaEndPicture()?
What I mean is about frame.
Yes. Before calling the vaEndPicture, we can't handle next frame.
Only after calling vaBeginPicture, a new frame is started.
The decoding process can be considered as state-machine.
Post by Randy Li
The first step is to call vaBeginPicture
Call vaRenderPicture to prepare required parameter
call vaEndPicture
If a new frame can be started before calling vaEndPicture, the decoding
process will be in corruption state. That is wrong.
Post by Randy Li
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
directly output the video into video controller in our
platform.
But still have no
idea what kind of thing I should implement in the VA-API
driver.
It seems that
the VA-API base library would open a DRM instance for the
driver,
but leaving
those configure for connector, encoder, planes to VA-API
driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented. "Pretending an X output" is independent of KMS
configuration
for your display port.
No, what I do is pretended as a VA_DISPLAY_X11 display. I have read the
examples/grid.cpp from libyami-utils. It seems that those job have been
moved into VA-API client. The whole display system looks like departured.
So the element plugin vaapisink from gstreamer would be drop in the
future? As those job have been done by kmssink and glimagesink.
Post by Sean V Kelley
Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-
api
driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
Randy Li
2016-11-11 04:27:19 UTC
Permalink
Post by Zhao Yakui
Post by Randy Li
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more
efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.
com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
I looks like the currently VA-API only need vaDeriveImage() and
vaAcquireBufferHandle(), leaving the rendering output buffer to display
to VA-API client. vaapisink from gstreamer would play no role in this?
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
The DRM seems more complex, the reason I want to use the
DRM is
that,
GPU would not work with the 4K video rendering, so the DRM
means
that
The guys from algorithm department told me that the main problem is
VA-API can't process video parallelly and it won't process the next
frame until vaEndPicture() and a output function(like
vaDeriveImage(),
vaGetImage and vaPutSurface()).
What do you mean when you said 'VA-API' can't process video parallelly
? The examples/grid.cpp can processes multiple videoes parallelly.
If I understand the process sequence correctly, the next frame won't be
processed at vaBeginPicture() until the previous frame is end with
vaEndPicture()?
What I mean is about frame.
Yes. Before calling the vaEndPicture, we can't handle next frame.
Only after calling vaBeginPicture, a new frame is started.
The decoding process can be considered as state-machine.
Post by Randy Li
The first step is to call vaBeginPicture
Call vaRenderPicture to prepare required parameter
call vaEndPicture
If a new frame can be started before calling vaEndPicture, the decoding
process will be in corruption state. That is wrong.
Yes, I know that. But our video IP is not as power as Intel's, I need to
render the next frame into queue of v4l2. Also I need to reconstruct the
frame to extract some codec information that VA-API don't offer to me,
it would cost some extra time.

I think the decoder in VA-API had better introduce a sync mechanism like
encoder.
Post by Zhao Yakui
Post by Randy Li
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
directly output the video into video controller in our
platform.
But still have no
idea what kind of thing I should implement in the VA-API
driver.
It seems that
the VA-API base library would open a DRM instance for the
driver,
but leaving
those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented. "Pretending an X output" is independent of KMS
configuration
for your display port.
No, what I do is pretended as a VA_DISPLAY_X11 display. I have read the
examples/grid.cpp from libyami-utils. It seems that those job have been
moved into VA-API client. The whole display system looks like departured.
So the element plugin vaapisink from gstreamer would be drop in the
future? As those job have been done by kmssink and glimagesink.
Post by Sean V Kelley
Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-
api
driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
--
Randy Li
The third produce department
Zhao Yakui
2016-11-11 06:09:06 UTC
Permalink
Post by Randy Li
Post by Zhao Yakui
Post by Randy Li
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
gstreamer, and I have
no idea about where should I implement something functions like
eglExportDRMImageMESA().
VADriverVTableEGL is deprecated in libva, we has a more
efficient
way to use vaapi and egl.
You can refer to the examples in libyami-utils (https://github.
com/
01org/libyami-utils.git) for
how to use vaapi and egl.
I see, thank you.
I looks like the currently VA-API only need vaDeriveImage() and
vaAcquireBufferHandle(), leaving the rendering output buffer to display
to VA-API client. vaapisink from gstreamer would play no role in this?
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
The DRM seems more complex, the reason I want to use the
DRM is
that,
GPU would not work with the 4K video rendering, so the DRM
means
that
The guys from algorithm department told me that the main problem is
VA-API can't process video parallelly and it won't process the next
frame until vaEndPicture() and a output function(like
vaDeriveImage(),
vaGetImage and vaPutSurface()).
What do you mean when you said 'VA-API' can't process video parallelly
? The examples/grid.cpp can processes multiple videoes parallelly.
If I understand the process sequence correctly, the next frame won't be
processed at vaBeginPicture() until the previous frame is end with
vaEndPicture()?
What I mean is about frame.
Yes. Before calling the vaEndPicture, we can't handle next frame.
Only after calling vaBeginPicture, a new frame is started.
The decoding process can be considered as state-machine.
Post by Randy Li
The first step is to call vaBeginPicture
Call vaRenderPicture to prepare required parameter
call vaEndPicture
If a new frame can be started before calling vaEndPicture, the decoding
process will be in corruption state. That is wrong.
Yes, I know that. But our video IP is not as power as Intel's, I need to
render the next frame into queue of v4l2. Also I need to reconstruct the
frame to extract some codec information that VA-API don't offer to me,
it would cost some extra time.
I think the decoder in VA-API had better introduce a sync mechanism like
encoder.
The vaEndPicture is not a blocked API call. In such case it will return
after it tells the driver that all the required info is ready and the
decode command can be submitted to the HW. Then a new frame can be
prepared.

If you need the sync, you can call the explicit sync operation to wait
for the completion of decoding.

Thanks
yakui
Post by Randy Li
Post by Zhao Yakui
Post by Randy Li
Post by Randy Li
Post by Sean V Kelley
Post by Randy Li
Post by Xiang, Haihao
directly output the video into video controller in our
platform.
But still have no
idea what kind of thing I should implement in the VA-API
driver.
It seems that
the VA-API base library would open a DRM instance for the
driver,
but leaving
those configure for connector, encoder, planes to VA-API driver?
About the DRM, I have implemented a version which pretends a X output, I
would like to know a better way.
Connector properties and their configuration are entirely display port
oriented. "Pretending an X output" is independent of KMS
configuration
for your display port.
No, what I do is pretended as a VA_DISPLAY_X11 display. I have read the
examples/grid.cpp from libyami-utils. It seems that those job have been
moved into VA-API client. The whole display system looks like departured.
So the element plugin vaapisink from gstreamer would be drop in the
future? As those job have been done by kmssink and glimagesink.
Post by Sean V Kelley
Sean
Post by Randy Li
Post by Xiang, Haihao
configure for connector, encoder, planes aren't a part of va-
api
driver. You should check libdrm and drm/i915.
You can refer to the test case of modetest in libdrm
(git.freedesktop.org/git/mesa/drm)
Loading...