Hi Julien,
On 15 August 2017 at 12:39, Julien Isorce wrote:
> Also eglExportDMABUFImageMESA is still tagged 'MESA'
> (EGL_MESA_image_dma_buf_export). Compared to EGL_EXT_image_dma_buf_import .
The extensions are completely different and the MESA (vendor) tag is
since only one vendor has seen va
Hi Christian,
Thx for the suggestion. Actually I thought about dmabuf (ref project
proposal), but not about opening the EGL so using an internal mesa
function. Also eglExportDMABUFImageMESA is still tagged 'MESA'
(EGL_MESA_image_dma_buf_export). Compared to EGL_*EXT*_image_dma_buf_import
.
This ne
Hi Julien,
sorry, totally missed that question.
I think the cleanest approach would be that the OpenMAX state tracker
dlopen()s the EGL and tries to export the eglImage into a dma_buf handle.
No idea how to do this, but I'm pretty sure somebody on the mailing list
should know the details how
Hi Julien,
sorry, totally missed that question.
I think the cleanest approach would be that the OpenMAX state tracker
dlopen()s the EGL and tries to export the eglImage into a dma_buf handle.
No idea how to do this, but I'm pretty sure somebody on the mailing list
should know the details how
Hi,
With Gurkirpal we have been blocked on this problem last week and that
would be great to get some input.
It is not really urgent because Gurkirpal switched to the encoder work for
the time being.
So the goal is from src/gallium/state_trackers/omx, to find a way to
retrieve the underlying stru
Hi,
As a part of my GSoC project[1] I'm working on adding OMX_UseEGLImage
support in gallium/st/omx.
I have an egl_display[1] (OMX_NATIVE_WINDOWTYPE) and the EGLImage[2] in the
H.264 decoder component. I'm looking some sort of method to get mesa pipe
screen pointer (or some other pipe structure)