Skip to main content

Power mode at the Java stack initialization

2 replies [Last post]
jbernatik
Offline
Joined: 2010-09-13
Points: 0

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.
smaynard
Offline
Joined: 2009-01-27
Points: 0

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

cpratt
Offline
Joined: 2008-12-18
Points: 0

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?