Khronos public bugtracker – Full Text Bug Listing
|Summary:||OpenKODE and EGL initialization conflict - extend OpenKODE|
|Product:||OpenKODE||Reporter:||Norbert Nopper <NNopper>|
|Component:||Specification||Assignee:||Tim Renouf <tim.renouf>|
|Status:||NEW ---||QA Contact:||OpenKODE Work Group email alias <openkode>|
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.