Summarizing findings (compared to ideal) more concisely, ordered from most to least desirable.
@aplattner please let me know if the ideal scenario is achievable.
If not… is scenario #2 possible without workaround?
Scenario | Workaround | Result |
---|---|---|
(1) Ideal | None | Primary: Native resolution. Fullscreen 3840x2160 , No viewportSecondary: Native resolution, Fullscreen 2560x1440 , No Viewport |
(2) Patched module | Re-plug⁽¹⁾ | Primary: Native resolution, Fullscreen 3840x2160 , No ViewportSecondary: Native resolution, Viewport 3840x2160 |
(3 ) Unpatched 575 | Kernel Param⁽²⁾ | Primary: Lower resolution 2560x1440 , Fullscreen, No ViewportSecondary: Native resolution, Fullscreen 2560x1440 , No Viewport |
(4) Patched module | None | Primary: Native resolution, Viewport 2560x1440 , ArtifactsSecondary: Native resolution, Fullscreen 2560x1440 , No Viewport |
⁽¹⁾ Re-plug: System is booted with secondary display unplugged, reconnect at LUKS console prompt
⁽²⁾ Kernel Param: Set primary display resolution to match lesser secondary (video=DP-1:2560x1440@60
)
Downsides:
(1) None!
(2) Cannot see full output on secondary display as it exceeds the screen bounds. No biggie.
(3) Pauses while primary display switching resolutions between TTY and graphical targets.
(4) Smaller usable area on primary screen due to lower resolution viewport bounds. Artifacting.