So your goal is to support the following use case: User wants to set different screens properties (for example positions) on the same screen arrangement for when the lid is closed and when it is opened.

Correct? Had the lidOpenend mechanic this goal from the beginning or is this a new feature? To my understanding the lidOpenend mechanic does the following at the moment:

1. Disable the internal display on closing the lid and reenable it when the lid is opened again.
2. When the lid is opened again, restore to displays values, that were active before the lid was closed.

Function 2. is questionable. What if I move my external screens around while the lid is closed? Why should this become different for when the lid is opened again? With this logic the same holds the other way around. Why should the display positions of external screens become different just when I close the lid? It would make more sense to keep these display positions consistent independently of lid closed/opened and just reinsert the internal screen at a sensible / the old position. Can you explain why, as described in your test plan, it is sensible to have different display positions of external monitors for when having the lid opened and closed?

My goal is to make the screen configurations work reliably with notebooks, not to support a new use case. The use case is: work with a notebook docked and undocked, with and without external screen(s), lid open or closed.

The configurations work fine, if no notebook with a lid that can be opened or closed is involved.

But several users report, that they switch on their notebook (in docking station) in the morning, lid is closed, log in, and the external screens are swapped left and right again. Or only the empty background of the second screen is shown on the external monitor while the primary screen is on the closed integrated notebook screen.

So they configure it again as needed, while the lid is closed. But there is already a lidOpened-configuration lurking around, waiting for the lid to be opened and to destroy the configuration previously made.

Where does the wrong lidOpened-configuration come from? I guess it's created automatically when the lid is open and a button on the OSD ("Extend to right" or so) is clicked. After closing the lid, this configuration is copied to "lidOpened".

The situation described in the test plan is just a quick way to show what can go wrong and if that is fixed.

In D21082#463700, @hoffmannrobert wrote:

My goal is to make the screen configurations work reliably with notebooks, not to support a new use case. The use case is: work with a notebook docked and undocked, with and without external screen(s), lid open or closed.

The configurations work fine, if no notebook with a lid that can be opened or closed is involved.

But several users report, that they switch on their notebook (in docking station) in the morning, lid is closed, log in, and the external screens are swapped left and right again. Or only the empty background of the second screen is shown on the external monitor while the primary screen is on the closed integrated notebook screen.

This is the real issue. Why are the screen positions scrambled around although there should be a config from before shutdown/suspend (not the lidOpened one), that has the current positions stored. Apparently this one has the wrong positions saved as well. You could check this in your config files.

So they configure it again as needed, while the lid is closed. But there is already a lidOpened-configuration lurking around, waiting for the lid to be opened and to destroy the configuration previously made.

Where does the wrong lidOpened-configuration come from? I guess it's created automatically when the lid is open and a button on the OSD ("Extend to right" or so) is clicked. After closing the lid, this configuration is copied to "lidOpened".

If between yesterday and in the morning they never opened the lid, there should still be a lidOpened-config from the last time yesterday they closed the lid.

The situation described in the test plan is just a quick way to show what can go wrong and if that is fixed.

In D21082#463848, @romangg wrote:

This is the real issue. Why are the screen positions scrambled around although there should be a config from before shutdown/suspend (not the lidOpened one), that has the current positions stored. Apparently this one has the wrong positions saved as well. You could check this in your config files.

The problem is, there is no existing config anymore. If you configure screens with the lid closed, as soon as you open it again, the previous config is gone.

I added this scenario as Test 7 in the test plan.

If between yesterday and in the morning they never opened the lid, there should still be a lidOpened-config from the last time yesterday they closed the lid.

I guess they opened it some time after configuring and before logging out.

I added some more fixes:

• The OSD was displayed even on a closed laptop panel.
• With more than two screens, using the OSD always generated an "extend to right" configuration, even if "extend to left", "clone", or "disable external/internal" was selected. Now these options do what they say with more than two screens, too.

I added your diff to a task I created for tracking some improvements to KScreen.

Please test out how lid open/closed configs behave with the new code on master branch. Also rebase on current master.

Put the additional two fixes you did in separate diffs if they are independent of open/closed configs question. It sounds like that.

Thank you!

I tested the new code:
Tests 1-5 of the test plan behave like previously "without patch", in tests 6 and 7 the integrated laptop screen isn't reacitivated after opening.

After adapting my changes to the new code, all tests work as described "with patch".

The additional fixes are not independent of the first fix, so they are not separated.