Don't make a seperate call to disable outputs

[RasmusWL]

Having no enabled outputs crashed my WM, so I have grouped the
first enable xrandr call with the disable call

[phillipberndt]

This overrides import copy from above, so ll copy.deepcopy calls below won't work anymore. Please use copy.copy instead.

[phillipberndt]

I am not sure how this will interact with wertarbyte/autorandr#18 and tachylatus/autorandr@83355f4. @tachylatus, are you still affected by this problem / can you test if the approach from this pull request works for you?

If it doesn't, we could first disable all but one of the unused outputs, then enable the first used output (that's the one at 0x0) in the same call that disables the last one, and then enable the remainder in pairs of two. This would require us to change the logic of add_unused_outputs such that outputs that are connected, unused and continue to be unused in the profile that is to be loaded are removed entirely from the configuration. (Otherwise we could still end up with all outputs being disabled at some point.)

[RasmusWL]

Okay, so to sum up, there are problems when:

1. At some point no output is enabled (this pull request) [WM problem]
2. Making changes to more than two outputs at the same time (change each output separately wertarbyte/autorandr#18) [Driver problem]
3. Exceeding maximum number of outputs (tachylatus/autorandr@83355f4) [xrandr problem?]

Solution could be:

• Enable one output and disable one output in the first call to xrandr
• Disable rest of unused outputs in pairwise calls to xrandr
• Enable rest of outputs in pairwise calls to xrandr

[phillipberndt]

There's a fourth point to it: The first screen to be enabled must be the one at 0x0, because xrandr will move the first screen to that position no matter what. (autorandr.py already sorts that screen to the beginning of the list.)

[phillipberndt]

Here's an implementation of what I've suggested above:
0bb7e07

I don't know if this works yet.

[RasmusWL]

Yes, this works for me. But there is an edge case where things go wrong. Lets say 4 outputs are enabled, and you want to disable them all and enable an other one.

In the normal case, the first call to xrandr will disable 3 of the outputs, and a second call will be made to disable the last output while enabling the new output.

However, if the first call to xrandr fails (because the driver can only work on max 2 outputs at a time), then you group all 5 outputs changes in pairs of two, meaning the second call will disable 2 outputs, the next call will disable 2 outputs, and then your WM will crash because there are no enabled outputs 😞

[phillipberndt]

Right, thanks. (Though the only reported case of problems with changing multiple screens in one call concerns enabling screens, not disabling them.) 29cd564 should fix that.

[phillipberndt]

Apparently no one else is interested in this right now. Shall I merge my version, or do you prefer a different solution?

[RasmusWL]

No just merge your version, I think that should be fine :)

[phillipberndt]

Very well.