I'm currently working on the DRM Backend and from time to time stuff breaks. The odd behavior is, that this has consequences in the X world: After reboot and login to the X session instead of Wayland KWin doesn't start, instead I have to start it manually in a Konsole window via "kwin &". After that I can use it normally again. It also seems to influence the other way around as well: Sometimes only after I restart KWin in the Konsole window in the X session the Wayland session is working again. Is there some sort of data written if the Wayland session crashes which hinders the KWin start in the X session and vice versa?
There should not be any consequences especially given that the one is kwin_x11 and the other kwin_wayland. Maybe session restore tries to restore a wrong one in addition?
Maybe it's unrelated to my DRM work and instead it has something to do with this line in ~/.xsession-errors (logged when X session starts with KWin crashing): kwin_x11: symbol lookup error: /usr/lib/x86_64-linux-gnu/qt5/plugins/org.kde.kwin.platforms/KWinX11Platform.so: undefined symbol: _ZN4KWin21ModifierOnlyShortcutsC1Ev I compile the KWin tree and install it directly with kdesrc-build. In order to solve this problem I tried to: * delete KWin build directory * delete the file ../KWinX11Platform.so But KWin still crashes in X11 and it shows the aforementioned error in ~/.xsession-errors.
As I suspected by the error message and I confirmed by recompiling before this point, 4a976d58ec50d6acd22e5cdbff0ca7fbda1367d0 introduced this regression.
somehow this doesn't make sense as the change does not even touch platform x11. But now I remember that I hit that problem in the past as well and the reason was that I had old files in /usr/local. I figured that one out by stracing kwin
You have to view the change in combination with 65ddd32d1a783281610041d24daff7ee92011ded, where you declared the new ModifierOnlyShortcuts class. The later commit just enables the use of it (and so crashes KWin). My idea was it doesn't export the class correctly or there is an error in the CMake files for the platform plugin, but couldn't find a solution yet.
The problem was in fact, that an old version of the libkwin.so.5 file was also in /usr/local/lib/x86_64-linux-gnu/ Deleting it solved the issue. But I don't know how it went there in the first place. I just hope something like this doesn't happen on release.