Feed for discussion CWM/OpenKODE in project Graphics.Posts for CWM/OpenKODEpost117781: How to Zoom a displayed imgeSrinidhi T N(deleted)http://community.qnx.com/sf/go/post1177812017-06-09T06:04:47Z2017-06-09T06:04:47ZHi,
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:47Zpost113700: RE: Colorspace/Window formats drm-intelAlain Magloirehttp://community.qnx.com/sf/go/post1137002015-04-13T18:08:28Z2015-04-13T18:08:28ZBonjour,
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.comAlain Magloire2015-04-13T18:08:28Zpost113696: Colorspace/Window formats drm-intelKevin Stallard(deleted)http://community.qnx.com/sf/go/post1136962015-04-10T16:50:43Z2015-04-10T16:50:43ZI'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
KevinKevin Stallard(deleted)2015-04-10T16:50:43Zpost113316: pre-processing the window framebuffer before composition manager does the final composition?Shi yun(deleted)http://community.qnx.com/sf/go/post1133162015-02-15T10:55:24Z2015-02-15T10:55:24ZWe 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,
RobinShi yun(deleted)2015-02-15T10:55:24Zpost111879: Re: Alpha Blending w/ OpenGLES and OpenKODEJoel Pilon(deleted)http://community.qnx.com/sf/go/post1118792014-09-25T15:59:35Z2014-09-25T15:59:35ZHi 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.comJoel Pilon(deleted)2014-09-25T15:59:35Zpost111864: Alpha Blending w/ OpenGLES and OpenKODEDavid Beberman(deleted)http://community.qnx.com/sf/go/post1118642014-09-24T08:53:45Z2014-09-24T08:53:45ZHello 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:45Zpost101127: display in multiple processLu Li(deleted)http://community.qnx.com/sf/go/post1011272013-05-03T15:33:28Z2013-05-03T15:33:28ZHi 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,
LuLu Li(deleted)2013-05-03T15:33:28Zpost93511: Re: sysres utilitybhanu shankar d ghttp://community.qnx.com/sf/go/post935112012-06-05T11:40:19Z2012-06-05T11:40:19ZHi
if i run io-winmgr -sysres i am getting memory fault error! why?
Please help.bhanu shankar d g2012-06-05T11:40:19Zpost93490: Re: io-winmgr -sysres : how to use correctly?bhanu shankar d ghttp://community.qnx.com/sf/go/post934902012-06-04T11:49:22Z2012-06-04T11:49:22ZHi,
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 g2012-06-04T11:49:22Zpost93484: Re: Multiple Displaybhanu shankar d ghttp://community.qnx.com/sf/go/post934842012-06-04T09:31:01Z2012-06-04T09:31:01Zhow 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 g2012-06-04T09:31:01Zpost86354: Realizing an (initially) invisible window under CWMGlenn Schmottlachhttp://community.qnx.com/sf/go/post863542011-06-01T20:20:38Z2011-06-01T20:20:38ZI 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 Schmottlach2011-06-01T20:20:38Zpost84416: Re: RE: kdRealizeWindowBjoern Petrihttp://community.qnx.com/sf/go/post844162011-03-30T14:39:50Z2011-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 Petri2011-03-30T14:39:50Zpost84414: RE: kdRealizeWindowEric Fausetthttp://community.qnx.com/sf/go/post844142011-03-30T14:22:37Z2011-03-30T14:22:37ZI 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.
-
EricEric Fausett2011-03-30T14:22:37Zpost84413: kdRealizeWindowBjoern Petrihttp://community.qnx.com/sf/go/post844132011-03-30T14:11:42Z2011-03-30T14:11:42ZHi 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,
BjoernBjoern Petri2011-03-30T14:11:42Zpost73799: Re: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()?JIN YOUNC CHEONhttp://community.qnx.com/sf/go/post737992010-11-08T05:18:38Z2010-11-08T05:18:38ZThanks 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 CHEON2010-11-08T05:18:38Zpost73792: Re: Is there any alternative way to post frame to io-winmgr than
using eglswapbuffer()?Etienne Belanger(deleted)http://community.qnx.com/sf/go/post737922010-11-08T03:17:04Z2010-11-08T03:17:04ZWhat 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:04Zpost73778: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()?JIN YOUNC CHEONhttp://community.qnx.com/sf/go/post737782010-11-06T23:22:58Z2010-11-06T23:22:58ZI 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 CHEON2010-11-06T23:22:58Zpost65421: Re: focus event not received when changing window orderJoel Pilon(deleted)http://community.qnx.com/sf/go/post654212010-09-01T12:54:23Z2010-09-01T12:54:23ZTaking 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:23Zpost65381: focus event not received when changing window orderAdrian Higginshttp://community.qnx.com/sf/go/post653812010-09-01T07:01:14Z2010-09-01T07:01:14ZI 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
AdrianAdrian Higgins2010-09-01T07:01:14Zpost64755: Re: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in
Foundry27Gervais Mulongoyhttp://community.qnx.com/sf/go/post647552010-08-27T13:13:58Z2010-08-27T13:13:58ZThank you for the description.Gervais Mulongoy2010-08-27T13:13:58Zpost64751: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27Etienne Belanger(deleted)http://community.qnx.com/sf/go/post647512010-08-27T12:59:54Z2010-08-27T12:59:54ZThe 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/post64676Etienne Belanger(deleted)2010-08-27T12:59:54Zpost64690: Re: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27Gervais Mulongoyhttp://community.qnx.com/sf/go/post646902010-08-26T20:33:48Z2010-08-26T20:33:48ZScratch 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.htmlGervais Mulongoy2010-08-26T20:33:48Zpost64689: Re: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27Gervais Mulongoyhttp://community.qnx.com/sf/go/post646892010-08-26T20:30:21Z2010-08-26T20:30:21ZFor 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 Mulongoy2010-08-26T20:30:21Zpost64677: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27Joel Pilon(deleted)http://community.qnx.com/sf/go/post646772010-08-26T19:50:26Z2010-08-26T19:50:26ZWith 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/post64676Joel Pilon(deleted)2010-08-26T19:50:26Zpost64676: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27Gervais Mulongoyhttp://community.qnx.com/sf/go/post646762010-08-26T19:45:28Z2010-08-26T19:45:28ZHello,
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.
ThanksGervais Mulongoy2010-08-26T19:45:28Zpost57865: Re: Can we use OpenKODE at VWMARE?Chen ShunLihttp://community.qnx.com/sf/go/post578652010-06-25T02:45:04Z2010-06-25T02:45:04ZI 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 ShunLi2010-06-25T02:45:04Zpost57864: Re: Can we use OpenKODE at VWMARE?Chen ShunLihttp://community.qnx.com/sf/go/post578642010-06-25T02:35:22Z2010-06-25T02:35:22Z1. 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 ShunLi2010-06-25T02:35:22Zpost57863: Re: Can we use OpenKODE at VWMARE?Jason Mawdsleyhttp://community.qnx.com/sf/go/post578632010-06-25T02:30:00Z2010-06-25T02:30:00ZOpenKODE 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 Mawdsley2010-06-25T02:30:00Zpost57862: Re: Can we use OpenKODE at VWMARE?Chen ShunLihttp://community.qnx.com/sf/go/post578622010-06-25T01:44:54Z2010-06-25T01:44:54ZIn 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 ShunLi2010-06-25T01:44:54Zpost57861: Re: Can we use OpenKODE at VWMARE?Jason Mawdsleyhttp://community.qnx.com/sf/go/post578612010-06-25T01:28:24Z2010-06-25T01:28:24ZPlease 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 Mawdsley2010-06-25T01:28:24Zpost57860: Can we use OpenKODE at VWMARE?Chen ShunLihttp://community.qnx.com/sf/go/post578602010-06-25T01:26:31Z2010-06-25T01:26:31Zhi,
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 ShunLi2010-06-25T01:26:31Zpost56586: How to use opengles in photon Mode with VMWareChen ShunLihttp://community.qnx.com/sf/go/post565862010-06-11T05:36:15Z2010-06-11T05:36:15ZI 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 ShunLi2010-06-11T05:36:15Zpost52624: Re: Flash cann't live with multiple windowsshi huaronghttp://community.qnx.com/sf/go/post526242010-04-24T05:34:47Z2010-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 huarong2010-04-24T05:34:47Zpost52623: Flash cann't live with multiple windowsshi huaronghttp://community.qnx.com/sf/go/post526232010-04-24T05:24:12Z2010-04-24T05:24:12ZHello,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 huarong2010-04-24T05:24:12Zpost51055: Re: question about io-winmgrJoel Pilon(deleted)http://community.qnx.com/sf/go/post510552010-04-01T15:18:46Z2010-04-01T15:18:46ZWe 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=exsy1001Joel Pilon(deleted)2010-04-01T15:18:46Zpost51044: Re: question about io-winmgrJason Mawdsleyhttp://community.qnx.com/sf/go/post510442010-04-01T14:13:36Z2010-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 Mawdsley2010-04-01T14:13:36Zpost51012: question about io-winmgrivan chenhttp://community.qnx.com/sf/go/post510122010-04-01T06:33:00Z2010-04-01T06:33:00ZHi, 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 chen2010-04-01T06:33:00Zpost49870: Re: /dev entries for each display sectionGervais Mulongoyhttp://community.qnx.com/sf/go/post498702010-03-18T15:51:09Z2010-03-18T15:51:09ZI have since found out that is not the case. The :0 denotes the id/handle of the instance of io-winmgr.Gervais Mulongoy2010-03-18T15:51:09Zpost49667: /dev entries for each display sectionGervais Mulongoyhttp://community.qnx.com/sf/go/post496672010-03-16T21:03:45Z2010-03-16T21:03:45ZHello 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,
GervaisGervais Mulongoy2010-03-16T21:03:45Zpost49666: Re: winmgr.conf more than one display sectionGervais Mulongoyhttp://community.qnx.com/sf/go/post496662010-03-16T21:01:24Z2010-03-16T21:01:24ZThanks JP - wfd-device is actually needed.Gervais Mulongoy2010-03-16T21:01:24Zpost49619: winmgr.conf more than one display sectionGervais Mulongoyhttp://community.qnx.com/sf/go/post496192010-03-16T15:56:53Z2010-03-16T15:56:53ZHello 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,
GervaisGervais Mulongoy2010-03-16T15:56:53Zpost49549: RE: Howto instruct the flash player to target more than one display at a timePaul Streatchhttp://community.qnx.com/sf/go/post495492010-03-15T22:22:18Z2010-03-15T22:22:18ZNote 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/post49545Paul Streatch2010-03-15T22:22:18Zpost49545: Re: Howto instruct the flash player to target more than one display
at a timeRoger Macleanhttp://community.qnx.com/sf/go/post495452010-03-15T22:01:25Z2010-03-15T22:01:25ZYes, 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 Maclean2010-03-15T22:01:25Zpost49522: Re: Howto instruct the flash player to target more than one display at a timeGervais Mulongoyhttp://community.qnx.com/sf/go/post495222010-03-15T18:50:08Z2010-03-15T18:50:08ZHello 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,
GervaisGervais Mulongoy2010-03-15T18:50:08Zpost49514: Re: Howto instruct the flash player to target more than one display
at a timeJason Mawdsleyhttp://community.qnx.com/sf/go/post495142010-03-15T18:34:27Z2010-03-15T18:34:27ZYou 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 Mawdsley2010-03-15T18:34:27Zpost49512: Re: Howto instruct the flash player to target more than one display
at a timeRoger Macleanhttp://community.qnx.com/sf/go/post495122010-03-15T18:31:51Z2010-03-15T18:31:51ZYes, 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 Maclean2010-03-15T18:31:51Zpost49504: Re: Howto instruct the flash player to target more than one display at a timeGervais Mulongoyhttp://community.qnx.com/sf/go/post495042010-03-15T18:08:51Z2010-03-15T18:08:51ZSo the display setting is used specify which display to target to if there are more than one display available? Is this documented anywhere?Gervais Mulongoy2010-03-15T18:08:51Zpost49503: Re: Howto instruct the flash player to target more than one display at a timePaul Streatchhttp://community.qnx.com/sf/go/post495032010-03-15T17:52:52Z2010-03-15T17:52:52ZI 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/post49501Paul Streatch2010-03-15T17:52:52Zpost49501: Howto instruct the flash player to target more than one display at a timeGervais Mulongoyhttp://community.qnx.com/sf/go/post495012010-03-15T17:47:44Z2010-03-15T17:47:44ZHello 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,
GervaisGervais Mulongoy2010-03-15T17:47:44Zpost46930: eglSwapBuffers and io-winmgrGary Faulknerhttp://community.qnx.com/sf/go/post469302010-02-09T15:48:56Z2010-02-09T15:48:56ZWhat 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 Faulkner2010-02-09T15:48:56Zpost46651: Re: Alpha blending in CWM/OpenKODEEtienne Belanger(deleted)http://community.qnx.com/sf/go/post466512010-02-05T13:36:54Z2010-02-05T13:36:54ZIt will be in the next release, but I cannot say when that will be.Etienne Belanger(deleted)2010-02-05T13:36:54Zpost46603: Re: Alpha blending in CWM/OpenKODERadek Pesinahttp://community.qnx.com/sf/go/post466032010-02-04T22:02:59Z2010-02-04T22:02:59ZThanks 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,
RadekRadek Pesina2010-02-04T22:02:59Zpost46602: Re: Alpha blending in CWM/OpenKODERadek Pesinahttp://community.qnx.com/sf/go/post466022010-02-04T21:51:32Z2010-02-04T21:51:32ZThanks 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 Pesina2010-02-04T21:51:32Zpost46528: Re: Alpha blending in CWM/OpenKODEEtienne Belanger(deleted)http://community.qnx.com/sf/go/post465282010-02-04T14:03:35Z2010-02-04T14:03:35ZThis 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:35Zpost46508: Re: Alpha blending in CWM/OpenKODEEric Fausetthttp://community.qnx.com/sf/go/post465082010-02-04T06:41:54Z2010-02-04T06:41:54ZRadek,
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,
EricEric Fausett2010-02-04T06:41:54Zpost46507: Alpha blending in CWM/OpenKODERadek Pesinahttp://community.qnx.com/sf/go/post465072010-02-04T06:28:22Z2010-02-04T06:28:22ZHi,
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 Pesina2010-02-04T06:28:22Zpost46089: Multiple DisplayYossi Har-Novhttp://community.qnx.com/sf/go/post460892010-01-27T21:55:16Z2010-01-27T21:55:16ZHow 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-Nov2010-01-27T21:55:16Zpost45905: RE: kdSetTimer/kdCancelTimer??Joel Pilon(deleted)http://community.qnx.com/sf/go/post459052010-01-25T22:44:00Z2010-01-25T22:44:00ZCorrect 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/post45903Joel Pilon(deleted)2010-01-25T22:44:00Zpost45903: kdSetTimer/kdCancelTimer??Gary Faulknerhttp://community.qnx.com/sf/go/post459032010-01-25T22:20:16Z2010-01-25T22:20:16ZIt 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 Faulkner2010-01-25T22:20:16Zpost45850: Re: CM/OpenKODE "performance"Etienne Belanger(deleted)http://community.qnx.com/sf/go/post458502010-01-25T13:28:22Z2010-01-25T13:28:22ZYou 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:22Zpost45800: Re: CM/OpenKODE "performance"Joel Pilon(deleted)http://community.qnx.com/sf/go/post458002010-01-22T19:06:21Z2010-01-22T19:06:21ZYou 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:21Zpost45799: Re: CM/OpenKODE "performance"Gary Faulknerhttp://community.qnx.com/sf/go/post457992010-01-22T18:46:11Z2010-01-22T18:46:11Zso, 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 Faulkner2010-01-22T18:46:11Zpost45797: Re: CM/OpenKODE "performance"Gary Faulknerhttp://community.qnx.com/sf/go/post457972010-01-22T18:25:57Z2010-01-22T18:25:57Zheh... helps if I spell pipeline correctly (apparently -- go figure).
So, now my question becomes... do I no longer do eglSwapBuffers()??Gary Faulkner2010-01-22T18:25:57Zpost45795: Re: CM/OpenKODE "performance"Gary Faulknerhttp://community.qnx.com/sf/go/post457952010-01-22T18:09:24Z2010-01-22T18:09:24Zso, 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 Faulkner2010-01-22T18:09:24Zpost45785: Re: CM/OpenKODE "performance"Gary Faulknerhttp://community.qnx.com/sf/go/post457852010-01-22T16:50:45Z2010-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 Faulkner2010-01-22T16:50:45Zpost45783: Re: CM/OpenKODE "performance"Etienne Belanger(deleted)http://community.qnx.com/sf/go/post457832010-01-22T16:39:31Z2010-01-22T16:39:31ZI 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:31Zpost45779: Re: CM/OpenKODE "performance"Gary Faulknerhttp://community.qnx.com/sf/go/post457792010-01-22T15:51:24Z2010-01-22T15:51:24ZHello:
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 Faulkner2010-01-22T15:51:24Zpost45762: Re: CM/OpenKODE "performance"Etienne Belanger(deleted)http://community.qnx.com/sf/go/post457622010-01-22T13:48:53Z2010-01-22T13:48:53ZPlease 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:53Zpost45753: CM/OpenKODE "performance"Gary Faulknerhttp://community.qnx.com/sf/go/post457532010-01-22T12:42:12Z2010-01-22T12:42:12ZI 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 Faulkner2010-01-22T12:42:12Zpost45732: Re: un-flipping images displayed via vgDrawImage()??Gary Faulknerhttp://community.qnx.com/sf/go/post457322010-01-21T23:41:56Z2010-01-21T23:41:56ZNevermind... figured it out with the negative stride stuff.Gary Faulkner2010-01-21T23:41:56Zpost45731: un-flipping images displayed via vgDrawImage()??Gary Faulknerhttp://community.qnx.com/sf/go/post457312010-01-21T23:22:01Z2010-01-21T23:22:01ZSo, 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 Faulkner2010-01-21T23:22:01Zpost45651: Re: CM/OpenKODE image display oddityGary Faulknerhttp://community.qnx.com/sf/go/post456512010-01-21T15:19:28Z2010-01-21T15:19:28ZAs an aside, I also tried this using the openvg calls for images, and I get the same results.Gary Faulkner2010-01-21T15:19:28Zpost45624: CM/OpenKODE image display oddityGary Faulknerhttp://community.qnx.com/sf/go/post456242010-01-21T12:45:54Z2010-01-21T12:45:54ZFirst 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 Faulkner2010-01-21T12:45:54Zpost45375: Re: RE: EGL/KD and direct buffer manipulationGary Faulknerhttp://community.qnx.com/sf/go/post453752010-01-18T11:56:14Z2010-01-18T11:56:14ZActually, 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 Faulkner2010-01-18T11:56:14Zpost45349: Re: RE: EGL/KD and direct buffer manipulationGary Faulknerhttp://community.qnx.com/sf/go/post453492010-01-15T22:12:59Z2010-01-15T22:12:59ZThanks!
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 Faulkner2010-01-15T22:12:59Zpost45331: Re: RE: EGL/KD and direct buffer manipulationEtienne Belanger(deleted)http://community.qnx.com/sf/go/post453312010-01-15T19:25:04Z2010-01-15T19:25:04ZIt 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:04Zpost45312: Re: RE: EGL/KD and direct buffer manipulationGary Faulknerhttp://community.qnx.com/sf/go/post453122010-01-15T16:10:15Z2010-01-15T16:10:15ZThanks! 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 Faulkner2010-01-15T16:10:15Zpost45303: RE: EGL/KD and direct buffer manipulationJoel Pilon(deleted)http://community.qnx.com/sf/go/post453032010-01-15T15:15:45Z2010-01-15T15:15:45ZYou 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/post45284Joel Pilon(deleted)2010-01-15T15:15:45Zpost45289: Re: EGL/KD and direct buffer manipulationEtienne Belanger(deleted)http://community.qnx.com/sf/go/post452892010-01-15T13:56:01Z2010-01-15T13:56:01ZThe 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:01Zpost45284: EGL/KD and direct buffer manipulationGary Faulknerhttp://community.qnx.com/sf/go/post452842010-01-15T13:18:47Z2010-01-15T13:18:47ZFirst, 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?
-garyfGary Faulkner2010-01-15T13:18:47Zpost44595: Re: CWM/OpenKODE/GF questionGary Faulknerhttp://community.qnx.com/sf/go/post445952010-01-05T18:45:31Z2010-01-05T18:45:31Zjust 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 Faulkner2010-01-05T18:45:31Zpost44580: CWM/OpenKODE/GF questionGary Faulknerhttp://community.qnx.com/sf/go/post445802010-01-05T16:34:56Z2010-01-05T16:34:56ZHello:
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!
-garyfGary Faulkner2010-01-05T16:34:56Zpost44292: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BITGary Faulknerhttp://community.qnx.com/sf/go/post442922009-12-22T14:55:45Z2009-12-22T14:55:45ZAwesome! Thanks.. that works.Gary Faulkner2009-12-22T14:55:45Zpost44288: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BITEtienne Belanger(deleted)http://community.qnx.com/sf/go/post442882009-12-22T14:49:17Z2009-12-22T14:49:17ZI 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:17Zpost44286: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BITGary Faulknerhttp://community.qnx.com/sf/go/post442862009-12-22T14:44:43Z2009-12-22T14:44:43ZYou 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 Faulkner2009-12-22T14:44:43Zpost44274: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BITEtienne Belanger(deleted)http://community.qnx.com/sf/go/post442742009-12-22T13:52:18Z2009-12-22T13:52:18ZIf 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:18Zpost44273: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BITGary Faulknerhttp://community.qnx.com/sf/go/post442732009-12-22T13:49:02Z2009-12-22T13:49:02ZHello:
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 Faulkner2009-12-22T13:49:02Zpost44121: Re: touchscreen events in gles1-kd-gears demo appGary Faulknerhttp://community.qnx.com/sf/go/post441212009-12-18T14:31:08Z2009-12-18T14:31:08ZI 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 Faulkner2009-12-18T14:31:08Zpost44072: Re: touchscreen events in gles1-kd-gears demo appGary Faulknerhttp://community.qnx.com/sf/go/post440722009-12-17T20:51:03Z2009-12-17T20:51:03ZYup... 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 Faulkner2009-12-17T20:51:03Zpost44071: Re: touchscreen events in gles1-kd-gears demo appEtienne Belanger(deleted)http://community.qnx.com/sf/go/post440712009-12-17T20:45:42Z2009-12-17T20:45:42ZSome 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:42Zpost44067: Re: RE: RE: touchscreen events in gles1-kd-gears demo appGary Faulknerhttp://community.qnx.com/sf/go/post440672009-12-17T20:37:53Z2009-12-17T20:37:53ZThanks, 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 Faulkner2009-12-17T20:37:53Zpost44066: RE: RE: touchscreen events in gles1-kd-gears demo appJoel Pilon(deleted)http://community.qnx.com/sf/go/post440662009-12-17T20:31:50Z2009-12-17T20:31:50ZYou 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:50Zpost44063: Re: RE: touchscreen events in gles1-kd-gears demo appGary Faulknerhttp://community.qnx.com/sf/go/post440632009-12-17T20:14:38Z2009-12-17T20:14:38ZAhh.. 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 Faulkner2009-12-17T20:14:38Zpost44052: RE: touchscreen events in gles1-kd-gears demo appJoel Pilon(deleted)http://community.qnx.com/sf/go/post440522009-12-17T19:52:59Z2009-12-17T19:52:59ZYou 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/post44051Joel Pilon(deleted)2009-12-17T19:52:59Zpost44051: touchscreen events in gles1-kd-gears demo appGary Faulknerhttp://community.qnx.com/sf/go/post440512009-12-17T19:39:56Z2009-12-17T19:39:56ZHello:
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!!
-garyfGary Faulkner2009-12-17T19:39:56Zpost39741: Re: Screen captureJoel Pilon(deleted)http://community.qnx.com/sf/go/post397412009-10-12T19:14:19Z2009-10-12T19:14:19ZUnfortunately, 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:19Zpost38499: Screen captureChirag Shah(deleted)http://community.qnx.com/sf/go/post384992009-09-22T16:58:18Z2009-09-22T16:58:18ZIs there a command line way to capture the screen and save to a file?Chirag Shah(deleted)2009-09-22T16:58:18Zpost35967: Re: the problem about create windows by threadhu xiaohuahttp://community.qnx.com/sf/go/post359672009-08-14T00:46:35Z2009-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 xiaohua2009-08-14T00:46:35Zpost35907: Re: help with CM when using GFEtienne Belanger(deleted)http://community.qnx.com/sf/go/post359072009-08-13T13:22:56Z2009-08-13T13:22:56ZWhen 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:56Zpost35893: Re: the problem about create windows by threadEtienne Belanger(deleted)http://community.qnx.com/sf/go/post358932009-08-13T12:25:29Z2009-08-13T12:25:29ZThe 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:29Zpost35873: help with CM when using GFAdrian Higginshttp://community.qnx.com/sf/go/post358732009-08-13T06:28:55Z2009-08-13T06:28:55ZHowdy
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
AdrianAdrian Higgins2009-08-13T06:28:55Zpost35869: Re: the problem about create windows by threadhu xiaohuahttp://community.qnx.com/sf/go/post358692009-08-13T02:26:23Z2009-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 xiaohua2009-08-13T02:26:23Zpost35867: the problem about create windows by threadhu xiaohuahttp://community.qnx.com/sf/go/post358672009-08-13T01:49:22Z2009-08-13T01:49:22ZI 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 xiaohua2009-08-13T01:49:22Zpost35202: Re: Some questions about the HMI flash and the video windowEtienne Belanger(deleted)http://community.qnx.com/sf/go/post352022009-08-04T19:00:52Z2009-08-04T19:00:52ZThe 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:52Zpost35124: Some questions about the HMI flash and the video windowhu xiaohuahttp://community.qnx.com/sf/go/post351242009-08-02T11:58:10Z2009-08-02T11:58:10ZHi,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 xiaohua2009-08-02T11:58:10Zpost34875: The event of KD_QNX_WINDOWPROPERTY_POSITION handledhu xiaohuahttp://community.qnx.com/sf/go/post348752009-07-30T06:56:14Z2009-07-30T06:56:14ZI 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 xiaohua2009-07-30T06:56:14Zpost34786: Re: Post event to a window that created by another applicationhu xiaohuahttp://community.qnx.com/sf/go/post347862009-07-29T13:35:03Z2009-07-29T13:35:03ZI'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 xiaohua2009-07-29T13:35:03Zpost34781: Re: Post event to a window that created by another applicationEtienne Belanger(deleted)http://community.qnx.com/sf/go/post347812009-07-29T12:46:47Z2009-07-29T12:46:47ZYes, 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.htmlEtienne Belanger(deleted)2009-07-29T12:46:47Zpost34760: Re: Post event to a window that created by another applicationhu xiaohuahttp://community.qnx.com/sf/go/post347602009-07-29T00:54:19Z2009-07-29T00:54:19ZI'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 xiaohua2009-07-29T00:54:19Zpost34741: Re: Post event to a window that created by another applicationEtienne Belanger(deleted)http://community.qnx.com/sf/go/post347412009-07-28T16:12:33Z2009-07-28T16:12:33ZThese events come from the windowing system.Etienne Belanger(deleted)2009-07-28T16:12:33Zpost34733: Re: Post event to a window that created by another applicationhu xiaohuahttp://community.qnx.com/sf/go/post347332009-07-28T15:15:44Z2009-07-28T15:15:44ZI 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 xiaohua2009-07-28T15:15:44Zpost34700: Re: Post event to a window that created by another applicationEtienne Belanger(deleted)http://community.qnx.com/sf/go/post347002009-07-28T12:23:21Z2009-07-28T12:23:21ZNormally, 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:21Zpost34694: Post event to a window that created by another applicationhu xiaohuahttp://community.qnx.com/sf/go/post346942009-07-28T11:55:14Z2009-07-28T11:55:14ZHi,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 xiaohua2009-07-28T11:55:14Zpost34604: Re: The HMI interact with applicationsEtienne Belanger(deleted)http://community.qnx.com/sf/go/post346042009-07-27T12:57:42Z2009-07-27T12:57:42ZThe 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:42Zpost34594: The HMI interact with applicationshu xiaohuahttp://community.qnx.com/sf/go/post345942009-07-27T06:11:15Z2009-07-27T06:11:15ZHi,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 xiaohua2009-07-27T06:11:15Zpost32385: Re: Failed to post event by kdPostWindowEventQNXhu xiaohuahttp://community.qnx.com/sf/go/post323852009-06-24T00:53:27Z2009-06-24T00:53:27ZThank you very much !
I have soult out the question with your help!hu xiaohua2009-06-24T00:53:27Zpost32318: Re: Failed to post event by kdPostWindowEventQNXEtienne Belanger(deleted)http://community.qnx.com/sf/go/post323182009-06-23T14:57:30Z2009-06-23T14:57:30ZkdPostWindowEventQNX 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:30Zpost32300: Failed to post event by kdPostWindowEventQNXhu xiaohuahttp://community.qnx.com/sf/go/post323002009-06-23T13:44:24Z2009-06-23T13:44:24ZHi, 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 xiaohua2009-06-23T13:44:24Zpost31760: Re: RE: RE: Bulid error : OpenKode,OpenVGDennis Kelllyhttp://community.qnx.com/sf/go/post317602009-06-15T16:13:57Z2009-06-15T16:13:57ZRegarding 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 Kellly2009-06-15T16:13:57Zpost31602: Re: How to kill sub_thread in OpenKode??Etienne Belanger(deleted)http://community.qnx.com/sf/go/post316022009-06-12T12:36:37Z2009-06-12T12:36:37ZkdPostThreadEvent 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:37Zpost31583: Re: How to kill sub_thread in OpenKode??Yin Xingminhttp://community.qnx.com/sf/go/post315832009-06-12T02:20:23Z2009-06-12T02:20:23ZYes. 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,
YinYin Xingmin2009-06-12T02:20:23Zpost31481: Re: How to kill sub_thread in OpenKode??Etienne Belanger(deleted)http://community.qnx.com/sf/go/post314812009-06-11T13:35:56Z2009-06-11T13:35:56ZNot 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:56Zpost31479: Re: How to kill sub_thread in OpenKode??Yin Xingminhttp://community.qnx.com/sf/go/post314792009-06-11T13:31:33Z2009-06-11T13:31:33ZThank 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,
YinYin Xingmin2009-06-11T13:31:33Zpost31470: Re: How to kill sub_thread in OpenKode??Etienne Belanger(deleted)http://community.qnx.com/sf/go/post314702009-06-11T12:44:05Z2009-06-11T12:44:05ZAs 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:05Zpost31463: Re: RE: RE: Bulid error : OpenKode,OpenVGliu liming(deleted)http://community.qnx.com/sf/go/post314632009-06-11T11:50:49Z2009-06-11T11:50:49ZHi,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/post31173liu liming(deleted)2009-06-11T11:50:49Zpost31461: How to kill sub_thread in OpenKode??Yin Xingminhttp://community.qnx.com/sf/go/post314612009-06-11T09:18:52Z2009-06-11T09:18:52ZHi,
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 Xingmin2009-06-11T09:18:52Zpost31327: RE: RE: Bulid error : OpenKode,OpenVGGaétan Noëlhttp://community.qnx.com/sf/go/post313272009-06-10T12:55:27Z2009-06-10T12:55:27ZHi 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/post31173Gaétan Noël2009-06-10T12:55:27Zpost31324: RE: RE: setting bit depth for OpenVG flash-player via composition manager?Roger Macleanhttp://community.qnx.com/sf/go/post313242009-06-10T12:41:03Z2009-06-10T12:41:03ZYes, you should find they change significantly before and after
io-winmgr is running.Roger Maclean2009-06-10T12:41:03Zpost31315: Re: RE: setting bit depth for OpenVG flash-player via composition manager?Mate Szarvashttp://community.qnx.com/sf/go/post313152009-06-10T11:54:18Z2009-06-10T11:54:18ZOhhh! 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 Szarvas2009-06-10T11:54:18Zpost31308: Re: Can not get event by kdWaitEvent()liu liming(deleted)http://community.qnx.com/sf/go/post313082009-06-10T10:02:41Z2009-06-10T10:02:41ZOK, 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:41Zpost31198: RE: setting bit depth for OpenVG flash-player via composition manager?Roger Macleanhttp://community.qnx.com/sf/go/post311982009-06-09T13:27:05Z2009-06-09T13:27:05ZNo 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 Maclean2009-06-09T13:27:05Zpost31177: Re: egl-config value corresponding to a particular layerMate Szarvashttp://community.qnx.com/sf/go/post311772009-06-09T03:54:11Z2009-06-09T03:54:11ZEtienne, thanks for these answers (in all threads), this should let us go forward.
--
MateMate Szarvas2009-06-09T03:54:11Zpost31176: Re: setting bit depth for OpenVG flash-player via composition manager?Mate Szarvashttp://community.qnx.com/sf/go/post311762009-06-09T03:32:23Z2009-06-09T03:32:23ZTried 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 Szarvas2009-06-09T03:32:23Zpost31175: Re: setting bit depth for OpenVG flash-player via composition manager?Mate Szarvashttp://community.qnx.com/sf/go/post311752009-06-09T03:00:45Z2009-06-09T03:00:45ZThank 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)
--
MateMate Szarvas2009-06-09T03:00:45Zpost31173: Re: RE: Bulid error : OpenKode,OpenVGliu liming(deleted)http://community.qnx.com/sf/go/post311732009-06-09T01:56:50Z2009-06-09T01:56:50ZHi 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 Limingliu liming(deleted)2009-06-09T01:56:50Zpost31078: Re: Estimating image-bus bandwidth usage in CWMEtienne Belanger(deleted)http://community.qnx.com/sf/go/post310782009-06-08T13:51:35Z2009-06-08T13:51:35ZFor 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:35Zpost31076: RE: Bulid error : OpenKode,OpenVGGaétan Noëlhttp://community.qnx.com/sf/go/post310762009-06-08T13:42:08Z2009-06-08T13:42:08ZHi 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/post31070Gaétan Noël2009-06-08T13:42:08Zpost31074: Re: io-winmgr -sysres : how to use correctly?Etienne Belanger(deleted)http://community.qnx.com/sf/go/post310742009-06-08T13:30:43Z2009-06-08T13:30:43ZIn 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:43Zpost31073: Re: Can not get event by kdWaitEvent()Etienne Belanger(deleted)http://community.qnx.com/sf/go/post310732009-06-08T13:22:54Z2009-06-08T13:22:54ZRight 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:54Zpost31072: Re: egl-config value corresponding to a particular layerEtienne Belanger(deleted)http://community.qnx.com/sf/go/post310722009-06-08T13:20:22Z2009-06-08T13:20:22ZEGL_LEVEL represents the layer number.Etienne Belanger(deleted)2009-06-08T13:20:22Zpost31071: Bulid error : OpenKode,OpenVGliu liming(deleted)http://community.qnx.com/sf/go/post310712009-06-08T13:16:50Z2009-06-08T13:16:50ZHi,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:50Zpost31070: Bulid error : OpenKode,OpenVGliu liming(deleted)http://community.qnx.com/sf/go/post310702009-06-08T13:14:20Z2009-06-08T13:14:20ZHi,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:20Zpost31068: Re: setting bit depth for OpenVG flash-player via composition manager?Roger Macleanhttp://community.qnx.com/sf/go/post310682009-06-08T13:04:15Z2009-06-08T13:04:15ZIf 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 Maclean2009-06-08T13:04:15Zpost31062: setting bit depth for OpenVG flash-player via composition manager?Mate Szarvashttp://community.qnx.com/sf/go/post310622009-06-08T09:32:52Z2009-06-08T09:32:52ZWhen 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 Szarvas2009-06-08T09:32:52Zpost31061: Estimating image-bus bandwidth usage in CWMMate Szarvashttp://community.qnx.com/sf/go/post310612009-06-08T08:45:03Z2009-06-08T08:45:03ZIn 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 Szarvas2009-06-08T08:45:03Zpost31060: egl-config value corresponding to a particular layerMate Szarvashttp://community.qnx.com/sf/go/post310602009-06-08T07:49:06Z2009-06-08T07:49:06ZWe 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 Szarvas2009-06-08T07:49:06Zpost31059: io-winmgr -sysres : how to use correctly?Mate Szarvashttp://community.qnx.com/sf/go/post310592009-06-08T07:40:02Z2009-06-08T07:40:02ZWe 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 Szarvas2009-06-08T07:40:02Zpost31053: RE: Can not get event by kdWaitEvent()Max Feilhttp://community.qnx.com/sf/go/post310532009-06-07T15:42:43Z2009-06-07T15:42:43ZI 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/post31051Max Feil2009-06-07T15:42:43Zpost31051: Can not get event by kdWaitEvent()liu liming(deleted)http://community.qnx.com/sf/go/post310512009-06-07T11:19:42Z2009-06-07T11:19:42ZHi,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:42Zpost31050: Re: failed to kdCreateWindowliu liming(deleted)http://community.qnx.com/sf/go/post310502009-06-07T10:38:22Z2009-06-07T10:38:22ZThanks 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:22Zpost30943: Re: sysres utilityEtienne Belanger(deleted)http://community.qnx.com/sf/go/post309432009-06-05T12:18:00Z2009-06-05T12:18:00ZThe 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:00Zpost30930: sysres utilityMate Szarvashttp://community.qnx.com/sf/go/post309302009-06-05T10:41:48Z2009-06-05T10:41:48ZThe "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 Szarvas2009-06-05T10:41:48Zpost30403: Re: failed to kdCreateWindowEtienne Belanger(deleted)http://community.qnx.com/sf/go/post304032009-06-01T12:49:23Z2009-06-01T12:49:23ZkdCreateWindow 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:23Zpost30384: failed to kdCreateWindowliu liming(deleted)http://community.qnx.com/sf/go/post303842009-05-31T02:38:58Z2009-05-31T02:38:58ZHi,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:58Zpost25854: Re: What is CWM?Etienne Belanger(deleted)http://community.qnx.com/sf/go/post258542009-04-02T14:41:47Z2009-04-02T14:41:47ZCWM 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:47Zpost25849: What is CWM?Mario Mastrodicasahttp://community.qnx.com/sf/go/post258492009-04-02T14:29:58Z2009-04-02T14:29:58ZHi,
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 Mastrodicasa2009-04-02T14:29:58Z