Duo Lite: activity on the top screen causes games on the bottom screen to stutter

The Duo Lite has a weird dual-screen stuttering problem — I think I found what's causing it

I've been investigating a really strange performance issue on my Retroid Pocket Duo Lite, and I'm curious if other Duo/Duo Lite owners can reproduce it.

The problem is specifically with both screens being active at the same time.

Here's the simplest reproduction I've found:

1. Run a game on the bottom screen — I've been using Golden Sun in RetroArch.
2. With the top screen off/inactive, the game runs smoothly.
3. Turn the top screen on and leave something static on it, such as the Android Settings screen. The game on the bottom still runs smoothly.
4. Now scroll or otherwise animate something on the top screen.
5. The game on the bottom immediately starts exhibiting noticeable stutter.
6. Stop moving the top screen and the game becomes smooth again.

I've also reproduced it with video playing on the top screen, but video playback itself doesn't appear to be the cause. Simply having graphical activity on the top display is enough.

I've done quite a bit of testing to try to rule out the obvious stuff:

• GPU isn't being saturated.
• RAM isn't running out.
• Thermal throttling doesn't appear to be involved.
• Both displays are exactly 60 Hz.
• The emulator's workload is essentially identical when the stutter occurs.
• The issue happens even when the top application is using hardware composition rather than client/GPU composition.
• Other applications can independently run on the two displays.

I started digging into Android's display stack with ADB.

SurfaceFlinger consistently identifies the top display as the "pacesetter" and the bottom display as the "follower."

The interesting part is that the bottom display's hardware VSync is explicitly reported as:

hwVsyncState=Disallowed
pendingHwVsyncState=Disabled

while the top display has:

hwVsyncState=Enabled
pendingHwVsyncState=Enabled

Both displays are physical displays and both are running at 60 Hz.

The Duo Lite is using Qualcomm's display stack, including Qualcomm HWC/SDM. I pulled libsdmcore.so from the device and started looking through the VSync handling code.

There is an explicit Qualcomm VSync enable/disable path in DisplayBuiltIn::VSync() / SetVsyncStatus(), so this doesn't appear to simply be SurfaceFlinger inventing a software state. Qualcomm's display code is involved in the VSync state management.

I also checked the HWC missed-frame counters, but those aren't directly useful as a dropped-frame measurement — the counters continue increasing even when the display looks perfectly smooth.

One interesting thing: the Duo Lite's Command Center has "Top Only" and "Bottom Only" display modes, but these don't actually change the underlying SurfaceFlinger pacesetter/follower relationship. Both displays still exist in the display stack.

So at this point my working theory is that there's some kind of SurfaceFlinger/Qualcomm HWC synchronization or presentation interaction between the pacesetter and follower displays. I haven't proven that this is the root cause yet.

The device is running:

Android 15 / SDK 35
Firmware: RPDuoLite_V1.0.0.219_20260924_105531_user

I'd really like to know:

• Can other Duo/Duo Lite owners reproduce this?
• Does anyone know more about Qualcomm's SDM/HWC pacesetter/follower behavior?
• Is there a way to change which display SurfaceFlinger uses as the pacesetter?
• Has anyone seen this kind of dual-display synchronization problem on another Qualcomm Android device?

If anyone has ideas for tests I can run over ADB, I'm happy to try them. I've gotten pretty deep into the display stack at this point, so I'm interested in seeing where this leads.The Duo Lite has a weird dual-screen stuttering problem — I think I found what's causing itI've been investigating a really strange performance issue on my Retroid Pocket Duo Lite, and I'm curious if other Duo/Duo Lite owners can reproduce it.The problem is specifically with both screens being active at the same time.Here's the simplest reproduction I've found:Run a game on the bottom screen — I've been using Golden Sun in RetroArch.

With the top screen off/inactive, the game runs smoothly.

Turn the top screen on and leave something static on it, such as the Android Settings screen. The game on the bottom still runs smoothly.

Now scroll or otherwise animate something on the top screen.

The game on the bottom immediately starts exhibiting noticeable stutter.

Stop moving the top screen and the game becomes smooth again.I've also reproduced it with video playing on the top screen, but video playback itself doesn't appear to be the cause. Simply having graphical activity on the top display is enough.I've done quite a bit of testing to try to rule out the obvious stuff:GPU isn't being saturated.

RAM isn't running out.

Thermal throttling doesn't appear to be involved.

Both displays are exactly 60 Hz.

The emulator's workload is essentially identical when the stutter occurs.

The issue happens even when the top application is using hardware composition rather than client/GPU composition.

Other applications can independently run on the two displays.I started digging into Android's display stack with ADB.SurfaceFlinger consistently identifies the top display as the "pacesetter" and the bottom display as the "follower."The interesting part is that the bottom display's hardware VSync is explicitly reported as:hwVsyncState=Disallowed
pendingHwVsyncState=Disabled
while the top display has:hwVsyncState=Enabled
pendingHwVsyncState=Enabled
Both displays are physical displays and both are running at 60 Hz.The Duo Lite is using Qualcomm's display stack, including Qualcomm HWC/SDM. I pulled libsdmcore.so from the device and started looking through the VSync handling code.There is an explicit Qualcomm VSync enable/disable path in DisplayBuiltIn::VSync() / SetVsyncStatus(), so this doesn't appear to simply be SurfaceFlinger inventing a software state. Qualcomm's display code is involved in the VSync state management.I also checked the HWC missed-frame counters, but those aren't directly useful as a dropped-frame measurement — the counters continue increasing even when the display looks perfectly smooth.One interesting thing: the Duo Lite's Command Center has "Top Only" and "Bottom Only" display modes, but these don't actually change the underlying SurfaceFlinger pacesetter/follower relationship. Both displays still exist in the display stack.So at this point my working theory is that there's some kind of SurfaceFlinger/Qualcomm HWC synchronization or presentation interaction between the pacesetter and follower displays. I haven't proven that this is the root cause yet.The device is running:Android 15 / SDK 35
Firmware: RPDuoLite_V1.0.0.219_20260924_105531_userI'd really like to know:Can other Duo/Duo Lite owners reproduce this?

Does anyone know more about Qualcomm's SDM/HWC pacesetter/follower behavior?

Is there a way to change which display SurfaceFlinger uses as the pacesetter?

Has anyone seen this kind of dual-display synchronization problem on another Qualcomm Android device?If anyone has ideas for tests I can run over ADB, I'm happy to try them. I've gotten pretty deep into the display stack at this point, so I'm interested in seeing where this leads.