Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 2:33 AM, Dominik Vogt wrote: > It uses the window's screen which has already been set by the time > the window is placed. Great. So this is the right fix. I have commented and closed https://github.com/fvwmorg/fvwm3/issues/648 -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Fri, Dec 17, 2021 at 01:00:53AM +, Hegel3DReloaded wrote: > On Friday, December 17th, 2021 at 1:38 AM, Dominik Vogt > wrote: > > > Should be fixed now. > > > > However, I find it really annoying that screens now have to be > > specified by name. > > Yes, now it works. So you replaced $[w.screen] with ... something as I see > in git diff. Is it [c]urrent or is it aware if it should start on exact > screen? It uses the window's screen which has already been set by the time the window is placed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 1:38 AM, Dominik Vogt wrote: > Should be fixed now. > > However, I find it really annoying that screens now have to be > specified by name. Yes, now it works. So you replaced $[w.screen] with ... something as I see in git diff. Is it [c]urrent or is it aware if it should start on exact screen? > style xterm startsonscreen DVI-I-1 > is completely non-portable. Indeed it is. I can imagine after-pandemic situation where I go with notebook someware and connect it to monitor "DP-2" and this does not work because "DP-2" is not "DVI-I-1" nor HDMI1 ... I can imagine some translation table, where all non-primary monitors may be referred as left, top, right or bottom. StartsOnScreen p+1 for "right of primary" or p-1 for left and so on should be portable in a sense "ok FVWM, when there is setup where you have someting right of primary, do this with that window". -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Fri, Dec 17, 2021 at 12:42:25AM +, Hegel3DReloaded wrote: > On Friday, December 17th, 2021 at 1:18 AM, Dominik Vogt > wrote: > > > When __pl_position_get_pos_simple() enconters a "center" argument > > it replaces it with DEFAULT_PLACEMENT_POS_CENTER_STRING which is > > defined to "screen $[w.screen] 50-50w 50-50w" as of commit id > > 71c57858ffebdede86c2097464339b65b5742864: > > > > > PositionPlacement: include screen for Center > > > When using "PositionPlacement Center", take into account the screen the > > > window is on, so it's centered appropriately. > > > Fixes #211 > > > This string is passed to GetMoveArguments() for interpretation. > > However, $[w.screen] never gets expanded because that line is not > > passed through the parser. FScreenGetScrRect() later looks for a > > screen with the name "$[w.screen]", finds non and falls back to > > the global monitor for placement (since a recent patch) but seems > > to have used the "current" monitor before. > > > One way to fix this woud be to replace "$[w.screen]" with "c" for > > the current screen, but that ignores the window's screen if > > specified. Also, some places of the code expect screens specified > > as "@g", " @c", "@p" while others use "g", "c" and "p". > > Are this latest examples for the "Move arguments"? G is global, c > current, and p primary. I cannot find in docs what is the difference > with or without '@'. It depends on context and is mostly undocumented. :-( If the screen is part of a single string like +0+0@g it needs the "@". Otherwise it doesn't, but maybe not everywhere. Now that screens have names screen c is harmful because you cannot name your screen "c", "g" or "p". > Passing $[w.screen] to the parser is not an > option in that part of the code? No, it's not. The patched code takes the monitor from the window structure, prints the name into a generated string, passes that to GetMoveArguments() which then looks up the original monitor structure by name. That's stupid enough without piping it through the parser. > I'm too tired now. I will try to confirm tomorrow that it used 'c' before > breaking explicit monitor placement in the current release. FindScreen() used some monitor by "accident" when it didn't find one by that name. I fixed that a while ago because of undefined behaviour and crashes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 1:34 AM, Dominik Vogt wrote: > > Libvirt/KVM/qemu virtualization. > Wow, very complicated. Not at all. Once you get 1st VM, you just clone others and have nice farm of them. Getting new system for me is just to copy "golden" qcow2 image in place, copy piece of XML, change uuid, name, MAC address, and boot. # virsh list --all | wc -l 34 > After a bit of digging I figured out how > to split a single real screen into two xrandr screens: > > with a real screen of 1920x1200: > > > $ xrandr --setmonitor top 1920/1x600/1+0+600 none > $ xrandr --setmonitor bottom 1920/1x600/1+0+600 none > $ xrandr --fb 1921x1200 > $ xrandr --fb 1920x1200 Nice to know that. Never tried that before. -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 1:18 AM, Dominik Vogt wrote: > When __pl_position_get_pos_simple() enconters a "center" argument > it replaces it with DEFAULT_PLACEMENT_POS_CENTER_STRING which is > defined to "screen $[w.screen] 50-50w 50-50w" as of commit id > 71c57858ffebdede86c2097464339b65b5742864: > > > PositionPlacement: include screen for Center > > When using "PositionPlacement Center", take into account the screen the > > window is on, so it's centered appropriately. > > Fixes #211 > This string is passed to GetMoveArguments() for interpretation. > However, $[w.screen] never gets expanded because that line is not > passed through the parser. FScreenGetScrRect() later looks for a > screen with the name "$[w.screen]", finds non and falls back to > the global monitor for placement (since a recent patch) but seems > to have used the "current" monitor before. > One way to fix this woud be to replace "$[w.screen]" with "c" for > the current screen, but that ignores the window's screen if > specified. Also, some places of the code expect screens specified > as "@g", " @c", "@p" while others use "g", "c" and "p". Are this latest examples for the "Move arguments"? G is global, c current, and p primary. I cannot find in docs what is the difference with or without '@'. Passing $[w.screen] to the parser is not an option in that part of the code? P. S. I'm too tired now. I will try to confirm tomorrow that it used 'c' before breaking explicit monitor placement in the current release. -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Fri, Dec 17, 2021 at 12:13:42AM +, Hegel3DReloaded wrote: > On Friday, December 17th, 2021 at 12:18 AM, Dominik Vogt > wrote: > > On Thu, Dec 16, 2021 at 07:18:23PM +, Hegel3DReloaded wrote: > > >> xrandr --output Virtual-1 --mode 1400x1050 --primary --output Virtual-2 > >> --mode 1400x1050 --right-of Virtual-1 > > > And how do I get these virtual screens? > > Ok, I will describe my virtual environment in which I work and test. > > You need to have any Linux or *BSD system which supports > Libvirt/KVM/qemu virtualization. >... Wow, very complicated. After a bit of digging I figured out how to split a single real screen into two xrandr screens: # with a real screen of 1920x1200: $ xrandr --setmonitor top 1920/1x600/1+0+600 none $ xrandr --setmonitor bottom 1920/1x600/1+0+600 none $ xrandr --fb 1921x1200 $ xrandr --fb 1920x1200 Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Fri, Dec 17, 2021 at 01:18:17AM +0100, Dominik Vogt wrote: > On Thu, Dec 16, 2021 at 04:23:35PM +, Hegel3DReloaded wrote: > > I have opened an issue about PositionPlacement Center style: after > > the recent changes, in multi monitor mode, this centers window > > split between left and right monitor, while with latest fvwm3 > > release, this was not the case. Using dv/pager-noaspect where the > > current issues have been resolved couple days ago. It is > > repeatable on the current master. > > Actually that never worked, it only looked like it did - by > accident. > > When __pl_position_get_pos_simple() enconters a "center" argument > it replaces it with DEFAULT_PLACEMENT_POS_CENTER_STRING which is > defined to "screen $[w.screen] 50-50w 50-50w" as of commit id > 71c57858ffebdede86c2097464339b65b5742864: > > >PositionPlacement: include screen for Center > > > >When using "PositionPlacement Center", take into account the screen the > >window is on, so it's centered appropriately. > > > >Fixes #211 > > This string is passed to GetMoveArguments() for interpretation. > However, $[w.screen] never gets expanded because that line is not > passed through the parser. FScreenGetScrRect() later looks for a > screen with the name "$[w.screen]", finds non and falls back to > the global monitor for placement (since a recent patch) but seems > to have used the "current" monitor before. > > One way to fix this woud be to replace "$[w.screen]" with "c" for > the current screen, but that ignores the window's screen if > specified. Also, some places of the code expect screens specified > as "@g", " @c", "@p" while others use "g", "c" and "p". Should be fixed now. However, I find it really annoying that screens now have to be specified by name. style xterm startsonscreen DVI-I-1 is completely non-portable. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Thu, Dec 16, 2021 at 04:23:35PM +, Hegel3DReloaded wrote: > I have opened an issue about PositionPlacement Center style: after > the recent changes, in multi monitor mode, this centers window > split between left and right monitor, while with latest fvwm3 > release, this was not the case. Using dv/pager-noaspect where the > current issues have been resolved couple days ago. It is > repeatable on the current master. Actually that never worked, it only looked like it did - by accident. When __pl_position_get_pos_simple() enconters a "center" argument it replaces it with DEFAULT_PLACEMENT_POS_CENTER_STRING which is defined to "screen $[w.screen] 50-50w 50-50w" as of commit id 71c57858ffebdede86c2097464339b65b5742864: >PositionPlacement: include screen for Center > >When using "PositionPlacement Center", take into account the screen the >window is on, so it's centered appropriately. > >Fixes #211 This string is passed to GetMoveArguments() for interpretation. However, $[w.screen] never gets expanded because that line is not passed through the parser. FScreenGetScrRect() later looks for a screen with the name "$[w.screen]", finds non and falls back to the global monitor for placement (since a recent patch) but seems to have used the "current" monitor before. One way to fix this woud be to replace "$[w.screen]" with "c" for the current screen, but that ignores the window's screen if specified. Also, some places of the code expect screens specified as "@g", " @c", "@p" while others use "g", "c" and "p". Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 12:18 AM, Dominik Vogt wrote: > On Thu, Dec 16, 2021 at 07:18:23PM +, Hegel3DReloaded wrote: >> xrandr --output Virtual-1 --mode 1400x1050 --primary --output Virtual-2 >> --mode 1400x1050 --right-of Virtual-1 > And how do I get these virtual screens? Ok, I will describe my virtual environment in which I work and test. You need to have any Linux or *BSD system which supports Libvirt/KVM/qemu virtualization. I'm using Debian 11, and have whole virtual network of test virtual machines with various BSD, Linux and Solaris systems to test on. Additional virtual monitors are possible on virtual guests which have QXL kernel+Xorg driver, and spice protocol included into virtual machine definition. So nothing from BSD and OpenIndiana guests with multiple heads: they can only use legacy vesa driver. FreeBSD may have working QXL driver already, I don't know for sure. Your virtual guest needs to be recent Linux distro. Hardware host can be any system which can run Libvirt KVM Qemu. For a client, virt-manager's built in display is not capable of displaying mutliple monitors. You will need "remote-viewer" or similar spice protocol client. This is what I use. In virt-manager GUI, this are items "Display Spice", "Channel Spice" and "Video QXL" virtual hardware components. Configure "Display Spice" to have listen type "address", and choose some TCP port, like 5123/tcp. This is the point of remote-viewer connection (127.0.0.1:5123). Before starting virtual machine and connecting to it, there is one crucial thing virt-manager will NOT do for you: enable multiple monitor heads. You can do this by editing XML of VM guest before starting it. Edit with virsh(1), so you don't have to restart libvirtd(8). You will get "crontab -e" $VISUAL / $EDITOR like interface: virsh edit my-test-machine-1 Find section near the end of file, and change "heads" parameter from '1' to '4'. Increasing "vgamem" from 16386 to 32768 is also a good idea. This is from my testbox10 XML (also Debian 11 inside): virsh start my-test-machine-1 remote-viewer spice://localhost:5123 We are still not finished: When logged in, make sure you have spice-vdagentd daemon installed, up and running (spice-vdagent package), AND "spice-vdagent" client running as user from the X session. This will also allow you to move mouse in and out of guest window without Ctrl+Alt to release mouse. Now, you can choose from remote-viewer menu View -> Displays and enable display 2, display 3 ... Four is the maximum. Additional windows will appear empty, and when you run xrandr from the primary monitor, secondary will become alive. In that moment, you should make "Restart" of FVWM, because it still does not refresh and redraw everything in place. Your virtual RandR monitors will be called Virtual-0 and Virtual-1, or sometimes Virtual-1 and Virtual-2 ... depending on the virtual bus, slot, domain, function, kernel, moon at 7th house of Jupiter ... -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Thu, Dec 16, 2021 at 07:18:23PM +, Hegel3DReloaded wrote: > xrandr --output Virtual-1 --mode 1400x1050 --primary --output Virtual-2 > --mode 1400x1050 --right-of Virtual-1 And how do I get these virtual screens? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Thursday, December 16th, 2021 at 6:15 PM, Dominik Vogt wrote: > You forgot instructions to reproduce. I tought it was obvious, so in hurry I didn't described that. Here it is: Steps to reproduce with plain default FVWM setup: 1.Copy /share/fvwm3/default-config as ~/.fvwm 2.Edit ~/.fvwm/config, add Module FvwmMFL into StartFunction 3.Login to this session / start fvwm with this config 4.In one terminal window, enable the second screen and restart fvwm: xrandr --output Virtual-1 --mode 1400x1050 --primary --output Virtual-2 --mode 1400x1050 --right-of Virtual-1 FvwmCommand Restart Replace RandR names of the monitors above with you actual names. Then, configure xterm to have Style PositionPlacement Center and start it: FvwmCommand 'Style XTerm PositionPlacement Center' xterm & Xterm will appear between two monitors, in the real center instead of center of the current monitor. The same behaviour can be observer while calling Quit from the menu: Quit form will appear between two monitors. Latest release behaves well BTW.
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Thu, Dec 16, 2021 at 04:23:35PM +, Hegel3DReloaded wrote: > I have opened an issue about PositionPlacement Center style: after the recent > changes, > in multi monitor mode, this centers window split between left and right > monitor, while with > latest fvwm3 release, this was not the case. Using dv/pager-noaspect where > the current > issues have been resolved couple days ago. It is repeatable on the current > master. You forgot instructions to reproduce. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
