The problem
The DSDA1 has a single video output: an HDMI port. Despite this, Android on the device believes it is running on a 4K (3840×2160) screen, while the actual HDMI output runs at 1080p. As a result, Android bases all its layout and scaling decisions on 4K, causing incorrect UI scaling, wrong density, and unexpected element sizes on the connected screen. Using Xibo CMS, we now have multiply all screen resolutions by two. So if we have a screen with resolution 640x640, we have to set the resolution to 1280x1280. The problem is that we have setup several client profiles in xibo which specify a certain display resolution the client is using for kiosk displays. However, on the dsda1 device we have to edit this profile and multiply the resolution by two.
We have multiple DSDA1 devices, all have the same issue.
I have already reported this to DSDevices, but they report this is expected behaviour, due to Android always rendering in 4k regardless of which resolution the connected display has. I wanted check here if other users have the same issue, and if it’s really expected, because it feels wrong to have to multiply all resolutions.
I also have some more technical information about what actually happens, for people that are interested:
Technical details (via ADB)
Android sees two displays: the VBY.one connector (which it treats as the primary, internal display) and the HDMI output (which it treats as a secondary screen). Because Android bases all its layout and scaling decisions on the primary display, everything is calculated for 4K but then shown on a 1080p HDMI screen. This results in incorrect UI scaling, wrong density, and unexpected element sizes on the connected screen.
Running dumpsys SurfaceFlinger on the DSDA1 shows:
Display 4625716335649126511 (HWC display 0): port=111 pnpId=LNX displayName=“Linux FHD” ← VBY.one, 3840×2160, density 480
Display 4632668150418366987 (HWC display 1): port=11 pnpId=RTK displayName=“” ← HDMI output, 1920×1080, density 320
The VBY.one connector always reports as connected with a hardcoded EDID (pnpId=LNX, displayName=“Linux FHD”), and is enumerated before the HDMI connector at kernel/DRM level, giving it permanent priority as the primary display. The system stable display size is locked to 3840×2160 as a result.
adb shell wm size always returns 3840x2160, regardless which monitor is connected. On the previous DSDC9(x), this changed accordingly.
How to reproduce
1. Connect a DSDA1 to any 1080p display via HDMI.
2. Enable ADB and run: adb shell dumpsys SurfaceFlinger
3. Observe that HWC display 0 is port=111 (VBY.one, 4K) and HWC display 1 is port=11 (HDMI).
4. Run adb shell dumpsys display | grep mStableDisplaySize , it will report 3840×2160 regardless of the connected screen.
5. Observe UI scaling and density issues on the HDMI output.
Comparison with DSDC9(x)
On the DSDC9(x), this issue does not exist. There is only a single physical display registered (Built-in Screen, 1920×1080, density 240, FLAG_DEFAULT_DISPLAY), which correctly corresponds to the HDMI output. The stable display size is 1920×1080 and there is no VBY.one connector being enumerated.
Expected behaviour
The HDMI output should be registered as HWC display 0 (primary), or the VBY.one connector should not be registered as connected when no panel is physically attached.