DeviceContextEGL with specific eglDisplay

[wolfgangmauer]

I need to pass a specific value for eglDisplay to DeviceContext.Create but it will be ignored on DeviceContextEGL.

DeviceContext.Create(myDisplay, myHandle))

[wolfgangmauer]

And no default display for all :-)

` IntPtr defaultDisplay = new IntPtr (DEFAULT_DISPLAY); // Support for BCM VideoCore API if (IsAvailable && Bcm.IsAvailable) { // This need to be executed before any EGL/GL routine Bcm.bcm_host_init(); }

        // Support for Vu+ Duo2 BCM VideoCore API
        if (IsAvailable && VuDuo2.IsAvailable) {
            // This need to be executed before any EGL/GL routine
            defaultDisplay = VuDuo2.gles_init();
        }

if DEBUG

        string envEglInit = Environment.GetEnvironmentVariable("EGL_INIT");

        if (envEglInit != null && envEglInit == "NO")
            return;

endif

        // Get EGL information
        if (IsAvailable) {
            IntPtr eglDisplay = GetDisplay(defaultDisplay);

`

[wolfgangmauer]

Ups

[luca-piccioni]

VuDuo2.gles_init() returned value is a display handle? Then, it should be passed to DeviceContext.Create. Sadly, the display is got using eglGetDisplay with EGL_DEFAULT_DISPLAY; the returned value isn't suitable for your case?

It seems that you need optional EGL initialization. Isn't it?

Why don't you fork, so you can show your code in a better way?

[wolfgangmauer]

But this seems to be a chicken/egg problem. I have 3 extern Methods. First of all and only once GLES_Native_Init() GLES_Native_CreateNativeDisplay -> gives the value for eglGetDisplay(....) GLES_Native_CreateNativeWindow -> gives the native window

Sorry, but all my test i do with Mono.Cairo, because it's hard to test with embedded system like i have. The snippet is just like it can be... If the getDisplay in the Initialize always use a "DEFAULT_DISPLAY" i cannot use it.

[wolfgangmauer]

And i get a little confused with the naming.. A lot of devices have a "BCM VideoCore GPU", not just the Pi ;-)

[luca-piccioni]

Can you elaborate more about the naming? Did you intend the Bcm wrapper class?

[wolfgangmauer]

Just name the classes like the device, not as the chipset. PI->bcm->videocore Vuplus duo2->bcm->videocore Vuplus 4k ->bcm->videocore so how should be the classnames for the other devices?

[luca-piccioni]

Well, now that EGL can be initialized by hooking the KhronosApi.EglInitializing event, every platform can initialize EGL with any native function, without including any P/Invoke declaration. Indeed I think that Bcm wrapper will be moved in OpenGL.Net.VideoCore.

The naming of OpenGL.Net.VideoCore is originated by the fact that on RPi you must use the Video Core IV (4) API (VC4? VIV?), containing a libbcmhost.so binary. Indeed Bcm wrapper, and "window" exposed in OpenGL.Net.VideoCore. This is not an API change, since Bcm is internal.

If you want to pull some code on repository, to add support to specific platforms, I see a single OpenGL.Net.Bcm library project, that is able to support multiple hardware; this project could be the OpenGL.Net.VideoCore renamed. It will contains a Raspberry class that is the actual Bcm; and it will contains a VuplusDuo2 and Vuplus4k classes that are the KhronosApi implementation for the relative platforms. If VuplusDuo2 and Vuplus4k have the very same API, that can be simplified in a single Vuplus class. Indeed, the window implementation uses a factory pattern to support multiple implementation on different platforms.

However, I don't understand why naming a software layer VideoCore and not having a standard API. :disappointed: