Comment 154 for bug 1292398

Hi Daniel,

I did some testing because I seemed to be affected by this issue on Ubuntu 20.04. In fact I first used the script from bernaerts mentioned above (#4 for instance). Anyway I disabled its startup before these tests, I mentioned it to clear the ground.

So I followed your instructions in #147: everything seems to work, the two monitors.xml are identical and the configuration is correctly applied on my system.

Then I tested some different real use behaviours, as I am working with a laptop attached to a TV and I not always have them connected, but most importantly I only use the TV to watch videos, while in normal use I prefer to work on my screen only.

So I started with a new monitors.xml, setup the dual monitors (Join Displays) view, and then tried:
1. unconnecting the TV "on hot", then connecting it again
2. the same, but logging out and in between the two steps
3. turning off the computer as it is, unconnecting the TV, restarting, and connect the TV at some point
4. switching the configuration to Single-Display, then activating dual view again

In cases 1-3 the configuration is back as expected, so everything ok. In case 4 the configuration is lost.
This is because in 1-3 monitors.xml is unaffected (a monitors.xml~ is instead created and apparently used; not sure how that is handled), whereas in 4 it is overwritten and the TV is not only marked <disabled>, but its whole configuration (X,Y, scale, etc.) deleted.

This might seem trivial, but I originally expected the single-display configuration not to interfere with the dual one in case 4 just as in the other ones. 4 is quite a usual behaviour of mine, and maybe not only: 1 and 2 are not recommendable (in fact, in one case the X session crashed); 3 is surely correct, but 4 might also be quite likely - a monitor/TV is physically connected, but used only at times (e.g., for watching movies or for particular tasks), so one would switch it off and want windows not to open there. Expecting the system to understand that "Off" does not mean "forget its configuration"...

I think more people here fall in this kind of behaviour (surely #143 and likely #114), which is not really an issue of the configuration not being loaded, but rather a 'bad managing' of different situations