Bug 313145 - Edges and "hiden panels" stop working when System Activity is shown
Summary: Edges and "hiden panels" stop working when System Activity is shown
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal (vote)
Target Milestone: 4.10.1
Assignee: KWin default assignee
URL: http://git.reviewboard.kde.org/r/108864/
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-12 19:48 UTC by Alex Fiestas
Modified: 2013-03-07 11:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.10.1
thomas.luebking: ReviewRequest+


Attachments
xwininfo -root --tree output (15.94 KB, text/plain)
2013-01-12 21:34 UTC, Alex Fiestas
Details
xwindow info from fullscreen (630 bytes, text/plain)
2013-02-07 10:34 UTC, Alex Fiestas
Details
patch in the blue (3.69 KB, patch)
2013-02-07 21:23 UTC, Thomas Lübking
Details
patch in the green (3.58 KB, patch)
2013-02-07 22:30 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Fiestas 2013-01-12 19:48:55 UTC
When I execute the shortcut "ctrl+esc" and KRunner shows the System Activity, the edges stop working and the hidden panels won't unhide when the Mouse is close to them.

A way of fixing this is showing a notification for example by executing:
"kdialog --passivepopup weird"

Once the notification is shown, edges and panels work again.

Reproducible: Always
Comment 1 Thomas Lübking 2013-01-12 20:17:01 UTC
Does krunner / master still show ksysguard?
If so "not here".

Either the edges got unmapped or (should not happen) covered by the desktop (or some input only window - can you still click the desktop?)

Please attach the output of "xwininfo -root -tree" when this happens (have a short look and scratch pot. private data on the output)
Comment 2 Alex Fiestas 2013-01-12 21:34:37 UTC
Created attachment 76429 [details]
xwininfo -root --tree output
Comment 3 Alex Fiestas 2013-01-12 21:35:28 UTC
Yes, I can click the desktop. 

Edges become working again also from showing Yakuake (I know this is not much help...)
Comment 4 Thomas Lübking 2013-01-12 21:38:57 UTC
Before i read cross that tree - the edges were not accessible at the moment you obtained it, right?
Comment 5 Alex Fiestas 2013-01-12 21:55:03 UTC
Right, I double checked everything.
Comment 6 Thomas Lübking 2013-01-12 22:22:13 UTC
please run

xev -id `xwininfo | sed -e '/Window id/! d; s/.*: 0x/0x/; s/ .*//'` | grep -A3 ConfigureNotify

and pick the desktop, then cause the issue and share the output (or whether it's void)
Comment 7 Alex Fiestas 2013-01-13 00:11:41 UTC
-Executed the command on a terminal
-Clicked the desktop and opened context menu in it
-Clicked again the desktop
-Triggered ctr+esc
-Tried to execute an Edge (top right one)
-Closed the System Activity window
-Tried to execute an edge (top right one)
-Show yakuake
-Tried to execute an edge (top right one) (this time it worked)

During this whole process I saw no output from the command you pasted.
Comment 8 Thomas Lübking 2013-01-13 00:27:02 UTC
meehh ... i'll write you a debug patch tomorrow. :-\
Comment 9 Thomas Lübking 2013-01-16 12:57:13 UTC
Coming back to this, i've got a remote idea what could cause this.
Please - if you can - shortcut "raisePanelProxies()" in screenedge.cpp (just "return;" immediately)

The funtion will for *sure* cause a false positive on some (often maximized?) windows because the input window being the clients input window (needs to be ignored) to allow borderless resize areas will eventually be on the edge of the screen and has nor maximum size limitation.


I'll fix that regardless but it would be great if you could check whether your trouble is caused by this function.
Comment 10 Alex Fiestas 2013-01-16 15:39:23 UTC
I put a return just in the first line of the Method.

The bug was still reproducible.
Comment 11 Thomas Lübking 2013-01-16 16:10:38 UTC
Bleh - wild shot: do "xwininfo" and "xprop" on where the input window for the panel proxy or screen edge should be.
Comment 12 Martin Flöser 2013-02-06 08:38:55 UTC
For the documentation record: I have seen the problem on Alex notebook.

It looked like the screen edge (and panel proxies) need to be re-raised which happens with the next update of stacking order (e.g. new window appears).

Still I'm not able to reproduce it. I'd say the reason for this problem is somewhere hidden in the system activity window.
Comment 13 Thomas Lübking 2013-02-06 09:52:53 UTC
could you check what window actually is there?
@alex
if you don't use the krunner shortcut but bind ksysguard via the hotkeys kcm - is the behavior the same?
any rules reg. ksysguard (or krunner?)?
Comment 14 Alex Fiestas 2013-02-06 10:31:11 UTC
No rules, executing ksysguard via shortcut does not produce the bug.

Only rule I have is:

(Default) Disable focus stealing prevention for XV

Thanks for looking into this :/ WIll try to give you a way of reproducing it.
Comment 15 Alex Fiestas 2013-02-07 10:34:59 UTC
Created attachment 76968 [details]
xwindow info from fullscreen

I realized that either with the new or old screen corners code, if I have a fullscreen window (like the one I attached in the xwindow) this bug is NOT reproducible.
Comment 16 Alex Fiestas 2013-02-07 10:35:40 UTC
With the new corner case code, this bug is still reproducible exactly as it was with the old code.
Comment 17 Thomas Lübking 2013-02-07 11:51:18 UTC
Expectable (because a hack to raise the fullscreen window) - xwininfo/xprop of the edge when it does /not/ work is more interesting.
Comment 18 Alex Fiestas 2013-02-07 17:03:05 UTC
Found a way of finally reproduce this, I'm so happy at this moment guys xD

1-Configure Oxygen window decorator to have Border size: No Border
2-Try to reproduce.

:D
Comment 19 Thomas Lübking 2013-02-07 17:06:05 UTC
What's you Qt version?
Comment 20 Alex Fiestas 2013-02-07 17:41:32 UTC
Using Qt version 4.8.4
Comment 21 Martin Flöser 2013-02-07 19:24:04 UTC
@Thomas: have a look at my review request for the input window. Apply it, compile it and look for the warnings. Then go to that place and look at the code (stacking order related). I think that code is completely conceptually broken.
Comment 22 Thomas Lübking 2013-02-07 20:22:26 UTC
Applied https://git.reviewboard.kde.org/r/108771/
Got:

/home/src/KDE4/kde-workspace/kwin/main.cpp: In Funktion »int kdemain(int, char**)«:
/home/src/KDE4/kde-workspace/kwin/main.cpp:534:19: Warnung: Variable »sargs« wird nicht verwendet [-Wunused-variable]


/home/src/KDE4/kde-workspace/kwin/useractions.cpp: In Elementfunktion »void KWin::Workspace::performWindowOperation(KWin::Client*, KDecorationDefines::WindowOperation)«:
/home/src/KDE4/kde-workspace/kwin/useractions.cpp:955:11: Warnung: Aufzählungswert »ToggleClientTiledStateOp« wird nicht von switch behandelt [-Wswitch]

/home/src/KDE4/kde-workspace/kwin/rules.cpp: In Elementfunktion »bool KWin::Rules::update(KWin::Client*, int)«:
/home/src/KDE4/kde-workspace/kwin/rules.cpp:522:8: Warnung: Vergleich zwischen »enum KWin::Rules::ForceRule« und »enum KWin::Rules::SetRule« [-Wenum-compare]
/home/src/KDE4/kde-workspace/kwin/rules.cpp:525:8: Warnung: Vergleich zwischen »enum KWin::Rules::ForceRule« und »enum KWin::Rules::SetRule« [-Wenum-compare]

(unimplemented NOW_REMEMBER(OpacityActive, opacityactive))

/home/src/KDE4/kde-workspace/kwin/effects.cpp:1643:9: Warnung: unbenutzter Parameter »parameter« [-Wunused-parameter]

I still have a bunch of local patches but reverted the one which altered the way to raise the panel proxies.

=> What do i miss?
Comment 23 Martin Flöser 2013-02-07 20:29:31 UTC
now I'm confused :-) have a look at layers.cpp propagateClients

there we have:
newWindowStack << (Window*)client->inputId();

and I get there a pointer size not matching warning. What strikes me is that inputId() and everything else there provides a Window/xcb_window_t and not a pointer.
Comment 24 Thomas Lübking 2013-02-07 20:38:45 UTC
/Actually/ i had seen that before (when checking the panelproxy thing i think) and wondered myself.

You'll get a warning on 64bit arch only since void* is 2^64 while X11 Cards remain 32bit - i've a bunch of 32bit blobs to run and no demands for > 4GB / process, thus 2^32 arch  =)

And yes: it looked weird then and still looks weird now - and is wrong for sure: XRestackWindows takes a WId array, not a WId* array.

Bring cast, align and som O3 magics in, and you're done.

@Alex: o3 compile? You gonna try a patch?

Cheers,
Thomas
Comment 25 Alex Fiestas 2013-02-07 21:08:40 UTC
-O2 -g -DQT_NO_DEBUG (RelWithDebInfo)

I Will try any patch you send me :p
Comment 26 Thomas Lübking 2013-02-07 21:23:15 UTC
Created attachment 76992 [details]
patch in the blue

Doesn't matter - weird pointer cast-a-round is wrong and Java iterators suck =)

Patch should apply on todays master.
Comment 27 Thomas Lübking 2013-02-07 22:24:13 UTC
WARNING: patch crashes alot, because screenedges::windows does not return a reference :-(
Update within few minutes, sorry.
Comment 28 Thomas Lübking 2013-02-07 22:30:43 UTC
Created attachment 76994 [details]
patch in the green

todo: check whether the "!= none" check is required at all then
Comment 29 Martin Flöser 2013-02-08 07:15:33 UTC
@Alex: I'm finally able to reproduce the issue :-)
Comment 30 Martin Flöser 2013-02-08 07:19:42 UTC
with patch applied, I'm no longer able to reproduce
Comment 31 Martin Flöser 2013-02-08 07:24:59 UTC
regression got introduced with ac0f8bfb24403168199027a77bba0107bc6d42e1. I'd blame code review for not noticing that the datatype changed from Window to Window*
Comment 32 Alex Fiestas 2013-02-08 09:43:53 UTC
Unable to reproduce with the patch applied.
Comment 33 Thomas Lübking 2013-02-12 21:30:17 UTC
Git commit be26c2f514b3feb2b3e1c94fb062557a563e45df by Thomas Lübking.
Committed on 07/02/2013 at 22:18.
Pushed by luebking into branch 'master'.

fix restacking ... code

- don't cast Window's to pointers for no apparent reason
bug introduced with ac0f8bfb24403168199027a77bba0107bc6d42e1
- no stupid java style iterators, we've stl everywhere
- postfix in a for loop is a bug. period. ;-)
REVIEW: 108864
FIXE-IN: 4.10.1

M  +17   -19   kwin/layers.cpp

http://commits.kde.org/kde-workspace/be26c2f514b3feb2b3e1c94fb062557a563e45df
Comment 34 Thomas Lübking 2013-02-18 21:48:26 UTC
Git commit 0b8605cc8e3d656854a634e0a93aabc7a3a3acce by Thomas Lübking.
Committed on 08/02/2013 at 19:54.
Pushed by luebking into branch 'master'.

fix restacking ... code

- don't cast Window's to pointers for no apparent reason
  bug introduced with ac0f8bfb24403168199027a77bba0107bc6d42e1
- no stupid java style iterators, we've stl everywhere
- postfix in a for loop is a bug. period. ;-)
FIXED-IN: 4.10.1

M  +19   -15   kwin/layers.cpp

http://commits.kde.org/kde-workspace/0b8605cc8e3d656854a634e0a93aabc7a3a3acce
Comment 35 Roberto Ragusa 2013-03-07 11:09:20 UTC
While searching a workaround to have the autohide panel to unhide again, I tried to change (and change back) things in the settings; no luck with action-on-edges, number of virtual-desktop, change activity, lock/unlock widgets, add/remove another panel, but it finally worked and I think it was "enable desktop effects", which was on, then switched off, then switched again on, that fixed the problem. (I hate restarting the session and also killing plasma-desktop, as it makes a mess of the window positions).