Hi,
I own an odroid XU3 wich runs currently with the newest mali driver (r6p0) on ubuntu 15.01 without X.
I spend the last days in trying to pass the drm buffer using gbm into the mali gpu, until now with no success.
Problem is, that I'm not able to set up a renderable surface, I tried several extensions (MESA_GBM for example) but they all fail.
Can you pls. provide me with the information if its possible or not?
If it should be possible - are there any resources / samples where to look or the key?
Thanks!
Markus
* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the error EGL_BAD_PARAMETER is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is incomplete, EGL_BAD_PARAMETER is generated.
* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the error EGL_BAD_PARAMETER is generated.
* If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is incomplete, EGL_BAD_PARAMETER is generated.
These are the possible reasons for EGL_BAD_PARAMETER.
Please make sure to change your buffer accordingly to rule out the first:
<buffer> must be NULL, cast into the type EGLClientBuffer.
As for the second, it looks like you have covered the requirements here based off of the spec. Please validate that the values are correct however:
* EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels* EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl.* EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image.* EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes.* EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats.
* EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels
* EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl.
* EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image.
* EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes.
* EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats.
We will try have a look on our end for any problems with this and report back if we find anything.
Similarly if you discover the solution, feel free to post it so others can benefit from this.
Kind Regards,
Michael McGeagh
Thanks for the quick response, Michael!
First let me say that I'm glad that the answer is not: "Not supported"
I came over this issue while building / testing the chromium content_shell application with the ozone gbm platform.
I already verified all the parameters passed to the function and they seem to be correct.
Chromium members told me, that the fbdev driver provided from malidevelopers might not work, I have to use the chrome-os driver (wich should have the same binary blob inside, doesn't it??)
I have a small test program, but it uses minigbm (from the chromium project) to handle the drm buffers.
I'll try to remove the minigbm dependencies this evening and send you a link to this simple program.
Thanks,
[Edit: I made a simple testcase wich uses only drm / egl now.
The example (https://github.com/mapfau/tests/blob/master/drm_image/drm_image.c) is without any cleanup code and written all in main for better readability.
On my odroid xu3 I have compiled it with: gcc -I/usr/include/libdrm/ -I/usr/include/exynos/ -O0 -g drm_image.c -ldrm -lmali -o drm_image
The example includes the steps: DRM setup / GEM buffer / DMA_Buffer retrieval and EGL initialization until the point where dhe eglImageKHR is created.
Thanks for looking over it!