I used artmem's solution but ran into the mouse problem mentioned by EoghanM. The workaround I found in the old bug report he linked to related to --panning.
I'm shooting for:
- DP1-2 3840x2160 in native DIP.
- eDP1 1366x768, scaled to look reasonable to the right of DP1-2.
I get this to happen by having a frame buffer that is like DP1-2 + (2x eDP1) then I scale everything going to eDP1 by 1/2.
This should be simple but xrandr is a bit tricky.
Here --scale is used to reduce everything going to eDP1 by 1/2. --panning is the same as eDP1 in the original frame buffer with the position (+3840+0) of just to the right of DP1-2. +0+2160 would be below it.
xrandr -d :0 --fb 6572x3696 --output DP1-2 --mode 3840x2160 --scale 1x1 --rate 60 --pos 0x0 --primary
# sometimes panning get applied incorrectly when switching from some other mode, running it twice is a work around
xrandr -d :0 --output eDP1 --off
xrandr -d :0 --fb 6572x3696 --output eDP1 --mode 1366x768 --scale 2x2 --panning 2732x1536+3840+0
xrandr -d :0 --fb 6572x3696 --output eDP1 --mode 1366x768 --scale 2x2 --panning 2732x1536+3840+0
I also set Xft.dpi to 185
$ cat ~/.Xresources
Xft.dpi: 185
When I unplug from the external monitor I run :
xrandr -d :0 --output DP1-2 --off
xrandr -d :0 --fb 2732x1536 --output eDP1 --mode 1366x768 --scale 2x2 --panning 2732x1536+0+0 --pos 0x0 --primary
That doesn't look great but I'm not away from my desk much. You could get around this by changing Xft.dpi and restarting all your desktop programs. I don't know of a way to change Xft.dpi and then get clients to use it without restarting them.