abedb464d5
Summary: The test DontCrashUseractionsMenu (Waylandonly) found an issue in our screen handling implementation in the QPA. The code exposed a short time frame between the dummy screen getting destroyed and the first screen being added. This could result in a crash of KWin. There is actually no need to implement Screen on top of Wayland screen. KWin has all the knowledge, so we can also base this on top of the Screens API. Advantages: * no delays due to Wayland roundtrips * handle screen getting removed (was a TODO) * handle resolution changes (was a TODO) The new implementation has a disadvantage that it destroys and readds all screens whenever something around the screen changes. This shouldn't be an issue in practice as it's only for the internal QPA and thus only affects KWin internal windows which is placed in global coordinates anyway. If it turns out to be a problem we need to track better the screen changes - so far those were not tracked at all. Test Plan: Run a few unit tests which change screens Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8345 |
||
---|---|---|
.. | ||
abstractplatformcontext.cpp | ||
abstractplatformcontext.h | ||
backingstore.cpp | ||
backingstore.h | ||
CMakeLists.txt | ||
integration.cpp | ||
integration.h | ||
kwin.json | ||
main.cpp | ||
nativeinterface.cpp | ||
nativeinterface.h | ||
platformcontextwayland.cpp | ||
platformcontextwayland.h | ||
platformcursor.cpp | ||
platformcursor.h | ||
screen.cpp | ||
screen.h | ||
sharingplatformcontext.cpp | ||
sharingplatformcontext.h | ||
window.cpp | ||
window.h |