Bug 440027 - Wayland crashes after login when "Right Alt never chooses 3rd level" layout option is set in Keyboard KCM
Summary: Wayland crashes after login when "Right Alt never chooses 3rd level" layout o...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: master
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Andrey
URL: https://github.com/xkbcommon/libxkbco...
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2021-07-19 07:51 UTC by slartibart70
Modified: 2021-11-12 16:56 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.23.1
butirsky: Wayland+
butirsky: X11-


Attachments
coredump-1 (3.51 MB, application/x-7z-compressed)
2021-07-19 08:47 UTC, slartibart70
Details
coredump-2 (3.41 MB, application/x-7z-compressed)
2021-07-19 08:47 UTC, slartibart70
Details
dump-bt (12.47 KB, text/plain)
2021-07-19 09:03 UTC, slartibart70
Details
bt full (12.89 KB, text/plain)
2021-10-06 18:38 UTC, slartibart70
Details
output.xkb (67.92 KB, text/plain)
2021-10-07 14:54 UTC, slartibart70
Details
kwin_wayland.xkb (66.77 KB, text/plain)
2021-10-07 18:45 UTC, Yaroslav Sidlovsky
Details
Source code of app to parse xkb-files (1.27 KB, application/zip)
2021-10-07 23:22 UTC, Yaroslav Sidlovsky
Details
My ~/.config/kxkbrc file (320 bytes, text/plain)
2021-10-07 23:23 UTC, Yaroslav Sidlovsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description slartibart70 2021-07-19 07:51:17 UTC
I am running fc34 with zawertun copr repos enabled (newest plasma releases, also updates-testing enabled) and when trying to enter the wayland desktop, the DE background shows for a short time and dies immediately.
This happens several times in a row (switching between DE-background and vconsole) until it gives up and shows the login screen again. 

Using plasma with x11 is fine, btw.

I attached an excerpt of the journalctl output, it seems that kwin crashes
Any idea what can be done to address this problem (and what further data is needed to analyze this?)

The system is an i5 with integrated intel graphics with a 4k displayPort attached monitor.
The wayland desktop was running properly with fc33 (plasma 5.21 or similar), but i didn't test it further at that time. Just saying, the DE was usable and did not crash, but i switched back to x11 then.

===


Process 3325 (kwin_wayland) of user 10001 dumped core.

Stack trace of thread 3325:
#0 0x00007f219354cc01 _ZN4KWin27KeyboardLayoutDBusInterface18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfac01)
#1 0x00007f219354cf43 _ZN4KWin27KeyboardLayoutDBusInterface11qt_metacallEN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfaf43)


Jul 18 22:33:08 m910x audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-3768-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 18 22:33:08 m910x akonadi_followupreminder_agent[3731]: The Wayland connection broke. Did the Wayland compositor die?
Jul 18 22:33:08 m910x klauncher[3606]: The Wayland connection broke. Did the Wayland compositor die?
Jul 18 22:33:08 m910x kded5[3365]: The Wayland connection broke. Did the Wayland compositor die?
Jul 18 22:33:08 m910x plasmashell[3392]: kf.plasma.quick: The compositor does not support the plasma shell protocol
Jul 18 22:33:08 m910x org_kde_powerdevil[3429]: The Wayland connection broke. Did the Wayland compositor die?
Jul 18 22:33:08 m910x xdg-desktop-portal-kde[3750]: The Wayland connection broke. Did the Wayland compositor die?
Jul 18 22:33:08 m910x korgac[3591]: The Wayland connection broke. Did the Wayland compositor die?
Jul 18 22:33:08 m910x seapplet[3563]: Error reading events from display: Broken pipe

Core Dump (PID 4187/UID 0).
Jul 18 22:33:11 m910x systemd-coredump[4191]: [🡕] Process 4183 (xembedsniproxy) of user 10001 dumped core.

Process 4180 (gmenudbusmenupr) of user 10001 dumped core.
Comment 1 Vlad Zahorodnii 2021-07-19 08:09:45 UTC
Can you please check coredumps for a backtrace?
Comment 2 slartibart70 2021-07-19 08:47:21 UTC
Created attachment 140177 [details]
coredump-1
Comment 3 slartibart70 2021-07-19 08:47:37 UTC
Created attachment 140178 [details]
coredump-2
Comment 4 slartibart70 2021-07-19 08:48:31 UTC
i added the first two coredumps, hope this is what you were looking for
Comment 5 Vlad Zahorodnii 2021-07-19 08:53:06 UTC
I don't think that I'll be able to open them on my computer. Could you please use gdb to get backtraces in text form?
Comment 6 slartibart70 2021-07-19 09:03:19 UTC
Created attachment 140179 [details]
dump-bt
Comment 7 slartibart70 2021-07-19 09:03:30 UTC
hmm... like that?
Comment 8 David Edmundson 2021-07-20 11:49:24 UTC
pasting inline

#0  0x00007f219354cc01 in KWin::KeyboardLayoutDBusInterface::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /lib64/libkwin.so.5
#1  0x00007f219354cf43 in KWin::KeyboardLayoutDBusInterface::qt_metacall(QMetaObject::Call, int, void**) () from /lib64/libkwin.so.5
#2  0x00007f21937f722b in QDBusConnectionPrivate::deliverCall(QObject*, int, QDBusMessage const&, QVector<int> const&, int) () from /lib64/libQt5DBus.so.5
#3  0x00007f21937fac7c in QDBusConnectionPrivate::activateCall(QObject*, int, QDBusMessage const&) [clone .part.0] () from /lib64/libQt5DBus.so.5
#4  0x00007f21937fb50d in QDBusConnectionPrivate::activateObject(QDBusConnectionPrivate::ObjectTreeNode&, QDBusMessage const&, int) () from /lib64/libQt5DBus.so.5


Did we speak in the past about how you had some quirky issues with DBus that were caused by use of musl and setcap?
Comment 9 slartibart70 2021-07-20 12:38:56 UTC
> Did we speak in the past about how you had some quirky issues with DBus that were caused by use of musl and setcap?

Sorry, no, wasn't me.

This fedora34 installation is not deviating from standard (updates included), i played with podman/cgroup hierarchies, but not with musl on this machine.
fc34 uses glibc as default 

Regarding keyboard: maybe just on slight thing that comes to my mind: i added a remapping of caps-lock to control key in a separate mapping file which is loaded / added with localctl

In plasma, there is a separate caps to control mapping, but i also want it for vconsole.

Could this interfere somehow?
Comment 10 slartibart70 2021-09-12 10:21:33 UTC
Newest updates to fedora34, still the same nasty bug when trying to start a wayland session

Out of ideas, how to fix this:
Any help?

====


Sep 12 12:05:36 m910x systemd-coredump[3606]: Process 3167 (kwin_wayland) of user 10001 dumped core.
                                              
                                              Stack trace of thread 3167:
                                              #0  0x00007f6b2423ec81 _ZN4KWin27KeyboardLayoutDBusInterface18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbc81)
                                              #1  0x00007f6b2423efc3 _ZN4KWin27KeyboardLayoutDBusInterface11qt_metacallEN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbfc3)
                                              #2  0x00007f6b244e91eb _ZN22QDBusConnectionPrivate11deliverCallEP7QObjectiRK12QDBusMessageRK7QVectorIiEi (libQt5DBus.so.5 + 0x281eb)
                                              #3  0x00007f6b244ecc3c _ZN22QDBusConnectionPrivate12activateCallEP7QObjectiRK12QDBusMessage.part.0 (libQt5DBus.so.5 + 0x2bc3c)
                                              #4  0x00007f6b244ed4cd _ZN22QDBusConnectionPrivate14activateObjectERNS_14ObjectTreeNodeERK12QDBusMessagei (libQt5DBus.so.5 + 0x2c4cd)
                                              #5  0x00007f6b244ef9fc _ZN24QDBusActivateObjectEvent13placeMetaCallEP7QObject (libQt5DBus.so.5 + 0x2e9fc)
                                              #6  0x00007f6b2292ef09 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2d0f09)
                                              #7  0x00007f6b2357e443 _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 0x1ae443)
                                              #8  0x00007f6b22904798 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x2a6798)
                                              #9  0x00007f6b22907d06 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5 + 0x2a9d06)
                                              #10 0x00007f6b22953075 _ZN20QEventDispatcherUNIX13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f5075)
                                              #11 0x0000556b495989a1 _ZN23QUnixEventDispatcherQPA13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (kwin_wayland + 0x8f9a1)
                                              #12 0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #13 0x00007f6b2290b6e4 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2ad6e4)
                                              #14 0x0000556b4953b1e9 main (kwin_wayland + 0x321e9)
                                              #15 0x00007f6b22070b75 __libc_start_main (libc.so.6 + 0x27b75)
                                              #16 0x0000556b4953baee _start (kwin_wayland + 0x32aee)
                                              
                                              Stack trace of thread 3172:
                                              #0  0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f6b244dcb6b _ZN22QDBusConnectionManager3runEv (libQt5DBus.so.5 + 0x1bb6b)
                                              #7  0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #8  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #9  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3175:
                                              #0  0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #7  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #8  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3176:
                                              #0  0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #7  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #8  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3177:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3178:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3179:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3180:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3181:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3182:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3186:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225175c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4)
                                              #2  0x00007f6b2274cf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a)
                                              #3  0x00007f6b2274a774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774)
                                              #4  0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #5  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #6  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3183:
                                              #0  0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f6b225175c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4)
                                              #2  0x00007f6b2274cf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a)
                                              #3  0x00007f6b2274a774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774)
                                              #4  0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #5  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #6  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 3184:
                                              #0  0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f6b2139c5ec _ZN17QQmlThreadPrivate3runEv (libQt5Qml.so.5 + 0x2d45ec)
                                              #7  0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #8  0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299)
                                              #9  0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
Comment 11 Yaroslav Sidlovsky 2021-10-01 12:05:28 UTC
Hi, please try to update to latest kwin: 5.22.5.
Looks like you're using old version.
Could you also paste there KDE version info from kinfocenter?
Comment 12 Yaroslav Sidlovsky 2021-10-01 12:08:10 UTC
P.S. Run `sudo dnf up --refresh` to update to latest version.
Comment 13 Andrey 2021-10-01 12:14:58 UTC
It seems like a temporary problem of that particular copr repo, we can't reproduce it now.
Please update and report back again.
Comment 14 slartibart70 2021-10-06 14:28:20 UTC
Hi all,

i just upgraded the installation, now i'm on plasma 5.22.5, kf5-... 5.86.0
Still the same problem.

After the login screen (wayland), the plasma desktop seems to show up, i see my background (plain color) and mousecursor. Before any panels are drawn on the screen, it crashes and goes in the already known loop (until giving up)

X11 works as it should, by the way.

What additional info can i provide to handle this particular problem?
Comment 15 slartibart70 2021-10-06 14:31:08 UTC
Oct 06 16:20:19 m910x systemd-coredump[4573]: [🡕] Process 4205 (kwin_wayland) of user 10001 dumped core.
                                              
                                              Stack trace of thread 4205:
                                              #0  0x00007f01fdbb8c81 _ZN4KWin27KeyboardLayoutDBusInterface18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbc81)
                                              #1  0x00007f01fdbb8fc3 _ZN4KWin27KeyboardLayoutDBusInterface11qt_metacallEN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbfc3)
                                              #2  0x00007f01fde631eb _ZN22QDBusConnectionPrivate11deliverCallEP7QObjectiRK12QDBusMessageRK7QVectorIiEi (libQt5DBus.so.5 + 0x281eb)
                                              #3  0x00007f01fde66c3c _ZN22QDBusConnectionPrivate12activateCallEP7QObjectiRK12QDBusMessage.part.0 (libQt5DBus.so.5 + 0x2bc3c)
                                              #4  0x00007f01fde674cd _ZN22QDBusConnectionPrivate14activateObjectERNS_14ObjectTreeNodeERK12QDBusMessagei (libQt5DBus.so.5 + 0x2c4cd)
                                              #7  0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #8  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #9  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4209:
                                              #0  0x00007f01fbaa25bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f01f9a1e48c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f01f99c7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f01fc2c4b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f01fc2721a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f01fc0b52aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #7  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #8  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4210:
                                              #0  0x00007f01fbaa25bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f01f9a1e48c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f01f99c7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f01fc2c4b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f01fc2721a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f01fc0b52aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #7  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #8  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4211:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4212:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4213:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4214:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4215:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4216:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0)
                                              #2  0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b)
                                              #3  0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb)
                                              #4  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #5  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4217:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe865c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4)
                                              #2  0x00007f01fc0bbf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a)
                                              #3  0x00007f01fc0b9774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774)
                                              #4  0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #5  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #6  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4221:
                                              #0  0x00007f01fbaa25bf __poll (libc.so.6 + 0xf55bf)
                                              #1  0x00007f01f9a1e48c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c)
                                              #2  0x00007f01f99c7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                              #3  0x00007f01fc2c4b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78)
                                              #4  0x00007f01fc2721a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2)
                                              #5  0x00007f01fc0b52aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa)
                                              #6  0x00007f01facff5ec _ZN17QQmlThreadPrivate3runEv (libQt5Qml.so.5 + 0x2d45ec)
                                              #7  0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #8  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #9  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
                                              
                                              Stack trace of thread 4223:
                                              #0  0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a)
                                              #1  0x00007f01fbe865c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4)
                                              #2  0x00007f01fc0bbf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a)
                                              #3  0x00007f01fc0b9774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774)
                                              #4  0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6)
                                              #5  0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299)
                                              #6  0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
Comment 16 slartibart70 2021-10-06 14:44:55 UTC
Operating System: Fedora 34
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.9-200.fc34.x86_64 (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-7500 CPU @ 3.40GHz
Memory: 15,5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 630
Comment 17 Yaroslav Sidlovsky 2021-10-06 15:37:41 UTC
Please show output of this command: `rpm -qf /usr/lib64/libkwin.so.5`.
Comment 18 slartibart70 2021-10-06 16:22:58 UTC
rpm -qf /usr/lib64/libkwin.so.5
> kwin-libs-5.22.5-1.fc34.x86_64
Comment 19 Yaroslav Sidlovsky 2021-10-06 16:54:58 UTC
Theory: you have some packages mixed from other repos (maybe `kwin-wayland`).
Till that's looks to me as packaging issue let's move to https://github.com/ZaWertun/fedora-copr-kde5/issues.
Comment 20 slartibart70 2021-10-06 18:36:15 UTC
i removed zawertun repos completely, and added 
dnf debuginfo-install kwin\* plasma\*

Moreover, i attached a different monitor (old hdmi-to-dvi 1280x1024 screen) instead of the 4K monitor.

So, even with the official repo kwin/plasma files, the wayland session crashes repeatedly
Comment 21 slartibart70 2021-10-06 18:38:29 UTC
Created attachment 142222 [details]
bt full
Comment 22 slartibart70 2021-10-06 18:45:47 UTC
the monitor change was tested because of the following strange event:

i have a 4K monitor connected via displayport, the same monitor is display for two machines, laptop and m910x. I just reproduced this very odd behaviour: When i connect the monitor to m910x machine, then try to log in, then i see the background, but no widgets, a short time later, the session crashes.

So, to get to the coredump, i have a ssh session open to m910x - i switched the monitor to the laptop, while m910x was still in the try and crash loop.

Then, after some wait, i connected the monitor back to m910x - and: surprisingly, the kwin desktop was here having also a menubar, with clock and some widgets in the panel of menubar, looking pretty much ok (not full ok, the pinned icons were missing, but it was too quick to tell details).

But, one second into this, it crashes again and the desktop never comes up again in the following die-and-retry loop.

Repeat the whole thing: monitor to m910x, log in, let it crash, disconnect monitor, wait, reconnect and - voila - menubar on the desktop. And crashing immediately after ~1 sec

This was only seen with the 4K monitor, 
with the hdmi/dvi connected old monitor this did not happen.

Here, i had something different: some popups were rendered on the desktop background in the lower left corner (still no menubar). One indicatint sth. about rpc bind and next time a familiar looking crash notificationi popup. Full with animation
But, no details here, crash came too quickly 

So i think, the problem is more fundamental than just kwin/wayland/plasma crashing?
Comment 23 slartibart70 2021-10-06 18:47:00 UTC
Yaroslav recommended to provide this info as well:

$ grep LayoutList ~/.config/kxkbrc
LayoutList=eu,us
Comment 24 Andrey 2021-10-06 20:05:35 UTC
(In reply to slartibart70 from comment #23)
> Yaroslav recommended to provide this info as well:
> 
> $ grep LayoutList ~/.config/kxkbrc
> LayoutList=eu,us
Considering the recent backtrace, XKB thinks there are 4 layouts, but you have only 2 in kxkbrc configured:
#5  KWin::KeyboardLayoutDBusInterface::getLayoutsList (this=0x5626bc88c680) at /usr/src/debug/kwin-5.22.5-1.fc34.x86_64/src/keyboard_layout.cpp:234
        i = 3
...
        layoutsSize = 4
        displayNamesSize = 2


Try to determine source of the extra layouts:

(In reply to slartibart70 from comment #9)
> Regarding keyboard: maybe just on slight thing that comes to my mind: i
> added a remapping of caps-lock to control key in a separate mapping file
> which is loaded / added with localctl
> 
> Could this interfere somehow?
Let's eliminate that. Make sure there is no external mapping taking place, no XKB.. environment variables with configuration, etc.
Comment 25 Andrey 2021-10-06 20:15:20 UTC
(In reply to Andrey from comment #24)
> Try to determine source of the extra layouts:
XKB_LOG_LEVEL, XKB_LOG_VERBOSITY environment variables might be helpful, see
https://xkbcommon.org/doc/current/group__context.html
Comment 26 Yaroslav Sidlovsky 2021-10-07 09:12:07 UTC
@slartibart70, please also run this command: `xkbcomp $DISPLAY ~/output.xkb`.
And upload file `output.xkb` here.
Comment 27 Andrey 2021-10-07 14:19:48 UTC
(In reply to slartibart70 from comment #23)
> Yaroslav recommended to provide this info as well:
> 
> $ grep LayoutList ~/.config/kxkbrc
> LayoutList=eu,us

Please paste all the kxkbrc file
Comment 28 slartibart70 2021-10-07 14:53:41 UTC
$ cat ~/.config/kxkbrc 
[$Version]
update_info=kxkb_variants.upd:split-variants

[Layout]
DisplayNames=,
LayoutList=eu,us
LayoutLoopCount=-1
Model=pc101
Options=caps:ctrl_modifier,lv3:lsgt_switch,lv3:ralt_alt
ResetOldOptions=true
ShowFlag=false
ShowLabel=true
ShowLayoutIndicator=true
ShowSingle=false
SwitchMode=Global
Use=true
VariantList=,

# additionally, my modified xkb map for vconsoles (same as above, Caps is Control)

cat /etc/vconsole.conf
KEYMAP=us-caps
FONT=ter-122b


$ diff --color <(zcat /usr/lib/kbd/keymaps/xkb/us.map.gz) <(zcat /usr/lib/kbd/keymaps/xkb/us-caps.map.gz)
16c16
< keycode 15 = Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab
---
> keycode 15 = Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab
59c59
< keycode 58 = Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock
---
> keycode 58 = Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control
Comment 29 slartibart70 2021-10-07 14:54:06 UTC
Created attachment 142238 [details]
output.xkb
Comment 30 Yaroslav Sidlovsky 2021-10-07 15:02:32 UTC
I see there is only 2 keyboard layouts in the `output.xkb`:

0. 'EurKEY (US)'
1. 'English (US)'

(it corresponds to the info from the `~/.config/kxkbrc`).
Comment 31 slartibart70 2021-10-07 15:08:59 UTC
i tried the following:
- deactivat caps lock as control
- deactivat 3rd level (never alt, <> key)
so, basically a reset to default

removed the eurKey layout, only us remains in the list

no change to the vconsole layout (still us-caps)

AND:
Wayland does not crash, gui is working and usable

(but, i *DO* like Ctrl on Caps, i use VI ... :-)
Comment 32 Andrey 2021-10-07 15:15:47 UTC
(In reply to slartibart70 from comment #31)
> i tried the following:
> - deactivat caps lock as control
> - deactivat 3rd level (never alt, <> key)
> so, basically a reset to default
> 
> removed the eurKey layout, only us remains in the list
> 
Try to revert this bit by bit and determine what configuration exactly caused the crash.

> no change to the vconsole layout (still us-caps)
>
In my understanding, it shouldn't interfere in any way.
Comment 33 Andrey 2021-10-07 15:46:40 UTC
I was able to reproduce with your config.
Let's find the problematic bits.
Comment 34 Andrey 2021-10-07 16:50:56 UTC
(In reply to slartibart70 from comment #28)
> Options=caps:ctrl_modifier,lv3:lsgt_switch,lv3:ralt_alt
It's lv3:ralt_alt option which problematic ("Right Alt never chooses 3rd level" in the list) - upon applying, it crashes the session immediately :)

I don't see any logic in this, it looks like xkbcommon bug, I'll report upstream.
Comment 35 Yaroslav Sidlovsky 2021-10-07 18:45:05 UTC
Created attachment 142240 [details]
kwin_wayland.xkb

Just dumped XKB config from KWin running on Wayland.
When parsing this file with xkbcommon - it returns 4 keyboard layouts:

0. 'English (US)'
1. 'Russian'
2. ''
3. ''
Comment 36 Andrey 2021-10-07 22:59:56 UTC
(In reply to Yaroslav Sidlovsky from comment #35)
> Created attachment 142240 [details]
> kwin_wayland.xkb
> 
> Just dumped XKB config from KWin running on Wayland.
> When parsing this file with xkbcommon - it returns 4 keyboard layouts:
> 
> 0. 'English (US)'
> 1. 'Russian'
> 2. ''
> 3. ''
How exactly did you dump/parse it, and what was in kxkbrc file?

I can guess here is the relevant lines:
key <RALT>               {
		type= "TWO_LEVEL",
		symbols[Group1]= [           Alt_R,          Meta_R ],
		symbols[Group2]= [           Alt_R,          Meta_R ],
		symbols[Group3]= [           Alt_R,          Meta_R ],
		symbols[Group4]= [           Alt_R,          Meta_R ]
Comment 37 Yaroslav Sidlovsky 2021-10-07 23:22:09 UTC
Created attachment 142245 [details]
Source code of app to parse xkb-files

Just unzip it and `cmake . && make -j`. xkb-file should be placed in `~/kwin.xkb` (path is hardcoded).
Comment 38 Yaroslav Sidlovsky 2021-10-07 23:23:57 UTC
Created attachment 142246 [details]
My ~/.config/kxkbrc file
Comment 39 Andrey 2021-10-07 23:25:56 UTC
Here is the relevant part of /usr/share/X11/xkb/symbols/level3 which might be the reason:

// The right Alt key never chooses the third level.
// This option attempts to undo the effect of a layout's inclusion of
// 'ralt_switch'.  You may want to also select another level3 option
// to map the level3 shift to some other key.
partial modifier_keys
xkb_symbols "ralt_alt" {
  key <RALT> {
    type[Group1]="TWO_LEVEL",
    type[Group2]="TWO_LEVEL",
    type[Group3]="TWO_LEVEL",
    type[Group4]="TWO_LEVEL",
    symbols[Group1] = [ Alt_R, Meta_R ],
    symbols[Group2] = [ Alt_R, Meta_R ],
    symbols[Group3] = [ Alt_R, Meta_R ],
    symbols[Group4] = [ Alt_R, Meta_R ]
  };
  modifier_map Mod1 { <RALT> };
};
Comment 40 Andrey 2021-10-08 00:33:29 UTC
I opened upstream issue:
https://github.com/xkbcommon/libxkbcommon/issues/262
Comment 41 Bug Janitor Service 2021-10-08 12:23:27 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1508
Comment 42 Andrey 2021-10-08 12:32:38 UTC
Thanks for reporting, it's so unexpected we could never detect it ourselves.
Comment 43 Andrey 2021-10-12 15:42:54 UTC
Git commit 59143eeef9042f3c9996a06d21a5fe05dc870dcd by Andrey Butirsky.
Committed on 12/10/2021 at 15:41.
Pushed by butirsky into branch 'master'.

[wayland] fix crash on startup with lv3:ralt_alt XKB option

With lv3:ralt_alt ("Right Alt never chooses 3rd level") option set, we
get more layouts from libxkbcommon than it was configured, see:
https://github.com/xkbcommon/libxkbcommon/issues/262
It might be correct lib's behavior, still.

The extra layouts are redundant, so we strip them out from usual usage.

M  +2    -2    src/xkb.cpp
M  +1    -1    src/xkb.h

https://invent.kde.org/plasma/kwin/commit/59143eeef9042f3c9996a06d21a5fe05dc870dcd
Comment 44 Andrey 2021-10-12 15:43:56 UTC
Git commit ef6a9c47c5a77b45bdd77628279a4bfe85c97978 by Andrey Butirsky.
Committed on 12/10/2021 at 15:43.
Pushed by butirsky into branch 'Plasma/5.23'.

[wayland] fix crash on startup with lv3:ralt_alt XKB option

With lv3:ralt_alt ("Right Alt never chooses 3rd level") option set, we
get more layouts from libxkbcommon than it was configured, see:
https://github.com/xkbcommon/libxkbcommon/issues/262
It might be correct lib's behavior, still.

The extra layouts are redundant, so we strip them out from usual usage.


(cherry picked from commit 59143eeef9042f3c9996a06d21a5fe05dc870dcd)

M  +2    -2    src/xkb.cpp
M  +1    -1    src/xkb.h

https://invent.kde.org/plasma/kwin/commit/ef6a9c47c5a77b45bdd77628279a4bfe85c97978
Comment 45 Andrey 2021-10-12 15:49:42 UTC
Please note the lv3:ralt_alt ("Right Alt never chooses 3rd level") option is still problematic on Wayland:
https://invent.kde.org/plasma/kwin/-/merge_requests/1508#note_320276
Comment 46 Andrey 2021-10-13 10:51:34 UTC
(In reply to Andrey from comment #45)
> Please note the lv3:ralt_alt ("Right Alt never chooses 3rd level") option is
> still problematic on Wayland:
> https://invent.kde.org/plasma/kwin/-/merge_requests/1508#note_320276
This has been confirmed as xkbcommon bug:
https://github.com/xkbcommon/libxkbcommon/issues/262