TileManualPlacement doesn't apply to second monitor/desk

[Athanasius]

Upfront Information

Please provide the following information by running the command and providing
the output.

• Fvwm3 version (run: fvwm3 --version): 1.1.0 (compiled from source myself using the git tag)

• Linux distribution or BSD name/version: Debian bookworm (which is on fvwm3 v1.0.6, hence compiling from source)

• Platform (run: uname -sp): Linux unknown

Expected Behaviour

I'm converting over from an old fvwm2 configuration, and ended up starting from scratch so as to not be polluted by old/deprecated things. I'm trying to get window placement working how I want it to. I'm using ~/.fvwm/config as the initial configuration file. That then reads ~/.fvwm/conf.d/common first, which is where this configuration lies. It also then reads in ~/.fvwm/conf.d/monitor-left and ~/.fvwm/conf.d/monitor-right. These last two files should only contain configuration specific to each monitor, i.e. mostly startup items.

I now have Style "*" TileManualPlacement in common, which I expect to cause that placement scheme to be used for all windows that don't otherwise have a geometry/placement specified.

Actual Behaviour

It appears to be working fine on the left monitor (where desk 0 is used), but appears to have no effect on the right one (where desk 1 is used). Instead all new windows are placed as if there were no windows currently displaying in that Desk+Page. They even ignore any window just created via the same method, i.e. menu item that performs Exec exec xterm.

Enabling logging

There is no new logging as I place windows. Nothing earlier looks relevant. I did check this immediately after fvwm3 first started and the behaviour was the same, i.e. this wasn't caused by a Restart. This is the log file, which does include some restarts since as I was trying other options and addressing a need to use PositionPlacement for ssh-askpass-fullscreen.

fvwm3-output.log

Steps to Reproduce

How can the problem be reproduced? For this, the following is helpful:

• Reduce the problem to the smallest fvwm configuration example (where
  possible). Start with a blank config file (fvwm3 -f/dev/null) and go from
  there.

  I'll get back to you on this point, but see the attached configuration. It's possible I'm misunderstanding something about the fvwm3 paradigm for multiple monitors, with the ability to move/drag windows between them, i.e. using two desks when perhaps a single one would work.

• Does the problem also happen with Fvwm2? No, I was using Style "*" SmartPlacement there, and it did work.

Include your configuration with this issue.

Athanasius_github_miggy_org-fvwm3_configs.tar.gz

The .XDGMenu file is just menus, as produced by the Module FvwmPerl -l fvwm-menu-desktop-config.fpl window.

Does Fvwm3 crash?

No.

Extra Information

As I said, this is a wholly new configuration, and I might be misunderstanding, and thus misconfiguring, something to do with multiple monitors but single X11 screen. I'm using this:

xrandr --output DP-4 --mode 2560x1440 --rate 144.00 --output DP-2 --mode 2560x1440 --rate 143.91 --right-of DP-4

to get the monitors in the correct configuration/layout. So, DP-4 is the left monitor, and DP-2 the right.

• Attach $HOME/.fvwm/fvwm3-output.log from the step above. - Attached in that section.

[Athanasius]

OK, reproduced it with as minimal a configuration as possible (whilst ensuring I could still interact with things as needed):

Athanasius_github_miggy_org-fvwm3_configs-1043-minimal.tar.gz

This still exhibits the issue. Opening a bunch of XTerm using the menu works fine on the left hand monitor, they get autotiled until there's no room, then it's manual placement. But on the right monitor they all go to the same position, all the way left and just under the FvwmPager for Desk1 on that monitor.

[somiaj]

I can confirm this bug with the default-config. I have also ran into another bug with MinOverlapPlacement. The bug I see is when using DesktopConfiguration per-monitor, the placement works fine if both my monitors are on the same desktop, but it fails on my second monitor (stacking all windows in top/left corner) if the monitors are on different virtual destkops.

Seems there is some strange interaction between the placement methods and the RandR per monitor setup that probably needs to be worked out.

[Athanasius]

I have also ran into another bug with MinOverlapPlacement. The bug I see is when using DesktopConfiguration per-monitor, the placement works fine if both my monitors are on the same desktop, but it fails on my second monitor (stacking all windows in top/left corner) if the monitors are on different virtual destkops.

Seems there is some strange interaction between the placement methods and the RandR per monitor setup that probably needs to be worked out.

If this is the same bug that I also see, then it's that on startup it looks like all the second monitor windows are in the top-left (so, 0, 0) page of the second desk, but it's just a visual artefact. As soon as I change page within that second desk everything starts displaying correctly again. Specifically my second desk windows are a pair of XTerms that should be in middle-top, and when I use a keybind to go to middle-bottom (this is 3x2 pages), it displays correctly.

Really this should be in a separate bug report though.

[Athanasius]

To make it clearer what's happening, here's how my second monitor/desk pager looks initially:

And this is how it looks after using keybind to move down one page. This is how it should look, other than it should be highlighting the top-middle page as the focused one at startup obviously:

[somiaj]

@Athanasius Try the patch in the js/placement-fix branch. This fixes the issue I was having. It seems that initially the
incorrect monitor (and thus desk) is used when computing where to place the monitor. Which means any computations
done are on the wrong monitor and desk.

Let me know if this also fixes your issue.

[Athanasius]

@Athanasius Try the patch in the js/placement-fix branch. This fixes the issue I was having. It seems that initially the incorrect monitor (and thus desk) is used when computing where to place the monitor. Which means any computations done are on the wrong monitor and desk.

Let me know if this also fixes your issue.

1. I'm still running some local changes to address Steam menus issues.
2. I rebased that branch of mine on to js/placement-fix.
3. I then had to fix up the Debian patches (largely just replacing fvwm with fvwm3 in documentation) to get a build to complete.

Now all my windows are opening on my primary monitor, rather than a subset of them on the secondary. I'll re-run this test with a pure js/placement-fix just to be sure no other changes are interfering, stand by.

[Athanasius]

@somiaj Yup, even with a pure compile and install of js/placement-fix all my windows now start on primary monitor.

I'm definitely running that version, I uninstalled the debian package and:

10:10:33 0$ ps fx | grep fvwm3
  98976 ?        S      0:00  \_ fvwm3 --verbose -f /home/users/athan/.fvwm/config
 101807 pts/7    S+     0:00      |       \_ grep fvwm3
athan@emilia:~ (main);
10:12:13 0$ ls -l /proc/98976/exe
lrwxrwxrwx 1 athan athan 0 Oct 20 10:10 /proc/98976/exe -> /usr/local/bin/fvwm3*
10:12:15 0$ ls -l /usr/local/bin/fvwm3
-rwxr-xr-x 1 root staff 4450464 Oct 20 10:09 /usr/local/bin/fvwm3*
athan@emilia:~ (main);
10:12:35 0$ /usr/local/bin/fvwm3 --version
fvwm3 1.1.1 (1.1.0-94-g14e48d350-dirty)

[Athanasius]

I'm investigating this:

[1729415690.400711] FScreenInit: Using RandR 1.6
[1729415690.425617] scan_screens: Case 1: Add new monitors
[1729415690.425645] monitor_mark_new: Added new monitor: DP-4 (0x563e1f98f1f0)
[1729415690.425672] monitor_mark_new: Added new monitor: DP-2 (0x563e1f98f380)
[1729415690.435439] main: Loading window states via (null)
[1729415690.445091] CMD_Read: file '/usr/share/fvwm3/ConfigFvwmDefaults' not found
[1729415690.446048] do_execute_module: No such module 'FvwmMFL' in ModulePath '/usr/libexec/fvwm3/1.1.1'

which is likely screwing with my configuration working properly. With the Debian package gone, and definitely using the /usr/local/bin/ version I'm not sure why it's looking in those paths.

[Athanasius]

OK, a make clean, and then the usual ./autogen.sh && ./configure && make, followed by make install as root has cleared that up. No egregious errors in the verbose output (mostly lack of PNG support for some reason). Configuration otherwise working, but still all windows being placed on primary desktop.

This also has the side effect that my two monitors are now in lock-step for paging around, rather than being independent.

[Athanasius]

And to confirm, using current main HEAD cd8723ac8ca0f42e5f32fe7cb8419d4d1e91312a, my configuration is still working. Secondary monitor has the correct things started on it, paging is independent etc. So, it's something in js/placement-fix causing the issue. main still has the actual placement issue outlined in OP.

[somiaj]

I don't quite follow, you may have some other issues going on (such as your binary in /usr/local trying to find something in /usr). My patch did move some ordering of how things are done to work with my use case here, I will try to reproduce your issue in detail vs assume it was similar to the one I was experiencing.

[Athanasius]

I don't quite follow, you may have some other issues going on (such as your binary in /usr/local trying to find something in /usr). My patch did move some ordering of how things are done to work with my use case here, I will try to reproduce your issue in detail vs assume it was similar to the one I was experiencing.

I resolved that paths issue (seemed to be something left over from prior debian builds from the same source), with a make clean.

I'll try to find some time to look at the code your patch touches, along with producing a bare minimum configuration to re-create this issue. Anyone testing it will, of course, need a second display of some sort (I don't know if some 'virtual' display can be used for testing) to be sure of how it's working, or not.

[somiaj]

Okay, strange, the fix was working for me for both my issue and your issue, and then it stopped. I was afraid my reordering was going to mess something up. I'll dig a bit deeper.

[somiaj]

Note for testing, using the default-config is probably the best way to test things (you can manually change stuff in FvwmConsole/FvwmPrompt). To use the default-config just move your config out of the way. Then after testing you can just move your config back.

[somiaj]

Okay, I think I tracked it down again, I updated js/placement-fix. Let me know if that changes things for you. All my tests here seem positive so far.

[Athanasius]

Okay, I think I tracked it down again, I updated js/placement-fix. Let me know if that changes things for you. All my tests here seem positive so far.

Using precisely the updated js/placement-fix branch, yes, it's now working correctly for me.

1. With other windows visible in a second-monitor page, and space for a new one, it's auto-placed into some of the space.
2. When another window has no space to be placed it's invoking manual placement as per my configuration.

Now I just need to cherry-pick that into my steam menu fixes branch :)

Thanks for looking into this!

I'll go open a separate issue for the startup pager display issue.

[somiaj]

The pager issue seems like something else, what is your exact keybinding you use to 'move down one page'.

[Athanasius]

The pager issue seems like something else, what is your exact keybinding you use to 'move down one page'.

I've opened a new issue for that: #1077