Bug 274880

Summary: In full screen mode, some buttons in the tool bar don't behave properly
Product: [Plasma] kwin Reporter: Manu <manuavazquez>
Component: compositingAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: caulier.gilles, hugo.pereira.da.costa, manuavazquez, nemeskey.david
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Manu 2011-06-04 03:19:29 UTC
Version:           1.9.0 (using KDE 4.6.2) 
OS:                Linux

When in full screen mode the "clickable" part of the "exit full screen mode" button does not spread across the whole button (only the left part, close to the icon of the button). Also, the "presentation" button is almost impossible to click: you have to hover the mouse over the button for some time to find a clickable part.

Reproducible: Always

Steps to Reproduce:
Just enter fll screen mode

Actual Results:  
I can't get out of full screen mode by clicking any part of the "Exit full screen mode"

Expected Results:  
Any part of the button should do

OS: Linux (x86_64) release 2.6.38-gentoo-r6
Compiler: x86_64-pc-linux-gnu-gcc

I don't know if it matter but I have an ati graphics card and it happens with both open-source and proprietary drivers.
Comment 1 Marcel Wiesweg 2011-06-21 21:51:14 UTC
Cannot reproduce. Which style are you using, Oxygen?
Comment 2 Manu 2011-06-22 03:16:50 UTC
(In reply to comment #1)
> Cannot reproduce. Which style are you using, Oxygen?

Yes, I'm using Oxygen... I will try in a different computer and will get back to you (maybe it's Gentoo related...though it doesn't look very likely)
Comment 3 Manu 2011-06-22 07:37:59 UTC
(In reply to comment #1)
> Cannot reproduce. Which style are you using, Oxygen?

Ok, now I know the reason: it only happens here when composition is enabled. If I disable all the desktop effects :( the full screen mode works properly. That probably means this is a kwin (or something else) bug rather than a digikam one, doesn't it?
Comment 4 caulier.gilles 2011-06-22 08:32:15 UTC
yes probably. I move this file to Oxygen team.

Gilles Caulier
Comment 5 Hugo Pereira Da Costa 2011-06-22 12:15:07 UTC
Manu
Can you reproduce, with compositing on, and a different widget style ? 
to check whether its a kwin or an oxygen issue ?
Comment 6 Manu 2011-06-23 06:40:50 UTC
(In reply to comment #5)
> Manu
> Can you reproduce, with compositing on, and a different widget style ? 
> to check whether its a kwin or an oxygen issue ?

Yes, I just reproduced it with CDE. It seems to me that it's related to kwin...but maybe there is some hidden twisted option in the "Device" section of Xorg that fixes this (I'm refering to "XaaNoOffscreenPixmaps" "true" and stuff like that). I'm just saying because it shocks me that no one else reported this before :-S Anyway, I really appreciate someone taking care of this...so thank you very much!!
Comment 7 Hugo Pereira Da Costa 2011-06-23 10:45:10 UTC
So re-assigning to kwin
Comment 8 Martin Flöser 2011-06-23 11:42:36 UTC
@hugo: please remember to change the assignee when reassigning.


@manu: could you please provide some more info for the people not knowing digikam so that we can understand what's happening.

Personally I doubt that this is in any way related to kwin and I think it is a bug in a different part (e.g. Digikam or X). Compositing does not change window management and applications in any way. So we need to know whether the problem persists with different compositing modes (e.g. XRender) and other Compositors (e.g. Compiz) and if other applications show the same behavior.
Comment 9 Manu 2011-06-23 12:04:48 UTC
(In reply to comment #8)
> @hugo: please remember to change the assignee when reassigning.
> 
> 
> @manu: could you please provide some more info for the people not knowing
> digikam so that we can understand what's happening.
> 
> Personally I doubt that this is in any way related to kwin and I think it is a
> bug in a different part (e.g. Digikam or X). Compositing does not change window
> management and applications in any way. So we need to know whether the problem
> persists with different compositing modes (e.g. XRender) and other Compositors
> (e.g. Compiz) and if other applications show the same behavior.

Hi Martin,

I don't know exactly what information you need (xorg configuration, kde settings...). Apart from what I already described above, I can also mention than going from window mode to full screen mode and vice versa, the screen flickers for an instant (not that it's very annoying but maybe it's a symptom of something else). When in full screen mode it happens what I already tried to describe above: if you want to press the "exit full screen" button again, it seems that the only part of the button that is clickable is the very border.

More things: in this computer I'm using a nvidia graphics card with proprietary drivers (though it also happened to me in a laptop with open source ati drivers) and my xorg configuration is a basic one (no special options in the "Device" or "Screen" sections).

Also, I just tried using "Xrender" instead of "Opengl" in "Type of Composition" and the problem persists.

If you want me to try something else, just let me know.
Comment 10 Thomas Lübking 2011-06-23 14:30:18 UTC
I've never managed to get the toolbar visible in digikam fullscreen mode (so used the shortcut) - there's a checkbox, but the settgin seems just ignored in 1.9.0 *shrug*

However, this (iff at all) sounds like a "re-redirection flicker on tooltip" issue.
Call "kcmshell4 kwincompositing", select the "advanced" (3rd) tab and uncheck "suspend desktop effects for fullscreen windows"

Then try again and report.
Comment 11 Manu 2011-06-30 02:12:21 UTC
(In reply to comment #10)
> I've never managed to get the toolbar visible in digikam fullscreen mode (so
> used the shortcut) - there's a checkbox, but the settgin seems just ignored in
> 1.9.0 *shrug*
> 
> However, this (iff at all) sounds like a "re-redirection flicker on tooltip"
> issue.
> Call "kcmshell4 kwincompositing", select the "advanced" (3rd) tab and uncheck
> "suspend desktop effects for fullscreen windows"
> 
> Then try again and report.

Hi Thomas,

sorry for the dealy..but the day you posted that message I tried to follow the link from the e-mail, but it was broken...and after that I completely forgot :$

Anyway, that workaround is not working for me. It seems that it makes no difference wether that option is enabled or not (I just tried both and no way). Let me know if you want me to check something else.

Greetings.
Comment 12 Thomas Lübking 2011-06-30 11:13:35 UTC
Nevermind, happens to myself on a regular base as well ;-)

I've meanwhile hacked the digikam config file to get the toolbar in FS mode and cannot reproduce your observation (unredirectionm, compositing, OpenGL or not)

-> do you keep some (autohiding?) plasma panel or maybe yakuake on top of your screen?

The other thing was to determine a culprit effect (that might keep some input widget around)
-> disable all effect plugins but keep compositing enabled. If the problem vanishes you'll have to bisect it by re-enabling plugins one by one to see which causes this.
Comment 13 Manu 2011-07-01 10:46:06 UTC
(In reply to comment #12)

> -> do you keep some (autohiding?) plasma panel or maybe yakuake on top of your
> screen?

Yes I do keep an autohiding panel on top...and also yakuake :) Actually, I have two computers (desktop and laptop)
- with nvidia card (proprietary or open-source drivers): if I disable the autohiding panel (just the autohiding feature), then the issue goes away (I can't try right now if disabling desktop effects is also a workaround since I'm not at work)
- with ati (open-source drivers): disabling the desktop effects is indeed a workaround (I love them, though...damn it :D ) EVEN when the autohiding panel is enabled.

> The other thing was to determine a culprit effect (that might keep some input
> widget around)
> -> disable all effect plugins but keep compositing enabled. If the problem
> vanishes you'll have to bisect it by re-enabling plugins one by one to see
> which causes this.

I can try this it what I wrote above is not useful (I'm guessing not much, right?)
Comment 14 Thomas Lübking 2011-07-01 15:52:35 UTC
You're either clicking the plasma "shadows" (but the panel should not be on top of a fullscreen window) or plasma grabs intercepts clicks and sends them to the wrong client
This issue should be gone with 4.7 (where the panel shadows are no more part of a real window) but can you please
sleep 10; xwininfo
and in the 10 sleepy seconds set digikam fullscreen and then when the cursor turns into a cross click the "inactive" part of the toolbutton.

Then post the output. Thanks.
Comment 15 Thomas Lübking 2011-07-01 15:53:53 UTC
PS: you won't have to try on the effects anymore. If it's related to the plasma panel, it's hardly to one of them as well.
Comment 16 Manu 2011-07-03 01:07:57 UTC
(In reply to comment #14)
> but can you please
> sleep 10; xwininfo
> and in the 10 sleepy seconds set digikam fullscreen and then when the cursor
> turns into a cross click the "inactive" part of the toolbutton.

when I do this, I don't really know if I'm clicking a part of the button that is inactive (since it is kind of random :-S and no button is highlighted under the cross) so I made two attemps clicking two parts of the button that are "usually" inactive (almost any part of the button but the edges). The second output is probably more meaningful since at least the window is recognized as belonging to digikam.


xwininfo: Window id: 0x1e4af33 (has no name)

  Absolute upper-left X:  512
  Absolute upper-left Y:  0
  Relative upper-left X:  512
  Relative upper-left Y:  0
  Width: 342
  Height: 30
  Depth: 0
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOnly
  Colormap: 0x0 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +512+0  -512+0  -512-738  +512-738
  -geometry 342x30+512+0

============================


xwininfo: Window id: 0x6200042 "digiKam"
                                                                                              
  Absolute upper-left X:  0                                                                   
  Absolute upper-left Y:  0                                                                   
  Relative upper-left X:  0                                                                   
  Relative upper-left Y:  0
  Width: 1366
  Height: 768
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1366x768+0+0
Comment 17 Thomas Lübking 2011-07-03 10:27:51 UTC
> xwininfo: Window id: 0x1e4af33 (has no name)
..
> -geometry 342x30+512+0

Is your panel (including shadows) maybe 30px high and about 342px width...? ;-)
You can use kruler to estimate it more precisely.
Comment 18 Manu 2011-07-05 00:00:39 UTC
> Is your panel (including shadows) maybe 30px high and about 342px width...? ;-)
> You can use kruler to estimate it more precisely.

Actually, it's not exactly that: it's 314 x 52 :-S (I don't see any shadow, by the way)
Comment 19 Thomas Lübking 2011-07-05 13:33:06 UTC
Sounds close enough (14px padding for the shadows and 2px min height?), i guess the xwininfo measured size will change if you make the panel eg. wider as well.

-> the window should not be on top of the stack of a fullscreen window unless it's
a) override type
b) risen by the client (the result would be that digikam is no more "real" fulslcreen then)

You can check for this, but i'll configure me a plasma panel like yours and see what happens.

-> What plasma theme do you use?
Comment 20 Manu 2011-07-06 13:19:45 UTC
> the xwininfo measured size will change if you make the panel eg. wider as well.

I tried increasing the size of the panel and:

  Absolute upper-left X:  480
  Absolute upper-left Y:  0
  Relative upper-left X:  480
  Relative upper-left Y:  0
  Width: 406
  Height: 30
  Depth: 0
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOnly
  Colormap: 0x0 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +480+0  -480+0  -480-738  +480-738
  -geometry 406x30+480+0

so, yes, it seems the measurements of xwininfo change.

> -> the window should not be on top of the stack of a fullscreen window unless
> it's
> a) override type
> b) risen by the client (the result would be that digikam is no more "real"
> fulslcreen then)
> 
> You can check for this

I really don't know how to check any of that :-S if you want my help there, you will have to give some hints...

> -> What plasma theme do you use?

I'm using oxygen.
Comment 21 Martin Flöser 2011-07-10 06:42:55 UTC
*** Bug 255129 has been marked as a duplicate of this bug. ***
Comment 22 Martin Flöser 2016-11-02 13:36:58 UTC
The problem described in this bug report cannot happen with Plasma 5 any more. We changed the interaction of the auto-hiding panel and it gets hidden properly by KWin and does not take any input events any more.

As the initial problem was reported against a 4.x version I set to unmaintained, though fixed would also fit ;-)