<enunes>
warpme_: there havent been many recent lima changes, what did you update/change from a working setup?
<warpme_>
oh - not much. kernel is 5.8-rc5 now.....
<rellla>
warpme_: i never had that issue yet, but i'm on Allwinner H5 with Mali450...
<rellla>
enunes: btw, are you familiar with GLES userspace?
chewitt has joined #lima
<rellla>
chewitt: open for questions?
<chewitt>
rellla busy with work stuff .. and @jernej is the person you need more than me :)
<chewitt>
I'll be free in a couple of hourss
<rellla>
:)
<rellla>
i just need anyone, that can answer me a few questions, about how gles and drm planes work together :)
<rellla>
the more i read, the more complicated it seems to get ...
<chewitt>
jernej is the person who implemented most of the Allwinner bits for LE
<chewitt>
along with lrusak, butt he's not here
<rellla>
ok thanks, maybe jernej wants to ping me, or anyone else of course :p
<chewitt>
warpme_ might another person to ping .. he's been working on minimyth which does similar things
<daniels>
GLES has no interaction with DRM planes per se
<daniels>
if you have a client which displays GLES rendering on DRM planes, such as Weston or GNOME or kmscube or whatever, the way that works is: the client opens the DRM/KMS device for the display controller, enumerating all the planes. it creates one gbm_device for the device.
<jernej>
rellla: what do you want to know?
<daniels>
it then creates an EGLDisplay (using Mesa) which works together with GLES to give contexts
<daniels>
for each plane that it wants to render on, it creates a gbm_surface, then wraps that gbm_surface in an EGLSurface, which lets you use buffers which are acceptable for planes as a render target
<daniels>
the combination of gbm_surface/EGLSurface is where the buffer allocation happens; GLES just requests a current buffer to render into, and GBM/EGL ensure that those buffers are suitable for display
<daniels>
once that's done, the user calls eglSwapBuffers, then requests a handle to the current buffer via GBM, then passes that handle to KMS as part of an atomic modesetting request to finally have it displayed
<rellla>
daniels: thanks for that explanation... i have to think about that.
<rellla>
there has been some code in the past, where the whole gui composition was done with GL (GLES). framebuffers are bound as a texture (if that is explained correct)
<rellla>
vdpau interop feature was hacked in, and the surface was used to be rendered on (again bound as a texture iirc) libvdpau was then responsible to get that to screen.