Skip to main content

Power mode at the Java stack initialization

Please note these forums are being decommissioned and use the new and improved forums at
2 replies [Last post]
Joined: 2010-09-13

When the java stack is initialized, power mode is set via Host class. It sets the power mode by calling setDefaultPowerMode(), then it call native getHostPowerMode() to register Event Dispatcher listener. Doing that, the power change event is missed. When that happens, DeviceSettingsHostManagerImpl() which registers power mode change listener in Host does not get the power change event, meaning the vopEnable() is not called and video/audio output is not changed.

Would it make sense to move the call to setDefaultPowerMode() in the Host constructor after the ED is registered ?

Video output is being changed if mpeenv ocap.api.option.ds is enabled because in the DeviceSettingsHostImpl() power mode is changed again via call getPersistence().initHostSettings() - which seems to happen by luck more then by design.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2009-01-27

resolved with trunk revision 21493: re-order PowerMode calls forcing the queue to be registered before determining state or initialization.

In the instantiation of Host the correct sequence should have been to (1) register the queue, (2) make the call to determine the current state, (3) perform initialization based on the state returned by the call. The order previously seemed to be (2), (3), (1) meaning that an event received between (2) and (1) would be lost...

Joined: 2008-12-18

This certainly looks like a legit bug.

I can imagine a couple of solutions. But we'd want to ensure that clients aren't dependent upon the event to establish the initial power mode.

Could you file an issue so this can be addressed?