Bug 339434

Just a remark: I was using 2 monitors instead of my usual 1 monitor and I believe this is when the problem started. I am now using 1 monitor again but this problem persists. 

Is there any config where kwin might store my montior setup and it thinks that my screen corner is on monitor 2 although it really is on monitor 1 ? (just  a thought)

KWin's screen edges get disabled if there is an active fullscreen window, but for the corners. These are kept active to allow activating e.g. PresentWindows.

There is no config option to disable this.

See:
- https://bugs.kde.org/show_bug.cgi?id=271607
- https://git.reviewboard.kde.org/r/108513/
- https://git.reviewboard.kde.org/r/106722/

It's not a regression.
The screenedge would however be unregistered if compositing is suspended altogether.

> I have desktop effects deactivated for fullscreen applications and I am sure that I am running the game in fullscreen mode.

a) The config item is "mislabeled" (the window is just not redirected, but how do you tell that a user ;-)
    It has no impact on compositing in general (nor are effects unloaded - although present windows oc. has no visible result with an unredirected FS window on top of the stack)
b) The solution is (resourcewise) inferior to suspending the compositor entirely during playing the game, also unredirection was forcefully disabled for intel chips (incredibly crash prone)

If you don't want to suspend the compositor by hand, this can be automated with either a script:
http://kde-look.org/content/show.php/GameMode?content=156659

or a "special window" rule.

Okay, thank you! I am trying this script and you were right, with disabling composting all together it works.

Should we keep this report open, or should I close it? ( I am not sure if this is really the solution that everybody should be fine with...)

I frankly don't think that a global setting could be a solution - your demands will change when the FS window is a browser or image viewer, maybe even a video player.

The "normal" approach for (SDL) games is to grab the mouse and receive all input exclusively.

Whether a solution like originally requested in bug #271607 would work for you, depends on whether the client is managed at all (seems so) and detectable (doesn't, there no properties set  at all)
Notice that i just tried WC3 on wine - it however also actually grabs the pointer here.

I set it to wontfix. At least on X11 a game should grab the mouse when it needs such functionality. On Wayland that's currently not possible anyway, but the edges also don't steal mouse events any more.

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

(In reply to Thomas Lübking from comment #3)
> See:
> - https://bugs.kde.org/show_bug.cgi?id=271607
> - https://git.reviewboard.kde.org/r/108513/
> - https://git.reviewboard.kde.org/r/106722/
> 
> It's not a regression.
> The screenedge would however be unregistered if compositing is suspended
> altogether.
> 
> > I have desktop effects deactivated for fullscreen applications and I am sure that I am running the game in fullscreen mode.
> 
> a) The config item is "mislabeled" (the window is just not redirected, but
> how do you tell that a user ;-)
>     It has no impact on compositing in general (nor are effects unloaded -
> although present windows oc. has no visible result with an unredirected FS
> window on top of the stack)
> b) The solution is (resourcewise) inferior to suspending the compositor
> entirely during playing the game, also unredirection was forcefully disabled
> for intel chips (incredibly crash prone)
> 
> If you don't want to suspend the compositor by hand, this can be automated
> with either a script:
> http://kde-look.org/content/show.php/GameMode?content=156659
> 
> or a "special window" rule.

This didn't work for me. With compositor disabled hot corners still activate over fullscreen applications.

Only borders/corners assigned to compositor effects would be disabled, not eg. virtual desktop switching or autohiding panels etc.

Virtualbox scenario?