Feed for discussion CWM/OpenKODE in project Graphics. Posts for CWM/OpenKODE post117781: How to Zoom a displayed imge Srinidhi T N(deleted) http://community.qnx.com/sf/go/post117781 2017-06-09T06:04:47Z 2017-06-09T06:04:47Z Hi, I am looking for information on how to implement a zoom method. I referred Screen Graphics Subsystem Developer's guide. Could not find much explanation on how to implement zoom function. Could you please point to the document or some snippet of example code would help. Thanks in advance. Regards, Srinidhi. Srinidhi T N(deleted) 2017-06-09T06:04:47Z post113700: RE: Colorspace/Window formats drm-intel Alain Magloire http://community.qnx.com/sf/go/post113700 2015-04-13T18:08:28Z 2015-04-13T18:08:28Z Bonjour, The intel-drm wfd is not supporting RGB888 Thanks -----Original Message----- From: Kevin Stallard [mailto:community-noreply@qnx.com] Sent: April-10-15 12:51 PM To: cwm-graphics Subject: Colorspace/Window formats drm-intel I'm using QNX 6.6, drm-intel and screen. I've put rgb888 as the format for the frame buffer of our 1080p display, yet I am unable to create a window using SCREEN_FORMAT_RGB888 as the window format. Get an error saying it is not supported. It will only work with RGBA8888 or RGBX8888. I'm using the render buffers directly with a video capture system so that we can get real-time video. I would like to avoid any transformations that slow things down too much and so if possible would like to go directly from 24bit RBG to 24bit RGB. Is there a way get get screen to give me a window using SCREEN_FORMAT_RGB888 so that the render buffers use 24 bits? Thanks Kevin _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post113696 To cancel your subscription to this discussion, please e-mail cwm-graphics-unsubscribe@community.qnx.com Alain Magloire 2015-04-13T18:08:28Z post113696: Colorspace/Window formats drm-intel Kevin Stallard(deleted) http://community.qnx.com/sf/go/post113696 2015-04-10T16:50:43Z 2015-04-10T16:50:43Z I'm using QNX 6.6, drm-intel and screen. I've put rgb888 as the format for the frame buffer of our 1080p display, yet I am unable to create a window using SCREEN_FORMAT_RGB888 as the window format. Get an error saying it is not supported. It will only work with RGBA8888 or RGBX8888. I'm using the render buffers directly with a video capture system so that we can get real-time video. I would like to avoid any transformations that slow things down too much and so if possible would like to go directly from 24bit RBG to 24bit RGB. Is there a way get get screen to give me a window using SCREEN_FORMAT_RGB888 so that the render buffers use 24 bits? Thanks Kevin Kevin Stallard(deleted) 2015-04-10T16:50:43Z post113316: pre-processing the window framebuffer before composition manager does the final composition? Shi yun(deleted) http://community.qnx.com/sf/go/post113316 2015-02-15T10:55:24Z 2015-02-15T10:55:24Z We are developing application using QML/Qt on SDP6.6. We'd like to blur the underlying window content when another window is at foreground. Which means the foreground window is semi transparent and the background window is visible and gaussian blur(like MS Windows 7 Aero effect). We wanted that the background window content keeps updating even if it is at background. Is it possible to do one extra step to do gaussian blur for the background framebuffer before it is overlayed by the composition manager? Thanks in advance. - In graphics.conf, there is only one pipeline available. - the background window and foreground window MAY belong to different process(PID). Or MAY belong to same process. Br, Robin Shi yun(deleted) 2015-02-15T10:55:24Z post111879: Re: Alpha Blending w/ OpenGLES and OpenKODE Joel Pilon(deleted) http://community.qnx.com/sf/go/post111879 2014-09-25T15:59:35Z 2014-09-25T15:59:35Z Hi David, Unfortunately, any relevant details ‎have faded from my mind. You may need to follow up with QNX Support to get the issue sorted. -Joel Original Message From: David Beberman Sent: Wednesday, September 24, 2014 4:53 AM To: cwm-graphics Reply To: cwm-graphics@community.qnx.com Subject: Alpha Blending w/ OpenGLES and OpenKODE Hello everybody, we have an issue using QNX 6.5's OpenKODE Driver for OpenGLES (both 1.1 and 2.0) Our test case basically is: - Create EGL Display and Configuration - Create OpenKODE Context on top of it - Paint a green Fullscreen Rectangle and a smaller, semi-translucent blue rectangle => The blue (getting dark cyan) rectangle also changes background transparency so you can see the layers behind that application Doing the same steps with a Screen Context instead shows exactly what one would expect: A opaque dark cyan rectangle with green surroundings. I've attached the test application. Any idea? Specific information needed? _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post111864 To cancel your subscription to this discussion, please e-mail cwm-graphics-unsubscribe@community.qnx.com Joel Pilon(deleted) 2014-09-25T15:59:35Z post111864: Alpha Blending w/ OpenGLES and OpenKODE David Beberman(deleted) http://community.qnx.com/sf/go/post111864 2014-09-24T08:53:45Z 2014-09-24T08:53:45Z Hello everybody, we have an issue using QNX 6.5's OpenKODE Driver for OpenGLES (both 1.1 and 2.0) Our test case basically is: - Create EGL Display and Configuration - Create OpenKODE Context on top of it - Paint a green Fullscreen Rectangle and a smaller, semi-translucent blue rectangle => The blue (getting dark cyan) rectangle also changes background transparency so you can see the layers behind that application Doing the same steps with a Screen Context instead shows exactly what one would expect: A opaque dark cyan rectangle with green surroundings. I've attached the test application. Any idea? Specific information needed? David Beberman(deleted) 2014-09-24T08:53:45Z post101127: display in multiple process Lu Li(deleted) http://community.qnx.com/sf/go/post101127 2013-05-03T15:33:28Z 2013-05-03T15:33:28Z Hi there, I am new to QNX and CWM. Now I am working on a project to display using both opengles and QT in separate processes, and now either of them works ok. My opengles uses egl and gf (according to the documentation now) and QT uses pure gf (as far as I understand). My current solution is to use CWM to integrate them. my opengl initial code is similar to: http://code.google.com/p/glues/source/browse/trunk/glues/qnx/tests/nurbs/nurbs.c?r=27 I tried a few configurations for winmgr.conf including something like this one: begin display begin plane egl-config = 1 wfd-pipeline = 1 end plane end display When I started the io-winmgr and tried to start my opegl exe, my code will fail in gf_layer_attach. I looked at the demo and tutorial in the forum download, and tried the gear demo for egl (it seems that no gf calls in the demo), and it failed at very beginning when trying to do eglGetDisplay (returning null). My question will be: Is CWM the right solution to run both QT and my program. if answer is yes, can I run the code in the above link with modifying the winmgr.conf? if not, what else shall I change in the code? Thanks, Lu Lu Li(deleted) 2013-05-03T15:33:28Z post93511: Re: sysres utility bhanu shankar d g http://community.qnx.com/sf/go/post93511 2012-06-05T11:40:19Z 2012-06-05T11:40:19Z Hi if i run io-winmgr -sysres i am getting memory fault error! why? Please help. bhanu shankar d g 2012-06-05T11:40:19Z post93490: Re: io-winmgr -sysres : how to use correctly? bhanu shankar d g http://community.qnx.com/sf/go/post93490 2012-06-04T11:49:22Z 2012-06-04T11:49:22Z Hi, my io-winmgr -sysres is giving an error as Memory fault. my winmgr.conf file is attached. please help.i dont know why i am getting this error! bhanu shankar d g 2012-06-04T11:49:22Z post93484: Re: Multiple Display bhanu shankar d g http://community.qnx.com/sf/go/post93484 2012-06-04T09:31:01Z 2012-06-04T09:31:01Z how did you configure for single display? i am getting an error as memory fault when i try to run io-winmgr with sysres option. i.e my command line is as follows io-winmgr -start -sysres /abc.txt. my winmgr.conf is present in /etc/system/config directory. please help. bhanu shankar d g 2012-06-04T09:31:01Z post86354: Realizing an (initially) invisible window under CWM Glenn Schmottlach http://community.qnx.com/sf/go/post86354 2011-06-01T20:20:38Z 2011-06-01T20:20:38Z I need to create an initially *invisible* window in OpenKode so that when my application starts to run this window is not initially visible. From the documentation that I've read the call to kdRealizeWindow(kd_win, &egl_win) by default always makes the window visible (this is not what I want). I tried making a call to set the window "visibility" property prior to making this call: KDboolean visible = KD_FALSE; kdGetWindowPropertybv(kd_win, KD_WINDOWPROPERTY_VISIBILITY, &visible); but I still see this window visible until I explicitly (later) through my delegate window force it to become invisible. Is there some trick I'm not aware of to configure this window so it's initially realized as invisible? Thanks . . . Glenn Schmottlach 2011-06-01T20:20:38Z post84416: Re: RE: kdRealizeWindow Bjoern Petri http://community.qnx.com/sf/go/post84416 2011-03-30T14:39:50Z 2011-03-30T14:39:50Z > If you are relatively low on memory, or if physical memory is > fragmented you will get this error. That is what I assume too, but perhaps there might be some settings/ideas to increase the available memory. I hope someone already tried openKode on the beagleboard-xM. Bjoern Petri 2011-03-30T14:39:50Z post84414: RE: kdRealizeWindow Eric Fausett http://community.qnx.com/sf/go/post84414 2011-03-30T14:22:37Z 2011-03-30T14:22:37Z I haven't worked on the Beagleboard, but I'll offer a shot in the dark. The memory in question isn't just any memory, but it will most likely be requesting a physically contiguous block from what is available at the time. If you are relatively low on memory, or if physical memory is fragmented you will get this error. - Eric Eric Fausett 2011-03-30T14:22:37Z post84413: kdRealizeWindow Bjoern Petri http://community.qnx.com/sf/go/post84413 2011-03-30T14:11:42Z 2011-03-30T14:11:42Z Hi everyone, I try to run an OpenKode application on top of a beagle board xM by using the foundry 27 Beagleboard-xM Support Package. Unfortunately kdRealizeWindow always returns an ENOMEM-error. Hence it seems that it doesn't have enough memory Has anyone succeeded in running OpenKode applications on the Beagleboard-xM and might give me some hints, which configuration I need? Thanks in advance, Bjoern Bjoern Petri 2011-03-30T14:11:42Z post73799: Re: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()? JIN YOUNC CHEON http://community.qnx.com/sf/go/post73799 2010-11-08T05:18:38Z 2010-11-08T05:18:38Z Thanks in advance. What does conventional drawing under no io-winmgr mean, exactly ? What I meant by conventional drawing is drawing only using GF APIs like following. gf_dev_attach(); gf_display_attach(); gf_layer_attach(); gf_surface_create_layer(); gf_context_create(); gf_context_set_surface(context, surface); while(1){ gf_draw_begin(context); drawing_routine(); gf_draw_end(context); } On contrast, if I draw using egl APIs under io-winmgr, it was much slower. The code briefly looks like following. eglGetDisplay(); eglInitialize(); eglCreateWindowSurface(); gf_context_create(); gf_context_init(); gf_context_set_surface_3d(); while(1){ gf_draw_begin(context); drawing_routine(); gf_draw_end(context); eglbufferswap(); } What is the hardware ? We are using i.mx31 lit version(which doesn't have MBX). I have tested over VMWare. Other engineer in my team tested over i.mx31 and showed eglbufferswap() consumes much time. What are the settings in winmgr.conf ? begin globals input = all end globals begin display cursor = sw-arrow begin plane egl-config = auto end plane end display Why is CWM necessary in your current design ? Our graphic provides 2 physical layers. We needed more layers so we use software layers provided from io-winmgr. JIN YOUNC CHEON 2010-11-08T05:18:38Z post73792: Re: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()? Etienne Belanger(deleted) http://community.qnx.com/sf/go/post73792 2010-11-08T03:17:04Z 2010-11-08T03:17:04Z What does conventional drawing under no io-winmgr mean, exactly ? What is the hardware ? What are the settings in winmgr.conf ? Why is CWM necessary in your current design ? Etienne Belanger(deleted) 2010-11-08T03:17:04Z post73778: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()? JIN YOUNC CHEON http://community.qnx.com/sf/go/post73778 2010-11-06T23:22:58Z 2010-11-06T23:22:58Z I have tested drawing performance with gf-egl-vsync demo. Test result shows conventional drawing under no io-winmgr is much faster than doing under io-winmgr. It was 6 times faster. I suspect posting new frame using eglswapbuffer() to io-winmgr makes this difference in drawing time. Using CWM is necessary to current design. Is there any alternative way which works faster to post frame to io-winmgr than using eglswapbuffer()? JIN YOUNC CHEON 2010-11-06T23:22:58Z post65421: Re: focus event not received when changing window order Joel Pilon(deleted) http://community.qnx.com/sf/go/post65421 2010-09-01T12:54:23Z 2010-09-01T12:54:23Z Taking a quick peek at the source, it looks like we either missed that case, or decided against that behavior. You could try manually setting focus to the window your raising. Joel Pilon(deleted) 2010-09-01T12:54:23Z post65381: focus event not received when changing window order Adrian Higgins http://community.qnx.com/sf/go/post65381 2010-09-01T07:01:14Z 2010-09-01T07:01:14Z I and using kdSetWindowOrderQNX() to set the current application to the top. This works really well and I receive KD_EVENT_INPUT_POINTER events when I’m on top, and not when I’m on bottom. However I do not receive KD_EVENT_WINDOW_FOCUS events, so do not know when I have lost focus. Does a KD_EVENT_WINDOW_FOCUS (or even an Z_ORDER_CHANGED) event get firesd when the window order is changed using kdSetWindowOrderQNX()? Cheers Adrian Adrian Higgins 2010-09-01T07:01:14Z post64755: Re: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Gervais Mulongoy http://community.qnx.com/sf/go/post64755 2010-08-27T13:13:58Z 2010-08-27T13:13:58Z Thank you for the description. Gervais Mulongoy 2010-08-27T13:13:58Z post64751: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Etienne Belanger(deleted) http://community.qnx.com/sf/go/post64751 2010-08-27T12:59:54Z 2010-08-27T12:59:54Z The freeze property suspends the handling of posts from a window. Therefore, eglSwapBuffers will block when it runs out of buffers. After the first post, the client only has 1 buffer, so setting a freeze will cause eglSwapBuffers to block until the freeze is removed. The property was added as a big hammer for delegates that want to stop apps from updating. Not as a way of getting atomic operations. We implemented some form of atomic operations, probably on a different branch. -Etienne Belanger -----Original Message----- From: Gervais Mulongoy [mailto:community-noreply@qnx.com] Sent: August 26, 2010 3:45 PM To: cwm-graphics Subject: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Hello, The customer is trying to implement a smooth scrolling algorithm where they need to swap buffers and change window properties such as KD_WINDOWPROPERTY_SOURCE_POSITION_QNX in one step without intermediate states becoming visible on the display (basically they want the algo to be atomic). To that end, they began testing and ran into an issue that can be distilled into the test case below. They use the following steps in a test program (ie. gles1-kd-gears) in a loop: 1) Render something 2) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, true) 3) Call eglSwapBuffers() 4) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, false) The first iteration of the loop behaves as expected (the display stays black), but any subsequent iteration eglSwapBuffers() doesn't return, and the process becomes unresponsive. My first question, is it correct to use the freeze property in the way described above? Second, since this is a patch on F27, is the freeze property fully implemented in the patch? Third, do we have any other (better) mechanisms they could use to implement their smooth scrolling? My apologies if this is already documented somewhere and I missed the obvious. Thanks _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post64676 Etienne Belanger(deleted) 2010-08-27T12:59:54Z post64690: Re: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Gervais Mulongoy http://community.qnx.com/sf/go/post64690 2010-08-26T20:33:48Z 2010-08-26T20:33:48Z Scratch that, it is documented here: http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=/com.qnx.doc.composition_manager_dev_guide/kd_qnx_window.html Gervais Mulongoy 2010-08-26T20:33:48Z post64689: Re: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Gervais Mulongoy http://community.qnx.com/sf/go/post64689 2010-08-26T20:30:21Z 2010-08-26T20:30:21Z For sake of having this written down, what exactly does that freeze property do and why does it cause this issue when used with eglSwapBuffers()? Gervais Mulongoy 2010-08-26T20:30:21Z post64677: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Joel Pilon(deleted) http://community.qnx.com/sf/go/post64677 2010-08-26T19:50:26Z 2010-08-26T19:50:26Z With that version of CM it's not possible to atomically update window properties with a post. -Joel -----Original Message----- From: Gervais Mulongoy [mailto:community-noreply@qnx.com] Sent: Thu 8/26/2010 3:45 PM To: cwm-graphics Subject: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Hello, The customer is trying to implement a smooth scrolling algorithm where they need to swap buffers and change window properties such as KD_WINDOWPROPERTY_SOURCE_POSITION_QNX in one step without intermediate states becoming visible on the display (basically they want the algo to be atomic). To that end, they began testing and ran into an issue that can be distilled into the test case below. They use the following steps in a test program (ie. gles1-kd-gears) in a loop: 1) Render something 2) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, true) 3) Call eglSwapBuffers() 4) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, false) The first iteration of the loop behaves as expected (the display stays black), but any subsequent iteration eglSwapBuffers() doesn't return, and the process becomes unresponsive. My first question, is it correct to use the freeze property in the way described above? Second, since this is a patch on F27, is the freeze property fully implemented in the patch? Third, do we have any other (better) mechanisms they could use to implement their smooth scrolling? My apologies if this is already documented somewhere and I missed the obvious. Thanks _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post64676 Joel Pilon(deleted) 2010-08-26T19:50:26Z post64676: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27 Gervais Mulongoy http://community.qnx.com/sf/go/post64676 2010-08-26T19:45:28Z 2010-08-26T19:45:28Z Hello, The customer is trying to implement a smooth scrolling algorithm where they need to swap buffers and change window properties such as KD_WINDOWPROPERTY_SOURCE_POSITION_QNX in one step without intermediate states becoming visible on the display (basically they want the algo to be atomic). To that end, they began testing and ran into an issue that can be distilled into the test case below. They use the following steps in a test program (ie. gles1-kd-gears) in a loop: 1) Render something 2) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, true) 3) Call eglSwapBuffers() 4) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, false) The first iteration of the loop behaves as expected (the display stays black), but any subsequent iteration eglSwapBuffers() doesn't return, and the process becomes unresponsive. My first question, is it correct to use the freeze property in the way described above? Second, since this is a patch on F27, is the freeze property fully implemented in the patch? Third, do we have any other (better) mechanisms they could use to implement their smooth scrolling? My apologies if this is already documented somewhere and I missed the obvious. Thanks Gervais Mulongoy 2010-08-26T19:45:28Z post57865: Re: Can we use OpenKODE at VWMARE? Chen ShunLi http://community.qnx.com/sf/go/post57865 2010-06-25T02:45:04Z 2010-06-25T02:45:04Z I am sorry for disordered information. I add them to Excel file. Please check it. Thanks --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- Chen ShunLi 2010-06-25T02:45:04Z post57864: Re: Can we use OpenKODE at VWMARE? Chen ShunLi http://community.qnx.com/sf/go/post57864 2010-06-25T02:35:22Z 2010-06-25T02:35:22Z 1. Photon Mode: +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ | config id | caveat | red | green | blue | luminance | alpha | depth | stencil | samples | window | pbuffer | pixmap | gles1 | gles2 | vg | gl | native | level | +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ | 1 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 2 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 3 | none | 8 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 4 | none | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 5 | none | 5 | 5 | 5 | 0 | 1 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 6 | none | 0 | 0 | 0 | 8 | 0 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 7 | slow | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 8 | slow | 8 | 8 | 8 | 0 | 8 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 9 | slow | 8 | 8 | 8 | 0 | 8 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 10 | slow | 8 | 8 | 8 | 0 | 8 | 16 | 16 | 0 | | x | x | x | | | | | 0 | | 11 | slow | 8 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 12 | slow | 8 | 8 | 8 | 0 | 0 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 13 | slow | 8 | 8 | 8 | 0 | 0 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 14 | slow | 8 | 8 | 8 | 0 | 0 | 16 | 16 | 0 | | x | x | x | | | | | 0 | | 15 | slow | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 16 | slow | 5 | 5 | 5 | 0 | 1 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 17 | slow | 5 | 6 | 5 | 0 | 0 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 18 | slow | 5 | 5 | 5 | 0 | 1 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 19 | slow | 5 | 6 | 5 | 0 | 0 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 20 | slow | 5 | 5 | 5 | 0 | 1 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 21 | slow | 5 | 6 | 5 | 0 | 0 | 16 | 16 | 0 | | x | x | x | | | | | 0 | | 22 | slow | 5 | 5 | 5 | 0 | 1 | 16 | 16 | 0 | | x | x | x | | | | | 0 | +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ 2. Text Mode +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ | config id | caveat | red | green | blue | luminance | alpha | depth | stencil | samples | window | pbuffer | pixmap | gles1 | gles2 | vg | gl | native | level | +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ | 1 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 2 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 3 | none | 8 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 4 | none | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 5 | none | 5 | 5 | 5 | 0 | 1 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 6 | none | 0 | 0 | 0 | 8 | 0 | 0 | 0 | 0 | | x | x | | | | | x | 0 | | 7 | slow | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | x | x | x | x | | | | | 0 | | 8 | slow | 8 | 8 | 8 | 0 | 8 | 0 | 16 | 0 | x | x | x | x | | | | | 0 | | 9 | slow | 8 | 8 | 8 | 0 | 8 | 16 | 0 | 0 | x | x | x | x | | | | | 0 | | 10 | slow | 8 | 8 | 8 | 0 | 8 | 16 | 16 | 0 | x | x | x | x | | | | | 0 | | 11 | slow | 8 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 12 | slow | 8 | 8 | 8 | 0 | 0 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 13 | slow | 8 | 8 | 8 | 0 | 0 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 14 | slow | 8 | 8 | 8 | 0 | 0 | 16 | 16 | 0 | | x | x | x | | | | | 0 | | 15 | slow | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 16 | slow | 5 | 5 | 5 | 0 | 1 | 0 | 0 | 0 | | x | x | x | | | | | 0 | | 17 | slow | 5 | 6 | 5 | 0 | 0 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 18 | slow | 5 | 5 | 5 | 0 | 1 | 0 | 16 | 0 | | x | x | x | | | | | 0 | | 19 | slow | 5 | 6 | 5 | 0 | 0 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 20 | slow | 5 | 5 | 5 | 0 | 1 | 16 | 0 | 0 | | x | x | x | | | | | 0 | | 21 | slow | 5 | 6 | 5 | 0 | 0 | 16 | 16 | 0 | | x | x | x | | | | | 0 | | 22 | slow | 5 | 5 | 5 | 0 | 1 | 16 | 16 | 0 | | x | x | x | | | | | 0 | +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ ===================================== Chen Shunli AVNC&IS Division Neusoft Co., Ltd. No.2 Xin Xiu Street. Hun Nan New District, Shenyang 110179, PRC Tel:+86 24 83664044 Fax:+86 24 23781242 Email:chensl@neusoft.com Http://www.neusoft.com ===================================== -------------------------------------------------- From: "Jason Mawdsley" <community-noreply@qnx.com> Sent: Friday, June 25, 2010 10:30 AM To: "cwm-graphics" <post57863@community.qnx.com> Subject: Re: Can we use OpenKODE at VWMARE? > OpenKODE apps don¹t run in VMWare. > > Can you run egl-configs and put the output here? > > Thanks, > Jason > On 10-06-24 9:44 PM, "Chen ShunLi" <community-noreply@qnx.com> wrote: > >> In fact, the source code is copy from SVN "gles1-kd-pbuffer.c" and be >> changed some MACRO such as: >> KD_WINDOWPROPERTY_POSITION_QNX==>KD_QNX_WINDOWPROPERTY_POSITION >> >> 1. At the photon mode, the kdCreateWindow is failure >> 2. I change it to Text mode and run the io-winmgr by telnet, the >> kdCreateWindow is OK. >> But when we call kdRealizeWindow( kd_win, &egl_win), the elg_win is >> NULL. >> Full screen with white background displayed in VMWARE >> >> thanks >> >> >> ------------------------------------------------------------------------------ >> --------------------- >> Confidentiality Notice: The information contained in this e-mail and any >> accompanying attachment(s) >> is intended only for the use of the intended recipient and may be >> confidential >> and/or privileged of >> Neusoft Corporation, its subsidiaries and/or its affiliates. If any >> reader of >> this communication is >> not the intended recipient, unauthorized use, forwarding, printing, >> storing, >> disclosure or copying >> is strictly prohibited, and may be unlawful.If you have received this >> communication in error,please >> immediately notify the sender by return e-mail, and delete the original >> message and all copies from >> your system. Thank you. >> ------------------------------------------------------------------------------ >> --------------------- >> >> >> >> >> _______________________________________________ >> >> CWM/OpenKODE >> http://community.qnx.com/sf/go/post57862 >> > > > > > > _______________________________________________ > > CWM/OpenKODE > http://community.qnx.com/sf/go/post57863 > --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- Chen ShunLi 2010-06-25T02:35:22Z post57863: Re: Can we use OpenKODE at VWMARE? Jason Mawdsley http://community.qnx.com/sf/go/post57863 2010-06-25T02:30:00Z 2010-06-25T02:30:00Z OpenKODE apps don¹t run in VMWare. Can you run egl-configs and put the output here? Thanks, Jason On 10-06-24 9:44 PM, "Chen ShunLi" <community-noreply@qnx.com> wrote: > In fact, the source code is copy from SVN "gles1-kd-pbuffer.c" and be > changed some MACRO such as: > KD_WINDOWPROPERTY_POSITION_QNX==>KD_QNX_WINDOWPROPERTY_POSITION > > 1. At the photon mode, the kdCreateWindow is failure > 2. I change it to Text mode and run the io-winmgr by telnet, the > kdCreateWindow is OK. > But when we call kdRealizeWindow( kd_win, &egl_win), the elg_win is NULL. > Full screen with white background displayed in VMWARE > > thanks > > > ------------------------------------------------------------------------------ > --------------------- > Confidentiality Notice: The information contained in this e-mail and any > accompanying attachment(s) > is intended only for the use of the intended recipient and may be confidential > and/or privileged of > Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of > this communication is > not the intended recipient, unauthorized use, forwarding, printing, storing, > disclosure or copying > is strictly prohibited, and may be unlawful.If you have received this > communication in error,please > immediately notify the sender by return e-mail, and delete the original > message and all copies from > your system. Thank you. > ------------------------------------------------------------------------------ > --------------------- > > > > > _______________________________________________ > > CWM/OpenKODE > http://community.qnx.com/sf/go/post57862 > Jason Mawdsley 2010-06-25T02:30:00Z post57862: Re: Can we use OpenKODE at VWMARE? Chen ShunLi http://community.qnx.com/sf/go/post57862 2010-06-25T01:44:54Z 2010-06-25T01:44:54Z In fact, the source code is copy from SVN "gles1-kd-pbuffer.c" and be changed some MACRO such as: KD_WINDOWPROPERTY_POSITION_QNX==>KD_QNX_WINDOWPROPERTY_POSITION 1. At the photon mode, the kdCreateWindow is failure 2. I change it to Text mode and run the io-winmgr by telnet, the kdCreateWindow is OK. But when we call kdRealizeWindow( kd_win, &egl_win), the elg_win is NULL. Full screen with white background displayed in VMWARE thanks --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- Chen ShunLi 2010-06-25T01:44:54Z post57861: Re: Can we use OpenKODE at VWMARE? Jason Mawdsley http://community.qnx.com/sf/go/post57861 2010-06-25T01:28:24Z 2010-06-25T01:28:24Z Please attach your source code, or at least the initialization pieces. Thanks, Jason On 10-06-24 9:26 PM, "Chen ShunLi" <community-noreply@qnx.com> wrote: > > > hi, > Can we use the OpenKODE under the following environment: > VMWARE 5.5 > QNX 6.4.1 > OpenGL Es 1.4 > When we call the function kdRealizeWindow( kd_win, &egl_win), the egl_win > is NULL. > And can we use it at the Photon Mode? > > Thanks > ------------------------------------------------------------------------------ > --------------------- > Confidentiality Notice: The information contained in this e-mail and any > accompanying attachment(s) > is intended only for the use of the intended recipient and may be confidential > and/or privileged of > Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of > this communication is > not the intended recipient, unauthorized use, forwarding, printing, storing, > disclosure or copying > is strictly prohibited, and may be unlawful.If you have received this > communication in error,please > immediately notify the sender by return e-mail, and delete the original > message and all copies from > your system. Thank you. > ------------------------------------------------------------------------------ > --------------------- > > > > > _______________________________________________ > > CWM/OpenKODE > http://community.qnx.com/sf/go/post57860 > > Jason Mawdsley 2010-06-25T01:28:24Z post57860: Can we use OpenKODE at VWMARE? Chen ShunLi http://community.qnx.com/sf/go/post57860 2010-06-25T01:26:31Z 2010-06-25T01:26:31Z hi, Can we use the OpenKODE under the following environment: VMWARE 5.5 QNX 6.4.1 OpenGL Es 1.4 When we call the function kdRealizeWindow( kd_win, &egl_win), the egl_win is NULL. And can we use it at the Photon Mode? Thanks --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- Chen ShunLi 2010-06-25T01:26:31Z post56586: How to use opengles in photon Mode with VMWare Chen ShunLi http://community.qnx.com/sf/go/post56586 2010-06-11T05:36:15Z 2010-06-11T05:36:15Z I can run the opengl demo gears at the Text Mode. How can I run it in photon mode? Is it necessary to set the io-winngr? Comments: I am a greener, so please tell me in detail as possible. Thanks. --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- Chen ShunLi 2010-06-11T05:36:15Z post52624: Re: Flash cann't live with multiple windows shi huarong http://community.qnx.com/sf/go/post52624 2010-04-24T05:34:47Z 2010-04-24T05:34:47Z > Hello,I want to create flash that rendering by OpenVG on EGL config 0 and > create two windows by OpenKode on EGL config 1.The result is the flash display > nomally when the first window display, but the flash disappear when the > second window display,only the two windows left.I want to know the reason why > flash cann't live with multiple windows. I'm very sorry.The flash rendering on EGL level 0 (is not EGL config 0) and that two windows rendering an EGL level 1(is not EGL config 0). shi huarong 2010-04-24T05:34:47Z post52623: Flash cann't live with multiple windows shi huarong http://community.qnx.com/sf/go/post52623 2010-04-24T05:24:12Z 2010-04-24T05:24:12Z Hello,I want to create flash that rendering by OpenVG on EGL config 0 and create two windows by OpenKode on EGL config 1.The result is the flash display nomally when the first window display, but the flash disappear when the second window display,only the two windows left.I want to know the reason why flash cann't live with multiple windows. The EGL configures about board. +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ | config id | caveat | red | green | blue | luminance | alpha | depth | stencil | samples | window | pbuffer | pixmap | gles1 | gles2 | vg | gl | native | level | +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ | 1 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 2 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | x | x | x | | | x | | | 0 | | 3 | none | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 4 | none | 8 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 5 | none | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 6 | none | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | x | x | x | | | x | | | 0 | | 7 | none | 5 | 5 | 5 | 0 | 1 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 8 | none | 0 | 0 | 0 | 8 | 0 | 0 | 0 | 0 | x | x | x | | | | | x | 0 | | 9 | slow | 8 | 8 | 8 | 0 | 8 | 0 | 0 | 0 | x | x | x | x | | | | | 0 | | 10 | slow | 8 | 8 | 8 | 0 | 8 | 0 | 16 | 0 | x | x | x | x | | | | | 0 | | 11 | slow | 8 | 8 | 8 | 0 | 8 | 16 | 0 | 0 | x | x | x | x | | | | | 0 | | 12 | slow | 8 | 8 | 8 | 0 | 8 | 16 | 16 | 0 | x | x | x | x | | | | | 0 | | 13 | slow | 8 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | x | x | x | x | | | | | 0 | | 14 | slow | 8 | 8 | 8 | 0 | 0 | 0 | 16 | 0 | x | x | x | x | | | | | 0 | | 15 | slow | 8 | 8 | 8 | 0 | 0 | 16 | 0 | 0 | x | x | x | x | | | | | 0 | | 16 | slow | 8 | 8 | 8 | 0 | 0 | 16 | 16 | 0 | x | x | x | x | | | | | 0 | | 17 | slow | 5 | 6 | 5 | 0 | 0 | 0 | 0 | 0 | x | x | x | x | | | | | 0 | | 18 | slow | 5 | 5 | 5 | 0 | 1 | 0 | 0 | 0 | x | x | x | x | | | | | 0 | | 19 | slow | 5 | 6 | 5 | 0 | 0 | 0 | 16 | 0 | x | x | x | x | | | | | 0 | | 20 | slow | 5 | 5 | 5 | 0 | 1 | 0 | 16 | 0 | x | x | x | x | | | | | 0 | | 21 | slow | 5 | 6 | 5 | 0 | 0 | 16 | 0 | 0 | x | x | x | x | | | | | 0 | | 22 | slow | 5 | 5 | 5 | 0 | 1 | 16 | 0 | 0 | x | x | x | x | | | | | 0 | | 23 | slow | 5 | 6 | 5 | 0 | 0 | 16 | 16 | 0 | x | x | x | x | | | | | 0 | | 24 | slow | 5 | 5 | 5 | 0 | 1 | 16 | 16 | 0 | x | x | x | x | | | | | 0 | +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+ The io-winmgr configure file +--------+---------+--------+-------+-------+----+----+--------+ begin globals input = all end globals begin display cursor = off begin plane egl-config = auto wfd-pipeline = 1 end plane begin plane egl-config = auto wfd-pipeline = 2 end plane end display begin class name = display caption = routing delegate = false visible = true source-alpha = true end class +--------+---------+--------+-------+-------+----+----+--------+ The flash configure file +--------+---------+--------+-------+-------+----+----+--------+ dll =flashlite-vg.so extension { dll = hmip-openvg.so config { format = 565 } } extension { dll = hmip-compmgr.so config { window_manager = false winmgr_class = Flash } } +--------+---------+--------+-------+-------+----+----+--------+ The application about creat windows. #include <stdlib.h> #include <stdio.h> #include <pthread.h> #include <EGL/egl.h> #include <GLES/gl.h> #include <KD/kd.h> #include <KD/kd_qnx_window.h> #include <unistd.h> KDWindow *kd_win1; KDWindow *kd_win; EGLint egl_con_attr[]= { EGL_SURFACE_TYPE, EGL_WINDOW_BIT, EGL_RENDERABLE_TYPE, EGL_OPENGL_ES_BIT, EGL_LEVEL, 1, EGL_RED_SIZE, 5, EGL_GREEN_SIZE, 6, EGL_BLUE_SIZE, 5, EGL_ALPHA_SIZE,0, EGL_NONE }; void* thread_draw1( void *arg ) { EGLDisplay egl_disp; EGLConfig egl_config=0; EGLint egl_num_configs; EGLSurface egl_surf; EGLContext egl_ctx; EGLBoolean retValue; EGLNativeWindowType egl_win; KDint winSize[]={200,200}; KDint winPos[]={200,200}; EGLint egl_surf_attr[] = { EGL_WIDTH, 200, EGL_HEIGHT, 200, EGL_NONE }; GLfloat p1[]={ 0.5f,0.0f,0.0f }; GLfloat p2[]={ -0.5f,0.0f,0.0f }; GLfloat p3[]={ 0.0f,0.5f,0.0f }; printf("entry thread_draw1!\n"); egl_disp = eglGetDisplay(EGL_DEFAULT_DISPLAY); if(egl_disp == EGL_NO_DISPLAY) { printf("EGL NO Display!\n"); } eglInitialize(egl_disp,NULL,NULL); retValue = eglChooseConfig(egl_disp,egl_con_attr,&egl_config,1,&egl_num_configs); if(retValue == EGL_FALSE) { printf("Fail to EGL Choose Config!\n"); } printf("config:%d\n",(int)egl_config); kd_win1 = kdCreateWindow(egl_disp,egl_config,KD_NULL); kdSetWindowPropertyiv(kd_win1, KD_WINDOWPROPERTY_SIZE, winSize); kdSetWindowPropertyiv(kd_win1, KD_QNX_WINDOWPROPERTY_POSITION, winPos); kdRealizeWindow(kd_win1, &egl_win); egl_surf = eglCreateWindowSurface(egl_disp,egl_config,egl_win,egl_surf_attr); if(egl_surf == EGL_NO_SURFACE) { printf("No Surface!\n"); } egl_ctx = eglCreateContext(egl_disp,egl_config,EGL_NO_CONTEXT,NULL); if(egl_ctx == EGL_NO_CONTEXT) { printf("NO Context!\n"); } retValue = eglMakeCurrent(egl_disp,egl_surf,egl_surf,egl_ctx); if(retValue == EGL_FALSE) { printf("Failed to EGL Make Current!\n"); } eglSwapInterval(egl_disp, 1); glEnableClientState(GL_VERTEX_ARRAY); glClearColor(1.0f,1.0f,1.0f,1.0f); //glClear(GL_COLOR_BUFFER_BIT); glColor4f(1.0f,0.0f,0.0f,0.0f); glVertexPointer(3,GL_FLOAT ,0,p1); glVertexPointer(3,GL_FLOAT ,0,p2); glVertexPointer(3,GL_FLOAT ,0,p3); glDrawArrays(GL_TRIANGLE_STRIP ,0,3); eglSwapBuffers(egl_disp,egl_surf); sleep(15); //kdDestroyWindow(kd_win1); //eglTerminate(egl_disp); return NULL; } void* thread_draw2( void *arg ) { printf("entry thread_draw2!\n"); EGLDisplay egl_disp; EGLConfig egl_config=0; EGLint egl_num_configs; EGLSurface egl_surf; EGLContext egl_ctx; EGLBoolean retValue; KDWindow *kd_win; EGLNativeWindowType egl_win; KDint winSize[]={400,400}; KDint winPos[]={0,0}; EGLint egl_surf_attr[] = { EGL_WIDTH, 400, EGL_HEIGHT, 400, EGL_NONE }; GLfloat p1[]={ 0.5f,0.0f,0.0f }; GLfloat p2[]={ -0.5f,0.0f,0.0f }; GLfloat p3[]={ 0.0f,0.5f,0.0f }; egl_disp = eglGetDisplay(EGL_DEFAULT_DISPLAY); if(egl_disp == EGL_NO_DISPLAY) { printf("EGL NO Display!\n"); } eglInitialize(egl_disp,NULL,NULL); retValue = eglChooseConfig(egl_disp,egl_con_attr,&egl_config,1,&egl_num_configs); if(retValue == EGL_FALSE) { printf("Fail to EGL Choose Config!\n"); } printf("config:%d\n",(int)egl_config); kd_win = kdCreateWindow(egl_disp,egl_config,KD_NULL); printf("thread2 kdCreateWindow\n"); kdSetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, winSize); kdSetWindowPropertyiv(kd_win, KD_QNX_WINDOWPROPERTY_POSITION, winPos); kdRealizeWindow(kd_win, &egl_win); printf("thread2 kdRealizeWindow\n"); egl_surf = eglCreateWindowSurface(egl_disp,egl_config,egl_win,egl_surf_attr); printf("thread2 eglCreateWindowSurface\n"); if(egl_surf == EGL_NO_SURFACE) { printf("No Surface!\n"); } egl_ctx = eglCreateContext(egl_disp,egl_config,EGL_NO_CONTEXT,NULL); printf("thread2 eglCreateContext\n"); if(egl_ctx == EGL_NO_CONTEXT) { printf("NO Context!\n"); } retValue = eglMakeCurrent(egl_disp,egl_surf,egl_surf,egl_ctx); printf("thread2 eglMakeCurrent\n"); if(retValue == EGL_FALSE) { printf("Failed to EGL Make Current!\n"); } eglSwapInterval(egl_disp, 2); printf("thread2 eglSwapInterval\n"); glEnableClientState(GL_VERTEX_ARRAY); printf("thread2 glEnableClientState\n"); glClearColor(1.0f,1.0f,1.0f,1.0f); printf("thread2 glClearColor\n"); //glClear(GL_COLOR_BUFFER_BIT); printf("thread2 glClear\n"); glColor4f(1.0f,1.0f,0.0f,0.0f); printf("thread2 glColor4f\n"); glVertexPointer(3,GL_FLOAT ,0,p1); printf("thread2 glVertexPointer\n"); glVertexPointer(3,GL_FLOAT ,0,p2); glVertexPointer(3,GL_FLOAT ,0,p3); glDrawArrays(GL_TRIANGLE_STRIP ,0,3); printf("thread2 BF eglSwapBuffers\n"); eglSwapBuffers(egl_disp,egl_surf); printf("thread2 AF eglSwapBuffers\n"); // sleep(15); // kdDestroyWindow(kd_win); // eglTerminate(egl_disp); return NULL; } int kdMain( KDint argc, const KDchar *const *argv ) { thread_draw2((void*)0); sleep(10); thread_draw1((void*)0); while( 1 ) { sleep(20); } return EXIT_SUCCESS; } shi huarong 2010-04-24T05:24:12Z post51055: Re: question about io-winmgr Joel Pilon(deleted) http://community.qnx.com/sf/go/post51055 2010-04-01T15:18:46Z 2010-04-01T15:18:46Z We also provide a delegate interface which helps to write a window manager. The following tutorial is a simple example of a window manager: http://community.qnx.com/integration/viewvc/viewvc.cgi/trunk/apps/kd/tutorials/gles1-kd-hmi/?root=graphics&system=exsy1001 Joel Pilon(deleted) 2010-04-01T15:18:46Z post51044: Re: question about io-winmgr Jason Mawdsley http://community.qnx.com/sf/go/post51044 2010-04-01T14:13:36Z 2010-04-01T14:13:36Z > From the tutorials, it seems that io-winmgr is just a server. > > I start io-winmgr with default config file, just get a black screen. Yes, that is right, you can also specify a different colour if you so wish through the graphics.conf file. > If my understanding is right, to make composition work, there must be a client > app just like photon to provide a window system. Yes there must be a client app that is running. But not Photon. You need to create client app(s) to run that use the OpenKODE spec. Composition Manager implements part of that spec to allow for the creation, deletion, and managment of windows. > Is there a window manager on qnx provide a environment like composite desktop, > on which we can do rotate and reflect? These features are not implemented in CompManager at this point. Jason Mawdsley 2010-04-01T14:13:36Z post51012: question about io-winmgr ivan chen http://community.qnx.com/sf/go/post51012 2010-04-01T06:33:00Z 2010-04-01T06:33:00Z Hi, All From the tutorials, it seems that io-winmgr is just a server. I start io-winmgr with default config file, just get a black screen. If my understanding is right, to make composition work, there must be a client app just like photon to provide a window system. Is there a window manager on qnx provide a environment like composite desktop, on which we can do rotate and reflect? Thanks! ivan chen 2010-04-01T06:33:00Z post49870: Re: /dev entries for each display section Gervais Mulongoy http://community.qnx.com/sf/go/post49870 2010-03-18T15:51:09Z 2010-03-18T15:51:09Z I have since found out that is not the case. The :0 denotes the id/handle of the instance of io-winmgr. Gervais Mulongoy 2010-03-18T15:51:09Z post49667: /dev entries for each display section Gervais Mulongoy http://community.qnx.com/sf/go/post49667 2010-03-16T21:03:45Z 2010-03-16T21:03:45Z Hello all: It is currently my understanding that for each display section in winmgr.conf there will be a corresponding /dev/winmgr:0 style entry. Is this the case, or are the entries generated for a different reason? Thanks, Gervais Gervais Mulongoy 2010-03-16T21:03:45Z post49666: Re: winmgr.conf more than one display section Gervais Mulongoy http://community.qnx.com/sf/go/post49666 2010-03-16T21:01:24Z 2010-03-16T21:01:24Z Thanks JP - wfd-device is actually needed. Gervais Mulongoy 2010-03-16T21:01:24Z post49619: winmgr.conf more than one display section Gervais Mulongoy http://community.qnx.com/sf/go/post49619 2010-03-16T15:56:53Z 2010-03-16T15:56:53Z Hello all: I wanted to clarify a point in winmgr.conf. Now I understand for each physical display you want to target you need a display section in winmgr.conf. If you don't specify an id (like if you just copied the display section so you have two identical ones), will the display sections point to the default physical display or will they automatically know to associate with the next physical display? If we do in fact need to specify the id I am assuming we use the wfd-device setting and get the value from sysres as described in the comments. Thanks, Gervais Gervais Mulongoy 2010-03-16T15:56:53Z post49549: RE: Howto instruct the flash player to target more than one display at a time Paul Streatch http://community.qnx.com/sf/go/post49549 2010-03-15T22:22:18Z 2010-03-15T22:22:18Z Note that the two displays could have different pixel depths/color formats (making stretching/sharing of a single surface difficult). > -----Original Message----- > From: Roger Maclean [mailto:community-noreply@qnx.com] > Sent: March 15, 2010 6:01 PM > To: cwm-graphics > Subject: Re: Howto instruct the flash player to target more than one display at > a time > > Yes, you would have to run two instances of the flash player. > > I don't believe there is any way of cloning a display or stretching it > across two screens. I've asked about this and I'll let you know if I'm > wrong but I'd be very surprised. > > > > > _______________________________________________ > > CWM/OpenKODE > http://community.qnx.com/sf/go/post49545 Paul Streatch 2010-03-15T22:22:18Z post49545: Re: Howto instruct the flash player to target more than one display at a time Roger Maclean http://community.qnx.com/sf/go/post49545 2010-03-15T22:01:25Z 2010-03-15T22:01:25Z Yes, you would have to run two instances of the flash player. I don't believe there is any way of cloning a display or stretching it across two screens. I've asked about this and I'll let you know if I'm wrong but I'd be very surprised. Roger Maclean 2010-03-15T22:01:25Z post49522: Re: Howto instruct the flash player to target more than one display at a time Gervais Mulongoy http://community.qnx.com/sf/go/post49522 2010-03-15T18:50:08Z 2010-03-15T18:50:08Z Hello Roger: If I want to run the same SWF on two displays I would then need to start two instances of the flash player each with their own flash.conf targeting the appropriate display? So long as I had two device entries in display.conf and started io-display with both devices specified, and also two display sections in winmgr.conf. Finally is there no way to clone the display to another screen or is it possible to stretch the display on two screens? Thank you, Gervais Gervais Mulongoy 2010-03-15T18:50:08Z post49514: Re: Howto instruct the flash player to target more than one display at a time Jason Mawdsley http://community.qnx.com/sf/go/post49514 2010-03-15T18:34:27Z 2010-03-15T18:34:27Z You can always document it Gervais :) On 10-03-15 2:31 PM, "Roger Maclean" <community-noreply@qnx.com> wrote: > Yes, the value is just used as the parameter passed to eglGetDisplay. Each > instance of the Flash player can only target a single display. > > It's not currently documented anywhere, it has only been added fairly > recently. > > > > > _______________________________________________ > > CWM/OpenKODE > http://community.qnx.com/sf/go/post49512 > Jason Mawdsley 2010-03-15T18:34:27Z post49512: Re: Howto instruct the flash player to target more than one display at a time Roger Maclean http://community.qnx.com/sf/go/post49512 2010-03-15T18:31:51Z 2010-03-15T18:31:51Z Yes, the value is just used as the parameter passed to eglGetDisplay. Each instance of the Flash player can only target a single display. It's not currently documented anywhere, it has only been added fairly recently. Roger Maclean 2010-03-15T18:31:51Z post49504: Re: Howto instruct the flash player to target more than one display at a time Gervais Mulongoy http://community.qnx.com/sf/go/post49504 2010-03-15T18:08:51Z 2010-03-15T18:08:51Z So the display setting is used specify which display to target to if there are more than one display available? Is this documented anywhere? Gervais Mulongoy 2010-03-15T18:08:51Z post49503: Re: Howto instruct the flash player to target more than one display at a time Paul Streatch http://community.qnx.com/sf/go/post49503 2010-03-15T17:52:52Z 2010-03-15T17:52:52Z I think the flash player can only target a single display (the Flash stage cannot be shared between displays or windows). Paul ----- Original Message ----- From: Gervais Mulongoy <community-noreply@qnx.com> To: cwm-graphics <post49501@community.qnx.com> Sent: Mon Mar 15 13:47:45 2010 Subject: Howto instruct the flash player to target more than one display at a time Hello all: I have recently discovered that support for multiple displays was recently added to the flash player and to enable support, one needs to use the hmip-compmgr.so extension in the flash.conf as follows: [code] extension { dll = hmip-compmgr.so config { display = 1 } } [/code] Assuming a minimum of two device entries in display.conf, and io-display started with both devices specified at the command line what is the correct way to instruct the flash player to target both displays simulatenously? Should one added another display setting to the hmip-compmgr.so extension (ie. "display = 2")? Thanks, Gervais _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post49501 Paul Streatch 2010-03-15T17:52:52Z post49501: Howto instruct the flash player to target more than one display at a time Gervais Mulongoy http://community.qnx.com/sf/go/post49501 2010-03-15T17:47:44Z 2010-03-15T17:47:44Z Hello all: I have recently discovered that support for multiple displays was recently added to the flash player and to enable support, one needs to use the hmip-compmgr.so extension in the flash.conf as follows: [code] extension { dll = hmip-compmgr.so config { display = 1 } } [/code] Assuming a minimum of two device entries in display.conf, and io-display started with both devices specified at the command line what is the correct way to instruct the flash player to target both displays simulatenously? Should one added another display setting to the hmip-compmgr.so extension (ie. "display = 2")? Thanks, Gervais Gervais Mulongoy 2010-03-15T17:47:44Z post46930: eglSwapBuffers and io-winmgr Gary Faulkner http://community.qnx.com/sf/go/post46930 2010-02-09T15:48:56Z 2010-02-09T15:48:56Z What is happening when a client app calls eglSwapBuffers (in QNX 6.4.1)? Specifically from the io-winmgr perspective. Are the requests queued somehow in io-winmgr? Gary Faulkner 2010-02-09T15:48:56Z post46651: Re: Alpha blending in CWM/OpenKODE Etienne Belanger(deleted) http://community.qnx.com/sf/go/post46651 2010-02-05T13:36:54Z 2010-02-05T13:36:54Z It will be in the next release, but I cannot say when that will be. Etienne Belanger(deleted) 2010-02-05T13:36:54Z post46603: Re: Alpha blending in CWM/OpenKODE Radek Pesina http://community.qnx.com/sf/go/post46603 2010-02-04T22:02:59Z 2010-02-04T22:02:59Z Thanks alot for your help Etienne, based on your comments as a starting point we'll try reducing the amount of layers to see what improvements can be had. You mention that a future CM release will be using dirtied areas instead, do you know how far away the release is? Best regards, Radek Radek Pesina 2010-02-04T22:02:59Z post46602: Re: Alpha blending in CWM/OpenKODE Radek Pesina http://community.qnx.com/sf/go/post46602 2010-02-04T21:51:32Z 2010-02-04T21:51:32Z Thanks Eric, The contents of our winmgr.conf file are as follows: begin globals input = all end globals begin display cursor = sw-arrow begin plane egl-config = auto end plane end display I have attached the ouptut of io-winmgr -d. Cheers, Radek. Radek Pesina 2010-02-04T21:51:32Z post46528: Re: Alpha blending in CWM/OpenKODE Etienne Belanger(deleted) http://community.qnx.com/sf/go/post46528 2010-02-04T14:03:35Z 2010-02-04T14:03:35Z This is a pretty lengthy question, so I hope you don't mind if we answer indivdual elements over a couple of posts... As to whether rendering time should increase when alpha blending is enabled, even if the contents are fully opaque, the answer is yes, it is quite possible. The composition manager does not look at pixel values to determine areas with transparency, and there are no transparency hints yet. Therefore, compositing in this case will be performed with per-pixel alpha blending enabled. The graphics accelerator may be able to optimize this operation by skipping reading the destination buffer when the source alpha value is 255, but that is up to the hardware. The only type of blending that allows compositing optimizations is global alpha with an opaque value (255) with per-pixel alpha disabled expicitly or implicitly (no alpha channel). The way compositing works is quite straightforward. Any time a window changes, all visible windows and any background that intersect with that window are composited back to front. If a window is opaque, no window beneath it and no background will intersect. However, there could still be semi-transparent windows on top of it that will have to be re-composited too. Future releases will apply the same rules, but using dirtied areas instead of the full window. Until then, it is clear that the best approach to minimize updates is to minimize the number of overlapping semi-transparent layers. One way to do this would be to flatten static content, i.e. blend static images in a pre-processing stage, to reduce the number of layers. For content that is a little more dynamic, one could use a rendering API such as OpenGL ES, OpenVG, or even use software, to flatten some layers. What's best depends on what's static and what changes a lot, the number of layers, the size of the transparent areas, how they overlaps, and so on. Etienne Belanger(deleted) 2010-02-04T14:03:35Z post46508: Re: Alpha blending in CWM/OpenKODE Eric Fausett http://community.qnx.com/sf/go/post46508 2010-02-04T06:41:54Z 2010-02-04T06:41:54Z Radek, I just noticed your post here. While I can't address your question directly as I'm not 100% sure on the answer, I thought I'd chime in on what additional information you might provide so that the question can be addressed. You might want to include the winmgr.conf file that you are using as I'm sure it will be needed to address your question. I'm also guessing it would be useful to do a 'io-winmgr -d' while your application(s) is/are running and provide the output of that so that the internal configuration of that module can be known. http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/io-winmgr.html Regards, Eric Eric Fausett 2010-02-04T06:41:54Z post46507: Alpha blending in CWM/OpenKODE Radek Pesina http://community.qnx.com/sf/go/post46507 2010-02-04T06:28:22Z 2010-02-04T06:28:22Z Hi, We are using CM for our HMI and have major performance issues with the screen update. As such I am hoping that you could offer some suggestions. For reference the target micro is the i.MX31 and the displayed resolution is 800x480, RGB565. Our HMI screens consist of many alpha-blended layers, with separate layers for the background, frames, each button, each icon, text fields etc. The text is rendered while the remainder of the screen elements are PNG images (i.e we have a background image with an overlaying frame image with overlaying button images etc). Using a kernel trace we have observed the screen rendering times alone are around 700-800ms (combine this with the apps processing time, retrieval of PNG's from NAND etc and we're talking in the order of seconds for some screens). We tried (out of interest) to render a solid-coloured rectangle of size 800x480 to the display. With alpha-blending turned off it took around 20ms. With alpha-blending turned on the rendering time was 500ms. Considering it was only a single composite layer and therefore no alpha-blending was required to be calculated in this circumstance, should it take so much longer to render? Also, how does the CM layering work internally? i.e. is it more efficient to have the screen split into many smaller layers/elements so smaller areas are updated, or is it more efficient to minimise the amount of layers used and rather have larger-sized individual layers? Some parts of our screen can be up to 4 or 5 layers deep, however most/all layers have either full or no transparency. Since effectively only the topmost layer is visible, are all the below layers still calculated/alpha-blended? Are any of the settings in winmgr.conf worth changing? Cheers, Radek. Radek Pesina 2010-02-04T06:28:22Z post46089: Multiple Display Yossi Har-Nov http://community.qnx.com/sf/go/post46089 2010-01-27T21:55:16Z 2010-01-27T21:55:16Z How do I configure the io-winmngr for two displays? I have two display and touchscreen and I can only configure only one of them. How do I handle multiple displays? Yossi Har-Nov 2010-01-27T21:55:16Z post45905: RE: kdSetTimer/kdCancelTimer?? Joel Pilon(deleted) http://community.qnx.com/sf/go/post45905 2010-01-25T22:44:00Z 2010-01-25T22:44:00Z Correct they are not implemented. For a list of OpenKODE functions we support you can refer to: http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/externalapi.html Most of OpenKODE mirrors posix/ansi c, at this point posix is more portable then OpenKODE, so using timer_settime/timer_gettime is probably a better option even if the KD versions were implemented. The non-posix/non-ansi c portions of KD mostly consist of windowing and events which we do implement. -Joel -----Original Message----- From: Gary Faulkner [mailto:community-noreply@qnx.com] Sent: Mon 1/25/2010 5:20 PM To: cwm-graphics Subject: kdSetTimer/kdCancelTimer?? It would appear that these two are not in libKD* for QNX 6.4.1? Is that a known issue (or is it otherwise documented elsewhere and I've just missed it)?? _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post45903 Joel Pilon(deleted) 2010-01-25T22:44:00Z post45903: kdSetTimer/kdCancelTimer?? Gary Faulkner http://community.qnx.com/sf/go/post45903 2010-01-25T22:20:16Z 2010-01-25T22:20:16Z It would appear that these two are not in libKD* for QNX 6.4.1? Is that a known issue (or is it otherwise documented elsewhere and I've just missed it)?? Gary Faulkner 2010-01-25T22:20:16Z post45850: Re: CM/OpenKODE "performance" Etienne Belanger(deleted) http://community.qnx.com/sf/go/post45850 2010-01-25T13:28:22Z 2010-01-25T13:28:22Z You do need to call eglSwapBuffers. It doesn't matter if your window is single- or double-buffered, eglSwapBuffers is what's going to trigger composition by io-winmgr. If you don't call it, all your updates will remain offscreen. Etienne Belanger(deleted) 2010-01-25T13:28:22Z post45800: Re: CM/OpenKODE "performance" Joel Pilon(deleted) http://community.qnx.com/sf/go/post45800 2010-01-22T19:06:21Z 2010-01-22T19:06:21Z You can try setting your swap interval to 0 for benchmarking purposes. You can set swap interval with: eglSurfaceAttrib(egl_disp, egl_window_surf, EGL_SWAP_INTERVAL_QNX, 0); It's no recommended to always run with interval 0, since updates will be inconsistent and artifacts can be introduced. You'll still need to call eglSwapBuffers since your window is still double buffered. Running with rgb565/argb1555 would offer better performance also, assuming you don't need source-alpha blending. Joel Pilon(deleted) 2010-01-22T19:06:21Z post45799: Re: CM/OpenKODE "performance" Gary Faulkner http://community.qnx.com/sf/go/post45799 2010-01-22T18:46:11Z 2010-01-22T18:46:11Z so, apparently, for me, the right combination *might* be egl-config=1 (the one that matches the color-depth I want), and wfd-pipeline=1. In the blit2() case, with an image that is 780x380, this resolved two things: 1) my banding issue is now gone. 2) the frame rate is up to about 29 fps -- which I can definitely live with. Does this make any sense? Gary Faulkner 2010-01-22T18:46:11Z post45797: Re: CM/OpenKODE "performance" Gary Faulkner http://community.qnx.com/sf/go/post45797 2010-01-22T18:25:57Z 2010-01-22T18:25:57Z heh... helps if I spell pipeline correctly (apparently -- go figure). So, now my question becomes... do I no longer do eglSwapBuffers()?? Gary Faulkner 2010-01-22T18:25:57Z post45795: Re: CM/OpenKODE "performance" Gary Faulkner http://community.qnx.com/sf/go/post45795 2010-01-22T18:09:24Z 2010-01-22T18:09:24Z so, when I change to use wfd-pipline = 1, I no longer have any egl configs?? (at least according to sysres). Why would that be? Gary Faulkner 2010-01-22T18:09:24Z post45785: Re: CM/OpenKODE "performance" Gary Faulkner http://community.qnx.com/sf/go/post45785 2010-01-22T16:50:45Z 2010-01-22T16:50:45Z > I thought the blit2 test gave you 11-12 fps, not 54. One shouldn't compare > native to composition manager if the format is configured to swap surfaces > while the latter is configured to blit. Sorry, I got confusing there; yes, I got 11-12 fps using blit2 with CM, and 54ish with blit2 on gf. I was only pointing out that I didn't expect that much of a drop off (penalty) just from using CM. > > In any case, the first thing is to confirm that you want blitting enabled > instead of surface swapping. From past posts, it seems you want to have > multiple windows on one layer. If this is not the case, I suggest you remove > the egl-config = ... line and replace it with wfd-pipeline = 1. So... I guess I don't really understand this. What is the difference. I guess what I'm saying is that I only want to use 1 layer of the hardware (one of the reasons for us migrating to CM); However, I want to be able to display windows from multiple applications on that one layer. If I have wfd-pipeline=1 there instead of egl-config, what are the ramifcations of that? Does that mean I don't really get "compositing"?? > > Otherwise, you might want to try an EGL config id that matches your 8888 pixel > format, instead of using auto. It is possible that blits that require format > conversion revert to software on this driver. Alternatively, you can always > modify your blit2 GF test to blit from an 8888 surface to a 565 surface to see > if you get similar results... Actually, I have verified that the configuration that I pick is the right one with 8888 surface. Gary Faulkner 2010-01-22T16:50:45Z post45783: Re: CM/OpenKODE "performance" Etienne Belanger(deleted) http://community.qnx.com/sf/go/post45783 2010-01-22T16:39:31Z 2010-01-22T16:39:31Z I thought the blit2 test gave you 11-12 fps, not 54. One shouldn't compare native to composition manager if the format is configured to swap surfaces while the latter is configured to blit. In any case, the first thing is to confirm that you want blitting enabled instead of surface swapping. From past posts, it seems you want to have multiple windows on one layer. If this is not the case, I suggest you remove the egl-config = ... line and replace it with wfd-pipeline = 1. Otherwise, you might want to try an EGL config id that matches your 8888 pixel format, instead of using auto. It is possible that blits that require format conversion revert to software on this driver. Alternatively, you can always modify your blit2 GF test to blit from an 8888 surface to a 565 surface to see if you get similar results... Etienne Belanger(deleted) 2010-01-22T16:39:31Z post45779: Re: CM/OpenKODE "performance" Gary Faulkner http://community.qnx.com/sf/go/post45779 2010-01-22T15:51:24Z 2010-01-22T15:51:24Z Hello: I've attached my current winmgr.conf. Other responses inline: > Please provide us with your winmgr.conf configuration file to better help us > determine what the composition manager might be trying to do. > > Other questions: > > What is the EGL_SWAP_BEHAVIOR set to ? If EGL_BUFFER_PRESERVED is requested > this will add to the amount of work EGL has to do when swapping buffers. EGL_SWAP_BEHAVIOR is set to EGL_BUFFER_DESTROYED > > What are the values for KD_WINDOWPROPERTY_BUFFER_SIZE_QNX, > KD_WINDOWPROPERTY_SOURCE_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_POSITION, > KD_WINDOWPROPERTY_SIZE, and KD_WINDOWPROPERTY_POSITION_QNX ? KD_QNX_WINDOWPROPERTY_SOURCE_SIZE is 780,380 KD_QNX_WINDOWPROPERTY_SOURCE_POSITION is 0,0 KD_WINDOWPROPERTY_SIZE is 780,380 KD_QNX_WINDOWPROPERTY_POSITION_QNX is 0,0 > > What is the value of EGL_RED_SIZE, EGL_BLUE_SIZE, EGL_GREEN_SIZE, and > EGL_ALPHA_SIZE of the EGLConfig that your application is using to create the > window surface ? They are 8,8,8,8 respectively. > > Note that using the composition manager does have a performance impact, even > if compositing is disabled. In this case, EGL is forced to wait for renders to > complete before sending a post message to the composition manager. This > eliminates any potential overlapping of CPU and GPU and causes the GPU to be > idle for some time, unless other applications are running in parallel. > Consequently, free running frame rates of applications without composition > manager will always be equal or higher than their composition manager > counterpart. This can be overcome with triple buffering, which might be added > to our EGL at some point. Yup... I expected some performance impact, but not close to an order of magnitude. I have run that same test image through a simple gf blitting directly to a layer (without io-winmgr running) and get about 65 fps on that. So, overall I have several applications all running at the same time using CM. Aside from some transitions putting application windows on and off the screen, when an application window is visible, it owns the entire displayable area (800x480). Obviously my little image test program is only creating a window as large as the image it is displaying, so that may not count. Actually, I just ran a test with a full-screen sized image (and window) and it's fps using CM and openvg is about 4.5 fps, and with just a native gf it is about 54 fps. Gary Faulkner 2010-01-22T15:51:24Z post45762: Re: CM/OpenKODE "performance" Etienne Belanger(deleted) http://community.qnx.com/sf/go/post45762 2010-01-22T13:48:53Z 2010-01-22T13:48:53Z Please provide us with your winmgr.conf configuration file to better help us determine what the composition manager might be trying to do. Other questions: What is the EGL_SWAP_BEHAVIOR set to ? If EGL_BUFFER_PRESERVED is requested this will add to the amount of work EGL has to do when swapping buffers. What are the values for KD_WINDOWPROPERTY_BUFFER_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_POSITION, KD_WINDOWPROPERTY_SIZE, and KD_WINDOWPROPERTY_POSITION_QNX ? What is the value of EGL_RED_SIZE, EGL_BLUE_SIZE, EGL_GREEN_SIZE, and EGL_ALPHA_SIZE of the EGLConfig that your application is using to create the window surface ? Note that using the composition manager does have a performance impact, even if compositing is disabled. In this case, EGL is forced to wait for renders to complete before sending a post message to the composition manager. This eliminates any potential overlapping of CPU and GPU and causes the GPU to be idle for some time, unless other applications are running in parallel. Consequently, free running frame rates of applications without composition manager will always be equal or higher than their composition manager counterpart. This can be overcome with triple buffering, which might be added to our EGL at some point. Etienne Belanger(deleted) 2010-01-22T13:48:53Z post45753: CM/OpenKODE "performance" Gary Faulkner http://community.qnx.com/sf/go/post45753 2010-01-22T12:42:12Z 2010-01-22T12:42:12Z I was doing some performance comparisons this morning (imx35 based) between drawing images in the CM environment using blit2() vs. vgDrawImage(). First thing I noticed is that blit2 is *slightly* faster than vgDrawImage() (for the same image -- on the order of 11-12 fps for blit2() vs. 7-8 fps for vgDrawImage() on a 780x380 RGB/A png). However, while watching all of this, I notice that io-winmgr consumes a TON of CPU. I guess I'm wondering a couple of things: 1) Is it fully utilizing the HW capabilities I have for doing the compositing? 2) It seems like the expensive call here is eglSwapBuffers(). Why is that, and is there any tuning I can do to get around that fact? I ask about #1 because of the banding issue I discuss in http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.cwm_openkode.topc11707 At any rate.. I'm wondering, even in this relatively simple case, if there is some io-winmgr tuning I can/should be doing to get better performance/results (less CPU utilization too). Also, I'd still like to understand how to get around the banding issue that I'm seeing. I haven't yet run a comparable test using just gf, but I fully expect it to be significantly faster (in terms of fps). Thoughts? Gary Faulkner 2010-01-22T12:42:12Z post45732: Re: un-flipping images displayed via vgDrawImage()?? Gary Faulkner http://community.qnx.com/sf/go/post45732 2010-01-21T23:41:56Z 2010-01-21T23:41:56Z Nevermind... figured it out with the negative stride stuff. Gary Faulkner 2010-01-21T23:41:56Z post45731: un-flipping images displayed via vgDrawImage()?? Gary Faulkner http://community.qnx.com/sf/go/post45731 2010-01-21T23:22:01Z 2010-01-21T23:22:01Z So, if one does something like the following: VGImage image = vgCreateImage(VG_sRGBA_8888,img.w,img.h,VG_IMAGE_QUALITY_BETTER); if (image == (VGImage)0) { fprintf(stderr,"Unable to create VG image: %d\n",vgGetError()); return -1; } vgImageSubData(image,img.access.direct.data,img.access.direct.stride,VG_sARGB_8888,0,0,img.w,img then a vgDrawImage(image); the image is flipped upside-down. What is the correct way to either cause it to be loaded into the VGImage correctly, or to display it correctly? I realize this is "documented behavior" for openvg; but I'm not sure how one is supposed to (efficiently) overcome it. Thanks! Gary Faulkner 2010-01-21T23:22:01Z post45651: Re: CM/OpenKODE image display oddity Gary Faulkner http://community.qnx.com/sf/go/post45651 2010-01-21T15:19:28Z 2010-01-21T15:19:28Z As an aside, I also tried this using the openvg calls for images, and I get the same results. Gary Faulkner 2010-01-21T15:19:28Z post45624: CM/OpenKODE image display oddity Gary Faulkner http://community.qnx.com/sf/go/post45624 2010-01-21T12:45:54Z 2010-01-21T12:45:54Z First off, this is on an imx35 (not sure it matter for this case, but wanted to mention it). I'm seeing some oddities that I cannot explain with a particular type of image. The image is a png, RBGA, 8 bits of color. In the gf_* world, I have an image that I blit to the screen. I do this (in a very simple case) by loading the image with img_load_file(), wrap a surface around it with gf_surface_attach(), then I blit it to a surface that is attached to a real hardware layer. It looks greate. In the CM/OpenKODE world, I try to mimic this by loading the image with img_load_file(), wrapping a surface around it with gf_surface_attach(), and then blitting that surface to an eglSurface using: gf_context_set_surface_3d(); gf_draw_begin(); gf_draw_blit2() (with the dest surface as NULL, and the source surface as the one from gf_surface_attach()) gf_draw_end(); eglSwapBuffers(); The load and display "work", but the image is banded; it's like it's trying to be displayed on an RGB565 surface. However, I've verified that the surface should be correct (here's a description using the same messages as are printed from many of the sample apps): EGL_VENDOR = QNX Software Systems EGL_VERSION = 1.4 EGL_CLIENT_APIS = OpenGL_ES OpenVG EGL_EXTENSIONS = EGL_KHR_lock_surface EGL_QNX_gf_surface EGL_QNX_swap_interval EGL_CONFIG_ID = 1 EGL_RED_SIZE = 8 EGL_GREEN_SIZE = 8 EGL_BLUE_SIZE = 8 EGL_ALPHA_SIZE = 8 EGL_DEPTH_SIZE = 0 EGL_LEVEL = 0 EGL_NATIVE_RENDERABLE = EGL_TRUE EGL_NATIVE_VISUAL_TYPE = 5152 EGL_RENDERABLE_TYPE = 0x0000 EGL_SURFACE_TYPE = 0x0487 EGL_TRANSPARENT_TYPE = EGL_NONE So my question is, what is causing the banding? Gary Faulkner 2010-01-21T12:45:54Z post45375: Re: RE: EGL/KD and direct buffer manipulation Gary Faulkner http://community.qnx.com/sf/go/post45375 2010-01-18T11:56:14Z 2010-01-18T11:56:14Z Actually, let me be more specific. MOST of the time we need to be able to have more than one window visible at a time. However, when this particular application is displaying (the one doing the direct rendering), we do not need multiple windows. It still seems like the eglSwapBuffers is costing us significant cpu time, and I really wasn't expecting that at all. Gary Faulkner 2010-01-18T11:56:14Z post45349: Re: RE: EGL/KD and direct buffer manipulation Gary Faulkner http://community.qnx.com/sf/go/post45349 2010-01-15T22:12:59Z 2010-01-15T22:12:59Z Thanks! So a few things here.. First, we're on an imx35; blits are accelerated. Second, from reading the comments in the default winmgr.conf file, there are some issues with changing from egl-config to wfd-pipeline. Specifically, it would appear (from the comments) that only 1 window will be visible at a time. That is not what we want/need. Furthermore, when I do make this switch, my existing CWM/KD programs can no longer find a usable configuration. Gary Faulkner 2010-01-15T22:12:59Z post45331: Re: RE: EGL/KD and direct buffer manipulation Etienne Belanger(deleted) http://community.qnx.com/sf/go/post45331 2010-01-15T19:25:04Z 2010-01-15T19:25:04Z It is possible that the composition manager is configured to do compositing instead of flipping buffers on a layer. This would mean an extra blit each frame. If for some reason there is no acceleration of blits on your platform, this could end up using a lot of CPU, especially if the surface isn't cached. Look for 'egl-config' directives in the winmgr.conf. The default configuration file is usually: begin display begin plane egl-config = auto end plane end display Which means all windows are composited to one framebuffer. Changing it to begin display begin plane wfd-pipeline = 1 end plane end display would enable buffer flipping. You can add a plane for each layer available. The pipeline numbers start at 1 instead 0 like in GF. Etienne Belanger(deleted) 2010-01-15T19:25:04Z post45312: Re: RE: EGL/KD and direct buffer manipulation Gary Faulkner http://community.qnx.com/sf/go/post45312 2010-01-15T16:10:15Z 2010-01-15T16:10:15Z Thanks! this helps quite a bit. Now my problem appears to be that io-winmgr wants to eat up a ton of CPU in this case. From what I can tell it's all in the eglSwapBuffers (if I don't do this, io-winmgr doesn't chew through cpu, but (obviously) I don't get output on the screen. Seems like eglSwapBuffers is required; is there any way around that? Gary Faulkner 2010-01-15T16:10:15Z post45303: RE: EGL/KD and direct buffer manipulation Joel Pilon(deleted) http://community.qnx.com/sf/go/post45303 2010-01-15T15:15:45Z 2010-01-15T15:15:45Z You can use the EGL_KHR_lock_surface extension to lock your window surface and get a vadder to the render buffer. So if you memcpy directly to your window surface, performance should be much better. You can find an example application which uses the EGL_KHR_lock_surface extension at: http://community.qnx.com/integration/viewvc/viewvc.cgi/trunk/apps/kd/tutorials/sw-kd-vsync/sw-kd-vsync.c?root=graphics&system=exsy1001&view=markup For 6.4.2 we plan to release several improvements to software renders along with updated tutorials which make use of the new features. These new features have been found to increase performances significantly. -Joel -----Original Message----- From: Gary Faulkner [mailto:community-noreply@qnx.com] Sent: January 15, 2010 8:19 AM To: cwm-graphics Subject: EGL/KD and direct buffer manipulation First, I apologize if this seems like a bad question to even be asking; however.. In the gf_ world, one could create a surface with gf_surface_create_layer(), get the vaddr using gf_surface_get_info(), and copy data directly into the surface (and thereby into the display). (I realize that may or may not be a good thing, but it is possible to do). At any rate, in the CWM/OpenKODE world I'm not clear on how one would do that. I have an application that generates data that I want to display on the screen at a very fast rate (say 15-30 fps). Using gf, I can pretty much keep up with the display of that data. Using CWM/OpenKODE, I cannot. What I'm doing (for now) is creating a separate gf_surface, memcpying the data into the vaddr, and then when the whole surface is filled, doing the gf_context_set_surface_3d() gf_draw_being() gf_draw_blit2() gf_draw_end(); eglSwapBuffers() dance to blit the separate gf_surface onto the opened CWM window. Is there a better way to accomplish my goal here? -garyf _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post45284 Joel Pilon(deleted) 2010-01-15T15:15:45Z post45289: Re: EGL/KD and direct buffer manipulation Etienne Belanger(deleted) http://community.qnx.com/sf/go/post45289 2010-01-15T13:56:01Z 2010-01-15T13:56:01Z The options for software-based rasterizers are typically to render to the window, or to render into an offscreen buffer and then make the changes visible using some kind of blit. It seems you are using a variant of the second approach right now. It is important to note that unless most of the pixels in a window change every frame, rendering into an offscreen buffer first is usually more efficient. To render directly into a window this is what you can do: 1) Use eglGetConfigs or eglChooseConfig to get an EGL config with an EGL_SURFACE_TYPE that has both the EGL_WINDOW_BIT and the EGL_LOCK_SURFACE_BIT_KHR set. EGL_KHR_lock_surface is the EGL extension that allows you to get a pointer to one of an EGLSurface's buffers. 2) Create your window with eglCreateWindowSurface. You don't need an EGLContext since you will be using a software rasterizer. 3) In your rendering loop, call eglLockSurfaceKHR followed by eglQuerySurface to get a pointer to the back buffer. Unless the EGLSurface is single-buffered, the pointer to use will most likely change each frame because the back buffers get swapped. However, on some platforms they won't change even if the window is double-buffered, so the only way to be sure is to query for the pointer each iteration. 4) Use the pointer to the current back buffer to do your updates. When you are done you unlock the surface using eglUnlockSurfaceKHR. You can follow this by eglSwapBuffers on QNX platforms. Here are more things to keep in mind. * The pointer you are getting is most likely to a non-cached memory mapping because many display controllers and/or GPUs that might be used to do compositing aren't cache-coherent. This is also a problem for offscreen buffers. However, a cache flush or cache invalidate can be inserted at strategic points (e.g., prior to blits) instead of having the display controller do it before each refresh. * To get buffer flipping enabled, you need double-buffered windows. This is enabled by default in EGL. However, this means that partial rendering needs to consider changes from two frames ago. You can use EGL_SWAP_BEHAVIOR to ask EGL to preserve pixels each time buffers are swapped. In this case, there will be an extra blit for each post, making rendering into a double-buffered window no more efficient than rendering into an offscreen buffer. Etienne Belanger(deleted) 2010-01-15T13:56:01Z post45284: EGL/KD and direct buffer manipulation Gary Faulkner http://community.qnx.com/sf/go/post45284 2010-01-15T13:18:47Z 2010-01-15T13:18:47Z First, I apologize if this seems like a bad question to even be asking; however.. In the gf_ world, one could create a surface with gf_surface_create_layer(), get the vaddr using gf_surface_get_info(), and copy data directly into the surface (and thereby into the display). (I realize that may or may not be a good thing, but it is possible to do). At any rate, in the CWM/OpenKODE world I'm not clear on how one would do that. I have an application that generates data that I want to display on the screen at a very fast rate (say 15-30 fps). Using gf, I can pretty much keep up with the display of that data. Using CWM/OpenKODE, I cannot. What I'm doing (for now) is creating a separate gf_surface, memcpying the data into the vaddr, and then when the whole surface is filled, doing the gf_context_set_surface_3d() gf_draw_being() gf_draw_blit2() gf_draw_end(); eglSwapBuffers() dance to blit the separate gf_surface onto the opened CWM window. Is there a better way to accomplish my goal here? -garyf Gary Faulkner 2010-01-15T13:18:47Z post44595: Re: CWM/OpenKODE/GF question Gary Faulkner http://community.qnx.com/sf/go/post44595 2010-01-05T18:45:31Z 2010-01-05T18:45:31Z just figured this out; if I specify my destination EGLSurface in the blit2() call, it doesn't do anything (although it doesn't fail either). If I don't, but just make sure that the context targets that surface, it works. Gary Faulkner 2010-01-05T18:45:31Z post44580: CWM/OpenKODE/GF question Gary Faulkner http://community.qnx.com/sf/go/post44580 2010-01-05T16:34:56Z 2010-01-05T16:34:56Z Hello: I am (still) trying to port our existing completely GF based application(s) to use CWM/OpenKODE. I've run into an issue that I just cannot figure out. Our application is heavily blit2 dependent. Looking at the guidance in this thread (http://community.qnx.com/sf/go/projects.graphics/discussion.cwm_openkode.topc9295) I make sure that the final blit (the one to the window egl surface) is from a gf_surface_t to an EGLSurface. gf_draw_blit2() returns GF_ERR_OK. At that same point in the code, I am able to do gf_draw_rects just fine (I don't really want to do that, but I did so to attempt to figure out what is going on here). Are there any other gotcha's here that I'm missing? Something I need to do before and/or after the gf_draw_blit2() to make it actually do something? Are there any examples around showing doing this sort of thing? For example, taking an image loaded by libimg, and blitting it to the screen in a gf-kd type environment? Thanks! -garyf Gary Faulkner 2010-01-05T16:34:56Z post44292: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT Gary Faulkner http://community.qnx.com/sf/go/post44292 2009-12-22T14:55:45Z 2009-12-22T14:55:45Z Awesome! Thanks.. that works. Gary Faulkner 2009-12-22T14:55:45Z post44288: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT Etienne Belanger(deleted) http://community.qnx.com/sf/go/post44288 2009-12-22T14:49:17Z 2009-12-22T14:49:17Z I suspect it's simpler than that. Make sure you call eglBindAPI prior to calling eglCreateContext. With EGL, the current API defaults to OpenGL ES if it is supported, or to EGL_NONE otherwise. For OpenVG, you have to set it explicitely with eglBindAPI. Etienne Belanger(deleted) 2009-12-22T14:49:17Z post44286: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT Gary Faulkner http://community.qnx.com/sf/go/post44286 2009-12-22T14:44:43Z 2009-12-22T14:44:43Z You are correct; Here's my (current) version of the attrs section from gles1-kd-gears.c: struct { EGLint surface_type[2]; EGLint renderable_type[2]; EGLint depth_size[2]; EGLint level[2]; EGLint transparent_type[2]; EGLint red_size[2]; EGLint green_size[2]; EGLint blue_size[2]; EGLint alpha_size[2]; EGLint sample_buffers[2]; EGLint samples[2]; EGLint config_id[2]; EGLint none; } egl_conf_attr = { .surface_type = { EGL_SURFACE_TYPE, EGL_WINDOW_BIT }, .renderable_type = { EGL_RENDERABLE_TYPE, EGL_OPENVG_BIT }, .depth_size = { EGL_DEPTH_SIZE, 0 }, .level = { EGL_LEVEL, 0 }, .transparent_type = { EGL_TRANSPARENT_TYPE, EGL_DONT_CARE }, .red_size = { EGL_RED_SIZE, EGL_DONT_CARE }, .green_size = { EGL_GREEN_SIZE, EGL_DONT_CARE }, .blue_size = { EGL_BLUE_SIZE, EGL_DONT_CARE }, .alpha_size = { EGL_ALPHA_SIZE, EGL_DONT_CARE }, .sample_buffers = { EGL_SAMPLE_BUFFERS, 0 }, .samples = { EGL_SAMPLES, 0 }, .config_id = { EGL_CONFIG_ID, EGL_DONT_CARE }, .none = EGL_NONE }; That works (I find a config in eglChooseConfigs()). However, with that configuration, eglCreateContext() returns EGL_NO_CONTEXT, and eglGetError() returns EGL_BAD_CONFIG. So, while eglChooseConfig() found a config, eglCreateContext() cannot use it? as an aside, here's what I get now when I use the verbose flag to the gles1-kd-gears sample app: EGL_VENDOR = QNX Software Systems EGL_VERSION = 1.4 EGL_CLIENT_APIS = OpenGL_ES OpenVG EGL_EXTENSIONS = EGL_KHR_lock_surface EGL_QNX_gf_surface EGL_QNX_swap_interval EGL_CONFIG_ID = 2 EGL_RED_SIZE = 8 EGL_GREEN_SIZE = 8 EGL_BLUE_SIZE = 8 EGL_ALPHA_SIZE = 8 EGL_DEPTH_SIZE = 0 EGL_LEVEL = 0 EGL_NATIVE_RENDERABLE = EGL_FALSE EGL_NATIVE_VISUAL_TYPE = 5152 EGL_RENDERABLE_TYPE = 0x0002 EGL_SURFACE_TYPE = 0x0487 EGL_TRANSPARENT_TYPE = EGL_NONE I'm assuming that EGL_NATIVE_REDNERABLE being false is the issue here. So... does this imply that I cannot use EGL with an OPENVG config? From looking through my sysres output, it would appear that every config with the EGL_OPENVG_BIT renderable type has native_renderable as "no". Gary Faulkner 2009-12-22T14:44:43Z post44274: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT Etienne Belanger(deleted) http://community.qnx.com/sf/go/post44274 2009-12-22T13:52:18Z 2009-12-22T13:52:18Z If you provide us with the attrib list you are passing to eglChooseConfig, we should be able to tell you the exact cause of the error. I suspect that it is returning 0 configs because you are asking for EGL_OPENVG_BIT renderable type with a EGL_DEPTH_SIZE which isn't 0. Etienne Belanger(deleted) 2009-12-22T13:52:18Z post44273: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT Gary Faulkner http://community.qnx.com/sf/go/post44273 2009-12-22T13:49:02Z 2009-12-22T13:49:02Z Hello: I am trying to insure that the egl config I use has the EGL_OPENVG_BIT set for the renderable_type. This is on an i.MX35. I tried modifying the sample gles1-kd-gears app to set the EGL_OPENVG_BIT for the renderable type (in the egl_conf_attr struct). However, eglChooseConfig returns 0 configs. From looking at the sysres output from io-winmgr, it would appear that EGL_OPENVG_BIT is available on several of the configs. Why does eglChooseConfig not find the appropriate config? Gary Faulkner 2009-12-22T13:49:02Z post44121: Re: touchscreen events in gles1-kd-gears demo app Gary Faulkner http://community.qnx.com/sf/go/post44121 2009-12-18T14:31:08Z 2009-12-18T14:31:08Z I have more info now. I downloaded the i.mx25 bsp, which has a copy of libinput source in it. Using that version of libinput (which *appears* to be relatively new), I find that in devi_read, it appears that the FD that io-winmgr has open is marked as non-blocking. So, more often than not, devi-read returns EAGAIN. Additionally, because of that, the devi* interface isn't queuing up the input packets; it gets into process_wait_queue(), it sees nothing in the wait_queue, therefor, it just throws away the touch. Does this ring a bell? First off, is io-winmgr really opening the devi interface non-blocking? I don't see devi_notify ever getting called, so I am assuming that it's not doing a select/poll/etc. Gary Faulkner 2009-12-18T14:31:08Z post44072: Re: touchscreen events in gles1-kd-gears demo app Gary Faulkner http://community.qnx.com/sf/go/post44072 2009-12-17T20:51:03Z 2009-12-17T20:51:03Z Yup... got that (the first point). In fact, the kdWaitEvent is only delivering the events in a batched sequence... about once every 5 seconds or so. I'm running gles1-kd-gears in full-screen mode, so the screen coordinates should be at least close (and usually the first one in the batch is -- even if I don't move my finger all that much). I'm seeing 15+fps from the gears app (depending on which color-depth I use). > Some things to keep in mind when working with OpenKODE events, especially > pointer events: > > 1) The events aren't delivered; they are queried. Events just sit in a queue > maintained by the composition manager until an application requests for the > next event in the queue. This is done by calling kdWaitEvent. If an > application checks the event queue once every second, all pointer events that > happen during the interval will be bunched up until the next kdWaitEvent call( > s). > > 2) The coordinates are relative to the window, which is different from the > screen coordinates that the debug messages devi-hid prints out. > > How fast is the gears application running (in fps) ? Gary Faulkner 2009-12-17T20:51:03Z post44071: Re: touchscreen events in gles1-kd-gears demo app Etienne Belanger(deleted) http://community.qnx.com/sf/go/post44071 2009-12-17T20:45:42Z 2009-12-17T20:45:42Z Some things to keep in mind when working with OpenKODE events, especially pointer events: 1) The events aren't delivered; they are queried. Events just sit in a queue maintained by the composition manager until an application requests for the next event in the queue. This is done by calling kdWaitEvent. If an application checks the event queue once every second, all pointer events that happen during the interval will be bunched up until the next kdWaitEvent call(s). 2) The coordinates are relative to the window, which is different from the screen coordinates that the debug messages devi-hid prints out. How fast is the gears application running (in fps) ? Etienne Belanger(deleted) 2009-12-17T20:45:42Z post44067: Re: RE: RE: touchscreen events in gles1-kd-gears demo app Gary Faulkner http://community.qnx.com/sf/go/post44067 2009-12-17T20:37:53Z 2009-12-17T20:37:53Z Thanks, Joel. I've fired off that request (to get a recent build of libinput.a). Are there any docs or hints on seeing what is being delivered on the resource manager interface? Is there any way (for example) to get this level of debug from io-winmgr itself? (as an aside, yes, I am starting my devi driver with -P and -r). My current devi driver works just fine as an input source to gf (i.e. gfi). The output matches exactly what my gf_* based UI code sees. > You might be able to ask your support rep for a recent build of libinput.a. Oh > and I should of mentioned, that I believe you should be start your devi-* > driver with -r and -P. And note, the debug output of the devi-* may not always > reflect what you get from composition manager. The debug output is printing > events going into the photon interface. Composition manager uses the resource > manager interface which is similar code patch to that of gfi. So in the end > they should be relatively similar, but something is going wrong after the code > paths fork, it wouldn't be reflected in the debug output. It's generally > better to see what you get out of the raw res manager interface from input. E. > g. /dev/devi/touch0. > > -Joel > > -----Original Message----- > From: Gary Faulkner [mailto:community-noreply@qnx.com] > Sent: December 17, 2009 3:15 PM > To: cwm-graphics > Subject: Re: RE: touchscreen events in gles1-kd-gears demo app > > Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto > set in the winmgr.conf (as an aside, pointer-qsize = 1 does not work for me - > I don't get any events at all). > > So, where would I get a fixed libinput.a? Especially since there isn't a new > version of the devi ddk available for 6.4.x? Gary Faulkner 2009-12-17T20:37:53Z post44066: RE: RE: touchscreen events in gles1-kd-gears demo app Joel Pilon(deleted) http://community.qnx.com/sf/go/post44066 2009-12-17T20:31:50Z 2009-12-17T20:31:50Z You might be able to ask your support rep for a recent build of libinput.a. Oh and I should of mentioned, that I believe you should be start your devi-* driver with -r and -P. And note, the debug output of the devi-* may not always reflect what you get from composition manager. The debug output is printing events going into the photon interface. Composition manager uses the resource manager interface which is similar code patch to that of gfi. So in the end they should be relatively similar, but something is going wrong after the code paths fork, it wouldn't be reflected in the debug output. It's generally better to see what you get out of the raw res manager interface from input. E.g. /dev/devi/touch0. -Joel -----Original Message----- From: Gary Faulkner [mailto:community-noreply@qnx.com] Sent: December 17, 2009 3:15 PM To: cwm-graphics Subject: Re: RE: touchscreen events in gles1-kd-gears demo app Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto set in the winmgr.conf (as an aside, pointer-qsize = 1 does not work for me - I don't get any events at all). So, where would I get a fixed libinput.a? Especially since there isn't a new version of the devi ddk available for 6.4.x? Joel Pilon(deleted) 2009-12-17T20:31:50Z post44063: Re: RE: touchscreen events in gles1-kd-gears demo app Gary Faulkner http://community.qnx.com/sf/go/post44063 2009-12-17T20:14:38Z 2009-12-17T20:14:38Z Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto set in the winmgr.conf (as an aside, pointer-qsize = 1 does not work for me - I don't get any events at all). So, where would I get a fixed libinput.a? Especially since there isn't a new version of the devi ddk available for 6.4.x? > You can try including "pointer-qsize = auto" or "pointer-qsize = 1" in the > globals section of your winmgr.conf. There's been some fixes to the framework > for input drivers to help make them more responsive, unfortunately it requires > that each devi-* driver be recompiled with the libinput.a which contain these > corrections. The idea case would be having the devi-* driver compiled with a > recent libinput.a and "pointer-qsize = auto". Without the fixes however the " > auto" feature won't function properly, and could explain the behavior your > seeing. > > -Joel > > -----Original Message----- > From: Gary Faulkner [mailto:community-noreply@qnx.com] > Sent: Thu 12/17/2009 2:39 PM > To: cwm-graphics > Subject: touchscreen events in gles1-kd-gears demo app > > Hello: > > I'm trying to make sure that our touchscreen events are seen in an openkode/CM > application. I have put a printf in the case for KD_EVENT_INPUT_POINTER in > the main event loop to indicate when touches occurr. > > My problem is that what I'm getting in the app is different from what I get > from the debug from my devi* driver. It reports the correct coordinates/" > button state", but two odd things are happening in the gles1-kd-gears > application. > > First, the touches seem to be "bunched". That is, I seem to get a group of 5 > or 6 of them at a time, and they are not happening immediately when I touch > the screen. > > Second, the values are, for the most part, wrong; except for the first value. > > I'm doing this as testing prior to migrating our UI to CM. > > This is on the stock 6.4.1 io-winmgr. > > Any ideas on what is going on here, and how I can make these events get > delivered "as they happen"?? Is there something special that I need to do in > my devi* driver (aside from obviously starting it with -r)? > > Thanks!! > > -garyf > > > > _______________________________________________ > > CWM/OpenKODE > http://community.qnx.com/sf/go/post44051 > > Gary Faulkner 2009-12-17T20:14:38Z post44052: RE: touchscreen events in gles1-kd-gears demo app Joel Pilon(deleted) http://community.qnx.com/sf/go/post44052 2009-12-17T19:52:59Z 2009-12-17T19:52:59Z You can try including "pointer-qsize = auto" or "pointer-qsize = 1" in the globals section of your winmgr.conf. There's been some fixes to the framework for input drivers to help make them more responsive, unfortunately it requires that each devi-* driver be recompiled with the libinput.a which contain these corrections. The idea case would be having the devi-* driver compiled with a recent libinput.a and "pointer-qsize = auto". Without the fixes however the "auto" feature won't function properly, and could explain the behavior your seeing. -Joel -----Original Message----- From: Gary Faulkner [mailto:community-noreply@qnx.com] Sent: Thu 12/17/2009 2:39 PM To: cwm-graphics Subject: touchscreen events in gles1-kd-gears demo app Hello: I'm trying to make sure that our touchscreen events are seen in an openkode/CM application. I have put a printf in the case for KD_EVENT_INPUT_POINTER in the main event loop to indicate when touches occurr. My problem is that what I'm getting in the app is different from what I get from the debug from my devi* driver. It reports the correct coordinates/"button state", but two odd things are happening in the gles1-kd-gears application. First, the touches seem to be "bunched". That is, I seem to get a group of 5 or 6 of them at a time, and they are not happening immediately when I touch the screen. Second, the values are, for the most part, wrong; except for the first value. I'm doing this as testing prior to migrating our UI to CM. This is on the stock 6.4.1 io-winmgr. Any ideas on what is going on here, and how I can make these events get delivered "as they happen"?? Is there something special that I need to do in my devi* driver (aside from obviously starting it with -r)? Thanks!! -garyf _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post44051 Joel Pilon(deleted) 2009-12-17T19:52:59Z post44051: touchscreen events in gles1-kd-gears demo app Gary Faulkner http://community.qnx.com/sf/go/post44051 2009-12-17T19:39:56Z 2009-12-17T19:39:56Z Hello: I'm trying to make sure that our touchscreen events are seen in an openkode/CM application. I have put a printf in the case for KD_EVENT_INPUT_POINTER in the main event loop to indicate when touches occurr. My problem is that what I'm getting in the app is different from what I get from the debug from my devi* driver. It reports the correct coordinates/"button state", but two odd things are happening in the gles1-kd-gears application. First, the touches seem to be "bunched". That is, I seem to get a group of 5 or 6 of them at a time, and they are not happening immediately when I touch the screen. Second, the values are, for the most part, wrong; except for the first value. I'm doing this as testing prior to migrating our UI to CM. This is on the stock 6.4.1 io-winmgr. Any ideas on what is going on here, and how I can make these events get delivered "as they happen"?? Is there something special that I need to do in my devi* driver (aside from obviously starting it with -r)? Thanks!! -garyf Gary Faulkner 2009-12-17T19:39:56Z post39741: Re: Screen capture Joel Pilon(deleted) http://community.qnx.com/sf/go/post39741 2009-10-12T19:14:19Z 2009-10-12T19:14:19Z Unfortunately, we don't have any kind of utilities to do this. It's a feature we may add in the future. However, there is vga capture devices on the market that could be used to capture screen shots. Joel Pilon(deleted) 2009-10-12T19:14:19Z post38499: Screen capture Chirag Shah(deleted) http://community.qnx.com/sf/go/post38499 2009-09-22T16:58:18Z 2009-09-22T16:58:18Z Is there a command line way to capture the screen and save to a file? Chirag Shah(deleted) 2009-09-22T16:58:18Z post35967: Re: the problem about create windows by thread hu xiaohua http://community.qnx.com/sf/go/post35967 2009-08-14T00:46:35Z 2009-08-14T00:46:35Z > The first approach doesn't work because events are sent to the thread that > created the window. In this case, it is the main thread. > > The second approach should work, both in terms of graphics and events. I am > not sure I understand #3 in Process 2. Do you have 3 threads (created in step > #1) or 6 (3 created in step #1 and 3 in step #3) ? In any case, look for any > errors in eglMakeCurrent and/or eglSwapBuffers. I am sorry.I made a mistake when i wrote this . In Process 2 In (2) I don't used ③step. I create three thread in KdMain. but why the picture did not displayed on screen?? I except your response. Thanks a lot. hu xiaohua 2009-08-14T00:46:35Z post35907: Re: help with CM when using GF Etienne Belanger(deleted) http://community.qnx.com/sf/go/post35907 2009-08-13T13:22:56Z 2009-08-13T13:22:56Z When you look at the differences between the GF version and the same code converted to OpenKODE/EGL, you find that there aren't that many differences. However, making those changes, even if there are just a few, isn't always easy... The two big differences for GF apps rendering in OpenKODE windows are: 1) no layers; that's because with GF, the only "compositing" strategy is to use display controller layers. The compositied windowing system that handles OpenKODE windows can use other hardware like 2D cores, VG cores, or 3D cores. 2) different surfaces; you have to use EGL surfaces and not GF surfaces. If in the end each application has its own layer, you don't necessarily need the composited windowing system. The same thing can be done with plain GF. However, OpenKODE also gives you better events, delegates (which can be used to control other GF apps), and allows you to have multiple applications on the same layer (only one visible at any point in time). All of this cannot be done using GF only. http://community.qnx.com/svn/repos/graphics/trunk/apps/kd/tutorials/gf-kd-vsync/gf-kd-vsync.c is the OpenKODE equivalent of http://community.qnx.com/svn/repos/graphics/trunk/apps/egl/tutorials/gf-egl-vsync/gf-egl-vsync.c gf_draw_blit2 and gf_draw_blitscaled can still be used quite easily if one of the surfaces (source or destination) isn't an EGL surface. If you need to blit from an EGL surface to another EGL surface, you have 4 options: 1) blitting can be done with a Khronos rendering API like OpenGL ES, or OpenVG. In this case, you cannot blit directly from an EGL surface to another EGL surface. The source must be an object like a VGImage or a GL ES texture. 2) Use the EGL_QNX_gf_surface extension which will give you the gf_surface_t corresponding to the current renderbuffer of an EGL surface. This obviously only works if the EGL_QNX_gf_surface extension is supported, which may not always be the case. 3) Use the EGL_KHR_lock_surface extension, which allows software renderers to write their output to EGL surfaces. With this extension, you can get a CPU accessible address, the stride, and the bit offsets of each color component of an EGL surface. You can use gf_surface_attach and gf_surface_reattach to wrap it as a gf_surface_t. You will have to get the rest of the information from other calls, i.e. eglQuerySurface to get the width and height, and eglGetConfigAttrib to get the pixel format. Once an EGL surface is locked, it must be unlocked before you can do things with it, like eglMakeCurrent or eglSwapBuffers. Each time a surface is locked, the pointer and stride returned could be different from the last time. This is where gf_surface_reattach becomes useful... 4) Use eglCreatePixmapSurface for offscreen renderbuffers. The native pixmap is always a GF surface, which you can use as argument to gf_draw_blit2 and gf_draw_blitscaled. The EGL surface can be used as argument to eglMakeCurrent, etc. Now, getting back to square one, depending on what you are trying to do, there might be an easier approach than the generic solutions I have outlined here. Etienne Belanger(deleted) 2009-08-13T13:22:56Z post35893: Re: the problem about create windows by thread Etienne Belanger(deleted) http://community.qnx.com/sf/go/post35893 2009-08-13T12:25:29Z 2009-08-13T12:25:29Z The first approach doesn't work because events are sent to the thread that created the window. In this case, it is the main thread. The second approach should work, both in terms of graphics and events. I am not sure I understand #3 in Process 2. Do you have 3 threads (created in step #1) or 6 (3 created in step #1 and 3 in step #3) ? In any case, look for any errors in eglMakeCurrent and/or eglSwapBuffers. Etienne Belanger(deleted) 2009-08-13T12:25:29Z post35873: help with CM when using GF Adrian Higgins http://community.qnx.com/sf/go/post35873 2009-08-13T06:28:55Z 2009-08-13T06:28:55Z Howdy I'm converting a project from using GF only API to using the composition manager. I was lead to believe it would be a simple matter of substituting a few init calls...but as is usually the case, it's more complex than that. I understand that because I will have multiple applications requiring their own layers, I must use KD. Is this correct? Ideally I'd like something like: http://community.qnx.com/svn/repos/graphics/trunk/apps/egl/tutorials/gf-egl-vsync/gf-egl-vsync.c But I can't get this to work with the composition manager. Would this be becuase the concept of windows and multiple layers is one and the same? Anywho, I have managed to get the images displayed (albeit momentarily...probably something to do with swaping buffers, that'll be my next challenge) by substituing gf calls with kd or egl calls eg: gf_dev_attach and gf_display_attach() -> eglGetDisplay() eglInitialize() gf_layer_attach() -> kdCreateWindow() kdRealizeWindow() gf_surface_create_layer() or gf_surface_create -> eglCreateWindowSurface() And due to not having a gf_dev_info : gf_context_set_surface() -> gf_context_set_surface_3d() and/or eglMakeCurrent() The issue I'm now having is finding replacements for gf_draw_blit2() and gf_draw_blitscaled() as they require gf surfaces, not egl surfaces? Is there a way to cast egl surfaces to gf surfaces? I'm currently just using the main surface for each image, and therefore all images are dumped on top of each other, followed by all being dumped on by a full screen white fill (not sure why the screen is turning white...again that'll be the challenge after the next). Also, I haven't found a substitue for gf_surface_get_info() yet...this is required for size, format, stride... Am I correct in thinking this would be defined by the chosen egl_conf? The application is using the img library. Is there a simpler way to manage these images than directly using gf blit? Keep in mind, at this stage there are no 3D elements required, egl is only being used to increase the number of layers available. Any help would be appreciated. Cheers Adrian Adrian Higgins 2009-08-13T06:28:55Z post35869: Re: the problem about create windows by thread hu xiaohua http://community.qnx.com/sf/go/post35869 2009-08-13T02:26:23Z 2009-08-13T02:26:23Z > I wroten a App On Qnx.I want to create three windows. > Process 1: > (1)In KdMain: > ①init the windows info(three windows).win_size/win_name and so on > ②init EGL (three times) > a.Get the display by eglGetDisplay() > b.init EGL by eglInitialize() > c.eglBindAPI() > d.kdCreateWindow() > e.kdRealizeWindow() > f.eglCreateWindowSurface() > g.kdSetWindowPropertyiv() > h.eglCreateContext() > ③create three threads by kdThreadCreate() > (2)In each thread: > ①Draw the picture on each window by vgImageDraw() > the result is: > Three windows work OK.But,if any other thread sents event to the three > windows,they all receive the event by KdMain(). > > Process 2: > (1)In KdMain > ①create three threads > (2)In each thread: > ①init the windows info > ②init EGL( the steps the same as above ) > ③create three threads by kdThreadCreate() > ④draw the picture on window by vgImageDraw() > the result is: > Three thread work OK,each thread can receive event.But the picture is not > displayed on the windows. > > So ,my question is : > ①Must I init EGL in KdMain? > ②Is there any problem with my process? > > I excepting your responses,Thanks a lot. PS:in vgImageDraw(): eglMakeCurrent()→vgSeti()→vgCreateImage()→vgImageSubData() →vgDrawImage()→eglSwapBuffers() hu xiaohua 2009-08-13T02:26:23Z post35867: the problem about create windows by thread hu xiaohua http://community.qnx.com/sf/go/post35867 2009-08-13T01:49:22Z 2009-08-13T01:49:22Z I wroten a App On Qnx.I want to create three windows. Process 1: (1)In KdMain: ①init the windows info(three windows).win_size/win_name and so on ②init EGL (three times) a.Get the display by eglGetDisplay() b.init EGL by eglInitialize() c.eglBindAPI() d.kdCreateWindow() e.kdRealizeWindow() f.eglCreateWindowSurface() g.kdSetWindowPropertyiv() h.eglCreateContext() ③create three threads by kdThreadCreate() (2)In each thread: ①Draw the picture on each window by vgImageDraw() the result is: Three windows work OK.But,if any other thread sents event to the three windows,they all receive the event by KdMain(). Process 2: (1)In KdMain ①create three threads (2)In each thread: ①init the windows info ②init EGL( the steps the same as above ) ③create three threads by kdThreadCreate() ④draw the picture on window by vgImageDraw() the result is: Three thread work OK,each thread can receive event.But the picture is not displayed on the windows. So ,my question is : ①Must I init EGL in KdMain? ②Is there any problem with my process? I excepting your responses,Thanks a lot. hu xiaohua 2009-08-13T01:49:22Z post35202: Re: Some questions about the HMI flash and the video window Etienne Belanger(deleted) http://community.qnx.com/sf/go/post35202 2009-08-04T19:00:52Z 2009-08-04T19:00:52Z The usage of delegates in the attached diagram does not follow conventional usage. Events usually flow from windows to their delegates, and not the other way around. Additionally, if a window is itself a delegate, notifications about it won't be sent to other delegates. In short, if the HMI and Video apps are delegates, than the HMI cannot change or talk to the Video window. What I would do is the following: *Create HMI window, and register it as a delegate *Create Video window (but not as delegate) *Make HMI be the delegate of the Video application, i.e. respond to create event by setting the Video window's delegate to HMI window *Send OpenKODE user events to video application when play and stop buttons are pushed. You can do this in the HMI because, as a delegate, it received a window handle in the create event. If the HMI is responsible for choosing the size of the Video window, I would have it launch the application after setting the KD_WINDOWPROPERTY_SIZE=(width)x(height) in the environment. (Note that all window properties can be set this way, or by using classes) If you must create and destroy the window when the play and stop buttons are pressed, then I would still use OpenKODE events, except that the Video app has to respond to those by first creating the window, or finish by destroy it, depending if it receives the play or stop user event from the HMI. You can use kdGetWindowPropertyiv(KDWindow *window, KD_WINDOWPROPERTY_SIZE, KDint32 *size) to get the size of a window. Etienne Belanger(deleted) 2009-08-04T19:00:52Z post35124: Some questions about the HMI flash and the video window hu xiaohua http://community.qnx.com/sf/go/post35124 2009-08-02T11:58:10Z 2009-08-02T11:58:10Z Hi,I met some questions about the HMI flash and the video window. I'm afraid that you don't know the question I said,I write the information of system and questins in the appendix. Thank you very much! hu xiaohua 2009-08-02T11:58:10Z post34875: The event of KD_QNX_WINDOWPROPERTY_POSITION handled hu xiaohua http://community.qnx.com/sf/go/post34875 2009-07-30T06:56:14Z 2009-07-30T06:56:14Z I read this code but can't understand something. gles1-kd-hmi.c /** ** gles1-kd-hmi ** Windowed HMI example that uses OpenGL ES 1.X for rendering API. ** */ #include <ctype.h> /* Header file for isdigit */ #include <stdio.h> /* Header file for fprintf */ #include <stdlib.h> /* Header file for EXIT_FAILURE, EXIT_SUCCESS, atoi */ #include <string.h> /* Header file for strncmp */ #include <EGL/egl.h> /* Header file for EGL */ #include <KD/kd.h> /* Header file for OpenKODE */ #include <GLES/gl.h> /* Header file for OpenGL ES 1.X */ #include "error.h" /* dynamically allocated array where we keep information on windows */ KDint32 *windows = NULL; /* the value of nwin is the number of entries in the windows array */ unsigned nwin = 0; /* dynamically allocated array where vertices are kept */ GLshort *points = NULL; /* number of entries in points used; the size of points is nwin * 16 */ GLint nvtx = 0; static void add_window(KDWindow *kd_hmi_win, KDWindow *kd_win) { kdSetWindowPropertyiv(kd_win, KD_QNX_WINDOWPROPERTY_DELEGATE, (KDint32 *)kd_hmi_win); } static void set_border(int wid, KDWindow *kd_win, KDint32 kd_size[2]) { GLshort *new_points; KDint32 *new_windows; KDint32 kd_dst_rect[4]; KDint32 kd_rect[4]; KDint32 vid; KDint32 rc; unsigned i; rc = kdGetWindowPropertyiv(kd_win, KD_QNX_WINDOWPROPERTY_POSITION, kd_dst_rect); rc |= kdGetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, kd_dst_rect+2); if (rc || kd_dst_rect[2] == 0 || kd_dst_rect[3] == 0) { return; } if (wid == 0) { for (i = 0; i < nwin; i++) { if (windows[i] == -1) { wid = i+1; break; } } } if (wid == 0) { new_windows = realloc(windows, (nwin + 1) * sizeof(*windows)); if (new_windows == NULL) { return; } windows = new_windows; windows[nwin] = -1; wid = ++nwin; } kdSetWindowPropertyiv(kd_win, KD_QNX_WINDOWPROPERTY_DELEGATE_POINTER, &wid); wid--; if (windows[wid] == -1) { new_points = realloc(points, (nwin + 1) * 16 * sizeof(*points)); if (new_points == NULL) { return; } /* We will use one vertex array for all of our rendering */ points = new_points; glVertexPointer(2, GL_SHORT, 0, (const GLvoid *)points); glEnableClientState(GL_VERTEX_ARRAY); windows[wid] = nvtx; nvtx += 16; } kd_rect[0] = kd_dst_rect[0] + 1; kd_rect[1] = kd_dst_rect[1] + 1; kd_rect[2] = kd_dst_rect[0] + kd_dst_rect[2]; kd_rect[3] = kd_dst_rect[1] + kd_dst_rect[3]; vid = windows[wid]; points[vid++] = kd_rect[0]; points[vid++] = kd_size[1] - kd_rect[3]; points[vid++] = kd_rect[0]; points[vid++] = kd_size[1] - kd_rect[1]; points[vid++] = kd_rect[0]; points[vid++] = kd_size[1] - kd_rect[1]; points[vid++] = kd_rect[2]; points[vid++] = kd_size[1] - kd_rect[1]; points[vid++] = kd_rect[2]; points[vid++] = kd_size[1] - kd_rect[1]; points[vid++] = kd_rect[2]; points[vid++] = kd_size[1] - kd_rect[3]; points[vid++] = kd_rect[2]; points[vid++] = kd_size[1] - kd_rect[3]; points[vid++] = kd_rect[0]; points[vid++] = kd_size[1] - kd_rect[3]; } static void remove_border(int wid) { unsigned i; /* loop counter */ if (wid == 0) { return; } wid--; for (i = 0; i < nwin; i++) { if (windows[i] > windows[wid]) { /* 4 lines, 8 vertices, 16 elements */ windows[i] -= 16; } } /* Decrease the total element count by 16 as well */ nvtx -= 16; memmove(&points[windows[wid]], &points[windows[wid] + 16], (nvtx - windows[wid]) * sizeof(GLshort) * 2); windows[wid] = -1; } KDint kdMain(KDint argc, const KDchar *const *argv) { EGLDisplay egl_disp; EGLConfig egl_conf; EGLSurface egl_surf; EGLContext egl_ctx; KDWindow *kd_win; EGLNativeWindowType egl_win; KDint32 kd_size[2]; EGLint interval = 1; EGLBoolean verbose = EGL_FALSE; const KDEvent *event; KDboolean kd_bool = KD_TRUE; const char *conf_str = NULL; GLfloat r, g, b; int rval = EXIT_FAILURE; int rc; int i; egl_disp = eglGetDisplay(EGL_DEFAULT_DISPLAY); if (egl_disp == EGL_NO_DISPLAY) { egl_perror("eglGetDisplay"); goto fail1; } rc = eglInitialize(egl_disp, NULL, NULL); if (rc != EGL_TRUE) { egl_perror("eglInitialize"); goto fail2; } egl_conf = choose_config(egl_disp, conf_str); if (egl_conf == (EGLConfig)0) { goto fail2; } kd_win = kdCreateWindow(egl_disp, egl_conf, KD_NULL); if (kd_win == KD_NULL) { kd_perror("kdCreateWindow"); goto fail2; } rc = kdSetWindowPropertybv(kd_win, KD_QNX_WINDOWPROPERTY_DELEGATE, &kd_bool); if (rc) { kd_perror("KD_QNX_WINDOWPROPERTY_DELEGATE"); goto fail3; } eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_TYPE, &i); if (i == EGL_TRANSPARENT_RGB) { eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_RED_VALUE, &i); r = (float)i / 255; eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_GREEN_VALUE, &i); g = (float)i / 255; eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_BLUE_VALUE, &i); b = (float)i / 255; } else { rc = kdSetWindowPropertybv(kd_win, KD_QNX_WINDOWPROPERTY_SOURCE_ALPHA, &kd_bool); if (rc) { kd_perror("KD_QNX_WINDOWPROPERTY_SOURCE_ALPHA"); goto fail3; } r = 0.0f; g = 0.0f; b = 1.0f; } rc = kdRealizeWindow(kd_win, &egl_win); if (rc) { kd_perror("kdRealizeWindow"); goto fail3; } egl_surf = eglCreateWindowSurface(egl_disp, egl_conf, egl_win, NULL); if (egl_surf == EGL_NO_SURFACE) { egl_perror("eglCreateWindowSurface"); goto fail3; } egl_ctx = eglCreateContext(egl_disp, egl_conf, EGL_NO_CONTEXT, NULL); if (egl_ctx == EGL_NO_CONTEXT) { egl_perror("eglCreateContext"); goto fail4; } rc = eglMakeCurrent(egl_disp, egl_surf, egl_surf, egl_ctx); if (rc != EGL_TRUE) { egl_perror("eglMakeCurrent"); goto fail5; } rc = eglSwapInterval(egl_disp, interval); if (rc != EGL_TRUE) { egl_perror("eglSwapInterval"); goto fail2; } kdGetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, kd_size); /* Set the viewport and projection matrix */ glViewport(0, 0, kd_size[0], kd_size[1]); glMatrixMode(GL_PROJECTION); glOrthof(0.0f, kd_size[0], 0.0f, kd_size[1], -1.0f, 1.0f); glMatrixMode(GL_MODELVIEW); /* Set the clear color to the transparent color or black */ glClearColor(r, g, b, 0.0f); /* We will draw all of our borders red */ glColor4f(1.0f, 0.0f, 0.0f, 1.0f); while (1) { event = kdWaitEvent(1000000000); if (event == KD_NULL) { if (kdGetError() != KD_EAGAIN) { /* to exit cleanly, all we need to to break from this loop */ break; } else { /* timeouts are normal; we'll just wait another second */ continue; } } switch (event->type) { /** ** Events for other windows **/ case KD_QNX_EVENT_WINDOW_CREATE: add_window(kd_win, event->data.windowcreateqnx.window); continue; case KD_QNX_EVENT_WINDOW_REALIZE: set_border((int)event->userptr, event->data.windowrealizeqnx.window, kd_size); break; case KD_QNX_EVENT_WINDOW_PROPERTY: switch (event->data.windowpropertyqnx.pname) { case KD_WINDOWPROPERTY_SIZE: case KD_QNX_WINDOWPROPERTY_POSITION: set_border((int)event->userptr, event->data.windowpropertyqnx.window, kd_size); break; case KD_WINDOWPROPERTY_VISIBILITY: kdGetWindowPropertybv(event->data.windowpropertyqnx.window, KD_WINDOWPROPERTY_VISIBILITY, &kd_bool); if (kd_bool) { set_border((int)event->userptr, event->data.windowpropertyqnx.window, kd_size); } else { remove_border((int)event->userptr); } break; } break; case KD_QNX_EVENT_WINDOW_CLOSE: remove_border((int)event->userptr); break; case KD_EVENT_WINDOW_CLOSE: goto end; default: kdDefaultEvent(event); continue; } /* Start by clearing with transparency everywhere */ glClear(GL_COLOR_BUFFER_BIT); if (nvtx > 0) { /* Draw our borders using GL_LINES */ glDrawArrays(GL_LINES, 0, nvtx/2); } rc = eglSwapBuffers(egl_disp, egl_surf); if (rc != EGL_TRUE) { egl_perror("eglSwapBuffers"); break; } } end: rval = EXIT_SUCCESS; eglMakeCurrent(egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT); fail5: eglDestroyContext(egl_disp, egl_ctx); fail4: eglDestroySurface(egl_disp, egl_surf); fail3: kdDestroyWindow(kd_win); fail2: eglTerminate(egl_disp); eglReleaseThread(); fail1: return rval; } __SRCVERSION( "$URL: http://svn.ott.qnx.com/product/trunk/apps/kd/tutorials/gles1-kd-hmi/gles1-kd-hmi.c $ $Rev: 220409 $" ); when an event of KD_QNX_WINDOWPROPERTY_POSITION received,call the function of set_border.The first step get the new size of window by kdGetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, kd_size). But the new size is not included in the event,where to get the size? How to change the window size by composition window manager? hu xiaohua 2009-07-30T06:56:14Z post34786: Re: Post event to a window that created by another application hu xiaohua http://community.qnx.com/sf/go/post34786 2009-07-29T13:35:03Z 2009-07-29T13:35:03Z I'm very sorry.This documentions had been read.The framework of event and window cann't understand.For example: 1.The HMI flash contains some play buttons.These buttons control the video play. 2. The window that video picture display created 3.The window under the HMI flash 4.The flash player will register itself as a delegate with io-winmgr 5.The kdMain function that video display window created receive event and handled I don't know these questions 1.How to transfer the event of touching button to composition window manager 2.The composition window manager tranfer the pointer input event to the kdMain,or tranfer the window create event to the kdMain? 3.It can create some KDwindows in a kdMain window? Thank you very much! hu xiaohua 2009-07-29T13:35:03Z post34781: Re: Post event to a window that created by another application Etienne Belanger(deleted) http://community.qnx.com/sf/go/post34781 2009-07-29T12:46:47Z 2009-07-29T12:46:47Z Yes, the windowing system is the composition manager. You can manually create events with kdCreateEvent and send it to another window using kdPostWindowEventQNX. The composition manager implements the OpenKODE 1.0.2 specification, as part as events goes, so it is a good place to start. Any changes are documented in our two extensions, KD_QNX_window and KD_QNX_input. http://www.khronos.org/registry/kode/specs/openkode.1.0.2.pdf http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/kd_qnx_window.html http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/kd_qnx_input.html Etienne Belanger(deleted) 2009-07-29T12:46:47Z post34760: Re: Post event to a window that created by another application hu xiaohua http://community.qnx.com/sf/go/post34760 2009-07-29T00:54:19Z 2009-07-29T00:54:19Z I'm very sorry. The windowing system is composition manager? How to create an event with composition manager? How to get the documentation about the event framework of composition manager? Thank you very much! hu xiaohua 2009-07-29T00:54:19Z post34741: Re: Post event to a window that created by another application Etienne Belanger(deleted) http://community.qnx.com/sf/go/post34741 2009-07-28T16:12:33Z 2009-07-28T16:12:33Z These events come from the windowing system. Etienne Belanger(deleted) 2009-07-28T16:12:33Z post34733: Re: Post event to a window that created by another application hu xiaohua http://community.qnx.com/sf/go/post34733 2009-07-28T15:15:44Z 2009-07-28T15:15:44Z I read the program gles1-hmi. Receive event and create window program: event_win = KDWaitEvent(1000000); if(event_win == KD_NULL){ return ; } switch(event_win->type){ case KD_QNX_EVENT_WINDOW_CREATE: set the window with delegates of composition manager continue; case KD_QNX_EVENT_WINDOW_REALIZE: set border of window break; case KD_QNX_EVENT_WINDOW_PROPERTY: change the size or position of window break; case KD_QNX_EVENT_WINDOW_CLOSE: remove the border of window break; } I don't know the event where come from? Another application post event? OpenKode core post event? Thank you very much! hu xiaohua 2009-07-28T15:15:44Z post34700: Re: Post event to a window that created by another application Etienne Belanger(deleted) http://community.qnx.com/sf/go/post34700 2009-07-28T12:23:21Z 2009-07-28T12:23:21Z Normally, this function would be used by applications with a window registered as delegate. Delegates receive events whenever a window is created. Information contained in the event includes a KDWindow* that the application can use to make such calls. For now, we don't provide any other mechanism for non-delegate applications to send events to other processes. Do you mind summarizing what you intended doing with these cross-process KD events ? Etienne Belanger(deleted) 2009-07-28T12:23:21Z post34694: Post event to a window that created by another application hu xiaohua http://community.qnx.com/sf/go/post34694 2009-07-28T11:55:14Z 2009-07-28T11:55:14Z Hi,I try to post a event to a window that created by another application by kdPostWindowEventQNX. The "KD_QNX_window" documentation: http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/kd_qnx_window.html refers to post an event into another application's queue. But what is the value of window argument? How to know the pointer of window? hu xiaohua 2009-07-28T11:55:14Z post34604: Re: The HMI interact with applications Etienne Belanger(deleted) http://community.qnx.com/sf/go/post34604 2009-07-27T12:57:42Z 2009-07-27T12:57:42Z The Flash composition manager plugin (hmip-compmgr) has a configuration option that controls if the player will register itself as a delegate with io-winmgr. When "window_manager" is set to true, the Flash player will start receiving notifications from the Composition Manager whenever new windows are created, existing windows are deleted, or when a window's property has changed. The composition manager will allow the HMI to control windows is if they were its own. The feature that gives an HMI access to another application's buffers is still under development. Etienne Belanger(deleted) 2009-07-27T12:57:42Z post34594: The HMI interact with applications hu xiaohua http://community.qnx.com/sf/go/post34594 2009-07-27T06:11:15Z 2009-07-27T06:11:15Z Hi,I try to create a video player that the flash HMI and video display application. The flash HMI contain the play button and stop button.The video display application is that display picture by OpenVG.The HMI flash is on the head of graphics layer,the application is on the second graphics layer. The "Enabling the HMI" documentation: http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/overview.html refers to How to the flash HMI commnicate with the OpenKode? if there aren't the flash HMI the application can run correctly,add to the flash HMI the applications need to chang? How to the HMI call io-winmgr to access application buffers? Thank you very much! hu xiaohua 2009-07-27T06:11:15Z post32385: Re: Failed to post event by kdPostWindowEventQNX hu xiaohua http://community.qnx.com/sf/go/post32385 2009-06-24T00:53:27Z 2009-06-24T00:53:27Z Thank you very much ! I have soult out the question with your help! hu xiaohua 2009-06-24T00:53:27Z post32318: Re: Failed to post event by kdPostWindowEventQNX Etienne Belanger(deleted) http://community.qnx.com/sf/go/post32318 2009-06-23T14:57:30Z 2009-06-23T14:57:30Z kdPostWindowEventQNX will return KD_EOPNOTSUPP if the event type is not one of KD_EVENT_WINDOW_CLOSE, KD_EVENT_WINDOW_REDRAW, KD_EVENT_WINDOW_FOCUS, KD_EVENT_WINDOWPROPERTY_CHANGE, KD_EVENT_STATE, KD_EVENT_INPUT, KD_EVENT_INPUT_JOG, KD_EVENT_INPUT_POINTER, KD_EVENT_INPUT_STICK, KD_EVENT_USER, KD_QNX_EVENT_KEYBOARD, KD_QNX_EVENT_WINDOW_CREATE, KD_QNX_EVENT_WINDOW_REALIZE, KD_QNX_EVENT_WINDOW_PROPERTY, or KD_QNX_EVENT_WINDOW_CLOSE. To answer your specific questions, the error code returned by kdGetError is not changed unless kdSetError is called or another OpenKODE function sets the value as specified for that function. kdPostThreadEvent would normally be used to post events from one thread to another. However, this function isn't implemented in QNX yet, so your best be is to stick with kdPostWindowEventQNX for now. Etienne Belanger(deleted) 2009-06-23T14:57:30Z post32300: Failed to post event by kdPostWindowEventQNX hu xiaohua http://community.qnx.com/sf/go/post32300 2009-06-23T13:44:24Z 2009-06-23T13:44:24Z Hi, everyone! I want to post an event from a thread to the window(or thread) that created by kdCreateWindow.The environmoment of platform is QNX 6.4.0 and HP(x86)PC. The process is: 1.EGL get display (ok) 2.EGL initialize(ok) 3.choose config by EGL(ok) 4.kdCreateWindow(ok) 5.kdRealizeWindow(ok) 6.kdThreadCreate(ok) 6.1 kdCreateEvent(ok) 6.2 set event data(0k) 6.3 kdPostWindowEventQNX(NG) 7.kdWaitEvent(event nothing) ※6.1 6.2and 6.3 is sub thread process 6.3error id is 31(KD_EOPNOTSUPP)operation not supported. My question: 1.How to clear the error? 2.There is another method to post a event from thread to window(or thread)? hu xiaohua 2009-06-23T13:44:24Z post31760: Re: RE: RE: Bulid error : OpenKode,OpenVG Dennis Kellly http://community.qnx.com/sf/go/post31760 2009-06-15T16:13:57Z 2009-06-15T16:13:57Z Regarding the compile error, check for a line like __SRCVERSION( "$URL: http://svn.ott.qnx.com/product/trunk/... at the end of include .h files. If it is there, comment it and rebuild. Dennis Kellly 2009-06-15T16:13:57Z post31602: Re: How to kill sub_thread in OpenKode?? Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31602 2009-06-12T12:36:37Z 2009-06-12T12:36:37Z kdPostThreadEvent isn't implemented in 6.4.1 yet. That's why you are having problems. kdPostWindowEventQNX is, but as you know, you need a window. The ability to create multiple OpenKODE windows that share the same buffers is something we are considering adding as an extension. This isn't possible with the way OpenKODE Core does things, because normally you create an EGL surface for a native (OpenKODE) window, not the other way around. You can always create and realize OpenKODE windows to get events going with kdPostWindowEventQNX. Unless you call eglCreateWindowSurface, the overhead is pretty small. Etienne Belanger(deleted) 2009-06-12T12:36:37Z post31583: Re: How to kill sub_thread in OpenKode?? Yin Xingmin http://community.qnx.com/sf/go/post31583 2009-06-12T02:20:23Z 2009-06-12T02:20:23Z Yes. I know. Thank you very much! I have another problem. I'm doing my development with QNX Software Development Platform 6.4.1. The kdPostThreadEvent() seems to cannot work well. If I want to post event between threads, it seems that I can only use the kdPostWindowEventQNX() right now. Can I create numbers of kdWindow with the same EGLSurface? Regards, Yin Yin Xingmin 2009-06-12T02:20:23Z post31481: Re: How to kill sub_thread in OpenKode?? Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31481 2009-06-11T13:35:56Z 2009-06-11T13:35:56Z Not necessarily. It still needs to "cooperate" and do a kdThreadExit upon reception of the user event. You can always use system calls like pthread_abort or ThreadDestroy, but in this case, you are no longer getting the portability that OpenKODE is meant to provide. Etienne Belanger(deleted) 2009-06-11T13:35:56Z post31479: Re: How to kill sub_thread in OpenKode?? Yin Xingmin http://community.qnx.com/sf/go/post31479 2009-06-11T13:31:33Z 2009-06-11T13:31:33Z Thank you very much! If I use the event to inform the sub thread to exit, will the thread be suspended when waiting for the event? Or,could I use the QNX's function to terminate the sub thread?(e.g. pthread_abort(), ThreadDestroy()) Regards, Yin Yin Xingmin 2009-06-11T13:31:33Z post31470: Re: How to kill sub_thread in OpenKode?? Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31470 2009-06-11T12:44:05Z 2009-06-11T12:44:05Z As far as I understand the spec, there is no way for one OpenKODE thread of "killing" another thread that is still running. The standard way of handling threads is to do a kdThreadExit/kdThreadJoin, or kdThreadDetach/kdThreadExit. You can always try to post a user event to that thread hoping that it will get it and respond with a kdThreadExit, but it's not as convenient as killing it from another thread. Etienne Belanger(deleted) 2009-06-11T12:44:05Z post31463: Re: RE: RE: Bulid error : OpenKode,OpenVG liu liming(deleted) http://community.qnx.com/sf/go/post31463 2009-06-11T11:50:49Z 2009-06-11T11:50:49Z Hi,Gaétan Thanks for your answer and I had finished this question. 1.When I use your header file in qnx6.4.0, complied failed beacause there is no sys/srcversion.h in qnx6.4.0 2.So I update my os to Qnx6.4.1, then everything becames ok. Thanks very much for your answer.And best regard. Liu Liming > Hi Liu, > Here are a few more comments / clarifications: > > 1- a) libOpenVG-G12.so.1 doesn't need a .so link (but libOpenVG.so.1 does) > b) You should also keep the .so.1 files around, so in the end you should > have two copies of the same files, one .so.1 and one .so > > 2- a) Have you tried using the header files I had attached to my previous > post? The problem with the files you had was at the end of the files, where > there's a call to __SRCVERSION (and in some files an #include of <sys/srcversion.h>, and 6.4 > doesn't have these defined. It is safe to remove these lines. > b) I suppose you have taken vgext.h from Khronos (as we don't provide this > file...)? Our OpenVG implementation doesn't support the KHR extensions, so > you should not be including this file from your application. > > 3- VGImage is defined in openvg.h, so if your application includes openvg.h ( > as it appears to be doing) and it still causes compilation problems even with > the __SRCVERSION references removed (as in the files I had previously attached > ), then chances are there's a problem in your code before the #include > statement. The openvg.h file comes directly from Khronos. If after steps one > and two above you are still having compilation problems, please attach the > new build output (as it will be different than what you had previously > attached). > > Regards, > Gaétan > > -----Original Message----- > From: liu liming [mailto:community-noreply@qnx.com] > Sent: June 8, 2009 9:57 PM > To: cwm-graphics > Subject: Re: RE: Bulid error : OpenKode,OpenVG > > Hi Gaétan, > Thanks your answer and I followed your advice. > > 1.I changed the filename > libEGL.so.1 ->libEGL.so > libgf.so.1 ->libgf.so > libGLESv1_CM.so.1 ->libGLESv1_CM.so > libGLES_CM.so.1 ->libGLES_CM.so > libKD.so.1 -> libKD.so > libWFD.so.1 ->libWFD.so > libOpenVG.so.1 ->libOpenVG.so > libOpenVG-G12.so.1 -> libOpenVG-G12.so > > 2.I checked my include file of > "C:\QNX640\target\qnx6\usr\include\VG", and get the result.I think it will be > ok. > ------------------------------------------------------------------ > 2009/06/05 17:18 34,982 openvg.h > 2009/06/05 17:18 9,892 ovg11_api_backend.h > 2009/06/05 17:18 2,481 ovg_backend.h > 2009/06/05 17:18 1,658 ovg_driver_backend.h > 2009/06/05 17:50 10,083 vgext.h > 2009/06/05 17:18 3,188 vgplatform.h > 2009/06/05 17:18 5,812 vgu.h > ------------------------------------------------------------------ > > 3.And I set the other option of linker tab to: > "-lgf -lEGL -lasound -lkd -lOpenVG -lOpenVG-G12" > But the error message is same. > > Then I change the other option of linker tab to: > "-lgf -lEGL -lasound -lkd -lOpenVG" > and got the same error message. > > Best Regards > > Liu Liming > > > _______________________________________________ > CWM/OpenKODE > http://community.qnx.com/sf/go/post31173 liu liming(deleted) 2009-06-11T11:50:49Z post31461: How to kill sub_thread in OpenKode?? Yin Xingmin http://community.qnx.com/sf/go/post31461 2009-06-11T09:18:52Z 2009-06-11T09:18:52Z Hi, I had created a sub_thread in the kdMain. But how can I kill the sub_thread in kdMain? Is there any API to kill the sub_thread or is there any method to kill the sub_thread?(The kdMain will be still running.) Thank you for your suggestion!! Yin Xingmin 2009-06-11T09:18:52Z post31327: RE: RE: Bulid error : OpenKode,OpenVG Gaétan Noël http://community.qnx.com/sf/go/post31327 2009-06-10T12:55:27Z 2009-06-10T12:55:27Z Hi Liu, Here are a few more comments / clarifications: 1- a) libOpenVG-G12.so.1 doesn't need a .so link (but libOpenVG.so.1 does) b) You should also keep the .so.1 files around, so in the end you should have two copies of the same files, one .so.1 and one .so 2- a) Have you tried using the header files I had attached to my previous post? The problem with the files you had was at the end of the files, where there's a call to __SRCVERSION (and in some files an #include of <sys/srcversion.h>, and 6.4 doesn't have these defined. It is safe to remove these lines. b) I suppose you have taken vgext.h from Khronos (as we don't provide this file...)? Our OpenVG implementation doesn't support the KHR extensions, so you should not be including this file from your application. 3- VGImage is defined in openvg.h, so if your application includes openvg.h (as it appears to be doing) and it still causes compilation problems even with the __SRCVERSION references removed (as in the files I had previously attached), then chances are there's a problem in your code before the #include statement. The openvg.h file comes directly from Khronos. If after steps one and two above you are still having compilation problems, please attach the new build output (as it will be different than what you had previously attached). Regards, Gaétan -----Original Message----- From: liu liming [mailto:community-noreply@qnx.com] Sent: June 8, 2009 9:57 PM To: cwm-graphics Subject: Re: RE: Bulid error : OpenKode,OpenVG Hi Gaétan, Thanks your answer and I followed your advice. 1.I changed the filename libEGL.so.1 ->libEGL.so libgf.so.1 ->libgf.so libGLESv1_CM.so.1 ->libGLESv1_CM.so libGLES_CM.so.1 ->libGLES_CM.so libKD.so.1 -> libKD.so libWFD.so.1 ->libWFD.so libOpenVG.so.1 ->libOpenVG.so libOpenVG-G12.so.1 -> libOpenVG-G12.so 2.I checked my include file of "C:\QNX640\target\qnx6\usr\include\VG", and get the result.I think it will be ok. ------------------------------------------------------------------ 2009/06/05 17:18 34,982 openvg.h 2009/06/05 17:18 9,892 ovg11_api_backend.h 2009/06/05 17:18 2,481 ovg_backend.h 2009/06/05 17:18 1,658 ovg_driver_backend.h 2009/06/05 17:50 10,083 vgext.h 2009/06/05 17:18 3,188 vgplatform.h 2009/06/05 17:18 5,812 vgu.h ------------------------------------------------------------------ 3.And I set the other option of linker tab to: "-lgf -lEGL -lasound -lkd -lOpenVG -lOpenVG-G12" But the error message is same. Then I change the other option of linker tab to: "-lgf -lEGL -lasound -lkd -lOpenVG" and got the same error message. Best Regards Liu Liming _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post31173 Gaétan Noël 2009-06-10T12:55:27Z post31324: RE: RE: setting bit depth for OpenVG flash-player via composition manager? Roger Maclean http://community.qnx.com/sf/go/post31324 2009-06-10T12:41:03Z 2009-06-10T12:41:03Z Yes, you should find they change significantly before and after io-winmgr is running. Roger Maclean 2009-06-10T12:41:03Z post31315: Re: RE: setting bit depth for OpenVG flash-player via composition manager? Mate Szarvas http://community.qnx.com/sf/go/post31315 2009-06-10T11:54:18Z 2009-06-10T11:54:18Z Ohhh! So I need the to get the configs for winmgr.conf before starting io-winmgr and need to get them for flash.conf after starting io-winmgr. Was trying to use the configs from before starting io-winmgr in flash.conf Thanks for the explanation, this should let us go! Mate Szarvas 2009-06-10T11:54:18Z post31308: Re: Can not get event by kdWaitEvent() liu liming(deleted) http://community.qnx.com/sf/go/post31308 2009-06-10T10:02:41Z 2009-06-10T10:02:41Z OK, I had fix the problem. 1.In qnx , kdPostThreadEvent is not implemented and we should use the function of "kdPostWindowEventQNX" to send kdevent. 2.The receive thread must create a window and initialized it. Thanks all very much. liu liming(deleted) 2009-06-10T10:02:41Z post31198: RE: setting bit depth for OpenVG flash-player via composition manager? Roger Maclean http://community.qnx.com/sf/go/post31198 2009-06-09T13:27:05Z 2009-06-09T13:27:05Z No doubt it's all a little confusing. As I mentioned in my previous message, there are several EGL surfaces involved here. The settings for hmip-openvg.so only controls the surface used for rendering off-screen. There is no reason why you would want this one to be tied to a layer since it is never visible. You would probably just want to set its format depending on whether you're wanting to render using 16 or 32 bits. The egl_config setting you will want to set will be the setting for the other extension, hmip-compmgr.so. This is the extension that deals with the composition manager window itself. You would want to pick a config that has the window bit set, has red, green, blue and alpha size that matches the format you've chosen for hmip-openvg.so and has the layer you want. The split in responsibilities between the two extensions are because hmip-compmgr.so can also be used with software rendering. As to the problems you had when you tried to set the egl_config setting of hmip-openvg.so, is the list of egl-configs you provide those obtained when io-winmgr was running or before? The egl configs that are relevant to Flash are those that are available when io-winmgr is running. If you used the other set, you might have chosen ones without the OpenVG bit and it would have failed. To see what egl configs Flash chooses for itself, you can add the configuration setting (to the main part of the configuration, not the extensions): log_mask = configuration you should see messages regarding the configuration that the player has chosen for the render surface and window. Roger Maclean 2009-06-09T13:27:05Z post31177: Re: egl-config value corresponding to a particular layer Mate Szarvas http://community.qnx.com/sf/go/post31177 2009-06-09T03:54:11Z 2009-06-09T03:54:11Z Etienne, thanks for these answers (in all threads), this should let us go forward. -- Mate Mate Szarvas 2009-06-09T03:54:11Z post31176: Re: setting bit depth for OpenVG flash-player via composition manager? Mate Szarvas http://community.qnx.com/sf/go/post31176 2009-06-09T03:32:23Z 2009-06-09T03:32:23Z Tried using extension { dll = hmip_openvg.so config { egl_config = 11 } } with values for egl_config: 3, 4, 10, 11 (also tried 1 and 2 though these are not VG renderable so no surprise). In each case flash displayed the following lines and the screen remained blank: emerg: hmip_openvg: Create context failed: 0x3005 config:11 emerg: framebuffer alloc (640X480) failed The output from egl-configs is attached and the output from use -i flash is like: NAME=flash DESCRIPTION=FlashLite Player DATE=2009/04/15-09:09:18-EDT STATE=experimental HOST=cctrunk USER=builder VERSION=6.4.0 TAGID=9999@218225 The board is i.mx35 custom board. Any advice what's going wrong? # The player displays no problem when specifying "format=565" # and not specifying egl_config at all. Mate Szarvas 2009-06-09T03:32:23Z post31175: Re: setting bit depth for OpenVG flash-player via composition manager? Mate Szarvas http://community.qnx.com/sf/go/post31175 2009-06-09T03:00:45Z 2009-06-09T03:00:45Z Thank you Roger. Now I understand that using the "format" configuration value is the preferred way. Thought to set the egl_config value directly in order to have control over the physical layer where the player is being placed. Is there any other way to set the flash player to a specific hardware layer? # likely these questions are covered in the documentation # but for some reason my IDE cannot display the documentation # (windows host) -- Mate Mate Szarvas 2009-06-09T03:00:45Z post31173: Re: RE: Bulid error : OpenKode,OpenVG liu liming(deleted) http://community.qnx.com/sf/go/post31173 2009-06-09T01:56:50Z 2009-06-09T01:56:50Z Hi Gaétan, Thanks your answer and I followed your advice. 1.I changed the filename libEGL.so.1 ->libEGL.so libgf.so.1 ->libgf.so libGLESv1_CM.so.1 ->libGLESv1_CM.so libGLES_CM.so.1 ->libGLES_CM.so libKD.so.1 -> libKD.so libWFD.so.1 ->libWFD.so libOpenVG.so.1 ->libOpenVG.so libOpenVG-G12.so.1 -> libOpenVG-G12.so 2.I checked my include file of "C:\QNX640\target\qnx6\usr\include\VG", and get the result.I think it will be ok. ------------------------------------------------------------------ 2009/06/05 17:18 34,982 openvg.h 2009/06/05 17:18 9,892 ovg11_api_backend.h 2009/06/05 17:18 2,481 ovg_backend.h 2009/06/05 17:18 1,658 ovg_driver_backend.h 2009/06/05 17:50 10,083 vgext.h 2009/06/05 17:18 3,188 vgplatform.h 2009/06/05 17:18 5,812 vgu.h ------------------------------------------------------------------ 3.And I set the other option of linker tab to: "-lgf -lEGL -lasound -lkd -lOpenVG -lOpenVG-G12" But the error message is same. Then I change the other option of linker tab to: "-lgf -lEGL -lasound -lkd -lOpenVG" and got the same error message. Best Regards Liu Liming liu liming(deleted) 2009-06-09T01:56:50Z post31078: Re: Estimating image-bus bandwidth usage in CWM Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31078 2009-06-08T13:51:35Z 2009-06-08T13:51:35Z For component #2, it is very difficult to estimate the total bandwidth usage for rendering a 100 x 100 window. Things to consider: * Are all pixels touched ? If the surface is single-buffered, you could skip the clear and just redraw parts of the buffer. If the surface is double-bufferd (the default), all pixels have to be redrawn. EGL_SWAP_BEHAVIOR_PRESERVED may let the application think that it doesn't have to redraw all the pixels, but under the hood it's just a blit. * What is the architecture of the graphics core ? Graphics core that do deferred rendering like PowerVR will only write each pixel once. If the rendering is not deferred, then clearing the surface before drawing a line will take a little more bandwidth because of the pixel overdaws. * Are there any per-pixel image-based operations ? If a pixel requires memory lookups (texture sampling, blits, transparency masks), then the bandwidth usage will be higher. Other per-pixel operations like blending will have an impact as well. * Are other buffers involved in the rendering process like stencil buffers, depth buffers ? What rendering API is used ? Using OpenVG, or OpenGL ES, or doing everything in software will probably affect bandwidth. * Is anti-aliasing enabled ? Each anti-aliasing technique (full-scene, multi-sampling, coverage) and the sampling resolve will affect memory bandwidth. For component #3, the scene layout is an important factor. The composition manager clips all the windows into rectangles so that there are no overdraws. However, overlaps when blending is enabled cannot be eliminated. Etienne Belanger(deleted) 2009-06-08T13:51:35Z post31076: RE: Bulid error : OpenKode,OpenVG Gaétan Noël http://community.qnx.com/sf/go/post31076 2009-06-08T13:42:08Z 2009-06-08T13:42:08Z Hi Liu, Normally, your files with size zero should be links to the versioned .so files (e.g. libEGL.so linked to libEGL.so.1). Since you are running your build environment under Windows, just make a straight copy of the .so.1 files to .so, replacing the zero length files (and don't remove the .so.1). Furthermore, you'll need to also do this for libOpenVG.so.1 (i.e. copy libOpenVG.so.1 to libOpenVG.so). As a second comment, when using OpenVG, your application should link against libOpenVG, and not against libOpenVG-G12 (this one would be used by the driver itself). As for the problems your getting when compiling, please try the attached header files for OpenVG. I believe the files you have are for a 6.4.1 environment. So basically, you should simply put the attached files in your c:/QNX640/target/qnx6/usr/include/VG/ directory on your build machine. Please let me know how that goes. Regards, Gaétan -----Original Message----- From: liu liming [mailto:community-noreply@qnx.com] Sent: June 8, 2009 9:14 AM To: cwm-graphics Subject: Bulid error : OpenKode,OpenVG Hi,everybody I am writing an application with OpenKode and OpenVG.And my enviorment is :QNX6.4.0 + Aviage HMI Suite 2.0 I list my lib in "C:\QNX640\target\qnx6\x86\usr\lib" and get the result ---------------------------------------------------------------------------- 2009/03/26 03:12 0 libEGL.so 2009/03/26 03:12 62,126 libEGL.so.1 2009/03/26 03:12 0 libgf.so 2009/03/26 03:12 92,505 libgf.so.1 2009/03/26 03:12 0 libgf.so 2009/03/26 03:12 151,633 libGLESv1_CM.so.1 2009/03/26 03:12 0 libGLES_CM.so 2009/03/26 03:12 166,032 libGLES_CM.so.1 2009/03/26 03:12 0 libKD.so 2009/03/26 03:12 29,789 libKD.so.1 2009/03/26 03:12 0 libWFD.so 2009/03/26 03:12 39,649 libWFD.so.1 2009/06/05 17:21 383,262 libOpenVG-G12.so.1 2009/06/05 17:21 27,036 libOpenVG.so.1 2009/06/05 17:21 38,742 libutil.a ---------------------------------------------------------------------------- The strage thing is that size of libEGL.so, libgf.so, libgf.so,libKD.so,libWFD.so is zero. I fill the other option of linker option with "-lgf -lEGL -lasound -lkd -lOpenVG -lOpenVG-G12". But when bulid, I got many errores.I think it will be the problem of link option.How can I do for it? Thanks very much. ------------------------------------------------------- Severity and Description Path Resource Location Creation Time Id 'image' undeclared (first use in this function) my_application my_event_process.c line 311 1244465516977 3152 'image' undeclared (first use in this function) my_application my_event_process.c line 411 1244465516993 3160 'VGImage' undeclared (first use in this function) my_application my_event_process.c line 308 1244465516977 3150 'VGImage' undeclared (first use in this function) my_application my_event_process.c line 373 1244465516977 3158 C:/QNX640/target/qnx6/usr/include/errno.h expected ';' before 'extern' my_application line 40 1244465516977 3149 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'asm' my_application line 749 1244465516977 3139 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'typedef' my_application line 59 1244465516946 3072 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 649 1244465516977 3122 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 661 1244465516977 3125 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 700 1244465516977 3133 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 702 1244465516977 3134 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 709 1244465516977 3135 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 718 1244465516977 3136 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 722 1244465516977 3137 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 729 1244465516977 3138 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 593 1244465516946 3098 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 594 1244465516946 3099 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 598 1244465516946 3100 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 601 1244465516946 3101 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 602 1244465516946 3102 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 674 1244465516977 3127 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 675 1244465516977 3128 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 681 1244465516977 3129 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 686 1244465516977 3130 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 687 1244465516977 3131 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 691 1244465516977 3132 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 634 1244465516946 3116 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 635 1244465516946 3117 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 637 1244465516962 3118 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 641 1244465516962 3119 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 653 1244465516977 3123 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'mask' my_application line 563 1244465516946 3087 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 570 1244465516946 3090 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 571 1244465516946 3091 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 575 1244465516946 3092 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 526 1244465516946 3078 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 529 1244465516946 3079 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 532 1244465516946 3080 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 535 1244465516946 3081 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 539 1244465516946 3082 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 541 1244465516946 3083 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 543 1244465516946 3084 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 545 1244465516946 3085 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 548 1244465516946 3086 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 623 1244465516946 3109 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 624 1244465516946 3110 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 626 1244465516946 3112 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 627 1244465516946 3113 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 628 1244465516946 3114 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 566 1244465516946 3088 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 588 1244465516946 3094 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 589 1244465516946 3095 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 590 1244465516946 3096 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 592 1244465516946 3097 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 606 1244465516946 3103 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 608 1244465516946 3104 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 613 1244465516946 3105 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 616 1244465516946 3106 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 619 1244465516946 3107 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgChildImage' my_application line 646 1244465516962 3120 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateFont' my_application line 673 1244465516977 3126 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateImage' my_application line 631 1244465516946 3115 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateMaskLayer' my_application line 569 1244465516946 3089 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePaint' my_application line 622 1244465516946 3108 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePath' my_application line 582 1244465516946 3093 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGFont' my_application line 64 1244465516946 3076 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetPaint' my_application line 625 1244465516946 3111 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetParent' my_application line 648 1244465516962 3121 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGImage' my_application line 62 1244465516946 3074 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGMaskLayer' my_application line 63 1244465516946 3075 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPaint' my_application line 65 1244465516946 3077 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPath' my_application line 61 1244465516946 3073 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected declaration specifiers or '...' before 'VGImage' my_application line 655 1244465516977 3124 C:/QNX640/target/qnx6/usr/include/VG/vgplatform.h sys/srcversion.h: No such file or directory my_application line 108 1244465516946 3071 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguArc' my_application line 99 1244465516977 3145 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToQuad' my_application line 117 1244465516977 3148 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToSquare' my_application line 105 1244465516977 3146 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpSquareToQuad' my_application line 111 1244465516977 3147 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguEllipse' my_application line 95 1244465516977 3144 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguLine' my_application line 78 1244465516977 3140 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguPolygon' my_application line 82 1244465516977 3141 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRect' my_application line 86 1244465516977 3142 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRoundRect' my_application line 90 1244465516977 3143 expected ';' before 'image' my_application my_event_process.c line 308 1244465516977 3151 expected ';' before 'image' my_application my_event_process.c line 373 1244465516993 3159 make[2]: *** [my_event_process.o] Error 1 my_application line 0 1244465516993 3164 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 325 1244465516977 3155 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 339 1244465516977 3156 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 425 1244465516993 3161 assignment discards qualifiers from pointer target type my_application my_application.c line 78 1244465516946 3070 implicit declaration of function 'vgCreateImage' my_application my_event_process.c line 311 1244465516977 3153 implicit declaration of function 'vgDestroyImage' my_application my_event_process.c line 350 1244465516977 3157 implicit declaration of function 'vgImageSubData' my_application my_event_process.c line 319 1244465516977 3154 passing argument 1 of 'eglGetDisplay' makes integer from pointer without a cast my_application my_app_init.c line 336 1244465516946 3069 passing argument 2 of 'kdRealizeWindow' from incompatible pointer type my_application my_event_process.c line 1145 1244465516993 3162 passing argument 3 of 'eglCreateWindowSurface' makes pointer from integer without a cast my_application my_event_process.c line 1149 1244465516993 3163 -------------------------------------------------------    _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post31070 Gaétan Noël 2009-06-08T13:42:08Z post31074: Re: io-winmgr -sysres : how to use correctly? Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31074 2009-06-08T13:30:43Z 2009-06-08T13:30:43Z In order to get EGL configs that can be used in winmgr.conf, you should use io-winmgr -sysres prior to starting io-winmgr. In general, io-winmgr should just sit there and wait for content updates. If there are none, the CPU usage should be very low. We've fixed similar problems before. I cannot say for sure if this is one of those or not. Etienne Belanger(deleted) 2009-06-08T13:30:43Z post31073: Re: Can not get event by kdWaitEvent() Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31073 2009-06-08T13:22:54Z 2009-06-08T13:22:54Z Right now, kdPostThreadEvent is not implemented. KD_EAGAIN typically is the error when the OpenKODE library can't connect to io-winmgr. Etienne Belanger(deleted) 2009-06-08T13:22:54Z post31072: Re: egl-config value corresponding to a particular layer Etienne Belanger(deleted) http://community.qnx.com/sf/go/post31072 2009-06-08T13:20:22Z 2009-06-08T13:20:22Z EGL_LEVEL represents the layer number. Etienne Belanger(deleted) 2009-06-08T13:20:22Z post31071: Bulid error : OpenKode,OpenVG liu liming(deleted) http://community.qnx.com/sf/go/post31071 2009-06-08T13:16:50Z 2009-06-08T13:16:50Z Hi,everybody I am writing an application with OpenKode and OpenVG.And my enviorment is :QNX6.4.0 + Aviage HMI Suite 2.0 I list my lib in "C:\QNX640\target\qnx6\x86\usr\lib" and get the result ---------------------------------------------------------------------------- 2009/03/26 03:12 0 libEGL.so 2009/03/26 03:12 62,126 libEGL.so.1 2009/03/26 03:12 0 libgf.so 2009/03/26 03:12 92,505 libgf.so.1 2009/03/26 03:12 0 libgf.so 2009/03/26 03:12 151,633 libGLESv1_CM.so.1 2009/03/26 03:12 0 libGLES_CM.so 2009/03/26 03:12 166,032 libGLES_CM.so.1 2009/03/26 03:12 0 libKD.so 2009/03/26 03:12 29,789 libKD.so.1 2009/03/26 03:12 0 libWFD.so 2009/03/26 03:12 39,649 libWFD.so.1 2009/06/05 17:21 383,262 libOpenVG-G12.so.1 2009/06/05 17:21 27,036 libOpenVG.so.1 2009/06/05 17:21 38,742 libutil.a ---------------------------------------------------------------------------- The strange thing is that size of libEGL.so, libgf.so, libgf.so,libKD.so,libWFD.so is zero. I fill the other option of linker tab with "-lgf -lEGL -lasound -lkd -lOpenVG -lOpenVG-G12". But when bulid, I got many errores.I think it will be the problem of link option.How can I do for it? Thanks very much. ------------------------------------------------------- Severity and Description Path Resource Location Creation Time Id 'image' undeclared (first use in this function) my_application my_event_process.c line 311 1244465516977 3152 'image' undeclared (first use in this function) my_application my_event_process.c line 411 1244465516993 3160 'VGImage' undeclared (first use in this function) my_application my_event_process.c line 308 1244465516977 3150 'VGImage' undeclared (first use in this function) my_application my_event_process.c line 373 1244465516977 3158 C:/QNX640/target/qnx6/usr/include/errno.h expected ';' before 'extern' my_application line 40 1244465516977 3149 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'asm' my_application line 749 1244465516977 3139 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'typedef' my_application line 59 1244465516946 3072 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 649 1244465516977 3122 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 661 1244465516977 3125 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 700 1244465516977 3133 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 702 1244465516977 3134 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 709 1244465516977 3135 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 718 1244465516977 3136 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 722 1244465516977 3137 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 729 1244465516977 3138 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 593 1244465516946 3098 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 594 1244465516946 3099 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 598 1244465516946 3100 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 601 1244465516946 3101 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 602 1244465516946 3102 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 674 1244465516977 3127 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 675 1244465516977 3128 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 681 1244465516977 3129 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 686 1244465516977 3130 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 687 1244465516977 3131 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 691 1244465516977 3132 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 634 1244465516946 3116 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 635 1244465516946 3117 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 637 1244465516962 3118 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 641 1244465516962 3119 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 653 1244465516977 3123 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'mask' my_application line 563 1244465516946 3087 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 570 1244465516946 3090 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 571 1244465516946 3091 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 575 1244465516946 3092 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 526 1244465516946 3078 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 529 1244465516946 3079 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 532 1244465516946 3080 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 535 1244465516946 3081 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 539 1244465516946 3082 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 541 1244465516946 3083 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 543 1244465516946 3084 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 545 1244465516946 3085 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 548 1244465516946 3086 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 623 1244465516946 3109 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 624 1244465516946 3110 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 626 1244465516946 3112 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 627 1244465516946 3113 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 628 1244465516946 3114 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 566 1244465516946 3088 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 588 1244465516946 3094 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 589 1244465516946 3095 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 590 1244465516946 3096 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 592 1244465516946 3097 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 606 1244465516946 3103 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 608 1244465516946 3104 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 613 1244465516946 3105 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 616 1244465516946 3106 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 619 1244465516946 3107 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgChildImage' my_application line 646 1244465516962 3120 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateFont' my_application line 673 1244465516977 3126 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateImage' my_application line 631 1244465516946 3115 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateMaskLayer' my_application line 569 1244465516946 3089 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePaint' my_application line 622 1244465516946 3108 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePath' my_application line 582 1244465516946 3093 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGFont' my_application line 64 1244465516946 3076 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetPaint' my_application line 625 1244465516946 3111 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetParent' my_application line 648 1244465516962 3121 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGImage' my_application line 62 1244465516946 3074 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGMaskLayer' my_application line 63 1244465516946 3075 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPaint' my_application line 65 1244465516946 3077 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPath' my_application line 61 1244465516946 3073 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected declaration specifiers or '...' before 'VGImage' my_application line 655 1244465516977 3124 C:/QNX640/target/qnx6/usr/include/VG/vgplatform.h sys/srcversion.h: No such file or directory my_application line 108 1244465516946 3071 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguArc' my_application line 99 1244465516977 3145 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToQuad' my_application line 117 1244465516977 3148 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToSquare' my_application line 105 1244465516977 3146 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpSquareToQuad' my_application line 111 1244465516977 3147 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguEllipse' my_application line 95 1244465516977 3144 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguLine' my_application line 78 1244465516977 3140 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguPolygon' my_application line 82 1244465516977 3141 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRect' my_application line 86 1244465516977 3142 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRoundRect' my_application line 90 1244465516977 3143 expected ';' before 'image' my_application my_event_process.c line 308 1244465516977 3151 expected ';' before 'image' my_application my_event_process.c line 373 1244465516993 3159 make[2]: *** [my_event_process.o] Error 1 my_application line 0 1244465516993 3164 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 325 1244465516977 3155 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 339 1244465516977 3156 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 425 1244465516993 3161 assignment discards qualifiers from pointer target type my_application my_application.c line 78 1244465516946 3070 implicit declaration of function 'vgCreateImage' my_application my_event_process.c line 311 1244465516977 3153 implicit declaration of function 'vgDestroyImage' my_application my_event_process.c line 350 1244465516977 3157 implicit declaration of function 'vgImageSubData' my_application my_event_process.c line 319 1244465516977 3154 passing argument 1 of 'eglGetDisplay' makes integer from pointer without a cast my_application my_app_init.c line 336 1244465516946 3069 passing argument 2 of 'kdRealizeWindow' from incompatible pointer type my_application my_event_process.c line 1145 1244465516993 3162 passing argument 3 of 'eglCreateWindowSurface' makes pointer from integer without a cast my_application my_event_process.c line 1149 1244465516993 3163 -------------------------------------------------------    liu liming(deleted) 2009-06-08T13:16:50Z post31070: Bulid error : OpenKode,OpenVG liu liming(deleted) http://community.qnx.com/sf/go/post31070 2009-06-08T13:14:20Z 2009-06-08T13:14:20Z Hi,everybody I am writing an application with OpenKode and OpenVG.And my enviorment is :QNX6.4.0 + Aviage HMI Suite 2.0 I list my lib in "C:\QNX640\target\qnx6\x86\usr\lib" and get the result ---------------------------------------------------------------------------- 2009/03/26 03:12 0 libEGL.so 2009/03/26 03:12 62,126 libEGL.so.1 2009/03/26 03:12 0 libgf.so 2009/03/26 03:12 92,505 libgf.so.1 2009/03/26 03:12 0 libgf.so 2009/03/26 03:12 151,633 libGLESv1_CM.so.1 2009/03/26 03:12 0 libGLES_CM.so 2009/03/26 03:12 166,032 libGLES_CM.so.1 2009/03/26 03:12 0 libKD.so 2009/03/26 03:12 29,789 libKD.so.1 2009/03/26 03:12 0 libWFD.so 2009/03/26 03:12 39,649 libWFD.so.1 2009/06/05 17:21 383,262 libOpenVG-G12.so.1 2009/06/05 17:21 27,036 libOpenVG.so.1 2009/06/05 17:21 38,742 libutil.a ---------------------------------------------------------------------------- The strage thing is that size of libEGL.so, libgf.so, libgf.so,libKD.so,libWFD.so is zero. I fill the other option of linker option with "-lgf -lEGL -lasound -lkd -lOpenVG -lOpenVG-G12". But when bulid, I got many errores.I think it will be the problem of link option.How can I do for it? Thanks very much. ------------------------------------------------------- Severity and Description Path Resource Location Creation Time Id 'image' undeclared (first use in this function) my_application my_event_process.c line 311 1244465516977 3152 'image' undeclared (first use in this function) my_application my_event_process.c line 411 1244465516993 3160 'VGImage' undeclared (first use in this function) my_application my_event_process.c line 308 1244465516977 3150 'VGImage' undeclared (first use in this function) my_application my_event_process.c line 373 1244465516977 3158 C:/QNX640/target/qnx6/usr/include/errno.h expected ';' before 'extern' my_application line 40 1244465516977 3149 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'asm' my_application line 749 1244465516977 3139 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'typedef' my_application line 59 1244465516946 3072 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 649 1244465516977 3122 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 661 1244465516977 3125 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 700 1244465516977 3133 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 702 1244465516977 3134 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 709 1244465516977 3135 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 718 1244465516977 3136 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 722 1244465516977 3137 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 729 1244465516977 3138 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 593 1244465516946 3098 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 594 1244465516946 3099 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 598 1244465516946 3100 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 601 1244465516946 3101 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 602 1244465516946 3102 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 674 1244465516977 3127 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 675 1244465516977 3128 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 681 1244465516977 3129 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 686 1244465516977 3130 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 687 1244465516977 3131 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 691 1244465516977 3132 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 634 1244465516946 3116 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 635 1244465516946 3117 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 637 1244465516962 3118 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 641 1244465516962 3119 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 653 1244465516977 3123 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'mask' my_application line 563 1244465516946 3087 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 570 1244465516946 3090 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 571 1244465516946 3091 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 575 1244465516946 3092 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 526 1244465516946 3078 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 529 1244465516946 3079 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 532 1244465516946 3080 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 535 1244465516946 3081 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 539 1244465516946 3082 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 541 1244465516946 3083 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 543 1244465516946 3084 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 545 1244465516946 3085 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 548 1244465516946 3086 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 623 1244465516946 3109 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 624 1244465516946 3110 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 626 1244465516946 3112 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 627 1244465516946 3113 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 628 1244465516946 3114 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 566 1244465516946 3088 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 588 1244465516946 3094 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 589 1244465516946 3095 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 590 1244465516946 3096 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 592 1244465516946 3097 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 606 1244465516946 3103 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 608 1244465516946 3104 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 613 1244465516946 3105 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 616 1244465516946 3106 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 619 1244465516946 3107 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgChildImage' my_application line 646 1244465516962 3120 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateFont' my_application line 673 1244465516977 3126 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateImage' my_application line 631 1244465516946 3115 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateMaskLayer' my_application line 569 1244465516946 3089 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePaint' my_application line 622 1244465516946 3108 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePath' my_application line 582 1244465516946 3093 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGFont' my_application line 64 1244465516946 3076 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetPaint' my_application line 625 1244465516946 3111 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetParent' my_application line 648 1244465516962 3121 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGImage' my_application line 62 1244465516946 3074 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGMaskLayer' my_application line 63 1244465516946 3075 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPaint' my_application line 65 1244465516946 3077 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPath' my_application line 61 1244465516946 3073 C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected declaration specifiers or '...' before 'VGImage' my_application line 655 1244465516977 3124 C:/QNX640/target/qnx6/usr/include/VG/vgplatform.h sys/srcversion.h: No such file or directory my_application line 108 1244465516946 3071 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguArc' my_application line 99 1244465516977 3145 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToQuad' my_application line 117 1244465516977 3148 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToSquare' my_application line 105 1244465516977 3146 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpSquareToQuad' my_application line 111 1244465516977 3147 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguEllipse' my_application line 95 1244465516977 3144 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguLine' my_application line 78 1244465516977 3140 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguPolygon' my_application line 82 1244465516977 3141 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRect' my_application line 86 1244465516977 3142 C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRoundRect' my_application line 90 1244465516977 3143 expected ';' before 'image' my_application my_event_process.c line 308 1244465516977 3151 expected ';' before 'image' my_application my_event_process.c line 373 1244465516993 3159 make[2]: *** [my_event_process.o] Error 1 my_application line 0 1244465516993 3164 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 325 1244465516977 3155 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 339 1244465516977 3156 too many arguments to function 'vgSetPixels' my_application my_event_process.c line 425 1244465516993 3161 assignment discards qualifiers from pointer target type my_application my_application.c line 78 1244465516946 3070 implicit declaration of function 'vgCreateImage' my_application my_event_process.c line 311 1244465516977 3153 implicit declaration of function 'vgDestroyImage' my_application my_event_process.c line 350 1244465516977 3157 implicit declaration of function 'vgImageSubData' my_application my_event_process.c line 319 1244465516977 3154 passing argument 1 of 'eglGetDisplay' makes integer from pointer without a cast my_application my_app_init.c line 336 1244465516946 3069 passing argument 2 of 'kdRealizeWindow' from incompatible pointer type my_application my_event_process.c line 1145 1244465516993 3162 passing argument 3 of 'eglCreateWindowSurface' makes pointer from integer without a cast my_application my_event_process.c line 1149 1244465516993 3163 -------------------------------------------------------    liu liming(deleted) 2009-06-08T13:14:20Z post31068: Re: setting bit depth for OpenVG flash-player via composition manager? Roger Maclean http://community.qnx.com/sf/go/post31068 2009-06-08T13:04:15Z 2009-06-08T13:04:15Z If you want to set the EGL config used for the EGL surface that Flash initially renders into (Flash makes use of multiple surfaces), then you either as you mentoined, use the format parameter for the hmip_openvg.so extension. If you really want to be more specific than that, this same extension supports a egl_config setting as well. So you'd use: extension { dll = hmip_openvg.so config { egl_config = 11 } } The egl_config setting you tried setting was for the hmip_compmgr.so extension and this just affects the EGL config used for the composition manager window itself. I don't believe you normally want to do this though. The intended way of configuring the player is to set the format for the openvg extension and all other EGL configs are based on this. The various egl_config settings in the extensions are there more as a last resort if there are other considerations that the player has not taken into account. If these settings are needed it really means we need to improve the player. Using egl_config settings directly is risky since the values do not have a fixed meaning. Unless you ensure that you reassess the settings with any change to your target, you could end up using something quite different to what you want. Roger Maclean 2009-06-08T13:04:15Z post31062: setting bit depth for OpenVG flash-player via composition manager? Mate Szarvas http://community.qnx.com/sf/go/post31062 2009-06-08T09:32:52Z 2009-06-08T09:32:52Z When running /bin/flash with openvg rendering, we can set the bit depth using the format parameter in flash.conf: extension { dll = hmip-openvg.so config { format = 565 } } Is it possible to set the egl config more specifically? We tried extension { dll = hmip-compmgr.so config { winmgr_class = Flash egl_config = 11 } } but it seems to have no effect. We also tried begin display begin plane #FRANK - uncommented this line, not sure of the affects of this egl-config = 11 ... in winmgr.conf but it also had no effect. Also, how is the default value for the format and egl config value determined? Mate Szarvas 2009-06-08T09:32:52Z post31061: Estimating image-bus bandwidth usage in CWM Mate Szarvas http://community.qnx.com/sf/go/post31061 2009-06-08T08:45:03Z 2009-06-08T08:45:03Z In order to have control over flicker in our i.mx35-based system with limited image-bus bandwidth we would like come up with an estimate on the upper bound of bandwidth usage. We have some limited understanding of the factors, as follows: Bandwidth usage with multiple physical layers is the sum of bandwidth usage for each layer. The bandwidth usage may be different for each layer, depending on the applications running on the given layer. For each layer the bandwidth usage is the sum 3 components of: 1. display controller refresh bandwidth: display_refresh_rate * pixel_count * bits_per_pixel where pixel_count is about display_width * display_height (e.g. 640*480 in VGA mode) 2. content updates of all applications rendering to the given physical layer: sum of bandwidth use of each application's update, regardless of whether the application's window is fully occluded or fully visible How to compute the BW usage resulting from a single application updating a 100 * 100 pixels window? Is the BW usage the same whether we draw just a diagonal line from the top-left to the bottom right corner and when we draw a square filling the complete 100 x 100 area? Will the bandwidth usage increase if we redraw (parts) of the 100 * 100 pixels window multiple times in a single update cycle, such as when clearing the background completely first and then rendering a vector-based map? What other factors influence the bandwidth use resulting from content updates? 3. Compositing of dirtied rectangles at the application's update rate How to estimate bandwidth usage by the compositing process depending on the area of diritied rectangles? Is the bandwidth usage here dependent on whether the dirtied rectangles of different applications overlap or not? Is there any other factor to consider for estimating the bandwidth usage? Is the bandwidth usage the same regardless of using the OpenVG accelerator or doing all rendering by software? Mate Szarvas 2009-06-08T08:45:03Z post31060: egl-config value corresponding to a particular layer Mate Szarvas http://community.qnx.com/sf/go/post31060 2009-06-08T07:49:06Z 2009-06-08T07:49:06Z We would like to select an egl-config value corresponding to layer 1 on an i.mx35 system supporting 2 physical layers. A section of the output from io-winmgr -sysres looks like this: <id>10</id> <config_caveat>EGL_NONE</config_caveat> <buffer_size>16</buffer_size> <red_size>5</red_size> <green_size>6</green_size> <blue_size>5</blue_size> <alpha_size>0</alpha_size> <alpha_mask_size>0</alpha_mask_size> <depth_size>0</depth_size> <stencil_size>0</stencil_size> <level>0<level> <renderable_type>EGL_OPENVG_BIT</renderable_type> <native_renderable>no</native_renderable> <native_visual_type>GF_FORMAT_PACK_RGB565</native_visual_type> <samples>0</samples> <sample_buffers>0</sample_buffers> <surface_type>EGL_PBUFFER_BIT|EGL_PIXMAP_BIT|EGL_WINDOW_BIT|EGL_SWAP_BEHAVIOR_PRESERVED_BIT|EGL_LOCK_SURFACE_BIT_KHR</surface_type> </config> <config> <id>11</id> <config_caveat>EGL_NONE</config_caveat> <buffer_size>16</buffer_size> <red_size>5</red_size> <green_size>6</green_size> <blue_size>5</blue_size> <alpha_size>0</alpha_size> <alpha_mask_size>0</alpha_mask_size> <depth_size>0</depth_size> <stencil_size>0</stencil_size> <level>1<level> <renderable_type>EGL_OPENVG_BIT</renderable_type> <native_renderable>no</native_renderable> <native_visual_type>GF_FORMAT_PACK_RGB565</native_visual_type> <samples>0</samples> <sample_buffers>0</sample_buffers> <surface_type>EGL_PBUFFER_BIT|EGL_PIXMAP_BIT|EGL_WINDOW_BIT|EGL_SWAP_BEHAVIOR_PRESERVED_BIT|EGL_LOCK_SURFACE_BIT_KHR</surface_type> </config> Which of these config values indicates the physical layer number? Mate Szarvas 2009-06-08T07:49:06Z post31059: io-winmgr -sysres : how to use correctly? Mate Szarvas http://community.qnx.com/sf/go/post31059 2009-06-08T07:40:02Z 2009-06-08T07:40:02Z We would like to set winmgr.conf / display / plane / elg-conifig to a value corresponding to 16 bits of bit-depth in order to avoid flicker on an i.mx35-based system. Per the documentation and your previous response we were running io-winmgr -sysres (after another instance of io-winmgr was already running) but the config values reported do not appear to be correct. We judged that based on the presence of flicker. We managed to obtain correct 16-bit configuration values by running io-winmgr -sysres while no other instance of io-winmgr was running in the system but in this case the io-winmgr process never terminated, unless we sent it a signal. Also, when starting io-winmgr -sysres in the background and looking at its state with the pidin command, io-winmgr was always in the READY state and the hogs utility reported io-winmgr as using 85% of the CPU (with another 13% used by io-pkt even though no network communication was going on in the system). The last few lines output by io-winmgr -sysres were: <samples>0</samples> <sample_buffers>0</sample_buffers> <surface_type>EGL_PBUFFER_BIT|EGL_PIXMAP_BIT|EGL_LOCK_SURFACE_BIT_KHR</surface_type> </config> </configs> </egl> <wfd> use -i /sbin/io-winmgr reports: NAME=io-winmgr DESCRIPTION=compositing window manager DATE=2009/04/15-09:25:09-EDT STATE=experimental HOST=cctrunk USER=builder VERSION=6.4.0 TAGID=9999@218225 Is this hangup to be expected or it's something with our configuration or our use of the command? Mate Szarvas 2009-06-08T07:40:02Z post31053: RE: Can not get event by kdWaitEvent() Max Feil http://community.qnx.com/sf/go/post31053 2009-06-07T15:42:43Z 2009-06-07T15:42:43Z I ran into this issue. The thread receiving OpenKode events must be the same one that initialized the OpenKode window (realization, etc). I solved this by calling my OpenKode initialization function from my input thread. Regards, Max -----Original Message----- From: liu liming [mailto:community-noreply@qnx.com] Sent: Sunday, June 07, 2009 7:20 AM To: cwm-graphics Subject: Can not get event by kdWaitEvent() Hi,every body. I need to send/receive openkode event in multi thread. I follow the OpenKode1.0.2 and I think my source will be Ok. But it does not work. 1).kdWaitEvent(-1) , err code is KD_EAGAIN (5): In OpenKode1.0.2, this means:The timeout expired while the event queue was empty. 2).kdPostThreadEvent(), err code is KD_EAGAIN (5): In OpenKode1.0.2, this means:Resource unavailable, try again. I think it may be the reason of init of event queue , but I can not found any function to init the queue. How can i do for it, thanks. This is my source code ------------------------------------------------------------------------ --------------------- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/keycodes.h> #include <time.h> #include <EGL/egl.h> #include <KD/kd.h> #include <GLES/gl.h> KDThread * pRecvThread = KD_NULL; void * kdSendThreadFun(void * arg) { printf("SubThreadFunc: Enter\n"); KDEvent * pSendEvent = KD_NULL; KDint looCnt = 0; while(looCnt < 1) { pSendEvent = kdCreateEvent(); if(KD_NULL == pSendEvent) { printf("SubThreadFunc: Failed to create KdEvent, and the errCode is:%d\n", kdGetError()); } else { printf("SubThreadFunc: Successed to create KdEvent\n"); if(-1 == kdPostThreadEvent(pSendEvent, pRecvThread)) { printf("SubTheadFunc: Failed to send KdEvent, and the errCode is:%d\n", kdGetError()); } else { printf("SubTheadFunc: Successed to send KdEvent\n"); } } //sleep(5); looCnt++; } return KD_NULL; } KDint kdMain(KDint argc, const KDchar *const *argv) { KDThread * pSendThread = KD_NULL; const KDEvent * pRecvEvent = KD_NULL; KDust recvTimeout = -1; pRecvThread = kdThreadSelf(); pSendThread = kdThreadCreate(KD_NULL, &kdSendThreadFun, KD_NULL); if(KD_NULL == pSendThread) { printf("MainThread: Failed to create sub thread, and errCode is:%d\n", kdGetError()); } else { printf("MainThread: Successed to create sub thread\n"); } while ((pRecvEvent = kdWaitEvent(recvTimeout)) != 0) { printf("MainThread: Successed to recv KdEvent\n"); kdDefaultEvent(pRecvEvent); } printf("MainThread: Failed To Receive Event,and the errCode is:%d\n", kdGetError()); return 0; } ------------------------------------------------------------------------ --------------------- This is the result ------------------------------------------------------------------------ --------------------- SubThreadFunc: Enter SubThreadFunc: Successed to create KdEvent MainThread: Successed to create sub thread SubTheadFunc: Failed to send KdEvent, and the errCode is:5 MainThread: Failed To Receive Event,and the errCode is:5 ------------------------------------------------------------------------ --------------------- _______________________________________________ CWM/OpenKODE http://community.qnx.com/sf/go/post31051 Max Feil 2009-06-07T15:42:43Z post31051: Can not get event by kdWaitEvent() liu liming(deleted) http://community.qnx.com/sf/go/post31051 2009-06-07T11:19:42Z 2009-06-07T11:19:42Z Hi,every body. I need to send/receive openkode event in multi thread. I follow the OpenKode1.0.2 and I think my source will be Ok. But it does not work. 1).kdWaitEvent(-1) , err code is KD_EAGAIN (5): In OpenKode1.0.2, this means:The timeout expired while the event queue was empty. 2).kdPostThreadEvent(), err code is KD_EAGAIN (5): In OpenKode1.0.2, this means:Resource unavailable, try again. I think it may be the reason of init of event queue , but I can not found any function to init the queue. How can i do for it, thanks. This is my source code --------------------------------------------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/keycodes.h> #include <time.h> #include <EGL/egl.h> #include <KD/kd.h> #include <GLES/gl.h> KDThread * pRecvThread = KD_NULL; void * kdSendThreadFun(void * arg) { printf("SubThreadFunc: Enter\n"); KDEvent * pSendEvent = KD_NULL; KDint looCnt = 0; while(looCnt < 1) { pSendEvent = kdCreateEvent(); if(KD_NULL == pSendEvent) { printf("SubThreadFunc: Failed to create KdEvent, and the errCode is:%d\n", kdGetError()); } else { printf("SubThreadFunc: Successed to create KdEvent\n"); if(-1 == kdPostThreadEvent(pSendEvent, pRecvThread)) { printf("SubTheadFunc: Failed to send KdEvent, and the errCode is:%d\n", kdGetError()); } else { printf("SubTheadFunc: Successed to send KdEvent\n"); } } //sleep(5); looCnt++; } return KD_NULL; } KDint kdMain(KDint argc, const KDchar *const *argv) { KDThread * pSendThread = KD_NULL; const KDEvent * pRecvEvent = KD_NULL; KDust recvTimeout = -1; pRecvThread = kdThreadSelf(); pSendThread = kdThreadCreate(KD_NULL, &kdSendThreadFun, KD_NULL); if(KD_NULL == pSendThread) { printf("MainThread: Failed to create sub thread, and errCode is:%d\n", kdGetError()); } else { printf("MainThread: Successed to create sub thread\n"); } while ((pRecvEvent = kdWaitEvent(recvTimeout)) != 0) { printf("MainThread: Successed to recv KdEvent\n"); kdDefaultEvent(pRecvEvent); } printf("MainThread: Failed To Receive Event,and the errCode is:%d\n", kdGetError()); return 0; } --------------------------------------------------------------------------------------------- This is the result --------------------------------------------------------------------------------------------- SubThreadFunc: Enter SubThreadFunc: Successed to create KdEvent MainThread: Successed to create sub thread SubTheadFunc: Failed to send KdEvent, and the errCode is:5 MainThread: Failed To Receive Event,and the errCode is:5 --------------------------------------------------------------------------------------------- liu liming(deleted) 2009-06-07T11:19:42Z post31050: Re: failed to kdCreateWindow liu liming(deleted) http://community.qnx.com/sf/go/post31050 2009-06-07T10:38:22Z 2009-06-07T10:38:22Z Thanks every much. I start io-winmgr , and log to the qnx by telent to start my programe.It works. liu liming(deleted) 2009-06-07T10:38:22Z post30943: Re: sysres utility Etienne Belanger(deleted) http://community.qnx.com/sf/go/post30943 2009-06-05T12:18:00Z 2009-06-05T12:18:00Z The documentation refers to the sysres command line option of io-winmgr. Running io-winmgr -sysres--which should be run before starting the io-winmgr resource manager--will give a complete list of EGL configs, display controller devices, ports, and pipelines found on a particular system. Etienne Belanger(deleted) 2009-06-05T12:18:00Z post30930: sysres utility Mate Szarvas http://community.qnx.com/sf/go/post30930 2009-06-05T10:41:48Z 2009-06-05T10:41:48Z The "Configuring io-winmgr" documentation: http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/configuring.html refers to "sysres utility" in the explanation of the display/plane/egl-config parameter. Is there actually a sysres utility or "sysres utility" refers to the -sysres option "io-winmgr -sysres"? Mate Szarvas 2009-06-05T10:41:48Z post30403: Re: failed to kdCreateWindow Etienne Belanger(deleted) http://community.qnx.com/sf/go/post30403 2009-06-01T12:49:23Z 2009-06-01T12:49:23Z kdCreateWindow raises the KD_ENOSYS error if the display argument does not correspond to a composited window system display connection, and the KD_ENOMEM error if it failed to allocate a KDWindow * for the new window. eglGetDisplay(EGL_DEFAULT_DISPLAY) will try to establish a composition manager display connection, and will fallback to the null-windowing system connection with io-winmgr is not running. I suspect you are getting this error because io-winmgr is not running. Etienne Belanger(deleted) 2009-06-01T12:49:23Z post30384: failed to kdCreateWindow liu liming(deleted) http://community.qnx.com/sf/go/post30384 2009-05-31T02:38:58Z 2009-05-31T02:38:58Z Hi,everybody I install Aviage HMI Suite 2.0 and Composition Manager [Patch ID 1347] on Qnx6.4.0, and write a openkode application. But, the function of kdCreateWindow can't work and the error message is "kdCreateWindow not support". 1.The init of EGL is ok 2.My Display Card is : Intel G33, and I select the dirver i830. For this thing , I install the QnxDsp6.4.1 and Aviage HMI Suite 2.0 and failued too. What can I do for it? Thanks every much. liu liming(deleted) 2009-05-31T02:38:58Z post25854: Re: What is CWM? Etienne Belanger(deleted) http://community.qnx.com/sf/go/post25854 2009-04-02T14:41:47Z 2009-04-02T14:41:47Z CWM stands for Composited Windowing Manager. The acronym might be misleading a bit because this refers to a complete composited windowing system, not just a window manager, like PWM. Photon will continue to be QNX's traditional windowing system. However, we will soon be offering a composited windowing system as an alternative. Unlike traditional windowing systems that arbitrate access to a single buffer, a composited windowing system combines off-screen buffers into one image that is displayed. The APIs to communicate with this windowing system are all open specifications, e.g. OpenKODE and EGL. Etienne Belanger(deleted) 2009-04-02T14:41:47Z post25849: What is CWM? Mario Mastrodicasa http://community.qnx.com/sf/go/post25849 2009-04-02T14:29:58Z 2009-04-02T14:29:58Z Hi, I've a question. What is CWM? Is it a replacement for PWM? Where I can found doc, headers, libraries and so on? Mario. Mario Mastrodicasa 2009-04-02T14:29:58Z