Khronos Public Bugzilla
Bug 55 - OpenKODE and EGL initialization conflict - extend OpenKODE
OpenKODE and EGL initialization conflict - extend OpenKODE
Status: NEW
Product: OpenKODE
Classification: Unclassified
Component: Specification
1.0 (Provisional)
All All
: P3 normal
: ---
Assigned To: Tim Renouf
OpenKODE Work Group email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-29 04:35 PST by Norbert Nopper
Modified: 2007-12-03 08:08 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert Nopper 2007-11-29 04:35:57 PST
Hi all, 

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
Comment 1 Tim Renouf 2007-11-30 06:34:55 PST
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
input.

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.
Comment 2 Norbert Nopper 2007-12-03 04:42:35 PST
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

kdDeactivateWindowHB
Takes away the focus from a window.

kdGetWindowCaptionHB
Get window caption.

kdGetWindowSizeHB
Get window size.

kdSetWindowAppearanceHB
Set the window appearance. E.g. opacity, border, caption visible, priority.

kdGetWindowAppearanceHB
Get the window appearance E.g. visible, focus, opacity, border, caption visible, priority.

---

Display						Extension KD_HB_display

kdActivateDisplayHB
Activates the given display and further operations (when not specified) are done on this display.

kdDeactivateDisplayHB
Deactivates the given display. Further operations (when not specified) are undefined.

kdGetDisplayNativeTypeHB
Get the native display handle.

kdSetDisplayBackgroundHB
Set the background color of the display.

kdGetDisplayBackgroundHB
Get the background color of the display.

kdSetDisplayWindowOrderHB
Set the window order of the display.

kdGetDisplayWindowListHB
Get the list of available windows for this display.

---

Device						Extension KD_HB_device

kdGetDeviceAmountDisplaysHB
Get the amount of displays available.

---

Locking						Extension KD_HB_locking

kdLockWindowHB
Locks the window.

kdUnlockWindowHB
Unlocks the window.

kdLockDisplayHB
Locks the display.

kdUnlockDisplayHB
Unlocks the display.

---

Snapshot					Extension KD_HB_snapshot

kdGetSnapshotWindowHB
Makes a snapshot (video memory dump) of the given window.

kdGetSnapshotDisplayHB
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.
Comment 3 Tim Renouf 2007-12-03 06:57:04 PST
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.
Comment 4 Norbert Nopper 2007-12-03 08:08:47 PST
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.

Norbert Nopper.