dynamic randr dpi configuration causes miss-configured screen dimensions

[mkarmona]

My laptop screen is a high-dpi one. Sometimes I need to connect an external screen and work in a clamshell mode. So I configure the monitor and disable the laptop one. Then I change the dpi to some factor. And when I maximise any window it does not fill the whole screen. To fix this, I do restart fvwm3 and it gets the proper scaled dimension.

I am using the latest tg-22 branch. If there is anything I can do to check this further happy to help so.

[ThomasAdam]

Hi @mkarmona ,

Please go back to using the master branch.

Can you add this to the top of your .fvwm2rc file:

BugOpts DebugRandr on

and reatart fvwm3 -- and then plug/unplug your different monitors, and send me the output? It's sent to STDERR, so typically you'll find this in ~/.xsession-errors.

Showing me the steps and commands you went through would be helpful as well.

Thanks,
Thomas

[mkarmona]

Sure! here you have @ThomasAdam . I personally use arandr application. to change the screen setup I disable one screen and then enable the other and click ok to confirm all at once. Not sure if that helps though. When I change to the other monitor having the xrandr dpi changed as xrandr --output DP1 --scale 1.5x1.5 I disconnected it again and I went back to my laptop screen but the virtual screen dimension was bigger than the actual screen so I had to restart again to get the real size. And I repeated the process a few times just to produce some logs.
fvwm_debug_out.log.zip

@ThomasAdam you can find my fvwm configuration here

[ThomasAdam]

Hi @mkarmona,

Thanks for this. Looking through the logs, I am puzzled, because I don't see any disabled monitors, only enabled ones. This means that FVWM still thinks of them as active.

In looking over the logs as well, the display widths and heights all seem to tally.

I've also tried to reproduce this (albeit not on a HiDPI screen), and for me, when I change monitor dimensions, FVWM correctly works out the root window sizes for the change in screen resolution.

What am I doing wrong?

[mkarmona]

I will dig into this during this weekend. I will try to formulate a reproducible case; as much as I can though. I will try to test at least two scenarios to see whether dpi changes play a role too.

[mkarmona]

@ThomasAdam I had few minutes off so here my tests

1. start fvwm3 having just my laptop screen edp1
2. connect my external monitor dp1
3. using arandr disable one and enable external and then apply all at once
4. the external monitor does not show the full desktop
5. apply my xrandr dpi 1.5x1.5 so I can get something more usable with my external dp1
6. screen looks odd as the resolution now is smaller than the new desktop
7. restart fvwm and it gets fixed.
8. do the same but the other way around
9. I have to restart again to get the proper desktop size fitting my laptop screen this time

fvwm_debug_out_20200501.zip

DP1 after change from laptop to external dp1 and apply 1.5x1.5 (before the desktop was bigger than the current screen in size (off the screen)

DP1 after fvwm restart with the Fvwm restart command

Swithcing back to eDP1 again the desk look bigger than the screen in extension but correct resolution as with the other monitor

All perfect again after Fvwm restart command

[ThomasAdam]

Hi @mkarmona

Thanks. I was able to reproduce this with playing with different DPI settings.

There's a bug in setting the desktop's working area which I've addressed -- please take a look at ta/gh-52 which has been created from master.

In terms of what should happen to the existing windows when a monitor's resolution changes, I am unsure what best to do here. I don't want to hard-code the behaviour in to FVWM, and it seems to be that we should concentrate on #26 instead.

What do other WMs do in the case where monitors change resolutions? Would such a fix be to ensure that ALL windows are visible on screen if the resolution changes?

[mkarmona]

@ThomasAdam you are welcome. Regarding your question about other WMs I could potentially explore others, I use i3 and awesomewm. Trying to answer your open question about moving windows back to a visible area, well not sure how is all managed internally but I would say in case positions are relative to the maximum area of the screen then they will logically remain the same. I guess the problem is the virtual area does not fit the full visible screen which as you said it is related to monitor's resolution changes.

[ThomasAdam]

@mkarmona,

Right -- with the code change I mentioned, the working area is updated with the change in monitor resolution. For example, without applying that code change, if you were to change the resolution and maximize a window, it would take up the wrong area on the screen. With my code change, however, maximizing an existing window uses the correct area.

So that's about 50% of the solution.

I'm still in two minds about whether to make some sensible hard-coded choices in FVWM3, or leave it all to FvwmEvent (and hence the user) to decide.

Perhaps a combination of both would make sense.

Thoughts welcomed! :)

[mkarmona]

I am currently using your suggested branch with the screen-size fix, although I didn't switch monitors yet. I will check later tonight.
@ThomasAdam thinking out loud, I am quite interested in a behaviour similar to what i3 does in terms of how to manage monitors and workspaces (workspace is similarly called desktop in Fvwm).
The new Fvwm configuration DesktopConfiguration offers either global or per monitor, still not sure how this could map to something similar. I would like to swap desktops between a pair of monitors or similar.
Fvwm should come with a sensible default behaviour set and being able to extend/modify by FvwmEvent too. I will try to join the IRC channel to chat about this

[ThomasAdam]

@mkarmona -- thanks, and please do join #fvwm on irc.freenode.net... :)

[mkarmona]

@ThomasAdam I had a chance to look at the logs again and I got this. I just compiled the master branch. I didn't change the monitor but it throws some bug and not sure related to this or not. Please, you tell me what I should do to help if possible.

fvwm 3.0.0 compiled on May  7 2020 at 18:14:35
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

fvwm_debug_out_20200508.zip

[ThomasAdam]

Hi @mkarmona,

Perfect. Thank you.

I think the problem you're having is partly related to some on-going fixes against #66.

I've rebased ta/gh-52 against ta/gh-66. Please can you retest and send through the logs if this is still misbehaving?

Also, if you want to chat about this on IRC, I'm about...

[ThomasAdam]

Hi @mkarmona,

Hope you're well. Have you had chance to look at this yet? I would suggest just jumping straight to the master branch...

[mkarmona]

Hi @ThomasAdam . I just tried right now. It does not recognise the proper dpi and resolution. I have to restart fvwm3 to just get the proper screen size and hence the apps to fit the screen when I maximise or any other related to sizing operations.
fvwm_debug_out_200525.zip

↓97% $ fvwm3  -V
fvwm3 3.0.0 (dd51bc21) compiled on May 25 2020 at 17:52:35
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

[mkarmona]

Should Fvwm restart when any xrandr event is produced? just to capture any screen configuration?

[ThomasAdam]

Hi @mkarmona,

A restart is not required, as FVWM3 should recognise this dynamically.

I'll take a look at your debug, although I can't reproduce this problem any more. You might want to take a look at:

#94

@lgsobalvarro -- you've got a similar set up to this -- can you help here as well?

Thanks again,
Thomas

[ThomasAdam]

AFAICT, this should be fixed now? I can't reproduce this, but if it's still a problem, please reopen this issue, adding any further relevant details.