Deprecate fvwm's individual screen functionality

[ThomasAdam]

Before the days of actual Xinerama or XRandR integration, it was possible to run fvwm on separate displays. So for example, if there were two physical monitors attached to a computer, then fvwm could be started as:

fvwm -s 0
fvwm -s 1

These days though, RandR support is sufficient such that fvwm shouldn't need to start up on separate displays. Indeed, a downside to this is that it is not possible for windows to move between displays.

Given the maturity of RandR, this mode in fvwm3 should be removed.

[slazav]

Now if no -s option is given, fork() is done for each screen of a display. Do you want to remove this as well and use only DefaultScreen(dpy)?

[ThomasAdam]

Hi @slazav

That's part of it. But this is also a lot of work. It's not as simple as just removing the option for -s. Internally, fvwm3 is tracking the state of various things which could be operating on separate displays. For example:

• LastScreenFocus -- if you check fvwm/focus.c you'll find various uses of that there. This is involved with separate screens.
• Grep for the string: pointer is on a different screen -- this is indicating the pointer is on a different display, and hence sometimes the coordinates are ignored, sometimes the x/y values are set to 0/0.

What we need to do here is carefully evaluate the state-tracking fvwm3 is doing in these instances and check what the correct behaviour should be. For that, it will be a little more involved.

@slazav -- I'm more than happy to mentor you through this if you want to give it a go?

[slazav]

The first step is clear, removing the -s option and using default screen. This is the first commit: https://github.com/slazav/fvwm3/commit/d184cd5d541a28729c8170b3c9754441fa3eaf07

Interaction with other screens is not clear for me yet. I will try to read the code today-tomorrow.

[ThomasAdam]

Hi @slazav,

How are you getting on with this? Is there anything I can do to help?

[slazav]

Hi,

In December I prepared a few commits in this branch: https://github.com/slazav/fvwm3/tree/remove_screens_%23333 Should I start making a pull request from them? I can return to this work in a few days, but I'm not sure that I go too deep in it, I'm quite busy at my work now.

Could you please look at #381, it still does not work for me (should it be reopened?)

[ThomasAdam]

Hi @slazav,

I understand completely about being busy! Please do open a PR your work and I'll pick up the remaining bits soon.

[ileGITimo]

Can I down vote this? I have both a 4 (work) and 2 (home) screens setup and configure X with the ZaphodHeads option, one fvwm per screen via the fork() route. I don't care about moving windows from one screen to another, but don't like the single fvwm approach that when I shift out all screens change.

[ThomasAdam]

Hi @ileGITimo

It's my understanding that Zaphod hasn't been supported in ages -- and certainly from what I can tell, hasn't seen the same level of attention that the RandR extension has had over the years.

This PR is still going ahead -- and in your situation, all I can recommend is doing something with multiple X servers running to simulate what you have now.

[ileGITimo]

Not sure about "ages", as at home I have a somewhat recent ASRock DeskMini X300 with a Ryzen 5 CPU/Raven GPU, and it supports Zaphod. There are a lot of people that forget that zaphod and/or more than one screen exists, and blindly use :0 for display, instead of :0.n. Couple of times I had to patch xdaliclock because of this, surprised JWZ that someone uses it. More recent I had to work with the tigervnc guys to fix vncviewer. I don't believe multiple X servers is an alternative, when more than one screen are on the same GPU. I'll stick with the last fvwm that supports it, up to the point where X.org isn't supported in "ages".

[ileGITimo]

Original post seems to be complaining about not being able to move between displays. To try this out I renamed my /etc/X11/xorg.conf away and let the system create one on the fly, Then I renamed my ~/.fvwm/config to left fvwm3 start with its built in configuration. I use xdm to login, renamed the init script where I start fvwm3 and all my initial windows, to only start one uxterm. I got one single fvwm running, a single display/screen :0, a 2x2 tiny desktop, each page covering the two displays (dashed line separated), my uxterm in the proper place. I can move windows between displays, and to all pages, confused what is the use case that benefits from removing -s and/or forking a new fvwm per screen.

[ileGITimo]

Turns out that this merge doesn't really stop me to run with Zaphod heads. With past versions, the XDM script that inits my session had something like:

fvwm3 &  # takes over all screens, forking $nscreens-1 copies
for d in 0..$nscreens-1
do
  DISPLAY=:0.$d
  xprog -args -display $DISPLAY &
  ...
done

and it suffices to move the fvwm3 call into the loop

for d in 0..$nscreens-1
do
  DISPLAY=:0.$d
  DISPLAY=:0.$d fvwm3 &  # takes over the $d screen
  xprog -args -display $DISPLAY &
  ...
done

as the xrandr call that each fvwm3 makes only sees display :0.$d, and the whole thing behaves just like before.

[ThomasAdam]

Hi @ileGITimo

That's correct. This change doesn't have anything to do with Zaphod. My understanding is Zaphod hasn't been supported years.

[ileGITimo]

Not being supported doesn't mean it doesn't work and most drivers still do have that option. X is "deprecated" too, pretty soon will be "not supported".

[ThomasAdam]

@ileGITimo -- Oh, sure. I just mean, this change has nothing to do with Zaphod, and if/when it does break, I wouldn't want yourself or anyone else reading this to think any changes we've made were meant to work.

If they're working now for you, great. :)