Dual-Display Adaptation of a Financial Terminal Tablet on OpenHarmony with RK3588: Architecture, DTS Configuration, Driver Porting, and Hotplug Handling

Recently we completed the adaptation of a flagship financial terminal tablet to OpenHarmony, enabling the tablet to connect various peripherals such as an HDMI monitor, thereby demonstrating our innovation in the OpenHarmony ecosystem.

The hardware and software stack used is RK3588 with OpenHarmony 4.0 and Linux 5.10, focusing on the eDP + DP‑to‑HDMI dual‑display adaptation process.

RK3588’s display subsystem follows a VOP 2.0 design; the graphics acceleration module consists of RGA (2D processing), GPU (rendering), and VPU (video decoding). Processed data is stored in DDR, read by the VOP, and output through interfaces such as HDMI or DP. The chip provides multiple independent VP ports, allowing three‑screen independent display, with four VP ports available on RK3588.

The tablet’s display consists of an internal eDP screen and an external DP port that, via an expansion, connects to an HDMI monitor, as illustrated in the DP‑to‑HDMI schematic.

The dual‑screen adaptation is achieved by configuring DP in legacy mode (dp1) via DTS:

&dp1 {
    status = "okay";
    ......
};

&vp1 {
    vp1_out_dp1: endpoint@3 {
        reg = <3>;
        remote-endpoint = <&dp1_in_vp1>;
    };
    ......
}

dp1_in_vp1: endpoint@1 {
    reg = <1>;
    remote-endpoint = <&vp1_out_dp1>;
    status = "okay";
};

During driver porting we discovered issues in the upstream DRM driver (highlighted in red boxes) and needed to import third‑party drivers located at:

drivers/gpu/drm/rockchip/
drivers/gpu/drm/bridge/analogix/
drivers/gpu/drm/bridge/synopsys/
drivers/phy/rockchip/

After successful porting, DP connection status can be verified via VOP state or by reading the sysfs node:

cat /sys/class/drm/card0-DP-2/status
connected

We used the hello_composer test program to validate the entire graphics pipeline—from screen information retrieval, layer creation, buffer allocation, rendering, composition, to final display—confirming that the core display functionality works.

However, when both screens were enabled, content failed to appear on either, leading us to investigate the RenderService. We found that the internal eDP screen was not initialized correctly, causing the default screen group to be missing. The issue stemmed from the unordered_map used to store screen information, which does not preserve order, resulting in the DP screen being treated as the default.

To resolve this, we implemented the following measures:

Re‑evaluate and enforce the initialization order so that the eDP screen is always initialized first.

Add checks during DP initialization to ensure the default eDP screen is already ready.

Introduce synchronization points to guarantee correct sequencing of screen and group creation.

Hot‑plug support for DP is currently lacking. Using hdc shell hidumper -s RenderService -a screen shows that the new DP screen is not managed by Rosen, indicating a HAL‑level handling problem. The hot‑plug processing flow involves:

HdiNetLinkMonitor::MonitorThread – listens for netlink messages.

ParseUeventMessage – parses uevent payloads.

HdiSession::HandleHotplug – processes the hot‑plug event.

DrmDevice::HandleHotplug – handles it at the DRM layer.

DrmConnector::HandleHotplug – final handling at the connector.

We discovered that the current implementation only parses HDMI‑related uevents (e.g., "STATE=HDMI=1"), ignoring DP events, and that failure to parse DP status causes the monitor thread to exit, making hot‑plug testing unstable.

Future work includes enhancing the hot‑plug logic with retry mechanisms and extending support to additional display protocols such as VGA and eDP, thereby improving OpenHarmony’s robustness.

In conclusion, the dual‑display adaptation resolved kernel driver defects, framework‑level interface gaps, and hot‑plug shortcomings, showcasing our capability in system adaptation and contributing to the growth of the OpenHarmony hardware ecosystem.