Bug 347566

Summary:	Application::notify stops after "some" randr event(s)
Product:	[Plasma] kwin	Reporter:	Achilleas Koutsou <achilleas.k>
Component:	xrandr	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	achilleas.k, adriano.mandala, kde, kdebugs, kef_kfb, mail, teemu.erkkola
Priority:	NOR
Version First Reported In:	5.3.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=349249
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Achilleas Koutsou 2015-05-11 19:40:13 UTC

After changing the monitor layout (e.g., from single to dual monitor, or vice versa) the Present Windows and Desktop Grid effects become unresponsive to any keyboard input.
For example, in Desktop Grid, pressing a number should switch to the Desktop indicated by the number and pressing escape should cancel the effect.
In Present Windows, typing anything should start filtering windows by name.

These functions stop working, but the effects continue to be responsive to mouse movement and clicking. Normal functionality resumes when the monitor layout is switched back to the original (the layout that was active during login).

Reproducible: Always

Steps to Reproduce:
1. Log in with two monitors attached.
2. Remove or disable one of the monitors such that the monitor layout switches to single monitor mode.
3. Activate desktop grid.
4. Press escape, or a number on the keyboard.

Actual Results:
Nothing happens.

Expected Results:
Desktop Grid should cancel and return to the last active desktop (if escape was pressed) or the view should switch to the desktop indicated by the number (in the case of a number being pressed).

Tested only on a Lenovo Thinkpad T510 with Intel graphics. It happens with different monitor layouts and different sequences of events:
- Dual monitor during login -> Breaks when external monitor is removed -> Works again when external monitor is plugged back in.
- Dual monitor during login -> Breaks when laptop monitor is disabled -> Works again when laptop monitor is enabled.
- Single monitor during login -> Breaks when external monitor is plugged in -> Works again when external monitor is removed.

Comment 1 Adriano 2015-05-12 20:23:42 UTC

Yes, some problem here.
Intel HD4000 on Samsung series 9 NP900X3C
After disconnet the second monitor:
- GFX broken, I can't click on any windows, but I can switch between them with Alt-Tab.
- EGL is partially broken, I can move windows but screen is translated as setttings.
I use XRender as workaround.

Comment 2 kef_kfb 2015-05-14 18:56:40 UTC

Something very similar to this affects me as well. If I activate my second monitor at any point then deactivate it again, after I initiate the present windows effect, it stops accepting any keyboard input including the key sequence to activate/end the effect. The only way to end the effect is by using mouse clicks. If I reactivate my second monitor present windows starts accepting keyboard input.

Kubuntu 15.04 with 5.3.0 on an AMD HD6850 with the radeon driver.

Comment 3 Thomas Lübking 2015-06-19 17:04:06 UTC

Some negative information:
--------------------------
despite grabXKeyboard() suggests "success", no keypress/release is received in workspaceEvent(xcb_event_t)

Changing the grab to operate on XCB_TIME_CURRENT_TIME makes no difference.

Omitting the DesktopButtonsView's doesn't help.
Restarting the compositor doesn't help.

Otoh, the tabbox grab still works ...

=> we silently, somehow, fail to grab the keyboard - but don't know why.

Comment 4 Thomas Lübking 2015-06-19 17:04:13 UTC

*** Bug 349249 has been marked as a duplicate of this bug. ***

Comment 5 Thomas Lübking 2015-06-21 13:35:54 UTC

The bug seems to be somewhere in Qt.

The event actually makes it into the X11 event processing but is passed to the Qt event queue in events.cpp:256 - yet no Application::notify() occurs in return (after the randr events)

That complex walk across QCA::notify() is likely done/required to map between X11 and Qt events resp. presses/releases and shortcuts.

With a little luck, this is the general randr/screen weakness.
But I fear we're not lucky :-(

Comment 6 Teemu Erkkola 2015-06-29 07:59:27 UTC

*** Bug 349702 has been marked as a duplicate of this bug. ***

Comment 7 Thomas Lübking 2015-08-04 20:44:02 UTC

*** Bug 350973 has been marked as a duplicate of this bug. ***

Comment 8 Justin Zobel 2021-03-10 00:32:29 UTC

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.