Feed for discussion CWM/OpenKODE in project Graphics.

post117781: How to Zoom a displayed imge

Srinidhi T N(deleted) — Fri, 09 Jun 2017 06:04:47 GMT

Hi,

I am looking for information on how to implement a zoom method. I referred Screen Graphics Subsystem Developer's guide. Could not find much explanation on how to implement zoom function. Could you please point to the document or some snippet of example code would help.

Thanks in advance.

Regards,

Srinidhi.

post113700: RE: Colorspace/Window formats drm-intel

Alain Magloire — Mon, 13 Apr 2015 18:08:28 GMT

Bonjour,

The intel-drm wfd is not supporting RGB888

Thanks

-----Original Message-----

From: Kevin Stallard [mailto:community-noreply@qnx.com]

Sent: April-10-15 12:51 PM

To: cwm-graphics

Subject: Colorspace/Window formats drm-intel

I'm using QNX 6.6, drm-intel and screen. I've put rgb888 as the format for the frame buffer of our 1080p display, yet I am unable to create a window using SCREEN_FORMAT_RGB888 as the window format. Get an error saying it is not supported.

It will only work with RGBA8888 or RGBX8888.

I'm using the render buffers directly with a video capture system so that we can get real-time video. I would like to avoid any transformations that slow things down too much and so if possible would like to go directly from 24bit RBG to 24bit RGB.

Is there a way get get screen to give me a window using SCREEN_FORMAT_RGB888 so that the render buffers use 24 bits?

Thanks

Kevin

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post113696

To cancel your subscription to this discussion, please e-mail cwm-graphics-unsubscribe@community.qnx.com

post113696: Colorspace/Window formats drm-intel

Kevin Stallard(deleted) — Fri, 10 Apr 2015 16:50:43 GMT

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

post113316: pre-processing the window framebuffer before composition manager does the final composition?

Shi yun(deleted) — Sun, 15 Feb 2015 10:55:24 GMT

We are developing application using QML/Qt on SDP6.6. We'd like to blur the underlying window content when another window is at foreground. Which means the foreground window is semi transparent and the background window is visible and gaussian blur(like MS Windows 7 Aero effect).

We wanted that the background window content keeps updating even if it is at background.

Is it possible to do one extra step to do gaussian blur for the background framebuffer before it is overlayed by the composition manager? Thanks in advance.

- In graphics.conf, there is only one pipeline available.

- the background window and foreground window MAY belong to different process(PID). Or MAY belong to same process.

Br,

Robin

post111879: Re: Alpha Blending w/ OpenGLES and OpenKODE

Joel Pilon(deleted) — Thu, 25 Sep 2014 15:59:35 GMT

Hi David,

Unfortunately, any relevant details ‎have faded from my mind. You may need to follow up with QNX Support to get the issue sorted.

-Joel

Original Message

From: David Beberman

Sent: Wednesday, September 24, 2014 4:53 AM

To: cwm-graphics

Reply To: cwm-graphics@community.qnx.com

Subject: Alpha Blending w/ OpenGLES and OpenKODE

Hello everybody,

we have an issue using QNX 6.5's OpenKODE Driver for OpenGLES (both 1.1 and 2.0)

Our test case basically is:

- Create EGL Display and Configuration

- Create OpenKODE Context on top of it

- Paint a green Fullscreen Rectangle and a smaller, semi-translucent blue rectangle

=> The blue (getting dark cyan) rectangle also changes background transparency so you can see the layers behind that application

Doing the same steps with a Screen Context instead shows exactly what one would expect: A opaque dark cyan rectangle with green surroundings.

I've attached the test application.

Any idea?

Specific information needed?

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post111864

To cancel your subscription to this discussion, please e-mail cwm-graphics-unsubscribe@community.qnx.com

post111864: Alpha Blending w/ OpenGLES and OpenKODE

David Beberman(deleted) — Wed, 24 Sep 2014 08:53:45 GMT

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?

post101127: display in multiple process

Lu Li(deleted) — Fri, 03 May 2013 15:33:28 GMT

Hi there,

I am new to QNX and CWM. Now I am working on a project to display using both opengles and QT in separate processes, and now either of them works ok. My opengles uses egl and gf (according to the documentation now) and QT uses pure gf (as far as I understand). My current solution is to use CWM to integrate them.

my opengl initial code is similar to:

http://code.google.com/p/glues/source/browse/trunk/glues/qnx/tests/nurbs/nurbs.c?r=27

I tried a few configurations for winmgr.conf including something like this one:

begin display

begin plane

egl-config = 1

wfd-pipeline = 1

end plane

end display

When I started the io-winmgr and tried to start my opegl exe, my code will fail in gf_layer_attach.

I looked at the demo and tutorial in the forum download, and tried the gear demo for egl (it seems that no gf calls in the demo), and it failed at very beginning when trying to do eglGetDisplay (returning null).

My question will be:

Is CWM the right solution to run both QT and my program. if answer is yes, can I run the code in the above link with modifying the winmgr.conf? if not, what else shall I change in the code?

Thanks,

Lu

post93511: Re: sysres utility

bhanu shankar d g — Tue, 05 Jun 2012 11:40:19 GMT

Hi

if i run io-winmgr -sysres i am getting memory fault error! why?

Please help.

post93490: Re: io-winmgr -sysres : how to use correctly?

bhanu shankar d g — Mon, 04 Jun 2012 11:49:22 GMT

Hi,

my io-winmgr -sysres is giving an error as Memory fault.

my winmgr.conf file is attached.

please help.i dont know why i am getting this error!

post93484: Re: Multiple Display

bhanu shankar d g — Mon, 04 Jun 2012 09:31:01 GMT

how did you configure for single display? i am getting an error as memory fault when i try to run io-winmgr with sysres option.

i.e

my command line is as follows

io-winmgr -start -sysres /abc.txt.

my winmgr.conf is present in /etc/system/config directory.

please help.

post86354: Realizing an (initially) invisible window under CWM

Glenn Schmottlach — Wed, 01 Jun 2011 20:20:38 GMT

I need to create an initially *invisible* window in OpenKode so that when my application starts to run this window is not initially visible. From the documentation that I've read the call to

kdRealizeWindow(kd_win, &egl_win)

by default always makes the window visible (this is not what I want). I tried making a call to set the window "visibility" property prior to making this call:

KDboolean visible = KD_FALSE;

kdGetWindowPropertybv(kd_win, KD_WINDOWPROPERTY_VISIBILITY, &visible);

but I still see this window visible until I explicitly (later) through my delegate window force it to become invisible. Is there some trick I'm not aware of to configure this window so it's initially realized as invisible?

Thanks . . .

post84416: Re: RE: kdRealizeWindow

Bjoern Petri — Wed, 30 Mar 2011 14:39:50 GMT

> 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.

post84414: RE: kdRealizeWindow

Eric Fausett(deleted) — Wed, 30 Mar 2011 14:22:37 GMT

I haven't worked on the Beagleboard, but I'll offer a shot in the dark.

The memory in question isn't just any memory, but it will most likely be

requesting a physically contiguous block from what is available at the

time. If you are relatively low on memory, or if physical memory is

fragmented you will get this error.

-

Eric

post84413: kdRealizeWindow

Bjoern Petri — Wed, 30 Mar 2011 14:11:42 GMT

Hi everyone,

I try to run an OpenKode application on top of a beagle board xM by using the foundry 27 Beagleboard-xM Support Package. Unfortunately kdRealizeWindow always returns an ENOMEM-error. Hence it seems that it doesn't have enough memory

Has anyone succeeded in running OpenKode applications on the Beagleboard-xM and might give me some hints, which configuration I need?

Thanks in advance,

Bjoern

post73799: Re: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()?

JIN YOUNC CHEON — Mon, 08 Nov 2010 05:18:38 GMT

Thanks in advance.

What does conventional drawing under no io-winmgr mean, exactly ?

What I meant by conventional drawing is drawing only using GF APIs like following.

gf_dev_attach();

gf_display_attach();

gf_layer_attach();

gf_surface_create_layer();

gf_context_create();

gf_context_set_surface(context, surface);

while(1){

gf_draw_begin(context);

drawing_routine();

gf_draw_end(context);

}

On contrast, if I draw using egl APIs under io-winmgr, it was much slower. The code briefly looks like following.

eglGetDisplay();

eglInitialize();

eglCreateWindowSurface();

gf_context_create();

gf_context_init();

gf_context_set_surface_3d();

while(1){

gf_draw_begin(context);

drawing_routine();

gf_draw_end(context);

eglbufferswap();

}

What is the hardware ?

We are using i.mx31 lit version(which doesn't have MBX). I have tested over VMWare. Other engineer in my team tested over i.mx31 and showed eglbufferswap() consumes much time.

What are the settings in winmgr.conf ?

begin globals

input = all

end globals

begin display

cursor = sw-arrow

begin plane

egl-config = auto

end plane

end display

Why is CWM necessary in your current design ?

Our graphic provides 2 physical layers. We needed more layers so we use software layers provided from io-winmgr.

post73792: Re: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()?

Etienne Belanger(deleted) — Mon, 08 Nov 2010 03:17:04 GMT

What does conventional drawing under no io-winmgr mean, exactly ?

What is the hardware ?

What are the settings in winmgr.conf ?

Why is CWM necessary in your current design ?

post73778: Is there any alternative way to post frame to io-winmgr than using eglswapbuffer()?

JIN YOUNC CHEON — Sat, 06 Nov 2010 23:22:58 GMT

I have tested drawing performance with gf-egl-vsync demo. Test result shows conventional drawing under no io-winmgr is much faster than doing under io-winmgr. It was 6 times faster.

I suspect posting new frame using eglswapbuffer() to io-winmgr makes this difference in drawing time.

Using CWM is necessary to current design. Is there any alternative way which works faster to post frame to io-winmgr than using eglswapbuffer()?

post65421: Re: focus event not received when changing window order

Joel Pilon(deleted) — Wed, 01 Sep 2010 12:54:23 GMT

Taking a quick peek at the source, it looks like we either missed that case, or decided against that behavior. You could try manually setting focus to the window your raising.

post65381: focus event not received when changing window order

Adrian Higgins — Wed, 01 Sep 2010 07:01:14 GMT

I and using kdSetWindowOrderQNX() to set the current application to the top.

This works really well and I receive KD_EVENT_INPUT_POINTER events when I’m on top, and not when I’m on bottom. However I do not receive KD_EVENT_WINDOW_FOCUS events, so do not know when I have lost focus.

Does a KD_EVENT_WINDOW_FOCUS (or even an Z_ORDER_CHANGED) event get firesd when the window order is changed using kdSetWindowOrderQNX()?

Cheers

Adrian

post64755: Re: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Gervais Mulongoy — Fri, 27 Aug 2010 13:13:58 GMT

Thank you for the description.

post64751: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Etienne Belanger(deleted) — Fri, 27 Aug 2010 12:59:54 GMT

The freeze property suspends the handling of posts from a window.

Therefore, eglSwapBuffers will block when it runs out of buffers. After

the first post, the client only has 1 buffer, so setting a freeze will

cause eglSwapBuffers to block until the freeze is removed. The property

was added as a big hammer for delegates that want to stop apps from

updating. Not as a way of getting atomic operations. We implemented some

form of atomic operations, probably on a different branch.

-Etienne Belanger

-----Original Message-----

From: Gervais Mulongoy [mailto:community-noreply@qnx.com]

Sent: August 26, 2010 3:45 PM

To: cwm-graphics

Subject: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in

Foundry27

Hello,

The customer is trying to implement a smooth scrolling algorithm where

they need to swap buffers and change window properties such as

KD_WINDOWPROPERTY_SOURCE_POSITION_QNX in one step without intermediate

states becoming visible on the display (basically they want the algo to

be atomic). To that end, they began testing and ran into an issue that

can be distilled into the test case below.

They use the following steps in a test program (ie. gles1-kd-gears) in a

loop:

1) Render something

2) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX,

true)

3) Call eglSwapBuffers()

4) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX,

false)

The first iteration of the loop behaves as expected (the display stays

black), but any subsequent iteration eglSwapBuffers() doesn't return,

and the process becomes unresponsive.

My first question, is it correct to use the freeze property in the way

described above?

Second, since this is a patch on F27, is the freeze property fully

implemented in the patch?

Third, do we have any other (better) mechanisms they could use to

implement their smooth scrolling?

My apologies if this is already documented somewhere and I missed the

obvious.

Thanks

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post64676

post64690: Re: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Gervais Mulongoy — Thu, 26 Aug 2010 20:33:48 GMT

Scratch that, it is documented here:

http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=/com.qnx.doc.composition_manager_dev_guide/kd_qnx_window.html

post64689: Re: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Gervais Mulongoy — Thu, 26 Aug 2010 20:30:21 GMT

For sake of having this written down, what exactly does that freeze property do and why does it cause this issue when used with eglSwapBuffers()?

post64677: RE: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Joel Pilon(deleted) — Thu, 26 Aug 2010 19:50:26 GMT

With that version of CM it's not possible to atomically update window properties with a post.

-Joel

-----Original Message-----

From: Gervais Mulongoy [mailto:community-noreply@qnx.com]

Sent: Thu 8/26/2010 3:45 PM

To: cwm-graphics

Subject: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Hello,

The customer is trying to implement a smooth scrolling algorithm where they need to swap buffers and change window properties such as KD_WINDOWPROPERTY_SOURCE_POSITION_QNX in one step without intermediate states becoming visible on the display (basically they want the algo to be atomic). To that end, they began testing and ran into an issue that can be distilled into the test case below.

They use the following steps in a test program (ie. gles1-kd-gears) in a loop:

1) Render something

2) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, true)

3) Call eglSwapBuffers()

4) Call kdSetWindowPropertybv(window, KD_WINDOWPROPERTY_FREEZE_QNX, false)

The first iteration of the loop behaves as expected (the display stays black), but any subsequent iteration eglSwapBuffers() doesn't return, and the process becomes unresponsive.

My first question, is it correct to use the freeze property in the way described above?

Second, since this is a patch on F27, is the freeze property fully implemented in the patch?

Third, do we have any other (better) mechanisms they could use to implement their smooth scrolling?

My apologies if this is already documented somewhere and I missed the obvious.

Thanks

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post64676

post64676: Using KD_WINDOWPROPERTY_FREEZE_QNX with patch 1.5.15.2856 in Foundry27

Gervais Mulongoy — Thu, 26 Aug 2010 19:45:28 GMT

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

post57865: Re: Can we use OpenKODE at VWMARE?

Chen ShunLi — Fri, 25 Jun 2010 02:45:04 GMT

I am sorry for disordered information. I add them to Excel file. Please
check it.
Thanks
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------

post57864: Re: Can we use OpenKODE at VWMARE?

Chen ShunLi — Fri, 25 Jun 2010 02:35:22 GMT

1. Photon Mode:
   +-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+
| config id | caveat | red | green | blue | luminance | alpha | depth |
stencil | samples | window | pbuffer | pixmap | gles1 | gles2 | vg | gl |
native | level |
+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+
|         1 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         2 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         3 |  none  |   8 |     8 |    8 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         4 |  none  |   5 |     6 |    5 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         5 |  none  |   5 |     5 |    5 |         0 |     1 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         6 |  none  |   0 |     0 |    0 |         8 |     0 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         7 |  slow  |   8 |     8 |    8 |         0 |     8 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|         8 |  slow  |   8 |     8 |    8 |         0 |     8 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|         9 |  slow  |   8 |     8 |    8 |         0 |     8 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        10 |  slow  |   8 |     8 |    8 |         0 |     8 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        11 |  slow  |   8 |     8 |    8 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        12 |  slow  |   8 |     8 |    8 |         0 |     0 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        13 |  slow  |   8 |     8 |    8 |         0 |     0 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        14 |  slow  |   8 |     8 |    8 |         0 |     0 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        15 |  slow  |   5 |     6 |    5 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        16 |  slow  |   5 |     5 |    5 |         0 |     1 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        17 |  slow  |   5 |     6 |    5 |         0 |     0 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        18 |  slow  |   5 |     5 |    5 |         0 |     1 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        19 |  slow  |   5 |     6 |    5 |         0 |     0 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        20 |  slow  |   5 |     5 |    5 |         0 |     1 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        21 |  slow  |   5 |     6 |    5 |         0 |     0 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        22 |  slow  |   5 |     5 |    5 |         0 |     1 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+

2. Text Mode
+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+
| config id | caveat | red | green | blue | luminance | alpha | depth |
stencil | samples | window | pbuffer | pixmap | gles1 | gles2 | vg | gl |
native | level |
+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+
|         1 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |
0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |
0 |
|         2 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         3 |  none  |   8 |     8 |    8 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         4 |  none  |   5 |     6 |    5 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         5 |  none  |   5 |     5 |    5 |         0 |     1 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         6 |  none  |   0 |     0 |    0 |         8 |     0 |     0 |
0 |       0 |        |    x    |    x   |       |       |    |    |    x   |
0 |
|         7 |  slow  |   8 |     8 |    8 |         0 |     8 |     0 |
0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |
0 |
|         8 |  slow  |   8 |     8 |    8 |         0 |     8 |     0 |
16 |       0 |    x   |    x    |    x   |   x   |       |    |    |
|     0 |
|         9 |  slow  |   8 |     8 |    8 |         0 |     8 |    16 |
0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |
0 |
|        10 |  slow  |   8 |     8 |    8 |         0 |     8 |    16 |
16 |       0 |    x   |    x    |    x   |   x   |       |    |    |
|     0 |
|        11 |  slow  |   8 |     8 |    8 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        12 |  slow  |   8 |     8 |    8 |         0 |     0 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        13 |  slow  |   8 |     8 |    8 |         0 |     0 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        14 |  slow  |   8 |     8 |    8 |         0 |     0 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        15 |  slow  |   5 |     6 |    5 |         0 |     0 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        16 |  slow  |   5 |     5 |    5 |         0 |     1 |     0 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        17 |  slow  |   5 |     6 |    5 |         0 |     0 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        18 |  slow  |   5 |     5 |    5 |         0 |     1 |     0 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        19 |  slow  |   5 |     6 |    5 |         0 |     0 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        20 |  slow  |   5 |     5 |    5 |         0 |     1 |    16 |
0 |       0 |        |    x    |    x   |   x   |       |    |    |        |
0 |
|        21 |  slow  |   5 |     6 |    5 |         0 |     0 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
|        22 |  slow  |   5 |     5 |    5 |         0 |     1 |    16 |
16 |       0 |        |    x    |    x   |   x   |       |    |    |
|     0 |
+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+

=====================================
Chen Shunli
AVNC&IS Division
Neusoft Co., Ltd.
No.2 Xin Xiu Street. Hun Nan New District,
Shenyang 110179, PRC
Tel：+86 24 83664044
Fax：+86 24 23781242
Email：chensl@neusoft.com
Http://www.neusoft.com
=====================================

--------------------------------------------------
From: "Jason Mawdsley" <community-noreply@qnx.com>
Sent: Friday, June 25, 2010 10:30 AM
To: "cwm-graphics" <post57863@community.qnx.com>
Subject: Re: Can we use OpenKODE at VWMARE?

> OpenKODE apps don¹t run in VMWare.
>
> Can you run egl-configs and put the output here?
>
> Thanks,
> Jason
> On 10-06-24 9:44 PM, "Chen ShunLi" <community-noreply@qnx.com> wrote:
>
>> In fact, the source code is copy from SVN "gles1-kd-pbuffer.c" and be
>> changed some MACRO such as:
>>    KD_WINDOWPROPERTY_POSITION_QNX==>KD_QNX_WINDOWPROPERTY_POSITION
>>
>> 1. At the photon mode, the kdCreateWindow is failure
>> 2. I change it to Text mode and run the io-winmgr by telnet, the
>> kdCreateWindow is OK.
>>    But when we call kdRealizeWindow( kd_win, &egl_win), the elg_win is
>> NULL.
>>    Full screen with white background displayed in VMWARE
>>
>> thanks
>>
>>
>> ------------------------------------------------------------------------------
>> ---------------------
>> Confidentiality Notice: The information contained in this e-mail and any
>> accompanying attachment(s)
>> is intended only for the use of the intended recipient and may be
>> confidential
>> and/or privileged of
>> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
>> reader of
>> this communication is
>> not the intended recipient, unauthorized use, forwarding, printing,
>> storing,
>> disclosure or copying
>> is strictly prohibited, and may be unlawful.If you have received this
>> communication in error,please
>> immediately notify the sender by return e-mail, and delete the original
>> message and all copies from
>> your system. Thank you.
>> ------------------------------------------------------------------------------
>> ---------------------
>>
>>
>>
>>
>> _______________________________________________
>>
>> CWM/OpenKODE
>> http://community.qnx.com/sf/go/post57862
>>
>
>
>
>
>
> _______________________________________________
>
> CWM/OpenKODE
> http://community.qnx.com/sf/go/post57863
>
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------

post57863: Re: Can we use OpenKODE at VWMARE?

Jason Mawdsley(deleted) — Fri, 25 Jun 2010 02:30:00 GMT

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

>

post57862: Re: Can we use OpenKODE at VWMARE?

Chen ShunLi — Fri, 25 Jun 2010 01:44:54 GMT

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.

---------------------------------------------------------------------------------------------------

post57861: Re: Can we use OpenKODE at VWMARE?

Jason Mawdsley(deleted) — Fri, 25 Jun 2010 01:28:24 GMT

Please attach your source code, or at least the initialization pieces.

Thanks,

Jason

On 10-06-24 9:26 PM, "Chen ShunLi" <community-noreply@qnx.com> wrote:

>

>

> hi,

>     Can we use the OpenKODE under the following environment:

>         VMWARE 5.5

>         QNX 6.4.1

>         OpenGL Es 1.4

>     When we call the function kdRealizeWindow( kd_win, &egl_win), the egl_win

> is NULL.

>     And can we use it at the Photon Mode?

>

>     Thanks

> ------------------------------------------------------------------------------

> ---------------------

> Confidentiality Notice: The information contained in this e-mail and any

> accompanying attachment(s)

> is intended only for the use of the intended recipient and may be confidential

> and/or privileged of

> Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of

> this communication is

> not the intended recipient, unauthorized use, forwarding, printing,  storing,

> disclosure or copying

> is strictly prohibited, and may be unlawful.If you have received this

> communication in error,please

> immediately notify the sender by return e-mail, and delete the original

> message and all copies from

> your system. Thank you.

> ------------------------------------------------------------------------------

> ---------------------

>

>

>

>

> _______________________________________________

>

> CWM/OpenKODE

> http://community.qnx.com/sf/go/post57860

>

>

post57860: Can we use OpenKODE at VWMARE?

Chen ShunLi — Fri, 25 Jun 2010 01:26:31 GMT

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.
---------------------------------------------------------------------------------------------------

post56586: How to use opengles in photon Mode with VMWare

Chen ShunLi — Fri, 11 Jun 2010 05:36:15 GMT

I can run the opengl demo gears at the Text Mode.
How can I run it in photon mode? Is it necessary to set the io-winngr?

Comments:
I am a greener, so please tell me in detail as possible.

Thanks.
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------

post52624: Re: Flash cann't live with multiple windows

shi huarong — Sat, 24 Apr 2010 05:34:47 GMT

> 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).

post52623: Flash cann't live with multiple windows

shi huarong — Sat, 24 Apr 2010 05:24:12 GMT

Hello,I want to create flash that rendering by OpenVG on EGL config 0 and create two windows by OpenKode on EGL config 1.The result is the flash display nomally when the first window display, but the flash disappear when the second window display,only the two windows left.I want to know the reason why flash cann't live with multiple windows.

The EGL configures about board.

+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+

| config id | caveat | red | green | blue | luminance | alpha | depth | stencil | samples | window | pbuffer | pixmap | gles1 | gles2 | vg | gl | native | level |

+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+

|         1 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |     0 |

|         2 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |  x |    |        |     0 |

|         3 |  none  |   8 |     8 |    8 |         0 |     8 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |     0 |

|         4 |  none  |   8 |     8 |    8 |         0 |     0 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |     0 |

|         5 |  none  |   5 |     6 |    5 |         0 |     0 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |     0 |

|         6 |  none  |   5 |     6 |    5 |         0 |     0 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |  x |    |        |     0 |

|         7 |  none  |   5 |     5 |    5 |         0 |     1 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |     0 |

|         8 |  none  |   0 |     0 |    0 |         8 |     0 |     0 |       0 |       0 |    x   |    x    |    x   |       |       |    |    |    x   |     0 |

|         9 |  slow  |   8 |     8 |    8 |         0 |     8 |     0 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        10 |  slow  |   8 |     8 |    8 |         0 |     8 |     0 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        11 |  slow  |   8 |     8 |    8 |         0 |     8 |    16 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        12 |  slow  |   8 |     8 |    8 |         0 |     8 |    16 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        13 |  slow  |   8 |     8 |    8 |         0 |     0 |     0 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        14 |  slow  |   8 |     8 |    8 |         0 |     0 |     0 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        15 |  slow  |   8 |     8 |    8 |         0 |     0 |    16 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        16 |  slow  |   8 |     8 |    8 |         0 |     0 |    16 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        17 |  slow  |   5 |     6 |    5 |         0 |     0 |     0 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        18 |  slow  |   5 |     5 |    5 |         0 |     1 |     0 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        19 |  slow  |   5 |     6 |    5 |         0 |     0 |     0 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        20 |  slow  |   5 |     5 |    5 |         0 |     1 |     0 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        21 |  slow  |   5 |     6 |    5 |         0 |     0 |    16 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        22 |  slow  |   5 |     5 |    5 |         0 |     1 |    16 |       0 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        23 |  slow  |   5 |     6 |    5 |         0 |     0 |    16 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

|        24 |  slow  |   5 |     5 |    5 |         0 |     1 |    16 |      16 |       0 |    x   |    x    |    x   |   x   |       |    |    |        |     0 |

+-----------+--------+-----+-------+------+-----------+-------+-------+---------+---------+--------+---------+--------+-------+-------+----+----+--------+-------+

The io-winmgr configure file

+--------+---------+--------+-------+-------+----+----+--------+

begin globals

input = all

end globals

begin display

    cursor = off

    begin plane

     egl-config = auto

        wfd-pipeline = 1

    end plane

    begin plane

     egl-config = auto

        wfd-pipeline = 2

    end plane

end display

begin class

name = display

caption = routing

delegate = false

visible = true

source-alpha = true

end class

+--------+---------+--------+-------+-------+----+----+--------+

The flash configure file

+--------+---------+--------+-------+-------+----+----+--------+

dll =flashlite-vg.so

extension {

dll = hmip-openvg.so

config {

           format = 565

        }

}

extension {

dll = hmip-compmgr.so

config {

                                 window_manager = false

           winmgr_class = Flash

                              }

                  }

+--------+---------+--------+-------+-------+----+----+--------+

The application about creat windows.

#include <stdlib.h>

#include <stdio.h>

#include <pthread.h>

#include <EGL/egl.h>

#include <GLES/gl.h>

#include <KD/kd.h>

#include <KD/kd_qnx_window.h>

#include <unistd.h>

KDWindow *kd_win1;

KDWindow *kd_win;

EGLint egl_con_attr[]=

{

EGL_SURFACE_TYPE, EGL_WINDOW_BIT,

EGL_RENDERABLE_TYPE, EGL_OPENGL_ES_BIT,

EGL_LEVEL, 1,

EGL_RED_SIZE, 5,

EGL_GREEN_SIZE, 6,

EGL_BLUE_SIZE, 5,

EGL_ALPHA_SIZE,0,

EGL_NONE

};

void* thread_draw1( void *arg )

{

EGLDisplay egl_disp;

EGLConfig egl_config=0;

EGLint egl_num_configs;

EGLSurface egl_surf;

EGLContext egl_ctx;

EGLBoolean  retValue;

EGLNativeWindowType egl_win;

KDint winSize[]={200,200};

KDint winPos[]={200,200};

EGLint egl_surf_attr[] = {

EGL_WIDTH,  200,

EGL_HEIGHT, 200,

EGL_NONE

};

GLfloat p1[]={ 0.5f,0.0f,0.0f };

GLfloat p2[]={ -0.5f,0.0f,0.0f };

GLfloat p3[]={ 0.0f,0.5f,0.0f };

printf("entry thread_draw1!\n");

egl_disp = eglGetDisplay(EGL_DEFAULT_DISPLAY);

if(egl_disp == EGL_NO_DISPLAY)

{

printf("EGL NO Display!\n");

}

eglInitialize(egl_disp,NULL,NULL);

retValue = eglChooseConfig(egl_disp,egl_con_attr,&egl_config,1,&egl_num_configs);

if(retValue == EGL_FALSE)

{

printf("Fail to EGL Choose Config!\n");

}

printf("config:%d\n",(int)egl_config);

kd_win1 = kdCreateWindow(egl_disp,egl_config,KD_NULL);

kdSetWindowPropertyiv(kd_win1, KD_WINDOWPROPERTY_SIZE, winSize);

kdSetWindowPropertyiv(kd_win1, KD_QNX_WINDOWPROPERTY_POSITION, winPos);

kdRealizeWindow(kd_win1, &egl_win);

egl_surf = eglCreateWindowSurface(egl_disp,egl_config,egl_win,egl_surf_attr);

if(egl_surf == EGL_NO_SURFACE)

{

printf("No Surface!\n");

}

egl_ctx = eglCreateContext(egl_disp,egl_config,EGL_NO_CONTEXT,NULL);

if(egl_ctx == EGL_NO_CONTEXT)

{

printf("NO Context!\n");

}

retValue = eglMakeCurrent(egl_disp,egl_surf,egl_surf,egl_ctx);

if(retValue == EGL_FALSE)

{

printf("Failed to EGL Make Current!\n");

}

eglSwapInterval(egl_disp, 1);

glEnableClientState(GL_VERTEX_ARRAY);

glClearColor(1.0f,1.0f,1.0f,1.0f);

//glClear(GL_COLOR_BUFFER_BIT);

glColor4f(1.0f,0.0f,0.0f,0.0f);

glVertexPointer(3,GL_FLOAT ,0,p1);

glVertexPointer(3,GL_FLOAT ,0,p2);

glVertexPointer(3,GL_FLOAT ,0,p3);

glDrawArrays(GL_TRIANGLE_STRIP  ,0,3);

eglSwapBuffers(egl_disp,egl_surf);

sleep(15);

//kdDestroyWindow(kd_win1);

//eglTerminate(egl_disp);

return NULL;

}

void* thread_draw2( void *arg )

{

printf("entry thread_draw2!\n");

EGLDisplay egl_disp;

EGLConfig egl_config=0;

EGLint egl_num_configs;

EGLSurface egl_surf;

EGLContext egl_ctx;

EGLBoolean  retValue;

KDWindow *kd_win;

EGLNativeWindowType egl_win;

KDint winSize[]={400,400};

KDint winPos[]={0,0};

EGLint egl_surf_attr[] = {

EGL_WIDTH,  400,

EGL_HEIGHT, 400,

EGL_NONE

};

GLfloat p1[]={ 0.5f,0.0f,0.0f };

GLfloat p2[]={ -0.5f,0.0f,0.0f };

GLfloat p3[]={ 0.0f,0.5f,0.0f };

egl_disp = eglGetDisplay(EGL_DEFAULT_DISPLAY);

if(egl_disp == EGL_NO_DISPLAY)

{

printf("EGL NO Display!\n");

}

eglInitialize(egl_disp,NULL,NULL);

retValue = eglChooseConfig(egl_disp,egl_con_attr,&egl_config,1,&egl_num_configs);

if(retValue == EGL_FALSE)

{

printf("Fail to EGL Choose Config!\n");

}

printf("config:%d\n",(int)egl_config);

kd_win = kdCreateWindow(egl_disp,egl_config,KD_NULL);

printf("thread2 kdCreateWindow\n");

kdSetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, winSize);

kdSetWindowPropertyiv(kd_win, KD_QNX_WINDOWPROPERTY_POSITION, winPos);

kdRealizeWindow(kd_win, &egl_win);

printf("thread2 kdRealizeWindow\n");

egl_surf = eglCreateWindowSurface(egl_disp,egl_config,egl_win,egl_surf_attr);

printf("thread2 eglCreateWindowSurface\n");

if(egl_surf == EGL_NO_SURFACE)

{

printf("No Surface!\n");

}

egl_ctx = eglCreateContext(egl_disp,egl_config,EGL_NO_CONTEXT,NULL);

printf("thread2 eglCreateContext\n");

if(egl_ctx == EGL_NO_CONTEXT)

{

printf("NO Context!\n");

}

retValue = eglMakeCurrent(egl_disp,egl_surf,egl_surf,egl_ctx);

printf("thread2 eglMakeCurrent\n");

if(retValue == EGL_FALSE)

{

printf("Failed to EGL Make Current!\n");

}

eglSwapInterval(egl_disp, 2);

printf("thread2 eglSwapInterval\n");

glEnableClientState(GL_VERTEX_ARRAY);

printf("thread2 glEnableClientState\n");

glClearColor(1.0f,1.0f,1.0f,1.0f);

printf("thread2 glClearColor\n");

//glClear(GL_COLOR_BUFFER_BIT);

printf("thread2 glClear\n");

glColor4f(1.0f,1.0f,0.0f,0.0f);

printf("thread2 glColor4f\n");

glVertexPointer(3,GL_FLOAT ,0,p1);

printf("thread2 glVertexPointer\n");

glVertexPointer(3,GL_FLOAT ,0,p2);

glVertexPointer(3,GL_FLOAT ,0,p3);

glDrawArrays(GL_TRIANGLE_STRIP  ,0,3);

printf("thread2  BF eglSwapBuffers\n");

eglSwapBuffers(egl_disp,egl_surf);

printf("thread2  AF eglSwapBuffers\n");

// sleep(15);

// kdDestroyWindow(kd_win);

// eglTerminate(egl_disp);

return NULL;

}

int kdMain( KDint argc, const KDchar *const *argv )

{

thread_draw2((void*)0);

sleep(10);

thread_draw1((void*)0);

while( 1 )

{

sleep(20);

}

return EXIT_SUCCESS;

}

post51055: Re: question about io-winmgr

Joel Pilon(deleted) — Thu, 01 Apr 2010 15:18:46 GMT

We also provide a delegate interface which helps to write a window manager.

The following tutorial is a simple example of a window manager:

http://community.qnx.com/integration/viewvc/viewvc.cgi/trunk/apps/kd/tutorials/gles1-kd-hmi/?root=graphics&system=exsy1001

post51044: Re: question about io-winmgr

Jason Mawdsley(deleted) — Thu, 01 Apr 2010 14:13:36 GMT

> 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.

post51012: question about io-winmgr

ivan chen — Thu, 01 Apr 2010 06:33:00 GMT

Hi, All

From the tutorials, it seems that io-winmgr is just a server.

I start io-winmgr with default config file, just get a black screen.

If my understanding is right, to make composition work, there must be a client app just like photon to provide a window system.

Is there a window manager on qnx provide a environment like composite desktop, on which we can do rotate and reflect?

Thanks!

post49870: Re: /dev entries for each display section

Gervais Mulongoy — Thu, 18 Mar 2010 15:51:09 GMT

I have since found out that is not the case. The :0 denotes the id/handle of the instance of io-winmgr.

post49667: /dev entries for each display section

Gervais Mulongoy — Tue, 16 Mar 2010 21:03:45 GMT

Hello all:

It is currently my understanding that for each display section in winmgr.conf there will be a corresponding /dev/winmgr:0 style entry. Is this the case, or are the entries generated for a different reason?

Thanks,

Gervais

post49666: Re: winmgr.conf more than one display section

Gervais Mulongoy — Tue, 16 Mar 2010 21:01:24 GMT

Thanks JP - wfd-device is actually needed.

post49619: winmgr.conf more than one display section

Gervais Mulongoy — Tue, 16 Mar 2010 15:56:53 GMT

Hello all:

I wanted to clarify a point in winmgr.conf. Now I understand for each physical display you want to target you need a display section in winmgr.conf. If you don't specify an id (like if you just copied the display section so you have two identical ones), will the display sections point to the default physical display or will they automatically know to associate with the next physical display?

If we do in fact need to specify the id I am assuming we use the wfd-device setting and get the value from sysres as described in the comments.

Thanks,

Gervais

post49549: RE: Howto instruct the flash player to target more than one display at a time

Paul Streatch(deleted) — Mon, 15 Mar 2010 22:22:18 GMT

Note that the two displays could have different pixel depths/color

formats (making stretching/sharing of a single surface difficult).

> -----Original Message-----

> From: Roger Maclean [mailto:community-noreply@qnx.com]

> Sent: March 15, 2010 6:01 PM

> To: cwm-graphics

> Subject: Re: Howto instruct the flash player to target more than one

display at

> a time

>

> Yes, you would have to run two instances of the flash player.

>

> I don't believe there is any way of cloning a display or stretching it

> across two screens. I've asked about this and I'll let you know if

I'm

> wrong but I'd be very surprised.

>

>

>

>

> _______________________________________________

>

> CWM/OpenKODE

> http://community.qnx.com/sf/go/post49545

post49545: Re: Howto instruct the flash player to target more than one display at a time

Roger Maclean — Mon, 15 Mar 2010 22:01:25 GMT

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.

post49522: Re: Howto instruct the flash player to target more than one display at a time

Gervais Mulongoy — Mon, 15 Mar 2010 18:50:08 GMT

Hello Roger:

If I want to run the same SWF on two displays I would then need to start two instances of the flash player each with their own flash.conf targeting the appropriate display? So long as I had two device entries in display.conf and started io-display with both devices specified, and also two display sections in winmgr.conf.

Finally is there no way to clone the display to another screen or is it possible to stretch the display on two screens?

Thank you,

Gervais

post49514: Re: Howto instruct the flash player to target more than one display at a time

Jason Mawdsley(deleted) — Mon, 15 Mar 2010 18:34:27 GMT

You can always document it Gervais :)

On 10-03-15 2:31 PM, "Roger Maclean" <community-noreply@qnx.com> wrote:

> Yes, the value is just used as the parameter passed to eglGetDisplay. Each

> instance of the Flash player can only target a single display.

>

> It's not currently documented anywhere, it has only been added fairly

> recently.

>

>

>

>

> _______________________________________________

>

> CWM/OpenKODE

> http://community.qnx.com/sf/go/post49512

>

post49512: Re: Howto instruct the flash player to target more than one display at a time

Roger Maclean — Mon, 15 Mar 2010 18:31:51 GMT

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.

post49504: Re: Howto instruct the flash player to target more than one display at a time

Gervais Mulongoy — Mon, 15 Mar 2010 18:08:51 GMT

So the display setting is used specify which display to target to if there are more than one display available? Is this documented anywhere?

post49503: Re: Howto instruct the flash player to target more than one display at a time

Paul Streatch(deleted) — Mon, 15 Mar 2010 17:52:52 GMT

I think the flash player can only target a single display (the Flash stage cannot be shared between displays or windows).

Paul

----- Original Message -----

From: Gervais Mulongoy <community-noreply@qnx.com>

To: cwm-graphics <post49501@community.qnx.com>

Sent: Mon Mar 15 13:47:45 2010

Subject: Howto instruct the flash player to target more than one display at a time

Hello all:

I have recently discovered that support for multiple displays was recently added to the flash player and to enable support, one needs to use the hmip-compmgr.so extension in the flash.conf as follows:

[code]

extension {

   dll = hmip-compmgr.so

   config {

      display = 1

   }

}

[/code]

Assuming a minimum of two device entries in display.conf, and io-display started with both devices specified at the command line what is the correct way to instruct the flash player to target both displays simulatenously? Should one added another display setting to the hmip-compmgr.so extension (ie. "display = 2")?

Thanks,

Gervais



_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post49501

post49501: Howto instruct the flash player to target more than one display at a time

Gervais Mulongoy — Mon, 15 Mar 2010 17:47:44 GMT

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

post46930: eglSwapBuffers and io-winmgr

Gary Faulkner — Tue, 09 Feb 2010 15:48:56 GMT

What is happening when a client app calls eglSwapBuffers (in QNX 6.4.1)? Specifically from the io-winmgr perspective.

Are the requests queued somehow in io-winmgr?

post46651: Re: Alpha blending in CWM/OpenKODE

Etienne Belanger(deleted) — Fri, 05 Feb 2010 13:36:54 GMT

It will be in the next release, but I cannot say when that will be.

post46603: Re: Alpha blending in CWM/OpenKODE

Radek Pesina — Thu, 04 Feb 2010 22:02:59 GMT

Thanks alot for your help Etienne, based on your comments as a starting point we'll try reducing the amount of layers to see what improvements can be had. You mention that a future CM release will be using dirtied areas instead, do you know how far away the release is?

Best regards,

Radek

post46602: Re: Alpha blending in CWM/OpenKODE

Radek Pesina — Thu, 04 Feb 2010 21:51:32 GMT

Thanks Eric,

The contents of our winmgr.conf file are as follows:

begin globals

input = all

end globals

begin display

cursor = sw-arrow

begin plane

egl-config = auto

end plane

end display

I have attached the ouptut of io-winmgr -d.

Cheers,

Radek.

post46528: Re: Alpha blending in CWM/OpenKODE

Etienne Belanger(deleted) — Thu, 04 Feb 2010 14:03:35 GMT

This is a pretty lengthy question, so I hope you don't mind if we answer indivdual elements over a couple of posts...

As to whether rendering time should increase when alpha blending is enabled, even if the contents are fully opaque, the answer is yes, it is quite possible. The composition manager does not look at pixel values to determine areas with transparency, and there are no transparency hints yet. Therefore, compositing in this case will be performed with per-pixel alpha blending enabled. The graphics accelerator may be able to optimize this operation by skipping reading the destination buffer when the source alpha value is 255, but that is up to the hardware. The only type of blending that allows compositing optimizations is global alpha with an opaque value (255) with per-pixel alpha disabled expicitly or implicitly (no alpha channel).

The way compositing works is quite straightforward. Any time a window changes, all visible windows and any background that intersect with that window are composited back to front. If a window is opaque, no window beneath it and no background will intersect. However, there could still be semi-transparent windows on top of it that will have to be re-composited too. Future releases will apply the same rules, but using dirtied areas instead of the full window. Until then, it is clear that the best approach to minimize updates is to minimize the number of overlapping semi-transparent layers. One way to do this would be to flatten static content, i.e. blend static images in a pre-processing stage, to reduce the number of layers. For content that is a little more dynamic, one could use a rendering API such as OpenGL ES, OpenVG, or even use software, to flatten some layers. What's best depends on what's static and what changes a lot, the number of layers, the size of the transparent areas, how they overlaps, and so on.

post46508: Re: Alpha blending in CWM/OpenKODE

Eric Fausett(deleted) — Thu, 04 Feb 2010 06:41:54 GMT

Radek,

I just noticed your post here. While I can't address your question directly as I'm not 100% sure on the answer, I thought I'd chime in on what additional information you might provide so that the question can be addressed.

You might want to include the winmgr.conf file that you are using as I'm sure it will be needed to address your question.

I'm also guessing it would be useful to do a 'io-winmgr -d' while your application(s) is/are running and provide the output of that so that the internal configuration of that module can be known.

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/io-winmgr.html

Regards,

Eric

post46507: Alpha blending in CWM/OpenKODE

Radek Pesina — Thu, 04 Feb 2010 06:28:22 GMT

Hi,

We are using CM for our HMI and have major performance issues with the screen update.  As such I am hoping that you could offer some suggestions.  For reference the target micro is the i.MX31 and the displayed resolution is 800x480, RGB565.

Our HMI screens consist of many alpha-blended layers, with separate layers for the background, frames, each button, each icon, text fields etc.  The text is rendered while the remainder of the screen elements are PNG images (i.e we have a background image with an overlaying frame image with overlaying button images etc).

Using a kernel trace we have observed the screen rendering times alone are around 700-800ms (combine this with the apps processing time, retrieval of PNG's from NAND etc and we're talking in the order of seconds for some screens).

We tried (out of interest) to render a solid-coloured rectangle of size 800x480 to the display.  With alpha-blending turned off it took around 20ms.  With alpha-blending turned on the rendering time was 500ms.  Considering it was only a single composite layer and therefore no alpha-blending was required to be calculated in this circumstance, should it take so much longer to render?

Also, how does the CM layering work internally? i.e. is it more efficient to have the screen split into many smaller layers/elements so smaller areas are updated, or is it more efficient to minimise the amount of layers used and rather have larger-sized individual layers?

Some parts of our screen can be up to 4 or 5 layers deep, however most/all layers have either full or no transparency. Since effectively only the topmost layer is visible, are all the below layers still calculated/alpha-blended?

Are any of the settings in winmgr.conf worth changing?

Cheers,

Radek.

post46089: Multiple Display

Yossi Har-Nov — Wed, 27 Jan 2010 21:55:16 GMT

How do I configure the io-winmngr for two displays? I have two display and touchscreen and I can only configure only one of them. How do I handle multiple displays?

post45905: RE: kdSetTimer/kdCancelTimer??

Joel Pilon(deleted) — Mon, 25 Jan 2010 22:44:00 GMT

Correct they are not implemented. For a list of OpenKODE functions we support you can refer to:

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/externalapi.html

Most of OpenKODE mirrors posix/ansi c, at this point posix is more portable then OpenKODE, so using timer_settime/timer_gettime is probably a better option even if the KD versions were implemented.

The non-posix/non-ansi c portions of KD mostly consist of windowing and events which we do implement.

-Joel

-----Original Message-----

From: Gary Faulkner [mailto:community-noreply@qnx.com]

Sent: Mon 1/25/2010 5:20 PM

To: cwm-graphics

Subject: kdSetTimer/kdCancelTimer??

It would appear that these two are not in libKD* for QNX 6.4.1? Is that a known issue (or is it otherwise documented elsewhere and I've just missed it)??

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post45903

post45903: kdSetTimer/kdCancelTimer??

Gary Faulkner — Mon, 25 Jan 2010 22:20:16 GMT

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)??

post45850: Re: CM/OpenKODE "performance"

Etienne Belanger(deleted) — Mon, 25 Jan 2010 13:28:22 GMT

You do need to call eglSwapBuffers. It doesn't matter if your window is single- or double-buffered, eglSwapBuffers is what's going to trigger composition by io-winmgr. If you don't call it, all your updates will remain offscreen.

post45800: Re: CM/OpenKODE "performance"

Joel Pilon(deleted) — Fri, 22 Jan 2010 19:06:21 GMT

You can try setting your swap interval to 0 for benchmarking purposes.

You can set swap interval with:

eglSurfaceAttrib(egl_disp, egl_window_surf, EGL_SWAP_INTERVAL_QNX, 0);

It's no recommended to always run with interval 0, since updates will be inconsistent and artifacts can be introduced.

You'll still need to call eglSwapBuffers since your window is still double buffered. Running with rgb565/argb1555 would offer better performance also, assuming you don't need source-alpha blending.

post45799: Re: CM/OpenKODE "performance"

Gary Faulkner — Fri, 22 Jan 2010 18:46:11 GMT

so, apparently, for me, the right combination *might* be egl-config=1 (the one that matches the color-depth I want), and wfd-pipeline=1.

In the blit2() case, with an image that is 780x380, this resolved two things:

1) my banding issue is now gone.

2) the frame rate is up to about 29 fps -- which I can definitely live with.

Does this make any sense?

post45797: Re: CM/OpenKODE "performance"

Gary Faulkner — Fri, 22 Jan 2010 18:25:57 GMT

heh... helps if I spell pipeline correctly (apparently -- go figure).

So, now my question becomes... do I no longer do eglSwapBuffers()??

post45795: Re: CM/OpenKODE "performance"

Gary Faulkner — Fri, 22 Jan 2010 18:09:24 GMT

so, when I change to use wfd-pipline = 1, I no longer have any egl configs?? (at least according to sysres). Why would that be?

post45785: Re: CM/OpenKODE "performance"

Gary Faulkner — Fri, 22 Jan 2010 16:50:45 GMT

> 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.

post45783: Re: CM/OpenKODE "performance"

Etienne Belanger(deleted) — Fri, 22 Jan 2010 16:39:31 GMT

I thought the blit2 test gave you 11-12 fps, not 54. One shouldn't compare native to composition manager if the format is configured to swap surfaces while the latter is configured to blit.

In any case, the first thing is to confirm that you want blitting enabled instead of surface swapping. From past posts, it seems you want to have multiple windows on one layer. If this is not the case, I suggest you remove the egl-config = ... line and replace it with wfd-pipeline = 1.

Otherwise, you might want to try an EGL config id that matches your 8888 pixel format, instead of using auto. It is possible that blits that require format conversion revert to software on this driver. Alternatively, you can always modify your blit2 GF test to blit from an 8888 surface to a 565 surface to see if you get similar results...

post45779: Re: CM/OpenKODE "performance"

Gary Faulkner — Fri, 22 Jan 2010 15:51:24 GMT

Hello:

I've attached my current winmgr.conf.  Other responses inline:

> Please provide us with your winmgr.conf configuration file to better help us

> determine what the composition manager might be trying to do.

>

> Other questions:

>

> What is the EGL_SWAP_BEHAVIOR set to ? If EGL_BUFFER_PRESERVED is requested

> this will add to the amount of work EGL has to do when swapping buffers.

EGL_SWAP_BEHAVIOR is set to EGL_BUFFER_DESTROYED

>

> What are the values for KD_WINDOWPROPERTY_BUFFER_SIZE_QNX,

> KD_WINDOWPROPERTY_SOURCE_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_POSITION,

> KD_WINDOWPROPERTY_SIZE, and KD_WINDOWPROPERTY_POSITION_QNX ?

KD_QNX_WINDOWPROPERTY_SOURCE_SIZE is 780,380

KD_QNX_WINDOWPROPERTY_SOURCE_POSITION is 0,0

KD_WINDOWPROPERTY_SIZE is 780,380

KD_QNX_WINDOWPROPERTY_POSITION_QNX is 0,0

>

> What is the value of EGL_RED_SIZE, EGL_BLUE_SIZE, EGL_GREEN_SIZE, and

> EGL_ALPHA_SIZE of the EGLConfig that your application is using to create the

> window surface ?

They are 8,8,8,8 respectively.

>

> Note that using the composition manager does have a performance impact, even

> if compositing is disabled. In this case, EGL is forced to wait for renders to

>  complete before sending a post message to the composition manager. This

> eliminates any potential overlapping of CPU and GPU and causes the GPU to be

> idle for some time, unless other applications are running in parallel.

> Consequently, free running frame rates of applications without composition

> manager will always be equal or higher than their composition manager

> counterpart. This can be overcome with triple buffering, which might be added

> to our EGL at some point.

Yup... I expected some performance impact, but not close to an order of magnitude. I have run that same test image through a simple gf blitting directly to a layer (without io-winmgr running) and get about 65 fps on that.

So, overall I have several applications all running at the same time using CM.  Aside from some transitions putting application windows on and off the screen, when an application window is visible, it owns the entire displayable area (800x480).  Obviously my little image test program is only creating a window as large as the image it is displaying, so that may not count.  Actually, I just ran a test with a full-screen sized image (and window) and it's fps using CM and openvg is about 4.5 fps, and with just a native gf it is about 54 fps.

post45762: Re: CM/OpenKODE "performance"

Etienne Belanger(deleted) — Fri, 22 Jan 2010 13:48:53 GMT

Please provide us with your winmgr.conf configuration file to better help us determine what the composition manager might be trying to do.

Other questions:

What is the EGL_SWAP_BEHAVIOR set to ? If EGL_BUFFER_PRESERVED is requested this will add to the amount of work EGL has to do when swapping buffers.

What are the values for KD_WINDOWPROPERTY_BUFFER_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_SIZE_QNX, KD_WINDOWPROPERTY_SOURCE_POSITION, KD_WINDOWPROPERTY_SIZE, and KD_WINDOWPROPERTY_POSITION_QNX ?

What is the value of EGL_RED_SIZE, EGL_BLUE_SIZE, EGL_GREEN_SIZE, and EGL_ALPHA_SIZE of the EGLConfig that your application is using to create the window surface ?

Note that using the composition manager does have a performance impact, even if compositing is disabled. In this case, EGL is forced to wait for renders to complete before sending a post message to the composition manager. This eliminates any potential overlapping of CPU and GPU and causes the GPU to be idle for some time, unless other applications are running in parallel. Consequently, free running frame rates of applications without composition manager will always be equal or higher than their composition manager counterpart. This can be overcome with triple buffering, which might be added to our EGL at some point.

post45753: CM/OpenKODE "performance"

Gary Faulkner — Fri, 22 Jan 2010 12:42:12 GMT

I was doing some performance comparisons this morning (imx35 based) between drawing images in the CM environment using blit2() vs. vgDrawImage().  First thing I noticed is that blit2 is *slightly* faster than vgDrawImage() (for the same image -- on the order of 11-12 fps for blit2() vs. 7-8 fps for vgDrawImage() on a 780x380 RGB/A png).

However, while watching all of this, I notice that io-winmgr consumes a TON of CPU.  I guess I'm wondering a couple of things:

1)  Is it fully utilizing the HW capabilities I have for doing the compositing?

2) It seems like the expensive call here is eglSwapBuffers().  Why is that, and is there any tuning I can do to get around that fact?

I ask about #1 because of the banding issue I discuss in http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.cwm_openkode.topc11707

At any rate.. I'm wondering, even in this relatively simple case, if there is some io-winmgr tuning I can/should be doing to get better performance/results (less CPU utilization too).  Also, I'd still like to understand how to get around the banding issue that I'm seeing.

I haven't yet run a comparable test using just gf, but I fully expect it to be significantly faster (in terms of fps).

Thoughts?

post45732: Re: un-flipping images displayed via vgDrawImage()??

Gary Faulkner — Thu, 21 Jan 2010 23:41:56 GMT

Nevermind... figured it out with the negative stride stuff.

post45731: un-flipping images displayed via vgDrawImage()??

Gary Faulkner — Thu, 21 Jan 2010 23:22:01 GMT

So, if one does something like the following:

    VGImage image = vgCreateImage(VG_sRGBA_8888,img.w,img.h,VG_IMAGE_QUALITY_BETTER);

    if (image == (VGImage)0)

    {

        fprintf(stderr,"Unable to create VG image: %d\n",vgGetError());

        return -1;

    }

    vgImageSubData(image,img.access.direct.data,img.access.direct.stride,VG_sARGB_8888,0,0,img.w,img

then a vgDrawImage(image);

the image is flipped upside-down.  What is the correct way to either cause it to be loaded into the VGImage correctly, or to display it correctly?

I realize this is "documented behavior" for openvg; but I'm not sure how one is supposed to (efficiently) overcome it.

Thanks!

post45651: Re: CM/OpenKODE image display oddity

Gary Faulkner — Thu, 21 Jan 2010 15:19:28 GMT

As an aside, I also tried this using the openvg calls for images, and I get the same results.

post45624: CM/OpenKODE image display oddity

Gary Faulkner — Thu, 21 Jan 2010 12:45:54 GMT

First off, this is on an imx35 (not sure it matter for this case, but wanted to mention it).

I'm seeing some oddities that I cannot explain with a particular type of image.  The image is a png, RBGA, 8 bits of color.

In the gf_* world, I have an image that I blit to the screen.  I do this (in a very simple case) by loading the image with img_load_file(), wrap a surface around it with gf_surface_attach(), then I blit it to a surface that is attached to a real hardware layer.  It looks greate.

In the CM/OpenKODE world, I try to mimic this by loading the image with img_load_file(), wrapping a surface around it with gf_surface_attach(), and then blitting that surface to an eglSurface using:

gf_context_set_surface_3d();

gf_draw_begin();

gf_draw_blit2() (with the dest surface as NULL, and the source surface as the one from gf_surface_attach())

gf_draw_end();

eglSwapBuffers();

The load and display "work", but the image is banded; it's like it's trying to be displayed on an RGB565 surface.  However, I've verified that the surface should be correct (here's a description using the same messages as are printed from many of the sample apps):

EGL_VENDOR = QNX Software Systems

EGL_VERSION = 1.4

EGL_CLIENT_APIS = OpenGL_ES OpenVG

EGL_EXTENSIONS = EGL_KHR_lock_surface EGL_QNX_gf_surface EGL_QNX_swap_interval

EGL_CONFIG_ID = 1

EGL_RED_SIZE = 8

EGL_GREEN_SIZE = 8

EGL_BLUE_SIZE = 8

EGL_ALPHA_SIZE = 8

EGL_DEPTH_SIZE = 0

EGL_LEVEL = 0

EGL_NATIVE_RENDERABLE = EGL_TRUE

EGL_NATIVE_VISUAL_TYPE = 5152

EGL_RENDERABLE_TYPE = 0x0000

EGL_SURFACE_TYPE = 0x0487

EGL_TRANSPARENT_TYPE = EGL_NONE

So my question is, what is causing the banding?

post45375: Re: RE: EGL/KD and direct buffer manipulation

Gary Faulkner — Mon, 18 Jan 2010 11:56:14 GMT

Actually, let me be more specific. MOST of the time we need to be able to have more than one window visible at a time. However, when this particular application is displaying (the one doing the direct rendering), we do not need multiple windows.

It still seems like the eglSwapBuffers is costing us significant cpu time, and I really wasn't expecting that at all.

post45349: Re: RE: EGL/KD and direct buffer manipulation

Gary Faulkner — Fri, 15 Jan 2010 22:12:59 GMT

Thanks!

So a few things here..

First, we're on an imx35; blits are accelerated.

Second, from reading the comments in the default winmgr.conf file, there are some issues with changing from egl-config to wfd-pipeline.  Specifically, it would appear (from the comments) that only 1 window will be visible at a time.

That is not what we want/need.  Furthermore, when I do make this switch, my existing CWM/KD programs can no longer find a usable configuration.

post45331: Re: RE: EGL/KD and direct buffer manipulation

Etienne Belanger(deleted) — Fri, 15 Jan 2010 19:25:04 GMT

It is possible that the composition manager is configured to do compositing instead of flipping buffers on a layer. This would mean an extra blit each frame. If for some reason there is no acceleration of blits on your platform, this could end up using a lot of CPU, especially if the surface isn't cached.

Look for 'egl-config' directives in the winmgr.conf. The default configuration file is usually:

begin display

  begin plane

    egl-config = auto

  end plane

end display

Which means all windows are composited to one framebuffer. Changing it to

begin display

  begin plane

    wfd-pipeline = 1

  end plane

end display

would enable buffer flipping. You can add a plane for each layer available. The pipeline numbers start at 1 instead 0 like in GF.

post45312: Re: RE: EGL/KD and direct buffer manipulation

Gary Faulkner — Fri, 15 Jan 2010 16:10:15 GMT

Thanks! this helps quite a bit. Now my problem appears to be that io-winmgr wants to eat up a ton of CPU in this case. From what I can tell it's all in the eglSwapBuffers (if I don't do this, io-winmgr doesn't chew through cpu, but (obviously) I don't get output on the screen.

Seems like eglSwapBuffers is required; is there any way around that?

post45303: RE: EGL/KD and direct buffer manipulation

Joel Pilon(deleted) — Fri, 15 Jan 2010 15:15:45 GMT

You can use the EGL_KHR_lock_surface extension to lock your window surface and get a vadder to the render buffer. So if you memcpy directly to your window surface, performance should be much better.

You can find an example application which uses the EGL_KHR_lock_surface extension at:

http://community.qnx.com/integration/viewvc/viewvc.cgi/trunk/apps/kd/tutorials/sw-kd-vsync/sw-kd-vsync.c?root=graphics&system=exsy1001&view=markup

For 6.4.2 we plan to release several improvements to software renders along with updated tutorials which make use of the new features. These new features have been found to increase performances significantly.

-Joel

-----Original Message-----

From: Gary Faulkner [mailto:community-noreply@qnx.com]

Sent: January 15, 2010 8:19 AM

To: cwm-graphics

Subject: EGL/KD and direct buffer manipulation

First, I apologize if this seems like a bad question to even be asking; however..

In the gf_ world, one could create a surface with gf_surface_create_layer(), get the vaddr using gf_surface_get_info(), and copy data directly into the surface (and thereby into the display). (I realize that may or may not be a good thing, but it is possible to do).

At any rate, in the CWM/OpenKODE world I'm not clear on how one would do that. I have an application that generates data that I want to display on the screen at a very fast rate (say 15-30 fps). Using gf, I can pretty much keep up with the display of that data. Using CWM/OpenKODE, I cannot.

What I'm doing (for now) is creating a separate gf_surface, memcpying the data into the vaddr, and then when the whole surface is filled, doing the

gf_context_set_surface_3d()

gf_draw_being()

gf_draw_blit2()

gf_draw_end();

eglSwapBuffers()

dance to blit the separate gf_surface onto the opened CWM window.

Is there a better way to accomplish my goal here?

-garyf

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post45284

post45289: Re: EGL/KD and direct buffer manipulation

Etienne Belanger(deleted) — Fri, 15 Jan 2010 13:56:01 GMT

The options for software-based rasterizers are typically to render to the window, or to render into an offscreen buffer and then make the changes visible using some kind of blit. It seems you are using a variant of the second approach right now. It is important to note that unless most of the pixels in a window change every frame, rendering into an offscreen buffer first is usually more efficient.

To render directly into a window this is what you can do:

1) Use eglGetConfigs or eglChooseConfig to get an EGL config with an EGL_SURFACE_TYPE that has both the EGL_WINDOW_BIT and the EGL_LOCK_SURFACE_BIT_KHR set. EGL_KHR_lock_surface is the EGL extension that allows you to get a pointer to one of an EGLSurface's buffers.

2) Create your window with eglCreateWindowSurface. You don't need an EGLContext since you will be using a software rasterizer.

3) In your rendering loop, call eglLockSurfaceKHR followed by eglQuerySurface to get a pointer to the back buffer. Unless the EGLSurface is single-buffered, the pointer to use will most likely change each frame because the back buffers get swapped. However, on some platforms they won't change even if the window is double-buffered, so the only way to be sure is to query for the pointer each iteration.

4) Use the pointer to the current back buffer to do your updates. When you are done you unlock the surface using eglUnlockSurfaceKHR. You can follow this by eglSwapBuffers on QNX platforms.

Here are more things to keep in mind.

* The pointer you are getting is most likely to a non-cached memory mapping because many display controllers and/or GPUs that might be used to do compositing aren't cache-coherent. This is also a problem for offscreen buffers. However, a cache flush or cache invalidate can be inserted at strategic points (e.g., prior to blits) instead of having the display controller do it before each refresh.

* To get buffer flipping enabled, you need double-buffered windows. This is enabled by default in EGL. However, this means that partial rendering needs to consider changes from two frames ago. You can use EGL_SWAP_BEHAVIOR to ask EGL to preserve pixels each time buffers are swapped. In this case, there will be an extra blit for each post, making rendering into a double-buffered window no more efficient than rendering into an offscreen buffer.

post45284: EGL/KD and direct buffer manipulation

Gary Faulkner — Fri, 15 Jan 2010 13:18:47 GMT

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

post44595: Re: CWM/OpenKODE/GF question

Gary Faulkner — Tue, 05 Jan 2010 18:45:31 GMT

just figured this out; if I specify my destination EGLSurface in the blit2() call, it doesn't do anything (although it doesn't fail either). If I don't, but just make sure that the context targets that surface, it works.

post44580: CWM/OpenKODE/GF question

Gary Faulkner — Tue, 05 Jan 2010 16:34:56 GMT

Hello:

I am (still) trying to port our existing completely GF based application(s) to use CWM/OpenKODE.  I've run into an issue that I just cannot figure out.

Our application is heavily blit2 dependent.  Looking at the guidance in this thread (http://community.qnx.com/sf/go/projects.graphics/discussion.cwm_openkode.topc9295) I make sure that the final blit (the one to the window egl surface) is from a gf_surface_t to an EGLSurface.  gf_draw_blit2() returns GF_ERR_OK.

At that same point in the code, I am able to do gf_draw_rects just fine (I don't really want to do that, but I did so to attempt to figure out what is going on here).

Are there any other gotcha's here that I'm missing?  Something I need to do before and/or after the gf_draw_blit2() to make it actually do something?

Are there any examples around showing doing this sort of thing?  For example, taking an image loaded by libimg, and blitting it to the screen in a gf-kd type environment?

Thanks!

-garyf

post44292: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT

Gary Faulkner — Tue, 22 Dec 2009 14:55:45 GMT

Awesome! Thanks.. that works.

post44288: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT

Etienne Belanger(deleted) — Tue, 22 Dec 2009 14:49:17 GMT

I suspect it's simpler than that. Make sure you call eglBindAPI prior to calling eglCreateContext. With EGL, the current API defaults to OpenGL ES if it is supported, or to EGL_NONE otherwise. For OpenVG, you have to set it explicitely with eglBindAPI.

post44286: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT

Gary Faulkner — Tue, 22 Dec 2009 14:44:43 GMT

You are correct; Here's my (current) version of the attrs section from gles1-kd-gears.c:

struct {

    EGLint surface_type[2];

    EGLint renderable_type[2];

    EGLint depth_size[2];

    EGLint level[2];

    EGLint transparent_type[2];

    EGLint red_size[2];

    EGLint green_size[2];

    EGLint blue_size[2];

    EGLint alpha_size[2];

    EGLint sample_buffers[2];

    EGLint samples[2];

    EGLint config_id[2];

    EGLint none;

} egl_conf_attr = {

    .surface_type = { EGL_SURFACE_TYPE, EGL_WINDOW_BIT },

    .renderable_type = { EGL_RENDERABLE_TYPE, EGL_OPENVG_BIT },

    .depth_size = { EGL_DEPTH_SIZE, 0 },

    .level = { EGL_LEVEL, 0 },

    .transparent_type = { EGL_TRANSPARENT_TYPE, EGL_DONT_CARE },

    .red_size = { EGL_RED_SIZE, EGL_DONT_CARE },

    .green_size = { EGL_GREEN_SIZE, EGL_DONT_CARE },

    .blue_size = { EGL_BLUE_SIZE, EGL_DONT_CARE },

    .alpha_size = { EGL_ALPHA_SIZE, EGL_DONT_CARE },

    .sample_buffers = { EGL_SAMPLE_BUFFERS, 0 },

    .samples = { EGL_SAMPLES, 0 },

    .config_id = { EGL_CONFIG_ID, EGL_DONT_CARE },

    .none = EGL_NONE

};

That works (I find a config in eglChooseConfigs()).

However, with that configuration, eglCreateContext() returns EGL_NO_CONTEXT, and eglGetError() returns EGL_BAD_CONFIG.

So, while eglChooseConfig() found a config, eglCreateContext() cannot use it?

as an aside, here's what I get now when I use the verbose flag to the gles1-kd-gears sample app:

EGL_VENDOR = QNX Software Systems

EGL_VERSION = 1.4

EGL_CLIENT_APIS = OpenGL_ES OpenVG

EGL_EXTENSIONS = EGL_KHR_lock_surface EGL_QNX_gf_surface EGL_QNX_swap_interval

EGL_CONFIG_ID = 2

EGL_RED_SIZE = 8

EGL_GREEN_SIZE = 8

EGL_BLUE_SIZE = 8

EGL_ALPHA_SIZE = 8

EGL_DEPTH_SIZE = 0

EGL_LEVEL = 0

EGL_NATIVE_RENDERABLE = EGL_FALSE

EGL_NATIVE_VISUAL_TYPE = 5152

EGL_RENDERABLE_TYPE = 0x0002

EGL_SURFACE_TYPE = 0x0487

EGL_TRANSPARENT_TYPE = EGL_NONE

I'm assuming that EGL_NATIVE_REDNERABLE being false is the issue here.  So... does this imply that I cannot use EGL with an OPENVG config? From looking through my sysres output, it would appear that every config with the EGL_OPENVG_BIT renderable type has native_renderable as "no".

post44274: Re: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT

Etienne Belanger(deleted) — Tue, 22 Dec 2009 13:52:18 GMT

If you provide us with the attrib list you are passing to eglChooseConfig, we should be able to tell you the exact cause of the error. I suspect that it is returning 0 configs because you are asking for EGL_OPENVG_BIT renderable type with a EGL_DEPTH_SIZE which isn't 0.

post44273: eglChooseConfig and EGL_RENDERABLE_TYPE EGL_OPENVG_BIT

Gary Faulkner — Tue, 22 Dec 2009 13:49:02 GMT

Hello:

I am trying to insure that the egl config I use has the EGL_OPENVG_BIT set for the renderable_type.

This is on an i.MX35.

I tried modifying the sample gles1-kd-gears app to set the EGL_OPENVG_BIT for the renderable type (in the egl_conf_attr struct). However, eglChooseConfig returns 0 configs. From looking at the sysres output from io-winmgr, it would appear that EGL_OPENVG_BIT is available on several of the configs.

Why does eglChooseConfig not find the appropriate config?

post44121: Re: touchscreen events in gles1-kd-gears demo app

Gary Faulkner — Fri, 18 Dec 2009 14:31:08 GMT

I have more info now.

I downloaded the i.mx25 bsp, which has a copy of libinput source in it.

Using that version of libinput (which *appears* to be relatively new), I find that in devi_read, it appears that the FD that io-winmgr has open is marked as non-blocking. So, more often than not, devi-read returns EAGAIN.

Additionally, because of that, the devi* interface isn't queuing up the input packets; it gets into process_wait_queue(), it sees nothing in the wait_queue, therefor, it just throws away the touch.

Does this ring a bell? First off, is io-winmgr really opening the devi interface non-blocking? I don't see devi_notify ever getting called, so I am assuming that it's not doing a select/poll/etc.

post44072: Re: touchscreen events in gles1-kd-gears demo app

Gary Faulkner — Thu, 17 Dec 2009 20:51:03 GMT

Yup... got that (the first point). In fact, the kdWaitEvent is only delivering the events in a batched sequence... about once every 5 seconds or so.

I'm running gles1-kd-gears in full-screen mode, so the screen coordinates should be at least close (and usually the first one in the batch is -- even if I don't move my finger all that much).

I'm seeing 15+fps from the gears app (depending on which color-depth I use).

> Some things to keep in mind when working with OpenKODE events, especially

> pointer events:

>

> 1) The events aren't delivered; they are queried. Events just sit in a queue

> maintained by the composition manager until an application requests for the

> next event in the queue. This is done by calling kdWaitEvent. If an

> application checks the event queue once every second, all pointer events that

> happen during the interval will be bunched up until the next kdWaitEvent call(

> s).

>

> 2) The coordinates are relative to the window, which is different from the

> screen coordinates that the debug messages devi-hid prints out.

>

> How fast is the gears application running (in fps) ?

post44071: Re: touchscreen events in gles1-kd-gears demo app

Etienne Belanger(deleted) — Thu, 17 Dec 2009 20:45:42 GMT

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) ?

post44067: Re: RE: RE: touchscreen events in gles1-kd-gears demo app

Gary Faulkner — Thu, 17 Dec 2009 20:37:53 GMT

Thanks, Joel.

I've fired off that request (to get a recent build of libinput.a).  Are there any docs or hints on seeing what is being delivered on the resource manager interface?  Is there any way (for example) to get this level of debug from io-winmgr itself?

(as an aside, yes, I am starting my devi driver with -P and -r).

My current devi driver works just fine as an input source to gf (i.e. gfi).  The output matches exactly what my gf_* based UI code sees.

> You might be able to ask your support rep for a recent build of libinput.a. Oh

>  and I should of mentioned, that I believe you should be start your devi-*

> driver with -r and -P. And note, the debug output of the devi-* may not always

>  reflect what you get from composition manager. The debug output is printing

> events going into the photon interface. Composition manager uses the resource

> manager interface which is similar code patch to that of gfi. So in the end

> they should be relatively similar, but something is going wrong after the code

>  paths fork, it wouldn't be reflected in the debug output. It's generally

> better to see what you get out of the raw res manager interface from input. E.

> g. /dev/devi/touch0.

>

> -Joel

>

> -----Original Message-----

> From: Gary Faulkner [mailto:community-noreply@qnx.com]

> Sent: December 17, 2009 3:15 PM

> To: cwm-graphics

> Subject: Re: RE: touchscreen events in gles1-kd-gears demo app

>

> Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto

> set in the winmgr.conf (as an aside, pointer-qsize = 1 does not work for me -

> I don't get any events at all).

>

> So, where would I get a fixed libinput.a?  Especially since there isn't a new

> version of the devi ddk available for 6.4.x?

post44066: RE: RE: touchscreen events in gles1-kd-gears demo app

Joel Pilon(deleted) — Thu, 17 Dec 2009 20:31:50 GMT

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?

post44063: Re: RE: touchscreen events in gles1-kd-gears demo app

Gary Faulkner — Thu, 17 Dec 2009 20:14:38 GMT

Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto set in the winmgr.conf (as an aside, pointer-qsize = 1 does not work for me - I don't get any events at all).

So, where would I get a fixed libinput.a?  Especially since there isn't a new version of the devi ddk available for 6.4.x?

> You can try including "pointer-qsize = auto" or "pointer-qsize = 1" in the

> globals section of your winmgr.conf. There's been some fixes to the framework

> for input drivers to help make them more responsive, unfortunately it requires

>  that each devi-* driver be recompiled with the libinput.a which contain these

>  corrections. The idea case would be having the devi-* driver compiled with a

> recent libinput.a and "pointer-qsize = auto". Without the fixes however the "

> auto" feature won't function properly, and could explain the behavior your

> seeing.

>

> -Joel

>

> -----Original Message-----

> From: Gary Faulkner [mailto:community-noreply@qnx.com]

> Sent: Thu 12/17/2009 2:39 PM

> To: cwm-graphics

> Subject: touchscreen events in gles1-kd-gears demo app

>

> Hello:

>

> I'm trying to make sure that our touchscreen events are seen in an openkode/CM

>  application.  I have put a printf in the case for KD_EVENT_INPUT_POINTER in

> the main event loop to indicate when touches occurr.

>

> My problem is that what I'm getting in the app is different from what I get

> from the debug from my devi* driver.  It reports the correct coordinates/"

> button state", but two odd things are happening in the gles1-kd-gears

> application.

>

> First, the touches seem to be "bunched".  That is, I seem to get a group of 5

> or 6 of them at a time, and they are not happening immediately when I touch

> the screen.

>

> Second, the values are, for the most part, wrong; except for the first value.

>

> I'm doing this as testing prior to migrating our UI to CM.

>

> This is on the stock 6.4.1 io-winmgr.

>

> Any ideas on what is going on here, and how I can make these events get

> delivered "as they happen"??  Is there something special that I need to do in

> my devi* driver (aside from obviously starting it with -r)?

>

> Thanks!!

>

> -garyf

>

>

>

> _______________________________________________

>

> CWM/OpenKODE

> http://community.qnx.com/sf/go/post44051

>

>

post44052: RE: touchscreen events in gles1-kd-gears demo app

Joel Pilon(deleted) — Thu, 17 Dec 2009 19:52:59 GMT

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

post44051: touchscreen events in gles1-kd-gears demo app

Gary Faulkner — Thu, 17 Dec 2009 19:39:56 GMT

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

post39741: Re: Screen capture

Joel Pilon(deleted) — Mon, 12 Oct 2009 19:14:19 GMT

Unfortunately, we don't have any kind of utilities to do this. It's a feature we may add in the future.

However, there is vga capture devices on the market that could be used to capture screen shots.

post38499: Screen capture

Chirag Shah(deleted) — Tue, 22 Sep 2009 16:58:18 GMT

Is there a command line way to capture the screen and save to a file?

post35967: Re: the problem about create windows by thread

hu xiaohua — Fri, 14 Aug 2009 00:46:35 GMT

> 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.

post35907: Re: help with CM when using GF

Etienne Belanger(deleted) — Thu, 13 Aug 2009 13:22:56 GMT

When you look at the differences between the GF version and the same code converted to OpenKODE/EGL, you find that there aren't that many differences. However, making those changes, even if there are just a few, isn't always easy...

The two big differences for GF apps rendering in OpenKODE windows are:

1) no layers; that's because with GF, the only "compositing" strategy is to use display controller layers. The compositied windowing system that handles OpenKODE windows can use other hardware like 2D cores, VG cores, or 3D cores.

2) different surfaces; you have to use EGL surfaces and not GF surfaces.

If in the end each application has its own layer, you don't necessarily need the composited windowing system. The same thing can be done with plain GF. However, OpenKODE also gives you better events, delegates (which can be used to control other GF apps), and allows you to have multiple applications on the same layer (only one visible at any point in time). All of this cannot be done using GF only.

http://community.qnx.com/svn/repos/graphics/trunk/apps/kd/tutorials/gf-kd-vsync/gf-kd-vsync.c is the OpenKODE equivalent of http://community.qnx.com/svn/repos/graphics/trunk/apps/egl/tutorials/gf-egl-vsync/gf-egl-vsync.c

gf_draw_blit2 and gf_draw_blitscaled can still be used quite easily if one of the surfaces (source or destination) isn't an EGL surface. If you need to blit from an EGL surface to another EGL surface, you have 4 options:

1) blitting can be done with a Khronos rendering API like OpenGL ES, or OpenVG. In this case, you cannot blit directly from an EGL surface to another EGL surface. The source must be an object like a VGImage or a GL ES texture.

2) Use the EGL_QNX_gf_surface extension which will give you the gf_surface_t corresponding to the current renderbuffer of an EGL surface. This obviously only works if the EGL_QNX_gf_surface extension is supported, which may not always be the case.

3) Use the EGL_KHR_lock_surface extension, which allows software renderers to write their output to EGL surfaces. With this extension, you can get a CPU accessible address, the stride, and the bit offsets of each color component of an EGL surface. You can use gf_surface_attach and gf_surface_reattach to wrap it as a gf_surface_t. You will have to get the rest of the information from other calls, i.e. eglQuerySurface to get the width and height, and eglGetConfigAttrib to get the pixel format. Once an EGL surface is locked, it must be unlocked before you can do things with it, like eglMakeCurrent or eglSwapBuffers. Each time a surface is locked, the pointer and stride returned could be different from the last time. This is where gf_surface_reattach becomes useful...

4) Use eglCreatePixmapSurface for offscreen renderbuffers. The native pixmap is always a GF surface, which you can use as argument to gf_draw_blit2 and gf_draw_blitscaled. The EGL surface can be used as argument to eglMakeCurrent, etc.

Now, getting back to square one, depending on what you are trying to do, there might be an easier approach than the generic solutions I have outlined here.

post35893: Re: the problem about create windows by thread

Etienne Belanger(deleted) — Thu, 13 Aug 2009 12:25:29 GMT

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.

post35873: help with CM when using GF

Adrian Higgins — Thu, 13 Aug 2009 06:28:55 GMT

Howdy

I'm converting a project from using GF only API to using the composition manager.

I was lead to believe it would be a simple matter of substituting a few init calls...but as is usually the case, it's more complex than that.

I understand that because I will have multiple applications requiring their own layers, I must use KD.

Is this correct?

Ideally I'd like something like:

http://community.qnx.com/svn/repos/graphics/trunk/apps/egl/tutorials/gf-egl-vsync/gf-egl-vsync.c

But I can't get this to work with the composition manager.

Would this be becuase the concept of windows and multiple layers is one and the same?

Anywho, I have managed to get the images displayed (albeit momentarily...probably something to do with swaping buffers, that'll be my next challenge) by substituing gf calls with kd or egl calls eg:

gf_dev_attach and gf_display_attach() -> eglGetDisplay() eglInitialize()

gf_layer_attach() -> kdCreateWindow() kdRealizeWindow()

gf_surface_create_layer() or gf_surface_create -> eglCreateWindowSurface()

And due to not having a gf_dev_info :

gf_context_set_surface() -> gf_context_set_surface_3d() and/or eglMakeCurrent()

The issue I'm now having is finding replacements for gf_draw_blit2() and gf_draw_blitscaled() as they require gf surfaces, not egl surfaces?

Is there a way to cast egl surfaces to gf surfaces?

I'm currently just using the main surface for each image, and therefore all images are dumped on top of each other, followed by all being dumped on by a full screen white fill (not sure why the screen is turning white...again that'll be the challenge after the next).

Also, I haven't found a substitue for gf_surface_get_info() yet...this is required for size, format, stride...

Am I correct in thinking this would be defined by the chosen egl_conf?

The application is using the img library.

Is there a simpler way to manage these images than directly using gf blit?

Keep in mind, at this stage there are no 3D elements required, egl is only being used to increase the number of layers available.

Any help would be appreciated.

Cheers

Adrian

post35869: Re: the problem about create windows by thread

hu xiaohua — Thu, 13 Aug 2009 02:26:23 GMT

> 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()

post35867: the problem about create windows by thread

hu xiaohua — Thu, 13 Aug 2009 01:49:22 GMT

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.

post35202: Re: Some questions about the HMI flash and the video window

Etienne Belanger(deleted) — Tue, 04 Aug 2009 19:00:52 GMT

The usage of delegates in the attached diagram does not follow conventional usage. Events usually flow from windows to their delegates, and not the other way around. Additionally, if a window is itself a delegate, notifications about it won't be sent to other delegates. In short, if the HMI and Video apps are delegates, than the HMI cannot change or talk to the Video window.

What I would do is the following:

*Create HMI window, and register it as a delegate

*Create Video window (but not as delegate)

*Make HMI be the delegate of the Video application, i.e. respond to create event by setting the Video window's delegate to HMI window

*Send OpenKODE user events to video application when play and stop buttons are pushed. You can do this in the HMI because, as a delegate, it received a window handle in the create event.

If the HMI is responsible for choosing the size of the Video window, I would have it launch the application after setting the KD_WINDOWPROPERTY_SIZE=(width)x(height) in the environment. (Note that all window properties can be set this way, or by using classes)

If you must create and destroy the window when the play and stop buttons are pressed, then I would still use OpenKODE events, except that the Video app has to respond to those by first creating the window, or finish by destroy it, depending if it receives the play or stop user event from the HMI.

You can use kdGetWindowPropertyiv(KDWindow *window, KD_WINDOWPROPERTY_SIZE, KDint32 *size) to get the size of a window.

post35124: Some questions about the HMI flash and the video window

hu xiaohua — Sun, 02 Aug 2009 11:58:10 GMT

Hi,I met some questions about the HMI flash and the video window.

I'm afraid that you don't know the question I said,I write the information of system and questins in the appendix.

Thank you very much!

post34875: The event of KD_QNX_WINDOWPROPERTY_POSITION handled

hu xiaohua — Thu, 30 Jul 2009 06:56:14 GMT

I read this code but can't understand something.

gles1-kd-hmi.c

/**

** gles1-kd-hmi

** Windowed HMI example that uses OpenGL ES 1.X for rendering API.

**

*/

#include <ctype.h>         /* Header file for isdigit */

#include <stdio.h>      /* Header file for fprintf */

#include <stdlib.h>     /* Header file for EXIT_FAILURE, EXIT_SUCCESS, atoi */

#include <string.h>     /* Header file for strncmp */

#include <EGL/egl.h>    /* Header file for EGL */

#include <KD/kd.h>      /* Header file for OpenKODE */

#include <GLES/gl.h>    /* Header file for OpenGL ES 1.X */

#include "error.h"

/* dynamically allocated array where we keep information on windows */

KDint32 *windows = NULL;

/* the value of nwin is the number of entries in the windows array */

unsigned nwin = 0;

/* dynamically allocated array where vertices are kept */

GLshort *points = NULL;

/* number of entries in points used; the size of points is nwin * 16 */

GLint nvtx = 0;

static void add_window(KDWindow *kd_hmi_win, KDWindow *kd_win)

{

        kdSetWindowPropertyiv(kd_win,

        KD_QNX_WINDOWPROPERTY_DELEGATE, (KDint32 *)kd_hmi_win);

}

static void set_border(int wid, KDWindow *kd_win, KDint32 kd_size[2])

{

    GLshort *new_points;

    KDint32 *new_windows;

    KDint32 kd_dst_rect[4];

    KDint32 kd_rect[4];

    KDint32 vid;

    KDint32 rc;

    unsigned i;



    rc = kdGetWindowPropertyiv(kd_win,

        KD_QNX_WINDOWPROPERTY_POSITION, kd_dst_rect);

    rc |= kdGetWindowPropertyiv(kd_win,

        KD_WINDOWPROPERTY_SIZE, kd_dst_rect+2);

    if (rc || kd_dst_rect[2] == 0 || kd_dst_rect[3] == 0) {

        return;

    }



    if (wid == 0) {

        for (i = 0; i < nwin; i++) {

            if (windows[i] == -1) {

                wid = i+1;

                break;

            }

        }

    }

     if (wid == 0) {

        new_windows = realloc(windows, (nwin + 1) * sizeof(*windows));

        if (new_windows == NULL) {

            return;

        }

        windows = new_windows;

        windows[nwin] = -1;

        wid = ++nwin;

    }

    kdSetWindowPropertyiv(kd_win,

        KD_QNX_WINDOWPROPERTY_DELEGATE_POINTER, &wid);

    wid--;

    if (windows[wid] == -1) {

        new_points = realloc(points, (nwin + 1) * 16 * sizeof(*points));

        if (new_points == NULL) {

            return;

        }

        /* We will use one vertex array for all of our rendering */

        points = new_points;

        glVertexPointer(2, GL_SHORT, 0, (const GLvoid *)points);

        glEnableClientState(GL_VERTEX_ARRAY);

        windows[wid] = nvtx;

        nvtx += 16;

    }



    kd_rect[0] = kd_dst_rect[0] + 1;

    kd_rect[1] = kd_dst_rect[1] + 1;

    kd_rect[2] = kd_dst_rect[0] + kd_dst_rect[2];

    kd_rect[3] = kd_dst_rect[1] + kd_dst_rect[3];

    vid = windows[wid];

    points[vid++] = kd_rect[0];

    points[vid++] = kd_size[1] - kd_rect[3];

    points[vid++] = kd_rect[0];

    points[vid++] = kd_size[1] - kd_rect[1];

    points[vid++] = kd_rect[0];

    points[vid++] = kd_size[1] - kd_rect[1];

    points[vid++] = kd_rect[2];

    points[vid++] = kd_size[1] - kd_rect[1];

    points[vid++] = kd_rect[2];

    points[vid++] = kd_size[1] - kd_rect[1];

    points[vid++] = kd_rect[2];

    points[vid++] = kd_size[1] - kd_rect[3];

    points[vid++] = kd_rect[2];

    points[vid++] = kd_size[1] - kd_rect[3];

    points[vid++] = kd_rect[0];

    points[vid++] = kd_size[1] - kd_rect[3];

}

static void remove_border(int wid)

{

    unsigned i; /* loop counter */



    if (wid == 0) {

        return;

    }

    wid--;

    for (i = 0; i < nwin; i++) {

        if (windows[i] > windows[wid]) {

            /* 4 lines, 8 vertices, 16 elements */

            windows[i] -= 16;

        }

    }

    /* Decrease the total element count by 16 as well */

    nvtx -= 16;

    memmove(&points[windows[wid]], &points[windows[wid] + 16],

        (nvtx - windows[wid]) * sizeof(GLshort) * 2);

    windows[wid] = -1;

}

KDint kdMain(KDint argc, const KDchar *const *argv)

{

    EGLDisplay egl_disp;

    EGLConfig egl_conf;

    EGLSurface egl_surf;

    EGLContext egl_ctx;

    KDWindow *kd_win;

    EGLNativeWindowType egl_win;

    KDint32 kd_size[2];

    EGLint interval = 1;

    EGLBoolean verbose = EGL_FALSE;

    const KDEvent *event;

    KDboolean kd_bool = KD_TRUE;

    const char *conf_str = NULL;

    GLfloat r, g, b;

    int rval = EXIT_FAILURE;

    int rc;

    int i;



    egl_disp = eglGetDisplay(EGL_DEFAULT_DISPLAY);

    if (egl_disp == EGL_NO_DISPLAY) {

        egl_perror("eglGetDisplay");

        goto fail1;

    }

    rc = eglInitialize(egl_disp, NULL, NULL);

    if (rc != EGL_TRUE) {

        egl_perror("eglInitialize");

        goto fail2;

    }

    egl_conf = choose_config(egl_disp, conf_str);

    if (egl_conf == (EGLConfig)0) {

        goto fail2;

    }



    kd_win = kdCreateWindow(egl_disp, egl_conf, KD_NULL);

    if (kd_win == KD_NULL) {

        kd_perror("kdCreateWindow");

        goto fail2;

    }



    rc = kdSetWindowPropertybv(kd_win, KD_QNX_WINDOWPROPERTY_DELEGATE, &kd_bool);

    if (rc) {

        kd_perror("KD_QNX_WINDOWPROPERTY_DELEGATE");

        goto fail3;

    }



    eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_TYPE, &i);

    if (i == EGL_TRANSPARENT_RGB) {

        eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_RED_VALUE, &i);

        r = (float)i / 255;

        eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_GREEN_VALUE, &i);

        g = (float)i / 255;

        eglGetConfigAttrib(egl_disp, egl_conf, EGL_TRANSPARENT_BLUE_VALUE, &i);

        b = (float)i / 255;

    } else {



        rc = kdSetWindowPropertybv(kd_win, KD_QNX_WINDOWPROPERTY_SOURCE_ALPHA, &kd_bool);

        if (rc) {

            kd_perror("KD_QNX_WINDOWPROPERTY_SOURCE_ALPHA");

            goto fail3;

        }

        r = 0.0f;

        g = 0.0f;

        b = 1.0f;

    }



    rc = kdRealizeWindow(kd_win, &egl_win);

    if (rc) {

        kd_perror("kdRealizeWindow");

        goto fail3;

    }



    egl_surf = eglCreateWindowSurface(egl_disp, egl_conf, egl_win, NULL);

    if (egl_surf == EGL_NO_SURFACE) {

        egl_perror("eglCreateWindowSurface");

        goto fail3;

    }



    egl_ctx = eglCreateContext(egl_disp, egl_conf, EGL_NO_CONTEXT, NULL);

    if (egl_ctx == EGL_NO_CONTEXT) {

        egl_perror("eglCreateContext");

        goto fail4;

    }



    rc = eglMakeCurrent(egl_disp, egl_surf, egl_surf, egl_ctx);

    if (rc != EGL_TRUE) {

        egl_perror("eglMakeCurrent");

        goto fail5;

    }



    rc = eglSwapInterval(egl_disp, interval);

    if (rc != EGL_TRUE) {

        egl_perror("eglSwapInterval");

        goto fail2;

    }



    kdGetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, kd_size);



    /* Set the viewport and projection matrix */

    glViewport(0, 0, kd_size[0], kd_size[1]);

    glMatrixMode(GL_PROJECTION);

    glOrthof(0.0f, kd_size[0], 0.0f, kd_size[1], -1.0f, 1.0f);

    glMatrixMode(GL_MODELVIEW);

    /* Set the clear color to the transparent color or black */

    glClearColor(r, g, b, 0.0f);

    /* We will draw all of our borders red */

    glColor4f(1.0f, 0.0f, 0.0f, 1.0f);



    while (1) {



        event = kdWaitEvent(1000000000);

        if (event == KD_NULL) {



            if (kdGetError() != KD_EAGAIN) {

                /* to exit cleanly, all we need to to break from this loop */

                break;

            } else {

                /* timeouts are normal; we'll just wait another second */

                continue;

            }

        }

        switch (event->type) {

            /**

             ** Events for other windows

             **/

            case KD_QNX_EVENT_WINDOW_CREATE:



                add_window(kd_win, event->data.windowcreateqnx.window);

                continue;

            case KD_QNX_EVENT_WINDOW_REALIZE:



                set_border((int)event->userptr,

                    event->data.windowrealizeqnx.window, kd_size);

                break;

            case KD_QNX_EVENT_WINDOW_PROPERTY:



                switch (event->data.windowpropertyqnx.pname) {



                    case KD_WINDOWPROPERTY_SIZE:

                    case KD_QNX_WINDOWPROPERTY_POSITION:

                        set_border((int)event->userptr,

                            event->data.windowpropertyqnx.window, kd_size);

                        break;

                    case KD_WINDOWPROPERTY_VISIBILITY:



                        kdGetWindowPropertybv(event->data.windowpropertyqnx.window,

                            KD_WINDOWPROPERTY_VISIBILITY, &kd_bool);

                        if (kd_bool) {

                            set_border((int)event->userptr,

                                event->data.windowpropertyqnx.window, kd_size);

                        } else {



                            remove_border((int)event->userptr);

                        }

                        break;

                }

                break;

            case KD_QNX_EVENT_WINDOW_CLOSE:



                remove_border((int)event->userptr);

                break;

            case KD_EVENT_WINDOW_CLOSE:



                goto end;

            default:



                kdDefaultEvent(event);

                continue;

        }

        /* Start by clearing with transparency everywhere */

        glClear(GL_COLOR_BUFFER_BIT);

        if (nvtx > 0) {

            /* Draw our borders using GL_LINES */

            glDrawArrays(GL_LINES, 0, nvtx/2);

        }

         rc = eglSwapBuffers(egl_disp, egl_surf);

        if (rc != EGL_TRUE) {

            egl_perror("eglSwapBuffers");

            break;

        }

    }

end:

    rval = EXIT_SUCCESS;



    eglMakeCurrent(egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);

fail5:

    eglDestroyContext(egl_disp, egl_ctx);

fail4:

    eglDestroySurface(egl_disp, egl_surf);

fail3:

    kdDestroyWindow(kd_win);

fail2:

    eglTerminate(egl_disp);

    eglReleaseThread();

fail1:

    return rval;

}

__SRCVERSION( "$URL: http://svn.ott.qnx.com/product/trunk/apps/kd/tutorials/gles1-kd-hmi/gles1-kd-hmi.c $ $Rev: 220409 $" );

when an event of KD_QNX_WINDOWPROPERTY_POSITION received,call the function of set_border.The first step get the new size of window by kdGetWindowPropertyiv(kd_win, KD_WINDOWPROPERTY_SIZE, kd_size).

But the new size is not included in the event,where to get the size?

How to change the window size by composition window manager?

post34786: Re: Post event to a window that created by another application

hu xiaohua — Wed, 29 Jul 2009 13:35:03 GMT

I'm very sorry.This documentions had been read.The framework of event and window cann't understand.For example:

1.The HMI flash contains some play buttons.These buttons control the video play.

2. The window that video picture display created

3.The window under the HMI flash

4.The flash player will register itself as a delegate with io-winmgr

5.The kdMain function that video display window created receive event and handled

I don't know these questions

1.How to transfer the event of touching button to composition window manager

2.The composition window manager tranfer the pointer input event to the kdMain,or tranfer the window create event to the kdMain?

3.It can create some KDwindows in a kdMain window?

Thank you very much!

post34781: Re: Post event to a window that created by another application

Etienne Belanger(deleted) — Wed, 29 Jul 2009 12:46:47 GMT

Yes, the windowing system is the composition manager.

You can manually create events with kdCreateEvent and send it to another window using kdPostWindowEventQNX.

The composition manager implements the OpenKODE 1.0.2 specification, as part as events goes, so it is a good place to start. Any changes are documented in our two extensions, KD_QNX_window and KD_QNX_input.

http://www.khronos.org/registry/kode/specs/openkode.1.0.2.pdf

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/kd_qnx_window.html

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/kd_qnx_input.html

post34760: Re: Post event to a window that created by another application

hu xiaohua — Wed, 29 Jul 2009 00:54:19 GMT

I'm very sorry.

The windowing system is composition manager?

How to create an event with composition manager?

How to get the documentation about the event framework of composition manager?

Thank you very much!

post34741: Re: Post event to a window that created by another application

Etienne Belanger(deleted) — Tue, 28 Jul 2009 16:12:33 GMT

These events come from the windowing system.

post34733: Re: Post event to a window that created by another application

hu xiaohua — Tue, 28 Jul 2009 15:15:44 GMT

I read the program gles1-hmi.

Receive event and create window program:

event_win = KDWaitEvent(1000000);

if(event_win == KD_NULL){

    return ;

}

switch(event_win->type){

    case KD_QNX_EVENT_WINDOW_CREATE:

            set the window with delegates of composition manager

            continue;

    case KD_QNX_EVENT_WINDOW_REALIZE:

            set border of window

            break;

    case KD_QNX_EVENT_WINDOW_PROPERTY:

            change the size or position of window

            break;

   case KD_QNX_EVENT_WINDOW_CLOSE:

           remove the border of window

          break;

}

I don't know the event where come from?

Another application post event?

OpenKode core post event?

Thank you very much!

post34700: Re: Post event to a window that created by another application

Etienne Belanger(deleted) — Tue, 28 Jul 2009 12:23:21 GMT

Normally, this function would be used by applications with a window registered as delegate. Delegates receive events whenever a window is created. Information contained in the event includes a KDWindow* that the application can use to make such calls.

For now, we don't provide any other mechanism for non-delegate applications to send events to other processes. Do you mind summarizing what you intended doing with these cross-process KD events ?

post34694: Post event to a window that created by another application

hu xiaohua — Tue, 28 Jul 2009 11:55:14 GMT

Hi,I try to post a event to a window that created by another application by kdPostWindowEventQNX.

The "KD_QNX_window" documentation:

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/kd_qnx_window.html refers to post an event into another application's queue.

But what is the value of window argument?

How to know the pointer of window?

post34604: Re: The HMI interact with applications

Etienne Belanger(deleted) — Mon, 27 Jul 2009 12:57:42 GMT

The Flash composition manager plugin (hmip-compmgr) has a configuration option that controls if the player will register itself as a delegate with io-winmgr. When "window_manager" is set to true, the Flash player will start receiving notifications from the Composition Manager whenever new windows are created, existing windows are deleted, or when a window's property has changed. The composition manager will allow the HMI to control windows is if they were its own.

The feature that gives an HMI access to another application's buffers is still under development.

post34594: The HMI interact with applications

hu xiaohua — Mon, 27 Jul 2009 06:11:15 GMT

Hi,I try to create a video player that the flash HMI and video display application.

The flash HMI contain the play button and stop button.The video display application is that display picture by OpenVG.The HMI flash is on the head of graphics layer,the application is on the second graphics layer.

The "Enabling the HMI" documentation:

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/overview.html refers to

How to the flash HMI commnicate with the OpenKode?

if there aren't the flash HMI the application can run correctly,add to the flash HMI the applications need to chang?

How to the HMI call io-winmgr to access application buffers?

Thank you very much!

post32385: Re: Failed to post event by kdPostWindowEventQNX

hu xiaohua — Wed, 24 Jun 2009 00:53:27 GMT

Thank you very much !

I have soult out the question with your help!

post32318: Re: Failed to post event by kdPostWindowEventQNX

Etienne Belanger(deleted) — Tue, 23 Jun 2009 14:57:30 GMT

kdPostWindowEventQNX will return KD_EOPNOTSUPP if the event type is not one of KD_EVENT_WINDOW_CLOSE, KD_EVENT_WINDOW_REDRAW, KD_EVENT_WINDOW_FOCUS, KD_EVENT_WINDOWPROPERTY_CHANGE, KD_EVENT_STATE, KD_EVENT_INPUT, KD_EVENT_INPUT_JOG, KD_EVENT_INPUT_POINTER, KD_EVENT_INPUT_STICK, KD_EVENT_USER, KD_QNX_EVENT_KEYBOARD, KD_QNX_EVENT_WINDOW_CREATE, KD_QNX_EVENT_WINDOW_REALIZE, KD_QNX_EVENT_WINDOW_PROPERTY, or KD_QNX_EVENT_WINDOW_CLOSE.

To answer your specific questions, the error code returned by kdGetError is not changed unless kdSetError is called or another OpenKODE function sets the value as specified for that function.

kdPostThreadEvent would normally be used to post events from one thread to another. However, this function isn't implemented in QNX yet, so your best be is to stick with kdPostWindowEventQNX for now.

post32300: Failed to post event by kdPostWindowEventQNX

hu xiaohua — Tue, 23 Jun 2009 13:44:24 GMT

Hi, everyone!

I want to post an event from a thread to the window(or thread) that created by kdCreateWindow.The environmoment of platform is QNX 6.4.0 and HP(x86)PC. The process is:

1.EGL get display (ok)

2.EGL initialize(ok)

3.choose config by EGL(ok)

4.kdCreateWindow(ok)

5.kdRealizeWindow(ok)

6.kdThreadCreate(ok)

6.1 kdCreateEvent(ok)

6.2 set event data(0k)

6.3 kdPostWindowEventQNX(NG)

7.kdWaitEvent(event nothing)

※6.1 6.2and 6.3 is sub thread process

6.3error id is 31(KD_EOPNOTSUPP)operation not supported.

My question:

1.How to clear the error?

2.There is another method to post a event from thread to window(or thread)?

post31760: Re: RE: RE: Bulid error : OpenKode,OpenVG

Dennis Kellly(deleted) — Mon, 15 Jun 2009 16:13:57 GMT

Regarding the compile error, check for a line like

__SRCVERSION( "$URL: http://svn.ott.qnx.com/product/trunk/...

at the end of include .h files. If it is there, comment it and rebuild.

post31602: Re: How to kill sub_thread in OpenKode??

Etienne Belanger(deleted) — Fri, 12 Jun 2009 12:36:37 GMT

kdPostThreadEvent isn't implemented in 6.4.1 yet. That's why you are having problems.

kdPostWindowEventQNX is, but as you know, you need a window. The ability to create multiple OpenKODE windows that share the same buffers is something we are considering adding as an extension. This isn't possible with the way OpenKODE Core does things, because normally you create an EGL surface for a native (OpenKODE) window, not the other way around.

You can always create and realize OpenKODE windows to get events going with kdPostWindowEventQNX. Unless you call eglCreateWindowSurface, the overhead is pretty small.

post31583: Re: How to kill sub_thread in OpenKode??

Yin Xingmin — Fri, 12 Jun 2009 02:20:23 GMT

Yes. I know. Thank you very much!

I have another problem.

I'm doing my development with QNX Software Development Platform 6.4.1. The kdPostThreadEvent() seems to cannot work well.

If I want to post event between threads, it seems that I can only use the kdPostWindowEventQNX() right now.

Can I create numbers of kdWindow with the same EGLSurface?

Regards,

Yin

post31481: Re: How to kill sub_thread in OpenKode??

Etienne Belanger(deleted) — Thu, 11 Jun 2009 13:35:56 GMT

Not necessarily. It still needs to "cooperate" and do a kdThreadExit upon reception of the user event. You can always use system calls like pthread_abort or ThreadDestroy, but in this case, you are no longer getting the portability that OpenKODE is meant to provide.

post31479: Re: How to kill sub_thread in OpenKode??

Yin Xingmin — Thu, 11 Jun 2009 13:31:33 GMT

Thank you very much!

If I use the event to inform the sub thread to exit, will the thread be suspended when waiting for the event?

Or,could I use the QNX's function to terminate the sub thread?(e.g. pthread_abort(), ThreadDestroy())

Regards,

Yin

post31470: Re: How to kill sub_thread in OpenKode??

Etienne Belanger(deleted) — Thu, 11 Jun 2009 12:44:05 GMT

As far as I understand the spec, there is no way for one OpenKODE thread of "killing" another thread that is still running. The standard way of handling threads is to do a kdThreadExit/kdThreadJoin, or kdThreadDetach/kdThreadExit. You can always try to post a user event to that thread hoping that it will get it and respond with a kdThreadExit, but it's not as convenient as killing it from another thread.

post31463: Re: RE: RE: Bulid error : OpenKode,OpenVG

liu liming(deleted) — Thu, 11 Jun 2009 11:50:49 GMT

Hi,Gaétan

   Thanks for your answer and I had finished this question.



   1.When I use your header file in qnx6.4.0, complied failed beacause there is no sys/srcversion.h in qnx6.4.0

   2.So I update my os to Qnx6.4.1, then everything becames ok.

   Thanks very much for your answer.And best regard.

Liu Liming

> Hi Liu,

> Here are a few more comments / clarifications:

>

> 1- a) libOpenVG-G12.so.1 doesn't need a .so link (but libOpenVG.so.1 does)

> b) You should also keep the .so.1 files around, so in the end you should

> have two copies of the same files, one .so.1 and one .so

>

> 2- a) Have you tried using the header files I had attached to my previous

> post?  The problem with the files you had was at the end of the files, where

> there's a call to __SRCVERSION (and in some files an #include of <sys/srcversion.h>, and 6.4

> doesn't have these defined.  It is safe to remove these lines.

> b) I suppose you have taken vgext.h from Khronos (as we don't provide this

> file...)?  Our OpenVG implementation doesn't support the KHR extensions, so

> you should not be including this file from your application.

>

> 3- VGImage is defined in openvg.h, so if your application includes openvg.h (

> as it appears to be doing) and it still causes compilation problems even with

> the __SRCVERSION references removed (as in the files I had previously attached

> ), then chances are there's a problem in your code before the #include

> statement.  The openvg.h file comes directly from Khronos.  If after steps one

>  and two above you are still having compilation problems, please attach the

> new build output (as it will be different than what you had previously

> attached).

>

> Regards,

> Gaétan

>

> -----Original Message-----

> From: liu liming [mailto:community-noreply@qnx.com]

> Sent: June 8, 2009 9:57 PM

> To: cwm-graphics

> Subject: Re: RE: Bulid error : OpenKode,OpenVG

>

> Hi Gaétan,

>   Thanks your answer and I followed your advice.

>

> 1.I changed the filename

> libEGL.so.1 ->libEGL.so

> libgf.so.1 ->libgf.so

> libGLESv1_CM.so.1 ->libGLESv1_CM.so

> libGLES_CM.so.1 ->libGLES_CM.so

> libKD.so.1 -> libKD.so

> libWFD.so.1 ->libWFD.so

> libOpenVG.so.1 ->libOpenVG.so

> libOpenVG-G12.so.1 -> libOpenVG-G12.so

>

> 2.I checked my include file of

> "C:\QNX640\target\qnx6\usr\include\VG", and get the result.I think it will be

> ok.

> ------------------------------------------------------------------

> 2009/06/05  17:18 34,982 openvg.h

> 2009/06/05  17:18 9,892 ovg11_api_backend.h

> 2009/06/05  17:18 2,481 ovg_backend.h

> 2009/06/05  17:18 1,658 ovg_driver_backend.h

> 2009/06/05  17:50 10,083 vgext.h

> 2009/06/05  17:18 3,188 vgplatform.h

> 2009/06/05  17:18 5,812 vgu.h

> ------------------------------------------------------------------

>

> 3.And I set the other option of linker tab to:

> "-lgf -lEGL -lasound -lkd -lOpenVG  -lOpenVG-G12"

> But the error message is same.

>

> Then I change the other option of linker tab to:

> "-lgf -lEGL -lasound -lkd -lOpenVG"

> and got the same error message.

>

> Best Regards

>

> Liu Liming

>

>

> _______________________________________________

> CWM/OpenKODE

> http://community.qnx.com/sf/go/post31173

post31461: How to kill sub_thread in OpenKode??

Yin Xingmin — Thu, 11 Jun 2009 09:18:52 GMT

Hi,

I had created a sub_thread in the kdMain.

But how can I kill the sub_thread in kdMain? Is there any API to kill the sub_thread or is there any method to kill the sub_thread?(The kdMain will be still running.)

Thank you for your suggestion!!

post31327: RE: RE: Bulid error : OpenKode,OpenVG

Gaétan Noël — Wed, 10 Jun 2009 12:55:27 GMT

Hi Liu,

Here are a few more comments / clarifications:

1- a) libOpenVG-G12.so.1 doesn't need a .so link (but libOpenVG.so.1 does)

b) You should also keep the .so.1 files around, so in the end you should have two copies of the same files, one .so.1 and one .so

2- a) Have you tried using the header files I had attached to my previous post?  The problem with the files you had was at the end of the files, where there's a call to __SRCVERSION (and in some files an #include of <sys/srcversion.h>, and 6.4 doesn't have these defined.  It is safe to remove these lines.

b) I suppose you have taken vgext.h from Khronos (as we don't provide this file...)?  Our OpenVG implementation doesn't support the KHR extensions, so you should not be including this file from your application.

3- VGImage is defined in openvg.h, so if your application includes openvg.h (as it appears to be doing) and it still causes compilation problems even with the __SRCVERSION references removed (as in the files I had previously attached), then chances are there's a problem in your code before the #include statement.  The openvg.h file comes directly from Khronos.  If after steps one and two above you are still having compilation problems, please attach the new build output (as it will be different than what you had previously attached).

Regards,

Gaétan

-----Original Message-----

From: liu liming [mailto:community-noreply@qnx.com]

Sent: June 8, 2009 9:57 PM

To: cwm-graphics

Subject: Re: RE: Bulid error : OpenKode,OpenVG

Hi Gaétan,

  Thanks your answer and I followed your advice.

1.I changed the filename

libEGL.so.1 ->libEGL.so

libgf.so.1 ->libgf.so

libGLESv1_CM.so.1 ->libGLESv1_CM.so

libGLES_CM.so.1 ->libGLES_CM.so

libKD.so.1 -> libKD.so

libWFD.so.1 ->libWFD.so

libOpenVG.so.1 ->libOpenVG.so

libOpenVG-G12.so.1 -> libOpenVG-G12.so

2.I checked my include file of

"C:\QNX640\target\qnx6\usr\include\VG", and get the result.I think it will be ok.

------------------------------------------------------------------

2009/06/05  17:18 34,982 openvg.h

2009/06/05  17:18 9,892 ovg11_api_backend.h

2009/06/05  17:18 2,481 ovg_backend.h

2009/06/05  17:18 1,658 ovg_driver_backend.h

2009/06/05  17:50 10,083 vgext.h

2009/06/05  17:18 3,188 vgplatform.h

2009/06/05  17:18 5,812 vgu.h

------------------------------------------------------------------

3.And I set the other option of linker tab to:

"-lgf -lEGL -lasound -lkd -lOpenVG  -lOpenVG-G12"

But the error message is same.

Then I change the other option of linker tab to:

"-lgf -lEGL -lasound -lkd -lOpenVG"

and got the same error message.

Best Regards

Liu Liming

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post31173

post31324: RE: RE: setting bit depth for OpenVG flash-player via composition manager?

Roger Maclean — Wed, 10 Jun 2009 12:41:03 GMT

Yes, you should find they change significantly before and after

io-winmgr is running.

post31315: Re: RE: setting bit depth for OpenVG flash-player via composition manager?

Mate Szarvas(deleted) — Wed, 10 Jun 2009 11:54:18 GMT

Ohhh! So I need the to get the configs for winmgr.conf before starting io-winmgr and need to get them for flash.conf after starting io-winmgr.

Was trying to use the configs from before starting io-winmgr in flash.conf

Thanks for the explanation, this should let us go!

post31308: Re: Can not get event by kdWaitEvent()

liu liming(deleted) — Wed, 10 Jun 2009 10:02:41 GMT

OK, I had fix the problem.

1.In qnx , kdPostThreadEvent is not implemented and we should use the function of "kdPostWindowEventQNX" to send kdevent.

2.The receive thread must create a window and initialized it.

Thanks all very much.

post31198: RE: setting bit depth for OpenVG flash-player via composition manager?

Roger Maclean — Tue, 09 Jun 2009 13:27:05 GMT

No doubt it's all a little confusing.  As I mentioned in my previous

message, there are several EGL surfaces involved here.  The settings for

hmip-openvg.so only controls the surface used for rendering off-screen.

There is no reason why you would want this one to be tied to a layer

since it is never visible.  You would probably just want to set its

format depending on whether you're wanting to render using 16 or 32

bits.

The egl_config setting you will want to set will be the setting for the

other extension, hmip-compmgr.so.  This is the extension that deals with

the composition manager window itself.  You would want to pick a config

that has the window bit set, has red, green, blue and alpha size that

matches the format you've chosen for hmip-openvg.so and has the layer

you want.  The split in responsibilities between the two extensions are

because hmip-compmgr.so can also be used with software rendering.

As to the problems you had when you tried to set the egl_config setting

of hmip-openvg.so, is the list of egl-configs you provide those obtained

when io-winmgr was running or before?  The egl configs that are relevant

to Flash are those that are available when io-winmgr is running. If you

used the other set, you might have chosen ones without the OpenVG bit

and it would have failed.  To see what egl configs Flash  chooses for

itself, you can add the configuration setting (to the main part of the

configuration, not the extensions):

log_mask = configuration

you should see messages regarding the configuration that the player has

chosen for the render surface and window.

post31177: Re: egl-config value corresponding to a particular layer

Mate Szarvas(deleted) — Tue, 09 Jun 2009 03:54:11 GMT

Etienne, thanks for these answers (in all threads), this should let us go forward.

--

Mate

post31176: Re: setting bit depth for OpenVG flash-player via composition manager?

Mate Szarvas(deleted) — Tue, 09 Jun 2009 03:32:23 GMT

Tried using

extension {

dll = hmip_openvg.so

config {

egl_config = 11

}

}

with values for egl_config: 3, 4, 10, 11 (also tried 1 and 2 though these

are not VG renderable so no surprise).

In each case flash displayed the following lines and the screen remained blank:

emerg: hmip_openvg: Create context failed: 0x3005 config:11

emerg: framebuffer alloc (640X480) failed

The output from egl-configs is attached and the output from use -i flash is like:

NAME=flash

DESCRIPTION=FlashLite Player

DATE=2009/04/15-09:09:18-EDT

STATE=experimental

HOST=cctrunk

USER=builder

VERSION=6.4.0

TAGID=9999@218225

The board is i.mx35 custom board.

Any advice what's going wrong?

# The player displays no problem when specifying "format=565"

# and not specifying egl_config at all.

post31175: Re: setting bit depth for OpenVG flash-player via composition manager?

Mate Szarvas(deleted) — Tue, 09 Jun 2009 03:00:45 GMT

Thank you Roger.

Now I understand that using the "format" configuration value

is the preferred way.

Thought to set the egl_config value directly in order to have

control over the physical layer where the player is being placed.

Is there any other way to set the flash player to a specific

hardware layer?

# likely these questions are covered in the documentation

# but for some reason my IDE cannot display the documentation

# (windows host)

--

Mate

post31173: Re: RE: Bulid error : OpenKode,OpenVG

liu liming(deleted) — Tue, 09 Jun 2009 01:56:50 GMT

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

post31078: Re: Estimating image-bus bandwidth usage in CWM

Etienne Belanger(deleted) — Mon, 08 Jun 2009 13:51:35 GMT

For component #2, it is very difficult to estimate the total bandwidth usage for rendering a 100 x 100 window. Things to consider:

* Are all pixels touched ? If the surface is single-buffered, you could skip the clear and just redraw parts of the buffer. If the surface is double-bufferd (the default), all pixels have to be redrawn. EGL_SWAP_BEHAVIOR_PRESERVED may let the application think that it doesn't have to redraw all the pixels, but under the hood it's just a blit.

* What is the architecture of the graphics core ? Graphics core that do deferred rendering like PowerVR will only write each pixel once. If the rendering is not deferred, then clearing the surface before drawing a line will take a little more bandwidth because of the pixel overdaws.

* Are there any per-pixel image-based operations ? If a pixel requires memory lookups (texture sampling, blits, transparency masks), then the bandwidth usage will be higher. Other per-pixel operations like blending will have an impact as well.

* Are other buffers involved in the rendering process like stencil buffers, depth buffers ? What rendering API is used ? Using OpenVG, or OpenGL ES, or doing everything in software will probably affect bandwidth.

* Is anti-aliasing enabled ? Each anti-aliasing technique (full-scene, multi-sampling, coverage) and the sampling resolve will affect memory bandwidth.

For component #3, the scene layout is an important factor. The composition manager clips all the windows into rectangles so that there are no overdraws. However, overlaps when blending is enabled cannot be eliminated.

post31076: RE: Bulid error : OpenKode,OpenVG

Gaétan Noël — Mon, 08 Jun 2009 13:42:08 GMT

Hi Liu,

Normally, your files with size zero should be links to the versioned .so files (e.g. libEGL.so linked to libEGL.so.1).  Since you are running your build environment under Windows, just make a straight copy of the .so.1 files to .so, replacing the zero length files (and don't remove the .so.1).  Furthermore, you'll need to also do this for libOpenVG.so.1 (i.e. copy libOpenVG.so.1 to libOpenVG.so).

As a second comment, when using OpenVG, your application should link against libOpenVG, and not against libOpenVG-G12 (this one would be used by the driver itself).

As for the problems your getting when compiling, please try the attached header files for OpenVG.  I believe the files you have are for a 6.4.1 environment.  So basically, you should simply put the attached files in your c:/QNX640/target/qnx6/usr/include/VG/ directory on your build machine.  Please let me know how that goes.

Regards,

Gaétan

-----Original Message-----

From: liu liming [mailto:community-noreply@qnx.com]

Sent: June 8, 2009 9:14 AM

To: cwm-graphics

Subject: Bulid error : OpenKode,OpenVG

Hi,everybody

  I am writing an application with OpenKode and OpenVG.And my enviorment is :QNX6.4.0　+　Aviage　HMI　Suite　2.0

  I list my lib in "C:\QNX640\target\qnx6\x86\usr\lib" and get the result

----------------------------------------------------------------------------

2009/03/26  03:12                 0       libEGL.so

2009/03/26  03:12            62,126    libEGL.so.1

2009/03/26  03:12                 0       libgf.so

2009/03/26  03:12            92,505    libgf.so.1

2009/03/26  03:12                 0        libgf.so

2009/03/26  03:12           151,633   libGLESv1_CM.so.1

2009/03/26  03:12                 0       libGLES_CM.so

2009/03/26  03:12           166,032   libGLES_CM.so.1

2009/03/26  03:12                 0       libKD.so

2009/03/26  03:12            29,789    libKD.so.1

2009/03/26  03:12                 0       libWFD.so

2009/03/26  03:12            39,649    libWFD.so.1

2009/06/05  17:21           383,262   libOpenVG-G12.so.1

2009/06/05  17:21            27,036    libOpenVG.so.1

2009/06/05  17:21            38,742    libutil.a

----------------------------------------------------------------------------

The strage thing is that size of libEGL.so, libgf.so, libgf.so,libKD.so,libWFD.so is zero.

I fill the other option of linker option with "-lgf -lEGL -lasound -lkd -lOpenVG  -lOpenVG-G12".

But when bulid, I got many errores.I think it will be the problem of link option.How can I do for it?

Thanks very much.

-------------------------------------------------------

Severity and Description Path Resource Location Creation Time Id

'image' undeclared (first use in this function) my_application my_event_process.c line 311 1244465516977 3152

'image' undeclared (first use in this function) my_application my_event_process.c line 411 1244465516993 3160

'VGImage' undeclared (first use in this function) my_application my_event_process.c line 308 1244465516977 3150

'VGImage' undeclared (first use in this function) my_application my_event_process.c line 373 1244465516977 3158

C:/QNX640/target/qnx6/usr/include/errno.h expected ';' before 'extern' my_application line 40 1244465516977 3149

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'asm' my_application line 749 1244465516977 3139

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before 'typedef' my_application line 59 1244465516946 3072

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 649 1244465516977 3122

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 661 1244465516977 3125

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 700 1244465516977 3133

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 702 1244465516977 3134

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 709 1244465516977 3135

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 718 1244465516977 3136

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 722 1244465516977 3137

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dst' my_application line 729 1244465516977 3138

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 593 1244465516946 3098

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 594 1244465516946 3099

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 598 1244465516946 3100

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 601 1244465516946 3101

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'dstPath' my_application line 602 1244465516946 3102

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 674 1244465516977 3127

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 675 1244465516977 3128

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 681 1244465516977 3129

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 686 1244465516977 3130

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 687 1244465516977 3131

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'font' my_application line 691 1244465516977 3132

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 634 1244465516946 3116

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 635 1244465516946 3117

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 637 1244465516962 3118

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 641 1244465516962 3119

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'image' my_application line 653 1244465516977 3123

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'mask' my_application line 563 1244465516946 3087

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 570 1244465516946 3090

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 571 1244465516946 3091

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'maskLayer' my_application line 575 1244465516946 3092

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 526 1244465516946 3078

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 529 1244465516946 3079

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 532 1244465516946 3080

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 535 1244465516946 3081

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 539 1244465516946 3082

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 541 1244465516946 3083

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 543 1244465516946 3084

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 545 1244465516946 3085

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'object' my_application line 548 1244465516946 3086

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 623 1244465516946 3109

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 624 1244465516946 3110

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 626 1244465516946 3112

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 627 1244465516946 3113

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'paint' my_application line 628 1244465516946 3114

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 566 1244465516946 3088

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 588 1244465516946 3094

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 589 1244465516946 3095

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 590 1244465516946 3096

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 592 1244465516946 3097

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 606 1244465516946 3103

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 608 1244465516946 3104

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 613 1244465516946 3105

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 616 1244465516946 3106

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before 'path' my_application line 619 1244465516946 3107

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgChildImage' my_application line 646 1244465516962 3120

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateFont' my_application line 673 1244465516977 3126

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateImage' my_application line 631 1244465516946 3115

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreateMaskLayer' my_application line 569 1244465516946 3089

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePaint' my_application line 622 1244465516946 3108

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgCreatePath' my_application line 582 1244465516946 3093

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGFont' my_application line 64 1244465516946 3076

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetPaint' my_application line 625 1244465516946 3111

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vgGetParent' my_application line 648 1244465516962 3121

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGImage' my_application line 62 1244465516946 3074

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGMaskLayer' my_application line 63 1244465516946 3075

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPaint' my_application line 65 1244465516946 3077

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'VGPath' my_application line 61 1244465516946 3073

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected declaration specifiers or '...' before 'VGImage' my_application line 655 1244465516977 3124

C:/QNX640/target/qnx6/usr/include/VG/vgplatform.h sys/srcversion.h: No such file or directory my_application line 108 1244465516946 3071

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguArc' my_application line 99 1244465516977 3145

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToQuad' my_application line 117 1244465516977 3148

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpQuadToSquare' my_application line 105 1244465516977 3146

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguComputeWarpSquareToQuad' my_application line 111 1244465516977 3147

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguEllipse' my_application line 95 1244465516977 3144

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguLine' my_application line 78 1244465516977 3140

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguPolygon' my_application line 82 1244465516977 3141

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRect' my_application line 86 1244465516977 3142

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or '__amyribute__' before 'vguRoundRect' my_application line 90 1244465516977 3143

expected ';' before 'image' my_application my_event_process.c line 308 1244465516977 3151

expected ';' before 'image' my_application my_event_process.c line 373 1244465516993 3159

make[2]: *** [my_event_process.o] Error 1 my_application line 0 1244465516993 3164

too many arguments to function 'vgSetPixels' my_application my_event_process.c line 325 1244465516977 3155

too many arguments to function 'vgSetPixels' my_application my_event_process.c line 339 1244465516977 3156

too many arguments to function 'vgSetPixels' my_application my_event_process.c line 425 1244465516993 3161

assignment discards qualifiers from pointer target type my_application my_application.c line 78 1244465516946 3070

implicit declaration of function 'vgCreateImage' my_application my_event_process.c line 311 1244465516977 3153

implicit declaration of function 'vgDestroyImage' my_application my_event_process.c line 350 1244465516977 3157

implicit declaration of function 'vgImageSubData' my_application my_event_process.c line 319 1244465516977 3154

passing argument 1 of 'eglGetDisplay' makes integer from pointer without a cast my_application my_app_init.c line 336 1244465516946 3069

passing argument 2 of 'kdRealizeWindow' from incompatible pointer type my_application my_event_process.c line 1145 1244465516993 3162

passing argument 3 of 'eglCreateWindowSurface' makes pointer from integer without a cast my_application my_event_process.c line 1149 1244465516993 3163

-------------------------------------------------------

　　

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post31070

post31074: Re: io-winmgr -sysres : how to use correctly?

Etienne Belanger(deleted) — Mon, 08 Jun 2009 13:30:43 GMT

In order to get EGL configs that can be used in winmgr.conf, you should use io-winmgr -sysres prior to starting io-winmgr.

In general, io-winmgr should just sit there and wait for content updates. If there are none, the CPU usage should be very low. We've fixed similar problems before. I cannot say for sure if this is one of those or not.

post31073: Re: Can not get event by kdWaitEvent()

Etienne Belanger(deleted) — Mon, 08 Jun 2009 13:22:54 GMT

Right now, kdPostThreadEvent is not implemented. KD_EAGAIN typically is the error when the OpenKODE library can't connect to io-winmgr.

post31072: Re: egl-config value corresponding to a particular layer

Etienne Belanger(deleted) — Mon, 08 Jun 2009 13:20:22 GMT

EGL_LEVEL represents the layer number.

post31071: Bulid error : OpenKode,OpenVG

liu liming(deleted) — Mon, 08 Jun 2009 13:16:50 GMT

Hi,everybody

  I am writing an application with OpenKode and OpenVG.And my enviorment is

:QNX6.4.0　+　Aviage　HMI　Suite　2.0

  I list my lib in "C:\QNX640\target\qnx6\x86\usr\lib" and get the result

----------------------------------------------------------------------------

2009/03/26  03:12                 0       libEGL.so

2009/03/26  03:12            62,126    libEGL.so.1

2009/03/26  03:12                 0       libgf.so

2009/03/26  03:12            92,505    libgf.so.1

2009/03/26  03:12                 0        libgf.so

2009/03/26  03:12           151,633   libGLESv1_CM.so.1

2009/03/26  03:12                 0       libGLES_CM.so

2009/03/26  03:12           166,032   libGLES_CM.so.1

2009/03/26  03:12                 0       libKD.so

2009/03/26  03:12            29,789    libKD.so.1

2009/03/26  03:12                 0       libWFD.so

2009/03/26  03:12            39,649    libWFD.so.1

2009/06/05  17:21           383,262   libOpenVG-G12.so.1

2009/06/05  17:21            27,036    libOpenVG.so.1

2009/06/05  17:21            38,742    libutil.a

----------------------------------------------------------------------------

The strange thing is that size of libEGL.so, libgf.so,

libgf.so,libKD.so,libWFD.so is zero.

I fill the other option of linker tab with

"-lgf -lEGL -lasound -lkd -lOpenVG  -lOpenVG-G12".

But when bulid, I got many errores.I think it will be the problem of link

option.How can I do for it?

Thanks very much.

-------------------------------------------------------

Severity and

Description Path Resource Location Creation Time Id

'image' undeclared (first use in this

function) my_application my_event_process.c line

311 1244465516977 3152

'image' undeclared (first use in this

function) my_application my_event_process.c line

411 1244465516993 3160

'VGImage' undeclared (first use in this

function) my_application my_event_process.c line

308 1244465516977 3150

'VGImage' undeclared (first use in this

function) my_application my_event_process.c line

373 1244465516977 3158

C:/QNX640/target/qnx6/usr/include/errno.h expected ';' before

'extern' my_application line 40 1244465516977 3149

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before

'asm' my_application line 749 1244465516977 3139

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ';' before

'typedef' my_application line 59 1244465516946 3072

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 649 1244465516977 3122

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 661 1244465516977 3125

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 700 1244465516977 3133

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 702 1244465516977 3134

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 709 1244465516977 3135

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 718 1244465516977 3136

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 722 1244465516977 3137

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dst' my_application line 729 1244465516977 3138

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dstPath' my_application line 593 1244465516946 3098

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dstPath' my_application line 594 1244465516946 3099

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dstPath' my_application line 598 1244465516946 3100

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dstPath' my_application line 601 1244465516946 3101

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'dstPath' my_application line 602 1244465516946 3102

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'font' my_application line 674 1244465516977 3127

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'font' my_application line 675 1244465516977 3128

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'font' my_application line 681 1244465516977 3129

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'font' my_application line 686 1244465516977 3130

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'font' my_application line 687 1244465516977 3131

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'font' my_application line 691 1244465516977 3132

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'image' my_application line 634 1244465516946 3116

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'image' my_application line 635 1244465516946 3117

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'image' my_application line 637 1244465516962 3118

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'image' my_application line 641 1244465516962 3119

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'image' my_application line 653 1244465516977 3123

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'mask' my_application line 563 1244465516946 3087

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'maskLayer' my_application line 570 1244465516946 3090

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'maskLayer' my_application line 571 1244465516946 3091

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'maskLayer' my_application line 575 1244465516946 3092

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 526 1244465516946 3078

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 529 1244465516946 3079

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 532 1244465516946 3080

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 535 1244465516946 3081

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 539 1244465516946 3082

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 541 1244465516946 3083

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 543 1244465516946 3084

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 545 1244465516946 3085

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'object' my_application line 548 1244465516946 3086

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'paint' my_application line 623 1244465516946 3109

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'paint' my_application line 624 1244465516946 3110

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'paint' my_application line 626 1244465516946 3112

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'paint' my_application line 627 1244465516946 3113

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'paint' my_application line 628 1244465516946 3114

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 566 1244465516946 3088

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 588 1244465516946 3094

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 589 1244465516946 3095

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 590 1244465516946 3096

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 592 1244465516946 3097

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 606 1244465516946 3103

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 608 1244465516946 3104

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 613 1244465516946 3105

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 616 1244465516946 3106

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected ')' before

'path' my_application line 619 1244465516946 3107

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgChildImage' my_application line

646 1244465516962 3120

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgCreateFont' my_application line

673 1244465516977 3126

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgCreateImage' my_application line

631 1244465516946 3115

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgCreateMaskLayer' my_application line

569 1244465516946 3089

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgCreatePaint' my_application line

622 1244465516946 3108

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgCreatePath' my_application line

582 1244465516946 3093

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'VGFont' my_application line

64 1244465516946 3076

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgGetPaint' my_application line

625 1244465516946 3111

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'vgGetParent' my_application line

648 1244465516962 3121

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'VGImage' my_application line

62 1244465516946 3074

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'VGMaskLayer' my_application line

63 1244465516946 3075

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'VGPaint' my_application line

65 1244465516946 3077

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected '=', ',', ';', 'asm'

or '__amyribute__' before 'VGPath' my_application line

61 1244465516946 3073

C:/QNX640/target/qnx6/usr/include/VG/openvg.h expected declaration

specifiers or '...' before 'VGImage' my_application line

655 1244465516977 3124

C:/QNX640/target/qnx6/usr/include/VG/vgplatform.h sys/srcversion.h: No such

file or directory my_application line

108 1244465516946 3071

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before 'vguArc' my_application line

99 1244465516977 3145

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before

'vguComputeWarpQuadToQuad' my_application line

117 1244465516977 3148

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before

'vguComputeWarpQuadToSquare' my_application line

105 1244465516977 3146

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before

'vguComputeWarpSquareToQuad' my_application line

111 1244465516977 3147

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before 'vguEllipse' my_application line

95 1244465516977 3144

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before 'vguLine' my_application line

78 1244465516977 3140

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before 'vguPolygon' my_application line

82 1244465516977 3141

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before 'vguRect' my_application line

86 1244465516977 3142

C:/QNX640/target/qnx6/usr/include/VG/vgu.h expected '=', ',', ';', 'asm' or

'__amyribute__' before 'vguRoundRect' my_application line

90 1244465516977 3143

expected ';' before 'image' my_application my_event_process.c line

308 1244465516977 3151

expected ';' before 'image' my_application my_event_process.c line

373 1244465516993 3159

make[2]: *** [my_event_process.o] Error 1 my_application line

0 1244465516993 3164

too many arguments to function

'vgSetPixels' my_application my_event_process.c line

325 1244465516977 3155

too many arguments to function

'vgSetPixels' my_application my_event_process.c line

339 1244465516977 3156

too many arguments to function

'vgSetPixels' my_application my_event_process.c line

425 1244465516993 3161

assignment discards qualifiers from pointer target

type my_application my_application.c line 78 1244465516946 3070

implicit declaration of function

'vgCreateImage' my_application my_event_process.c line

311 1244465516977 3153

implicit declaration of function

'vgDestroyImage' my_application my_event_process.c line

350 1244465516977 3157

implicit declaration of function

'vgImageSubData' my_application my_event_process.c line

319 1244465516977 3154

passing argument 1 of 'eglGetDisplay' makes integer from pointer without a

cast my_application my_app_init.c line 336 1244465516946 3069

passing argument 2 of 'kdRealizeWindow' from incompatible pointer

type my_application my_event_process.c line

1145 1244465516993 3162

passing argument 3 of 'eglCreateWindowSurface' makes pointer from integer

without a cast my_application my_event_process.c line

1149 1244465516993 3163

-------------------------------------------------------

　　

post31070: Bulid error : OpenKode,OpenVG

liu liming(deleted) — Mon, 08 Jun 2009 13:14:20 GMT

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

-------------------------------------------------------

　　

post31068: Re: setting bit depth for OpenVG flash-player via composition manager?

Roger Maclean — Mon, 08 Jun 2009 13:04:15 GMT

If you want to set the EGL config used for the EGL surface that Flash initially renders into (Flash makes use of multiple surfaces), then you either as you mentoined, use the format parameter for the hmip_openvg.so extension.  If you really want to be more specific than that, this same extension supports a egl_config setting as well. So you'd use:

extension {

    dll = hmip_openvg.so

config {

egl_config = 11

}

}

The egl_config setting you tried setting was for the hmip_compmgr.so extension and this just affects the EGL config used for the composition manager window itself.

I don't believe you normally want to do this though.  The intended way of configuring the player is to set the format for the openvg extension and all other EGL configs are based on this.  The various egl_config settings in the extensions are there more as a last resort if there are other considerations that the player has not taken into account.  If these settings are needed it really means we need to improve the player.  Using egl_config settings directly is risky since the values do not have a fixed meaning. Unless you ensure that you reassess the settings with any change to your target, you could end up using something quite different to what you want.

post31062: setting bit depth for OpenVG flash-player via composition manager?

Mate Szarvas(deleted) — Mon, 08 Jun 2009 09:32:52 GMT

When running /bin/flash with openvg rendering, we can set the

bit depth using the format parameter in flash.conf:

extension {

dll = hmip-openvg.so

config {

           format = 565

        }

}

Is it possible to set the egl config more specifically?

We tried

extension {

dll = hmip-compmgr.so

config {

  winmgr_class = Flash

          egl_config = 11

}

}

but it seems to have no effect.

We also tried

begin display

begin plane

  #FRANK - uncommented this line, not sure of the affects of this

  egl-config = 11

...

in winmgr.conf but it also had no effect.

Also, how is the default value for the format

and egl config value determined?

post31061: Estimating image-bus bandwidth usage in CWM

Mate Szarvas(deleted) — Mon, 08 Jun 2009 08:45:03 GMT

In order to have control over flicker in our i.mx35-based system with limited image-bus bandwidth

we would like  come up with an estimate on the upper bound of bandwidth usage.

We have some limited understanding of the factors, as follows:

Bandwidth usage with multiple physical layers is the sum of bandwidth usage for each layer.  The bandwidth usage may be different

for each layer, depending on the applications running on the given layer.

For each layer the bandwidth usage is the sum 3 components of:

   1.   display controller refresh bandwidth:

         display_refresh_rate * pixel_count * bits_per_pixel

         where

         pixel_count is about display_width * display_height

         (e.g. 640*480 in VGA mode)

   2.  content updates of all applications rendering to the given

        physical layer:

            sum of bandwidth use of each application's update,

            regardless of whether the application's window is

            fully occluded or fully visible

         How to compute the BW usage resulting from a single

         application updating a 100 * 100 pixels window?

         Is the BW usage the same whether we draw just a diagonal

         line from the top-left to the bottom right corner and when

         we draw a square filling the complete 100 x 100 area?

         Will the bandwidth usage increase if we redraw (parts) of the

         100 * 100 pixels window multiple times in a single update

         cycle, such as when clearing the background completely first

         and then rendering a vector-based map?

         What other factors influence the bandwidth use resulting from

         content updates?



   3.   Compositing of dirtied rectangles at the application's update

         rate

         How to estimate bandwidth usage by the compositing

         process depending on the area of diritied rectangles?

         Is the bandwidth usage here dependent on whether the

         dirtied rectangles of different applications overlap or not?

Is there any other factor to consider for estimating the bandwidth

usage?

Is the bandwidth usage the same regardless of using the OpenVG

accelerator or doing all rendering by software?

post31060: egl-config value corresponding to a particular layer

Mate Szarvas(deleted) — Mon, 08 Jun 2009 07:49:06 GMT

We would like to select an egl-config value corresponding

to layer 1 on an i.mx35 system supporting 2 physical layers.

A section of the output from io-winmgr -sysres looks like this:

<id>10</id>

<config_caveat>EGL_NONE</config_caveat>

<buffer_size>16</buffer_size>

<red_size>5</red_size>

<green_size>6</green_size>

<blue_size>5</blue_size>

<alpha_size>0</alpha_size>

<alpha_mask_size>0</alpha_mask_size>

<depth_size>0</depth_size>

<stencil_size>0</stencil_size>

<level>0<level>

<renderable_type>EGL_OPENVG_BIT</renderable_type>

<native_renderable>no</native_renderable>

<native_visual_type>GF_FORMAT_PACK_RGB565</native_visual_type>

<samples>0</samples>

<sample_buffers>0</sample_buffers>

<surface_type>EGL_PBUFFER_BIT|EGL_PIXMAP_BIT|EGL_WINDOW_BIT|EGL_SWAP_BEHAVIOR_PRESERVED_BIT|EGL_LOCK_SURFACE_BIT_KHR</surface_type>

</config>

<config>

<id>11</id>

<config_caveat>EGL_NONE</config_caveat>

<buffer_size>16</buffer_size>

<red_size>5</red_size>

<green_size>6</green_size>

<blue_size>5</blue_size>

<alpha_size>0</alpha_size>

<alpha_mask_size>0</alpha_mask_size>

<depth_size>0</depth_size>

<stencil_size>0</stencil_size>

<level>1<level>

<renderable_type>EGL_OPENVG_BIT</renderable_type>

<native_renderable>no</native_renderable>

<native_visual_type>GF_FORMAT_PACK_RGB565</native_visual_type>

<samples>0</samples>

<sample_buffers>0</sample_buffers>

<surface_type>EGL_PBUFFER_BIT|EGL_PIXMAP_BIT|EGL_WINDOW_BIT|EGL_SWAP_BEHAVIOR_PRESERVED_BIT|EGL_LOCK_SURFACE_BIT_KHR</surface_type>

</config>

Which of these config values indicates the physical layer number?

post31059: io-winmgr -sysres : how to use correctly?

Mate Szarvas(deleted) — Mon, 08 Jun 2009 07:40:02 GMT

We would like to set winmgr.conf / display / plane / elg-conifig

to a value corresponding to 16 bits of bit-depth in order to avoid

flicker on an i.mx35-based system.

Per the documentation and your previous response we were

running io-winmgr -sysres (after another instance of io-winmgr was already running) but the config values reported do

not appear to be correct. We judged that based on the presence

of flicker.

We managed to obtain correct 16-bit configuration values by running io-winmgr -sysres while no other instance of io-winmgr was running in the system but in this case the io-winmgr process never terminated, unless

we sent it a signal.

Also, when starting io-winmgr -sysres in the background and looking

at its state with the pidin command, io-winmgr was always in the

READY state and the hogs utility reported io-winmgr as using

85% of the CPU (with another 13% used by io-pkt even though

no network communication was going on in the system).

The last few lines output by io-winmgr -sysres were:

<samples>0</samples>

<sample_buffers>0</sample_buffers>

<surface_type>EGL_PBUFFER_BIT|EGL_PIXMAP_BIT|EGL_LOCK_SURFACE_BIT_KHR</surface_type>

</config>

</configs>

</egl>

<wfd>

use -i /sbin/io-winmgr reports:

NAME=io-winmgr

DESCRIPTION=compositing window manager

DATE=2009/04/15-09:25:09-EDT

STATE=experimental

HOST=cctrunk

USER=builder

VERSION=6.4.0

TAGID=9999@218225

Is this hangup to be expected or it's something with our configuration or our use of the command?

post31053: RE: Can not get event by kdWaitEvent()

Max Feil — Sun, 07 Jun 2009 15:42:43 GMT

I ran into this issue. The thread receiving OpenKode events must be the

same one that initialized the OpenKode window (realization, etc). I

solved this by calling my OpenKode initialization function from my input

thread.

Regards,

Max

-----Original Message-----

From: liu liming [mailto:community-noreply@qnx.com]

Sent: Sunday, June 07, 2009 7:20 AM

To: cwm-graphics

Subject: Can not get event by kdWaitEvent()

Hi,every body.

  I need to send/receive openkode event in multi thread.  I follow the

OpenKode1.0.2 and I think my source will be Ok. But it does not work.

1).kdWaitEvent(-1) , err code is  KD_EAGAIN (5):

In OpenKode1.0.2, this means:The timeout expired while the event queue

was empty.

2).kdPostThreadEvent(), err code is  KD_EAGAIN (5):

In OpenKode1.0.2, this means:Resource unavailable, try again.

  I think it may be the reason of init of event queue , but I can not

found any function to init the queue.

How can i do for it, thanks.

This is my source code

------------------------------------------------------------------------

---------------------

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/keycodes.h>

#include <time.h>

#include <EGL/egl.h>

#include <KD/kd.h>

#include <GLES/gl.h>

KDThread * pRecvThread = KD_NULL;

void  * kdSendThreadFun(void * arg)

{

printf("SubThreadFunc: Enter\n");

KDEvent *  pSendEvent = KD_NULL;

KDint looCnt = 0;

while(looCnt < 1)

{

pSendEvent = kdCreateEvent();

if(KD_NULL == pSendEvent)

{

printf("SubThreadFunc: Failed to create KdEvent,

and the errCode is:%d\n", kdGetError());

}

else

{

printf("SubThreadFunc: Successed to create

KdEvent\n");

if(-1 == kdPostThreadEvent(pSendEvent,

pRecvThread))

{

printf("SubTheadFunc: Failed to send

KdEvent, and the errCode is:%d\n", kdGetError());

}

else

{

printf("SubTheadFunc: Successed to send

KdEvent\n");

}

}

//sleep(5);

looCnt++;

}

return KD_NULL;

}

KDint kdMain(KDint argc, const KDchar *const *argv)

{

KDThread * pSendThread = KD_NULL;

const KDEvent   * pRecvEvent = KD_NULL;

KDust recvTimeout = -1;

pRecvThread = kdThreadSelf();

pSendThread = kdThreadCreate(KD_NULL, &kdSendThreadFun,

KD_NULL);

if(KD_NULL == pSendThread)

{

printf("MainThread: Failed to create sub thread, and

errCode is:%d\n", kdGetError());

}

else

{

printf("MainThread: Successed to create sub thread\n");

}

while ((pRecvEvent = kdWaitEvent(recvTimeout)) != 0)

{

printf("MainThread: Successed to recv KdEvent\n");

kdDefaultEvent(pRecvEvent);

}

printf("MainThread: Failed To Receive Event,and the errCode

is:%d\n", kdGetError());

return 0;

}

------------------------------------------------------------------------

---------------------

This is the result

------------------------------------------------------------------------

---------------------

SubThreadFunc: Enter

SubThreadFunc: Successed to create KdEvent

MainThread: Successed to create sub thread

SubTheadFunc: Failed to send KdEvent, and the errCode is:5

MainThread: Failed To Receive Event,and the errCode is:5

------------------------------------------------------------------------

---------------------

_______________________________________________

CWM/OpenKODE

http://community.qnx.com/sf/go/post31051

post31051: Can not get event by kdWaitEvent()

liu liming(deleted) — Sun, 07 Jun 2009 11:19:42 GMT

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

---------------------------------------------------------------------------------------------

post31050: Re: failed to kdCreateWindow

liu liming(deleted) — Sun, 07 Jun 2009 10:38:22 GMT

Thanks every much.

I start io-winmgr , and log to the qnx by telent to start my programe.It works.

post30943: Re: sysres utility

Etienne Belanger(deleted) — Fri, 05 Jun 2009 12:18:00 GMT

The documentation refers to the sysres command line option of io-winmgr. Running io-winmgr -sysres--which should be run before starting the io-winmgr resource manager--will give a complete list of EGL configs, display controller devices, ports, and pipelines found on a particular system.

post30930: sysres utility

Mate Szarvas(deleted) — Fri, 05 Jun 2009 10:41:48 GMT

The "Configuring io-winmgr" documentation:

http://www.qnx.com/developers/docs/6.4.1/composition_manager/dev_guide/configuring.html refers to "sysres utility" in the explanation of the display/plane/egl-config parameter.

Is there actually a sysres utility or "sysres utility" refers to the -sysres option "io-winmgr -sysres"?

post30403: Re: failed to kdCreateWindow

Etienne Belanger(deleted) — Mon, 01 Jun 2009 12:49:23 GMT

kdCreateWindow raises the KD_ENOSYS error if the display argument does not correspond to a composited window system display connection, and the KD_ENOMEM error if it failed to allocate a KDWindow * for the new window.

eglGetDisplay(EGL_DEFAULT_DISPLAY) will try to establish a composition manager display connection, and will fallback to the null-windowing system connection with io-winmgr is not running.

I suspect you are getting this error because io-winmgr is not running.

post30384: failed to kdCreateWindow

liu liming(deleted) — Sun, 31 May 2009 02:38:58 GMT

Hi,everybody

   I install Aviage HMI Suite 2.0 and Composition Manager [Patch ID 1347] on Qnx6.4.0, and write a openkode application.

   But, the function of kdCreateWindow can't work and the error message is "kdCreateWindow not support".

   1.The init of EGL is ok

   2.My Display Card is : Intel G33,  and I select the dirver i830.

  For this thing , I install the QnxDsp6.4.1 and Aviage HMI Suite 2.0 and failued too.

  What can I do for it?

Thanks every much.

post25854: Re: What is CWM?

Etienne Belanger(deleted) — Thu, 02 Apr 2009 14:41:47 GMT

CWM stands for Composited Windowing Manager. The acronym might be misleading a bit because this refers to a complete composited windowing system, not just a window manager, like PWM.

Photon will continue to be QNX's traditional windowing system. However, we will soon be offering a composited windowing system as an alternative. Unlike traditional windowing systems that arbitrate access to a single buffer, a composited windowing system combines off-screen buffers into one image that is displayed.

The APIs to communicate with this windowing system are all open specifications, e.g. OpenKODE and EGL.

post25849: What is CWM?

Mario Mastrodicasa — Thu, 02 Apr 2009 14:29:58 GMT

Hi,

I've a question. What is CWM? Is it a replacement for PWM?

Where I can found doc, headers, libraries and so on?

Mario.