Consider a hypothetical service terminal with two screens. An employee advances the queue on one; customers see the current ticket number on the other. Both views look correct during a demonstration. Then the customer display disconnects, reconnects, and shows an outdated number.
Getting different pixels onto two panels is only the beginning. Dual independent display lets a system send different content to each screen, but the application still owns the relationship between those views. That includes shared data, screen assignment, input routing, and recovery.
For a developer, the starting point is the behavior each screen must preserve when something changes.
Give each screen a job before giving it a window
In the queue example, the operator screen needs the waiting list, service controls, and connection status. The customer screen needs a large ticket number and clear instructions. Administrative controls have no place in the public view.
Write these as separate display roles. A role describes purpose; a display identifier describes where the software currently renders it. Keeping that distinction explicit makes startup and replacement behavior easier to reason about.
The hardware must support the arrangement. Two connectors do not establish which outputs can run simultaneously, and a mirrored desktop does not prove that applications can address two independent views. Ask for the intended operating system image and output combination when evaluating a board.
Rocktech's PX30 and RK3576 motherboards offer dual independent display support. For application work, the relevant question is how the selected board and firmware expose those outputs. A processor name alone does not answer that question.
Before designing the full interface, put a different temporary label on each output. Then verify the association between those outputs and the operator and customer roles. Use an explicit mapping supported by the deployment environment instead of assuming that the second item in a display list must always be the customer screen.
Share the queue state, then build two views
A tempting implementation gives each screen its own queue and sends messages between them. Now every cancellation, skipped ticket, and restart has to keep two copies consistent.
For this terminal, a simpler design gives one component ownership of the queue. The two interfaces receive views derived from that state. The operator view includes controls and operational details; the customer view contains only the information needed by the waiting customer.
Advancing a ticket becomes a state change followed by updates to both views. The public screen should not invent its next number from the number it currently displays. Otherwise, a missed update can leave it permanently behind.
Give published snapshots a revision number. Suppose the queue owner has reached revision 42 while the customer renderer last received revision 39. That discrepancy is easier to diagnose than two screenshots that merely appear different. Log the state revision alongside the screen role and rendering event.
Not every interface needs to live in one process. Separate processes can be useful for deployment or fault containment, but they still need an agreed owner for queue data and a way to obtain a complete current snapshot. Receiving future change events is insufficient when the renderer has missed earlier ones.
After reconnecting, a view should subscribe to updates without leaving a gap between reading its snapshot and receiving subsequent changes; otherwise, recovery can introduce another missed ticket.
On Android, the Presentation API can host a dedicated view on a compatible secondary display. Its layout uses that display's context and resources. This is useful when one application owns the operator interaction and the public view. Launching separate activities on separate screens introduces additional platform policies and application behavior to verify.
For Qt on embedded Linux, the display backend matters. With the EGLFS KMS backend, applications can assign different windows to different screens, subject to its windowing restrictions. Other backends have different capabilities. Establish the deployed backend before treating a desktop prototype as evidence of embedded behavior.
The shared state approach works with either platform. The display API determines how a view reaches a screen; the application determines which version of the queue that view represents.
Treat display loss as an ordinary application event
The customer screen may become available after the application starts, or disappear while the terminal is running. Recovery belongs in the normal control flow.
When a compatible output becomes available, resolve its role, create the appropriate view, and render the latest complete snapshot. When the output disappears, release the associated rendering resources and keep queue ownership separate from that view's lifecycle.
Android's Presentation lifecycle includes cancellation when its display is removed. That does not decide what happens to the business state. Application code still needs a policy for continued operation, user feedback, and rebuilding the view when an eligible display returns.
For the queue terminal, the operator might be allowed to continue serving while a warning reports that the public display is unavailable. Another product might need to pause. Choose that behavior deliberately; neither policy follows automatically from having two display outputs.
Also distinguish reconnection from a process restart. Recreating a view can use a snapshot already held in memory. Restarting the component that owns the queue requires an authoritative recovery source, such as persisted state or the service backend. Until that source is ready, the public screen should show an appropriate waiting message rather than an unverified ticket number.
Touch input adds another mapping. A display role and a touch device need to agree about where an action belongs. Rotating the rendered interface does not automatically establish the correct input transform. Test the intended screen orientation and verify that actions arrive at the expected view.
If the customer screen only presents information, keep its interaction requirements simple. If both screens accept simultaneous input, test focus behavior as well as coordinates. Two accurate touch reports do not, by themselves, prove that both interfaces remain independently usable.
Test transitions and record what each screen receives
A useful test changes one condition at a time while recording the queue revision and assigned display role. The following sequence exercises the proposed design:
- Start the application with both screens available and confirm the intended views.
- Advance several tickets, then cancel or skip one using the operator controls.
- Make the customer output unavailable using a method supported by the hardware.
- Continue or pause service according to the chosen policy, then restore the output.
- Confirm that the customer view renders the current snapshot, without replaying obsolete ticket announcements.
- Restart the application and verify its loading state before current queue data becomes available.
Physical disconnection tests belong only on interfaces designed for that operation. Internal panel connections may require powering the device down; application recovery can also be exercised with supported simulated display events.
Run the sequence with the intended media and background tasks active. Timestamp when a state update is published and when each renderer handles it. Those logs help locate delays, although they do not measure the exact moment pixels become visible on the panel.
A useful handoff records the board revision, firmware image, display mapping, application build, and expected recovery behavior. The next developer should be able to reproduce the same sequence and explain what both audiences will see at every step.
Top comments (0)