Khronos public bugtracker – Bug 55
OpenKODE and EGL initialization conflict - extend OpenKODE
Last modified: 2007-12-03 08:08:47 PST
from my understanding, the first steps creating a (full screen) window with OpenKODE and EGL works like this:
EGLDisplay eglDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);
KDWindow* kdWindow = kdCreateFullScreenWindow(eglDisplay, KD_NULL, KD_NULL);
I see the following problem:
Some EGL implementations do not work with EGL_DEFAULT_DISPLAY and need the EGLNativeDisplayType. Also, if there are multiple displays, it is not possible to determine the amount of displays and retrieve the EGLNativeDisplayType with OpenKODE.
At this point of time, from my experience and understanding, it is still necessary to use native platform libraries to initialize OpenKODE and EGL. From my understanding, this is not the philosophy of OpenKODE and EGL and this should be changed.
My suggestion is to extend OpenKODE at least with functions to retrieve the amount of available displays plus retrieving the EGLNativeDisplayType from the default display and/or by passing a display number.
What do you think?
Regards Norbert Nopper
OpenKODE 1.0 effectively mandates that EGL_DEFAULT_DISPLAY must work. An
OpenKODE with EGL that cannot do that is not compliant.
We did consider adding some functions to iterate available displays, but
decided to leave it to a future version of OpenKODE. We will consider it
again after OpenKODE 1.0 Final has been released. If you have a specific
proposal for how this might work, especially if it relates to an
existing platform with an EGL implementation, we would welcome the
In the meantime, an application is still free to use whatever
functionality is available on the platform to find the display it wants,
get the EGLDisplay for it, and use that in kdCreateFullScreenWindow.
However that application is then using functionality outside of OpenKODE
so has reduced portability.
I am currently defining an Khronos extension, that we, Harman/Becker, can better use the Khronos standards.
At this point of time, I defined the following:
Windowing Extension KD_HB_windowing
Takes away the focus from a window.
Get window caption.
Get window size.
Set the window appearance. E.g. opacity, border, caption visible, priority.
Get the window appearance E.g. visible, focus, opacity, border, caption visible, priority.
Display Extension KD_HB_display
Activates the given display and further operations (when not specified) are done on this display.
Deactivates the given display. Further operations (when not specified) are undefined.
Get the native display handle.
Set the background color of the display.
Get the background color of the display.
Set the window order of the display.
Get the list of available windows for this display.
Device Extension KD_HB_device
Get the amount of displays available.
Locking Extension KD_HB_locking
Locks the window.
Unlocks the window.
Locks the display.
Unlocks the display.
Snapshot Extension KD_HB_snapshot
Makes a snapshot (video memory dump) of the given window.
Makes a snapshot (video memory dump) of the given display.
I know it is quite a lot. I hope you understand, why we would need thes functions. If you have questions and/or suggestions, please let me know.
Also, I have started to make a reference implementation of this on Windows XP.
Thanks for the input.
A couple of comments from an initial read:
Are you able to give any information of the sort of application that you intend to use these extensions and why they need the functions ? This information can be as vague as you need to avoid commercial sensitivity.
Functions that manipulate a display may be better phrased as an EGL extension, since the data type (EGLDisplay) is from EGL.
The OpenKODE working group is working towards a release of OpenKODE 1.0 Final, and the draft spec we have has some significant changes in window handling over the OpenKODE 1.0 Provisional Revision 1 that is publicly available from earlier this year. There are now a small, fixed, number of functions to get and set properties on windows, so we'd expect people who want to write an extension to add features to windowing to do it by defining new properties. One of our members is going to propose such an extension soon, and this will probably at least partly overlap with your window proposal.
Okay, here we go. See my comments between the lines:
(In reply to comment #3)
> Thanks for the input.
> A couple of comments from an initial read:
> Are you able to give any information of the sort of application that you intend
> to use these extensions and why they need the functions ?
First, we was thinking about automotive applications. Second, I was also thinking about all possible applications. Also my private hobby in mind: Mobile Games
> This information can
> be as vague as you need to avoid commercial sensitivity.
I or we can not avoid commercial usage. This is your job but finally our job as well.
> Functions that manipulate a display may be better phrased as an EGL extension,
> since the data type (EGLDisplay) is from EGL.
Finally, the hardware is defining, which displays are available. For each display its own configuration. So, retrieving the displays from OpenKODE, configuring it with EGL.
> The OpenKODE working group is working towards a release of OpenKODE 1.0 Final,
> and the draft spec we have has some significant changes in window handling over
> the OpenKODE 1.0 Provisional Revision 1 that is publicly available from earlier
> this year. There are now a small, fixed, number of functions to get and set
> properties on windows, so we'd expect people who want to write an extension to
> add features to windowing to do it by defining new properties. One of our
> members is going to propose such an extension soon, and this will probably at
> least partly overlap with your window proposal.
See, it is just a suggestion from our side. I am happy with the solution now. The current implementations are somehow crab. If multiple, transparent windows and multiple displays with different resolutions and color models are somehow supported, we would be satisfied.