Hi,
 
1.	The devg driver gets buit as a shared library (dll).  It will
get loaded by both the server (io-display) and clients (applications)
Certain functions are handled by the server (modeswitch, layer
managenent, memory management) but others are loaded in by each client
(core/context rendering functions).   

2.	gf_display_devctl() is used to send a driver specific call to a
driver.   This call relates to properties of the display (mode, layers
etc.)   For example if your controller had some kind of special layer
setting not handled by the existing API you could pass values to driver
this way.   This should not be called from within a gf_draw_begin() and
gf_draw_end()

There is also a gf_devctl() function that can send a driver specific
call relating to rendering.  For example if you needed to configure some
draw property or registers the existing API doesn't support you could do
this here.
gf_devctl() should be called between gf_draw_begin() and gf_draw_end()
This sounds to be the function you're looking for.

Regards
Mike




-----Original Message-----
From: ivan chen [mailto:community-noreply@qnx.com] 
Sent: June 2, 2010 11:56 PM
To: advanced-graphics
Subject: qnx graphics driver development issue

Hi, All

I met some issues when developing graphics driver for qnx.

1. It looks like that all the modules in driver has to be built as
binary. Can client driver module be separted with server modules(loaded
by io-display)?

2. What's the usage of gf_display_devctl, in ddk there is no description
about this api.

In my implementation there is a core driver which manages the hw
resource including mode and memory management, kick off command to hw by
dma buffer, it is loaded by io-display.
Instead of standard protocol such as set mode, allocated surface, I need
some customized protocols to talk to resource management modules from 2d
client driver .

2d client driver -> io_display  -> (resource management modules driver)

 I tried to use gf_display_devctl , and implement devctl of mode
module.But it mets the deak lock.

gf_draw_begin() -->lock the hw_mutex
gf_draw_flush() ->gf_display_devctl() ->io_display()  it will also try
to lock hw_mutex
gf_draw_end() -->unlock the hw_mutex

Is there ay path to bypass this lock?

Thanks!
Ivan



_______________________________________________

Advanced Graphics
http://community.qnx.com/sf/go/post55973