On 09/01/2011 11:37 PM, Strelchun, Timothy wrote:
Generally, I think that DirectFB API usage should be stopped by the application prior to
system/SoC power entering a standby/suspended state, but for a robust solution when usage
still occurs it should be handled. I am curious what the "preferred" approach
is for applications using the DirectFB API when the system/SoC power is in a
standby/suspended state.
Should requests of the graphics driver block on access to the GPU unit and thus
in essence hide the concept of power management (PM) from the application? Of
course, that will not allow for the application to respond normally to requests
to change behavior or exit cleanly, or handle emergency shutdown needs in a
nice manner...
Or should requests of the graphics driver return failures to the DFB core which
will eventually bubble back out of the DFB API to the caller to handle?
An application should optionally register for power management events. Such an
application would then receive a STANDBY REQUEST event and could take certain
actions. The StandBy will not be entered before the application acknowledges
with an API call. There could be a timeout.
Any application not registered for such events or not acknowledging in certain
time frame should be blocked.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
