- Raspberry Pi 2 B+
- Debian Linux
- OpenMAX Camera Video capture
- Camera ports are disabled
- Renderer / Camera Tunnel is set
- All components state is set to Idle
- Ports are enabled
The first port being enabled is the Camera Input port ( Port #73 ), the port is being enabled using the “OMX_CommandPortEnable” command, as with the “OMX_CommandPortDisable” command, it is expected for the camera component to fire it’s “OMX_CALLBACKTYPE::EventHandler” event handler having “eEvent == OMX_EventCmdComplete” and “nData1 == OMX_CommandPortEnable”, however, this never happen, “OMX_CALLBACKTYPE::EventHandler” is never called ( with any argument ) and the application infinitely wait for the port to become enabled.
I am using std::condition_variable in conjunction with std::mutex to wait for the state change to complete, hence, OMX_CALLBACKTYPE::EventHandler updates the condition variable and calls “notify_one()” while the caller thread locks std::mutex and wait for the condition variable to be set, using this approach “OMX_CALLBACKTYPE::EventHandler” is never called and the program locks forever.
NOTE: When waiting for the condition variable the mutex is verified not to be previosly owned, this is done by verifying (0 == std::mutex::__owner)
HOWEVER, All works fine ( and “OMX_CALLBACKTYPE::EventHandler” is triggered ) when polling the status of the port by calling usleep and OMX_GetParameter(OMX_IndexParamPortDefinition) iteratively.
Question at hand
Why is “OMX_CALLBACKTYPE::EventHandler” triggered when polling it’s value and NOT triggered when using a conditional_variable? With windows there is the notion of APC & Alertable threads, is there any equivalent in linux? One that can explain the above mentioned?