I'm using the Mali-T76x fbdev drivers for Firefly and want to use /dev/fb1 as a second display. Is it possible to call eglGetDisplay() with an argument other than EGL_DEFAULT_DISPLAY in order to use a different framebuffer device?
Don't need to change the EGLDispaly. On Mali the EGLDisplay ~= which GPU to use, where there's almost always only one.
Instead, try calling eglCreateWindowSurface with the index of the /dev/fbX framebuffer device as the native window parameter.. So /dev/fb1 would be eglCreateWindowSurface(my_egl_display, my_egl_config, 1, my_attrib_list).
Thanks, that does seem to work (I have tested with each display independently but have not tried both in the same process).
Is that a change to EGLNativeWindowType with recent drivers? All of the examples I can find pass a pointer to a fbdev_window structure into that argument.
No, it's been in there since the first Midgard-based GPU, T604.. So thanks, I designed that particular feature into the driver ~5 years ago... glad to see it a) works and b) is genuinely useful to someone. :-)
Passing a pointer to the fbdev_window struct is the only way to get non-fullscreen rendering. Whereas if you just want to render to the whole framebuffer, you only need to pass in the integer value of the fbdev you want to render to. Originally, support for passing a pointer to an fbdev_window was added for backwards compatability with Mali-400 drivers, though I suspect the fbdev_window structs might have diverged since then (though not in binary incompatible ways).
Also - you should be able to create two EGLSurfaces, one for each framebuffer device and draw to them from one EGLContext. So if you want to draw the same textures, etc. to each of the framebuffers, you can. Further, if you want to draw to each framebuffer in two different threads, you'll need two EGLContexts (one to eglMakeCurrent with each EGLSurface in each thread) but those EGLContexts can still be "sharing" so the same textures, VBOs, shader programs, etc. should be usable in both contexts. This is largely the reason for going with native windows for abstracting the framebuffer device rather than the EGLDisplay (two EGLDisplays can't share resources like this).
Thanks, this does indeed work nicely with a static display configuration.
However... it looks like the driver does the FBIOGET_DMABUF operation during eglInitialize() and not during eglCreateWindowSurface(), so if the user hotplugs a monitor and we change the underlying framebuffer properties then we need to completely reinitialize EGL to use the new display (I'm thinking of a device with a built-in display and an optional external monitor). Do you think there's any chance of this changing in a future driver update?
Unfortunately not. EGL has to open all the fbdev devices in eglInitialize to learn which pixel format each are using, which it then uses to filter the list of EGLConfigs and only sets EGL_WINDOW_BIT on those EGLConfigs with compatible red/green/blue/alpha component sizes. This means for example, if the fbdev devices are all using RGB565 or BGR565 pixel formats, EGL will only tag EGLConfigs with EGL_WINDOW_BIT if they have EGL_RED_SIZE=5, EGL_GREEN_SIZE=6, EGL_BLUE_SIZE=5 & EGL_ALPHA_SIZE=0. The list of EGLConfigs and their attributes must be static while an EGLDisplay is active, so EGL can't re-parse. You might be able to eglTerminate the EGLDisplay and then re-eglInitialize it after monitor hotplug, but I'm not sure how well that's tested - worth a try though.
TBH, monitor hotplug isn't well served with fbdev & no window system EGL. If you want to do that, you'd likely be better off with KMS and a Wayland compositor, though I'm not sure those drivers are available for your platform?
I have only seen fbdev and X11 drivers and we don't want to use X11 (although the kernel side of atomic KMS is available). I can't see any Wayland drivers at ARM® Mali™ Midgard GPU User-Space Binary Drivers - Mali Developer Center, would you expect them to appear there (I'm using the r6p0-02rel0 Firefly drivers)?
I would expect them there indeed: as they are downloadable for odroid xu3 (mali t62x) on the same page.
For firefly I just have the firefly X11 drivers up and running on mainline kernel (4.7), however performance isn't that great yet - probably armsoc DDX is bottleneck here.
Anyone knows if firefly mali t76x wayland GBM drivers is in the pipeline to be released? Would be really great!