nanogui: Thread: Screensaver deactivation

I've searched the list archives and read every thread where screensaver is  
mentioned and I'm still no closer to understanding the process of stopping  
the screensaver (i.e. generating a deactivate GR_EVENT_TYPE_SCREENSAVER).
Can anyone point me towards a run-through of the screensaver process.   
Should it be started by a dedicated application, calling  
GrSetScreenSaverTimeout() and then watching for  
GR_EVENT_TYPE_SCREENSAVER?  Should the actual screen drawing part be a  
separate process that gets forked and killed by that event monitor?

To make things more complicated for me, the keypad driver used in this  
platform only allows itself to be opened once at a time (to prevent  
another app snooping on keypad input).  This type of security is a primary  
concern so the nano-X event-driven model, where other apps could monitor  
events, isn't suitable.  From thought experiments this seems to reduce the  
number of options available to signal the screensaver to stop.  Maybe  
GrInjectKeyboardEvent() would be useful here?

Also, I would like to manuipulate the existing content of the screen  
during the screensaver (i.e. ViewML is running and showing a page).  Doing  
GrCopyArea() from the root window to a new window doesn't seem to work  
(starts with a blank screen).  Can an application get the current screen  
contents using nano-X calls (independent of who drew the window(s) in the  
first place)?

If my understanding of anything here is off, please let me know.  It's a  
confusing enough world to be thrown into late in the day.  Thanks.

On 31 May 2006, at 14:02, Ciarán Rehill wrote:
> I've searched the list archives and read every thread where  
> screensaver is mentioned and I'm still no closer to understanding  
> the process of stopping the screensaver (i.e. generating a  
> deactivate GR_EVENT_TYPE_SCREENSAVER).

That happens when the mouse/touchscreen move or a key is pressed. You  
should be able to simulate it with a GrInjectKeyboardEvent() if you  
don't have an ordinary keyboard driver.

> Can anyone point me towards a run-through of the screensaver  
> process.  Should it be started by a dedicated application, calling  
> GrSetScreenSaverTimeout() and then watching for  
> GR_EVENT_TYPE_SCREENSAVER?  Should the actual screen drawing part  
> be a separate process that gets forked and killed by that event  
> monitor?

Take a look at the nsaver and launcher demos. Launcher sets the  
timeout period and launches the screensaver process on receiving a  
timeout event, and nsaver is a collection of screensavers. Launcher  
also has the ability for you to specify multiple screensavers and  
change them at set time intervals.

> Also, I would like to manuipulate the existing content of the  
> screen during the screensaver (i.e. ViewML is running and showing a  
> page).  Doing GrCopyArea() from the root window to a new window  
> doesn't seem to work (starts with a blank screen).  Can an  
> application get the current screen contents using nano-X calls  
> (independent of who drew the window(s) in the first place)?

Yes, in fact search for capture_screen in nsaver.c and you'll see an  
example of reading the current contents of the screen. I'm not sure  
if that's really what you want to do though.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

On 31 May 2006, at 20:04, Alex Holden wrote:
> That happens when the mouse/touchscreen move or a key is pressed.  
> You should be able to simulate it with a GrInjectKeyboardEvent() if  
> you don't have an ordinary keyboard driver.

On second thoughts, you'll probably need to inject a fake keyboard  
event every time your keypad reading process detects a button press  
in order to prevent the screensaver activating because it hasn't seen  
a keypress recently.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

: On second thoughts, you'll probably need to inject a fake keyboard  
: event every time your keypad reading process detects a button press  
: in order to prevent the screensaver activating because it hasn't seen  
: a keypress recently.

Don't we have an API mechanism to turn off screen saver entirely,
until another API call to turn it back on?

Regards,

Greg

On 1 Jun 2006, at 04:36, Greg Haerr wrote:
> : On second thoughts, you'll probably need to inject a fake keyboard
> : event every time your keypad reading process detects a button press
> : in order to prevent the screensaver activating because it hasn't  
> seen
> : a keypress recently.
> Don't we have an API mechanism to turn off screen saver entirely,
> until another API call to turn it back on?

Setting a screensaver timeout of 0 will prevent screensaver events  
being generated, but then your application would have to keep track  
of the time between key presses and take care of activating and  
deactivating the screensaver itself without the help of the built-in  
screensaver mechanism.

-- 
-----------------------------------------------------------
Alex Holden, Systems Engineer, Clear Digital Solutions Ltd.
        Tel: 01282 697280     Email: ####@####.####
-----------------------------------------------------------