Everytime I start Plasma 5, I can only interact with the currently active window. All other interactable objects like the taskbar are "inactive", they do not recognize, that they're being clicked. Changing to a virtual console and then back to Plasma 5 solves this problem. Reproducible: Always Steps to Reproduce: 1. Start Plasma 5 2. Try to open for example Kmenu Actual Results: Only the active window accepts mouse input Expected Results: All interactable objects should be interactable ;) Changing to a virtual console and then back to Plasma 5 solves the problem
may be either a windowmanager problem or frozen event loop in plasmashell. are the other windows, the inactive ones interactable?
If I alt+tab them to the front: yes
(In reply to mailman.ich from comment #2) > If I alt+tab them to the front: yes They do not activate if you eg. click the titlebar? Please attach the output of "qdbus org.kde.KWin /KWin supportInformation"
No, the title bar stays inactive in each case until I switch to a virtual console. But that's interesting: I recently changed the taskbar to the one with symbols only. These symbols stay active, and after activating another program the whole status bar (including Kmenu) is working. #qdbus org.kde.KWin /KWin supportInformation https://paste.kde.org/pzcdoiwfi
Do they neither raise? Would kwin_x11 --replace & "fix" it as well (w/o switching VT) Does is also happen with glx? ("kcmshell5 kwincompositing") What's the output of glxinfo | grep -i sync
(In reply to Thomas Lübking from comment #5) > Do they neither raise? Who raises? :D > Would > kwin_x11 --replace & > "fix" it as well (w/o switching VT) Doesn't affect anything > Does is also happen with glx? ("kcmshell5 kwincompositing") yes > What's the output of > glxinfo | grep -i sync glxinfo |grep -i sync GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_swap_control, GLX_SGI_video_sync GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_swap_control, GLX_SGI_video_sync GL_ARB_stencil_texturing, GL_ARB_sync, GL_ARB_texture_barrier, GL_ARB_shadow, GL_ARB_stencil_texturing, GL_ARB_sync,
(In reply to mailman.ich from comment #6) > Who raises? :D Inactive windows, when you click them. > > kwin_x11 --replace & > Doesn't affect anything No invalid/undefined state. > glxinfo |grep -i sync No sync object, dead end. From the described behavior, it seems as if kwin would not release the passive grab on inactive windows, nor pass events on. Since it does not activate (nor raise?) those windows, it sounds as if it doesn't get the mouse events itself. About changing VT: does that mean you eg. click an inactive window (nothing happens) then chenge to VT1 and back and now the window got activated (and possibly rose)?
(In reply to Thomas Lübking from comment #7) > (In reply to mailman.ich from comment #6) > > Who raises? :D > Inactive windows, when you click them. > About changing VT: does that mean you eg. click an inactive window (nothing > happens) then chenge to VT1 and back and now the window got activated (and > possibly rose)? No: I click an inactive window (nothing happens), then I change to VTx and back (still nothing happened). Now I can click the inactive window again and the window raises.
Congratulations. You approved for the "most weird situation I heard of - so far™" award ;-) 1) Are you able to interact w/ "inactive" (read: "all") windows w/o a WM or when replacing kwin_x11 by eg. openbox? openbox --replace & resp. pkill kwin_x11; sleep 60; kwin_x11 & # gets you 60 seconds to try out Of course, w/o a WM windows wont raise or "activate" (or move!), but you should still be able to switch tabs or press an "ok" button or similar. 2) Since switching the VT seems to make a HUGE difference: can you ssh into the machine for inspection? In case, please ensure xprop, xwininfo and xdotool are installed (on the broken system) export DISPLAY=:0 xdotool key "XF86LogGrabInfo" sleep 1 sed -n 'H; /Printing all currently active device grabs/h; ${g;p;}' /var/log/Xorg.0.log > bug.infos xprop >> bug.infos # cursor should become a '+', click an inactive window - it's ok that this has no reaction but a printout xwininfo >> bug.infos # as above out of curiosity, you may check whether things work as expected after calling either xprop or xwininfo. Please attach obtained bug.infos and in any case a dump of "xinput"
bug.infos: https://paste.kde.org/pl2drmgf7 1) makes my mouse completely useless, but yes, my keyboard still works. Apart from this: After booting the only window in which I can click buttons is the first active window. E.g. if firefox is started automatically, I may cannot move its window, but the buttons inside are clickable. If I alt+tab to another window, this window doesn't accept mouse input; firefox keeps its "mouse privilege".
I forgot to mention, that xprop and xwininfo both complained: "Can't grab the mouse"
(In reply to mailman.ich from comment #11) ============================================= [ 1214.303] (II) Printing all currently active device grabs: [ 1214.303] Active grab 0x2000000 (core) on device 'Virtual core pointer' (2): [ 1214.303] client pid 15921 /usr/bin/plasmashell --shut-up [ 1214.303] at 204816 (from passive grab) (implicit) (device thawed, state 1) [ 1214.303] core event mask 0x62a07f [ 1214.303] passive grab type 4, detail 0x0, activating key 0 [ 1214.303] owner-events false, kb 1 ptr 1, confine 0, cursor 0x0 [ 1214.303] (II) End list of active device grabs ============================================= > I forgot to mention, that xprop and xwininfo both complained: > "Can't grab the mouse" That's because the mouse is grabbed - by plasmashell, in the printout, while > E.g. if firefox is started automatically, I may cannot move its window > but the buttons inside are clickable. > If I alt+tab to another window, this window doesn't accept mouse input > firefox keeps its "mouse privilege". suggests it's firefox which grabs it (though, as suggested, only because it's randomly the first client?) =============================================== ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Mad Catz Mad Catz R.A.T.9 Wireless Mouse id=8 [slave pointer (2)] ⎜ ↳ Logitech Unifying Device. Wireless PID:4003 id=9 [slave pointer (2)] ⎜ ↳ MCE IR Keyboard/Mouse (saa716x) id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Eee PC WMI hotkeys id=10 [slave keyboard (3)] ↳ saa716x IR (TurboSight TBS 6982SE) id=12 [slave keyboard (3)] =============================================== There's a gamer mouse, a logitech unifying interface (ie. a semi-blutooth dongle that receives wireless mouse and keyboard) and a MCE remote control. Can you please remove all of them, attach a dumb, cheap, 2-3 button mouse (usb, ps/2 or even RS-232) and check the behavior? It seems, clients "randomly" grab the mouse what might indicate that no mousebutton release events are generated/received.
I'm able to reproduce this bug. The only way to workaround it is to go to another tty and run kwin_x11 --replace. Please, ask me questions so I'm able to help more. KWin 5.3.0-3, Qt 5.4.1.
Please check comment #9 on whether your mouse is grabbed in a similar way (and by which client) Notably attach output of xprop and xwininfo if the pointer should NOT be grabbed. Since the original report stated that it's sufficient to switch VTs forth and back, while you suggest it's required to restart KWin, I'm not sure this is the very same problem.
I assume this is no longer an issue? In case you still experience please reopen.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Yes, this problem was resolved. Thank you very much for your help and sorry for the very late response :)