RDKEMW-20221: Fix for WPEWebProcess during deepsleep wakeup scenario

[nejuma1]

RDKEMW-20221: Fix for WPEWebProcess during deepsleep wakeup scenario

[Copilot]

Pull request overview

This PR addresses a deepsleep wakeup scenario by reducing HDMI/HDCP status handling contention and attempting to avoid blocking the IARM dispatch thread during HDMI-related events.

Changes:

• Adds an internal mutex to serialize PlayerExternalsRdkInterface::SetHDMIStatus() execution and avoid re-entrancy.
• Adds power-transition gating to skip HDMI event processing while transitioning between power states.
• Introduces detached worker-thread dispatch for HDMI/HDCP IARM events and adds an additional DeInitialize() call in an exception path.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
externals/rdk/PlayerExternalsRdkInterface.h	Adds mutex member to guard HDMI status updates.
externals/rdk/PlayerExternalsRdkInterface.cpp	Uses try-lock to prevent concurrent SetHDMIStatus() and adds DeInitialize() in one exception path.
externals/rdk/IIarm/DeviceIARMInterface.cpp	Adds power-event gating and dispatches HDMI/HDCP handling via detached threads.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

externals/rdk/IIarm/DeviceIARMInterface.cpp:451

• In HDMI hotplug handling, SetHDMIStatus() is still called synchronously before the new detached worker thread is spawned. This both blocks the IARM dispatch thread (contradicting the comment) and causes a redundant second invocation (the worker typically just hits the try-lock and exits). Remove the synchronous call and keep only the worker dispatch.

            pInstance->SetHDMIStatus();

            // Dispatch to detached worker thread — do NOT block IARM dispatch thread
            std::thread([pInstance]() {
                pInstance->SetHDMIStatus();

externals/rdk/IIarm/DeviceIARMInterface.cpp:466

• Same as the hotplug case: SetHDMIStatus() is invoked synchronously and then again on a detached thread for HDCP status events. This duplicates work and still blocks the IARM dispatch thread. Keep only the asynchronous dispatch.

            pInstance->SetHDMIStatus();
            std::thread([pInstance]() {
                pInstance->SetHDMIStatus();
            }).detach();

externals/rdk/IIarm/DeviceIARMInterface.cpp:452

• std::thread is used here, but this file only includes <thread> under #ifdef USE_PREINIT_DECODING. When USE_PREINIT_DECODING is off, this block will not compile. <thread> should be included unconditionally (or at least whenever this handler is compiled).

            // Dispatch to detached worker thread — do NOT block IARM dispatch thread
            std::thread([pInstance]() {
                pInstance->SetHDMIStatus();
            }).detach();

externals/rdk/IIarm/DeviceIARMInterface.cpp:434

• SetPowerEvent()/GetPowerEvent() are now used to gate HDMI event handling across threads, but the underlying mPowerEvt is a plain bool with no synchronization. Reads/writes from different threads (power callback vs IARM/HDMI dispatch thread and the new worker threads) is a data race. Consider making it std::atomic_bool or guarding it with a mutex.

    if (pInstance->GetPowerEvent())
    {
        MW_LOG_WARN(" Skipping HDMI event processing during power transition\n");
        return;

externals/rdk/PlayerExternalsRdkInterface.cpp:315

• device::Manager::DeInitialize() is called on the normal path, and now also in the catch (...) path, but not in the catch (const std::exception&) path. If an exception is thrown after device::Manager::Initialize(), this can leak the initialized DeviceSettings manager. Deinitialize in both catch blocks (or use an RAII/scope guard).

    catch (...) {
        MW_LOG_WARN("DeviceSettings unknown exception caught\n");
	try { device::Manager::DeInitialize(); } catch (...) {}
    }