The gst_egl_image_from_dmabuf_direct_target always has the assumption
that the input surface/buffer is a linear one. It always set the modifier
to the DRM_FORMAT_MOD_LINEAR. But in fact, the input surface/buffer may
be a non-linear one. For example:
gst-launch-1.0 -vf filesrc location=xxx.bits ! h264parse ! vah264dec
! vapostproc ! video/x-raw(memory:DMABuf) ! glimagesink
generates garbage images in the EGL mode because of the tiling issue. The
output of vapostproc is a tiling one on Intel's platform, whose modifier is
I915_FORMAT_MOD_Y_TILED, but here we still force to set the modifier to the
DRM_FORMAT_MOD_LINEAR. It is not correct.
On current platforms, the 3D driver has the ability to detect and set the correct modifier if we do not obviously specify the modifier in the attributes. The furture platforms may fail to do the detect and we need to specify it in the caps. We should enable the modifier setting when that is ready.