Nice. Let's fix these few issues and get it merged before tomorrow. Other small issues can be fixed in beta phase.

I had already stated my opinion numerous times here in lengthy explanations and said that I don't want to continue this discussion. And my opinion has not changed. I am working on other stuff as well as you might know and don't have time for these immensely frustrating and pointless opinion battles just because KWin is a headless project with multi-stakeholders having all kinds of say into what it should maybe be or not be.

• Fix seg fault on orientation sensor

Rebase on series changes.

• Use connectedToBackend getter
• Replace DeviceOrientation

Rebase on master.

Rebase on master.

Superseded with D26511.

I tested this some more and it seems to actually work fine and the issue I saw was only with one specific monitor that does not disconnect correctly when switching off, which is then not a software issue.

Note: For testing you need the patches in KWin applied and add in libkscreen in the KWayland backend the features flags for auto rotation and tablet mode detection.

In D26038#589940, @aaronhoneycutt wrote:

Does this need testing on hardware at this point or has that been done?

• Rename framebuffer setter

• Fix names

I missed to update the test plan. So for reference: this is at it landed unrelated to Wayland and instead altering the behavior on X11. This should make the saving and loading of replications there more robust (see change in last revision of D26309)

In D25907#588536, @davidedmundson wrote:

I'm happy to accept this if we include D26371.

IMHO easiest is for @romangg to grab that and squash in here so history is cleanest but we can do whatever works

• Remove support in Wayland backend
• Add support in RandR backend

• Discard shape on XWayland surface size change

In D26311#586689, @davidedmundson wrote:

Forget 2 outputs, this spec falls apart on simple scenarios.

I have a 1920x1080 monitor, I want it cropped to 1000x1000 physical pixels that represent 1000x1000 logical pixels
I have a 1920x1080 monitor, I want it cropped to 1000x1000 physical pixels that represent 500x500 logical pixels

we can't do either.

• Fix Chromium in OpenGl
• Fix decorations in QPainter

• Add autotest
• Cleanup

In D26172#585870, @davidedmundson wrote:

What's our plan for deleted windows?

I suspect right now once a window close animation starts the buffer will suddenly jump to be the uncropped version.

• Rebase on series changes

• Cleanup

• Check source rectangle on related changes, buffer rename.

In D26311#585860, @davidedmundson wrote:

Good start, the general approach is ok, but it needs a little tweak.

---

I don't like OutputDeviceInterface::setLogicalSize.

Currently we have a pixel size and a scale, which gives us the logical size.
By adding an explicitly setLogicalSize we have this 3 way binding loop that is very confusing.

Having an explicitly set logical size with a scale right now would break that glViewport, and it's semantically confusing as to what the compositor view size is.

• Rename config key

I thought about adding separate events/requests for an immutable`logical_size` just giving always back the current logical size of the output and logical_size_override always giving back the explicitly set logical size or an invalid size if none is set.

This is an alternative to D23619 with more patches to come as discussed with David back then.

Rebase on master.

Shall we go with this patch here for now as a quick fix and look into optimizing the number of calculations later?

• Get auto rotation being supported
• Add tablet mode checkbox