Bug 515179 - Kwin crashes in KWin::EisContext::handleEvents when monitor wakes up while using Input Leap or Deskflow in Wayland
Summary: Kwin crashes in KWin::EisContext::handleEvents when monitor wakes up while us...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: input (other bugs)
Version First Reported In: 6.5.91
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2026-01-28 01:39 UTC by Chris Warren
Modified: 2026-02-19 10:16 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.6.1
Sentry Crash Report:


Attachments
New crash information added by DrKonqi (89.00 KB, text/plain)
2026-01-28 01:39 UTC, Chris Warren
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Warren 2026-01-28 01:39:49 UTC
Application: kwin_wayland (6.5.91)
 (Compiled from sources)
ApplicationNotResponding [ANR]: false
Qt Version: 6.10.1
Frameworks Version: 6.22.0
Operating System: Linux 6.18.7-gentoo-dist x86_64
Windowing System: Wayland
Distribution: "Gentoo Linux"
DrKonqi: 6.5.91 [CoredumpBackend]

-- Information about the crash:
This crash was generated under Plasma 6.6 Beta 2, but I experienced it under 6.6 Beta 1 as well. I haven't seen this kind of issue with any earlier versions of Plasma, at least the relevant versions since Plasma Wayland and InputLeap were compatible.

I work from home and have a work laptop. I have a personal desktop (which is running Gentoo Linux and KDE Plasma) and a work laptop running Windows. In the InputLeap configuration, the Linux desktop is acting as the client and the Windows laptop is the server. So of course, in this configuration my mouse and keyboard are connected to my work laptop (via a dock fwiw), so when I'm trying to use my Linux desktop, that would happen via InputLeap and the relevant portals.

When I'm working I do sometimes get distracted by work and the Plasma desktop goes long enough without activity that the screen locks and then eventually the monitors go into power saving mode. Before 6.6, simply dragging my mouse toward my Plasma desktop wakes my monitor up and then I can get back to my desktop after entering my password. Then I can do whatever I wanted to do.

With 6.6, kwin crashes either when the monitor turns off or when it wakes up. The experience is that after my Linux desktop screens turn off, I drag my mouse from the Windows laptop to the Linux desktop and InputLeap in Windows does appear to make the Linux desktop the active system. My Linux screens even wakes up like normal and I see in the logs for my Windows InputLeap instance that the mouse is switching to to the Linux system. But no matter how much I drag my mouse to my Linux system, I never see any indication of activity on the Plasma screen (beyond the fact it woke up). I think I also typed a bit to see if there was anything that came up, but the input field for the password isn't even showing by that point, so not much happens.

I switch my physical mouse/keyboard to my Linux system and then unlock my screen and then I see that kwin had crashed. Interestingly, the InputLeap app still seems to be running but I think pretty much everything else I was running disappeared. 

I believe this is related to my monitor's power saving mode so of course a workaround is to enable "Manually block sleep and screen locking" which makes it so my monitor always stays on. I haven't tested this too extensively, but there's been a few days that I've used the system running 6.6 during work and didn't have the issue if my monitor didn't go to sleep.

I don't know if InputLeap has anything directly to do this since I haven't noticed anything in the stack trace, but I've experienced this bug regardless of the version of Input Leap I'm using. I first observed this using the flatpak version of InputLeap but switched to using Gentoo's InputLeap ebuild that builds straight from their github, which this system is currently using.

The crash can be reproduced every time.

-- Backtrace (Reduced):
#4  KWin::EisContext::handleEvents (this=0x55edf6ca5e00) at /usr/src/debug/kde-plasma/kwin-6.5.91/kwin-6.5.91/src/plugins/eis/eiscontext.cpp:223
#5  0x00007f8c0ac490e2 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=0x55edf6ca5e20, a=0x7ffde6346940) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qobjectdefs_impl.h:461
#6  doActivate<false> (sender=0x55edf6ca5e20, signal_index=3, argv=argv@entry=0x7ffde6346940) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qobject.cpp:4257
[...]
#9  QSocketNotifier::activated (this=0x55edf6ca5e20, _t1=..., _t2=<optimized out>, _t3=...) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1_build/src/corelib/Core_autogen/include/moc_qsocketnotifier.cpp:161
#10 QSocketNotifier::event (this=0x55edf6ca5e20, e=<optimized out>) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qsocketnotifier.cpp:324
#11 0x00007f8c0bfb6582 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x55edf6ca5e20, e=0x7ffde6346a60) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/widgets/kernel/qapplication.cpp:3305
#12 0x00007f8c0ac65068 in QCoreApplication::notifyInternal2 (receiver=0x55edf6ca5e20, event=0x7ffde6346a60) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qcoreapplication.cpp:1109
#13 0x00007f8c0ac6524d in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qcoreapplication.cpp:1549
#14 0x00007f8c0ab35ef6 in QEventDispatcherUNIXPrivate::activateSocketNotifiers (this=this@entry=0x55edf433be30) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qeventdispatcher_unix.cpp:276
#15 0x00007f8c0ab363b0 in QEventDispatcherUNIX::processEvents (this=<optimized out>, flags=...) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qeventdispatcher_unix.cpp:498
#16 0x00007f8c0b810ab1 in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/gui/platform/unix/qunixeventdispatcher.cpp:28
#17 0x00007f8c0ac869ca in QEventLoop::exec (this=this@entry=0x7ffde6346bf0, flags=..., flags@entry=...) at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/global/qflags.h:77
#18 0x00007f8c0ac86b50 in QCoreApplication::exec () at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/corelib/kernel/qcoreapplication.cpp:1452
#19 0x00007f8c0b302030 in QGuiApplication::exec () at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/gui/kernel/qguiapplication.cpp:1973
#20 0x00007f8c0bf39fb9 in QApplication::exec () at /usr/src/debug/dev-qt/qtbase-6.10.1/qtbase-everywhere-src-6.10.1/src/widgets/kernel/qapplication.cpp:2575
#21 0x000055edeb1ad0cd in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kde-plasma/kwin-6.5.91/kwin-6.5.91/src/main_wayland.cpp:641


Reported using DrKonqi
Comment 1 Chris Warren 2026-01-28 01:39:51 UTC
Created attachment 188970 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.
Comment 2 Simon Lees 2026-02-11 06:17:12 UTC
Also seeing this on openSUSE Tumbleweed with deskflow, I have some further info on the crash.  I am also using deskflow as the client, IE it is receiving events from another in this case Linux machine.

In the following slightly modified code was triggered if the screen was locked, in this case `device` was returning as NULL. The code below is not a workable solution as it allows input into the lock screen's password box but will never actually unlock the screen. 

```
       case EIS_EVENT_FRAME: {
            auto device = eventDevice(event);
            if (!device) {
                qCCritical(KWIN_EIS) << "EventDevice NULL";
                break;
            }
            qCDebug(KWIN_EIS) << "Frame for device" << device->name();
            if (device->isTouch()) {
                Q_EMIT device->touchFrame(device);
            }
            if (device->isPointer()) {
                Q_EMIT device->pointerFrame(device);
            }
            break;
        }
```
To work around the previous case I disabled the lock screen and got the following crash. Which again points to `auto device = eventDevice(event);`  being NULL in the following code block.

case EIS_EVENT_POINTER_MOTION_ABSOLUTE: {
            auto device = eventDevice(event);
            const double x = eis_event_pointer_get_absolute_x(event);
            const double y = eis_event_pointer_get_absolute_y(event);
            qCDebug(KWIN_EIS) << device->name() << "pointer motion absolute" << x << y;
            Q_EMIT device->pointerMotionAbsolute({x, y}, currentTime(), device);
            break;
        }

My guess is I need some logging / debugging somewhere in where the events are being created, I haven't been looking through the codebase quite enough to know where that would be yet.

My build Info is below it is the 6.6 patches from https://invent.kde.org/plasma/kwin/-/merge_requests/8602 that should be unrelated but are also on my build
```
Operating System: openSUSE Tumbleweed 20260207
KDE Plasma Version: 6.5.91
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.2
Kernel Version: 6.18.8-1-default (64-bit)
Graphics Platform: Wayland
Processors: 16 × 11th Gen Intel® Core™ i9-11950H @ 2.60GHz
Memory: 48 GiB of RAM (46.8 GiB usable)
Graphics Processor: NVIDIA RTX A2000 Laptop GPU
```
Comment 3 David Redondo 2026-02-18 07:42:02 UTC Comment hidden (spam)
Comment 4 David Redondo 2026-02-18 07:46:56 UTC Comment hidden (spam)
Comment 5 Simon Lees 2026-02-18 08:02:13 UTC
I have 1.25.0, which is the release on openSUSE Tumbleweed, 

From what i've been able to track down looking at the code it seems like eis events probably don't have a device created correctly when the screen is off. Maybe this is an issue worth fixing in libei, maybe its something that can't be fixed there (I'm certainly not an expert) and in the case when eis has events of a certain type to process when the screen is off maybe it should ignore those events and just get kwin to wake up the screen. Again I haven't looked at how / whether it is possible.

As far as I can tell the crash tends to happen when I use the mouse / keyboard from my desktop to turn the screen on my laptop back on rather then doing it from the laptop touchpad. The issue seems to happen regularly but not every time.
Comment 6 David Redondo 2026-02-18 09:34:41 UTC
I just unlocked my screen through deskflow successfully without a crash.

Are you running plasma wayland also on the device where the mouse and keyboard are connected? 
Can you enable the kwin_libeis logging category and paste the events that lead up to the crash?
Comment 7 Simon Lees 2026-02-18 10:43:03 UTC
(In reply to David Redondo from comment #6)
> I just unlocked my screen through deskflow successfully without a crash.
> 
> Are you running plasma wayland also on the device where the mouse and
> keyboard are connected? 

Currently I have enlightenment on the other machine which is still running deskflow as the server so i'm guessing that's not the issue because I presume the original reporter is doing something else.

It was only an issue for me if I waited long enough for my screen to also turn off. I have my monitors configured to switch off after 15 minutes but to never suspend / hibernate when on AC power. I am not sure if I saw the crash everytime but I'll try to narrow down how it happened.

> Can you enable the kwin_libeis logging category and paste the events that
> lead up to the crash?

Yep i'll figure that out.
Comment 8 David Redondo 2026-02-18 10:49:13 UTC
The screen being turned off seems to be the clue, I could reproduce it now thanks.
Comment 9 Bug Janitor Service 2026-02-18 11:41:08 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8836
Comment 10 Simon Lees 2026-02-19 04:59:27 UTC
(In reply to Bug Janitor Service from comment #9)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/kwin/-/merge_requests/8836

This MR fixes the issue for me.
Comment 11 David Redondo 2026-02-19 09:23:11 UTC
Git commit fba9c6d13c655c0306119dafa8ff9eeb4b40a9cf by David Redondo.
Committed on 19/02/2026 at 09:23.
Pushed by davidre into branch 'master'.

plugins/eis: Guard against events of destroyed devices

libeis  might send an event for removed devices, while a libeis bug we
need to guard against it as users see crashes in the wild.
FIXED-IN: 6.6.1

M  +9    -18   src/plugins/eis/eiscontext.cpp

https://invent.kde.org/plasma/kwin/-/commit/fba9c6d13c655c0306119dafa8ff9eeb4b40a9cf
Comment 12 David Redondo 2026-02-19 10:16:04 UTC
Git commit 9af4f446b3eb7b22922e6119d109fa3caf2a9a0a by David Redondo.
Committed on 19/02/2026 at 09:29.
Pushed by davidre into branch 'Plasma/6.6'.

plugins/eis: Guard against events of destroyed devices

libeis  might send an event for removed devices, while a libeis bug we
need to guard against it as users see crashes in the wild.
FIXED-IN: 6.6.1


(cherry picked from commit fba9c6d13c655c0306119dafa8ff9eeb4b40a9cf)

4cf37318 plugins/eis: Guard against events of destroyed devices
91759b0a Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: David Redondo <kde@david-redondo.de>

M  +9    -18   src/plugins/eis/eiscontext.cpp

https://invent.kde.org/plasma/kwin/-/commit/9af4f446b3eb7b22922e6119d109fa3caf2a9a0a