Version: unspecified (using KDE 4.6.3) OS: Linux Java applications using fullscreen exclusive mode or simulated fullscreen mode are not displayed in fullscreen, the task bar is always drawn on top of them. I tested several applications relying on AWT/Swing. I have not yet tested Java applications using their own native windowing system (NEWT in JOGL 2.0 for example). This is a regression as it was working correctly in KDE 3. Reproducible: Always Steps to Reproduce: 1. Launch a Java Web Start application using fullscreen mode in command line by typing for example javaws http://tuer.sourceforge.net/tuer.jnlp 2. Click on the button "Ok" once (with Oracle Java) or 3 times on the button "Run" (with icedtea-web and OpenJDK) Actual Results: The game seems to occupy the whole window except the bottom. The task bar is drawn above the fullscreen window. Expected Results: The game occupies the whole window, the task bar is not visible. The "same" bug has been fixed in Metacity (GNOME) several years ago and then is not reproducible with the latest stable version of GNOME. I have reproduced this bug with Oracle Java Development Kit 1.6 update 25 and OpenJDK Runtime Environment (IcedTea6 1.10).
This bug is not reproducible on KDE 3.5.4-25 with Cent OS Linux 5.3. I will try this at home: kwriteconfig --file kwinrc --group Windows --key LegacyFullscreenSupport true qdbus org.kde.kwin /KWin reconfigure
I have disabled desktop effects by default, it does not solve the problem.
Desktop effects are not related. This is iff at all, still a kwin issue.
Pressing ALT+F3 -> "Advanced" -> "Fullscreen" works. Now I have a workaround.
I entered this command line: kwriteconfig --file kwinrc --group Windows --key LegacyFullscreenSupport true qdbus org.kde.kwin /KWin reconfigure It did not change anything. I'm going to try to restart KDE.
Please run konsole and enter: sleep 10; xprop > java_fullscreen_issue.txt then wait 10 seconds (the cursor will change to a cross) and click the java styled "fullscreen" window that does not cover the panel
Created attachment 61222 [details] java_fullscreen_issue.txt
Thank you very much for your help.
Thanks for the xprop. As predicted (why, oh why did i know this would happen...) the window is NOT tagged fullscreen "_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN" So basically this is a java issue, welcome to 2011. I though wonder why the legacy supprt doesn't work. Either Mageia has patched it out (i was about to suggest Martin to do the very same after i recommanded to keep it for a while with KDE 4.5 .... many thanks for confirming my paranoia :-( or the legacy hack somewhen in the past got a bug. You /do/ confirm that setting "LegacyFullscreenSupport" to "true" did not "help"? This is however irrelevant, since the legacy hack /will/ be dropped in the near future (and/because it breaks the netbook shell) So you should tell oracle and/or the vendor of the specific software* to follow the net_wm spec on X11 http://standards.freedesktop.org/wm-spec/wm-spec-latest.html This is really no "new" stuff and the propagated "standard" for around a decade. To help you out a little more: you can run "kcmshell4 keys", select "kwin", filter fo "fullscreen" and set a shortcut to set the current window fullscreen (dep. on how much you need it) *it's not said that java doesn't actually have an API for this, it may just be not promoted/used enough. (setting invalid since the window is not fullscreen, so there's no reason to treat it like this. iff the legacy hack does no more work, the bug would move to "unmaintained")
_NET_WM_STATE(ATOM) is empty when I use explicitly the exclusive fullscreen mode instead of the simulated fullscreen mode :( I confirm that LegacyFullscreenSupport does not solve the problem. It is strange as it works correctly in KDE 3.5. I will see with Oracle how to fix this bug. Thank you very much for all these precise pieces of information, it will be useful.
> I confirm that LegacyFullscreenSupport does not solve the problem. It is > strange as it works correctly in KDE 3.5. Given that 3.5 has been released several years ago and our code has changed quite a lot it is not strange to me. Thanks for the info that our legacy support is broken - a good reason to drop it.
The bug fix that does exactly what is suggested has been implemented in NEWT, in JOGL 2.0, in its C source code: https://github.com/sgothel/jogl/blob/master/src/newt/native/X11Window.c See static void NewtWindows_setFullscreen (Display *dpy, Window root, Window w, Bool fullscreen).
Hi! After some deeper investigations, it seems that the bug does not come from Java, /jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c (used both on Solaris and Linux) calls XSendEvent as you see here (in IcedTea but I checked in the most recent source code of the OpenJDK 1.6) in the method X11GD_SetFullscreenMode: http://icedtea.classpath.org/hg/openjdk/file/ce9dde984c21/j2se/src/solaris/native/sun/awt/awt_GraphicsEnv.c Calling XSendEvent should be enough, we should not manually change the state by calling XChangeProperty. Therefore, Java respects the spec as far as I know. That's why I want to reopen this bug. In the EWMH spec, it is NOT written that a window has to be in the state _NET_WM_STATE_ABOVE to be promoted in the state _NET_WM_STATE_FULLSCREEN.
Created attachment 61440 [details] Fullscreen exclusive mode test in Java
Created attachment 61441 [details] Test of the FSEM, xprop output on KDE 3.5.4 _NET_WM_STATE_FULLSCREEN does not appear in the file whereas XSendEvent is called. Despite that, in KDE 3.5.4, the fullscreen exclusive mode works.
Created attachment 61442 [details] Test of the FSEM, xprop output on GNOME 2.16.1 Fullscreen exclusive mode works on GNOME 2.16.1 and you can see this line in this file: _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
> Calling XSendEvent should be enough, we should not manually change the state by > calling XChangeProperty. Looks like a(nother) misunderstanding of the NETWM spec (on either side). Exctp: ------- "A Client wishing to change the state of a window MUST send a _NET_WM_STATE client message to the root window (see below). The Window Manager MUST keep this property updated to reflect the current state of the window." It is NOT "The Window Manager MUST update the property on the window" but with (mine as well ;-) wonky knowledge of the English language, the section could actually just as well be read like this. This code is quite old, so i've no idea whether it's matter of understanding or implementation lack (like from NETWM 1.2 -> 1.3) KWIn (in a quite global approach) just watches for the event, inspects the _present_ properties and acts on changes. The KWIn reading (as implemented in NEWT) does make quite some sense to me, since the client usually wants to change the state, regardless whether there (at this very moment) a WM or not and then inform the WM to please handle the change. (If the window wasn't mapped at this time, the client would naturally set the window property to have it honored, but since it is it just also has to inform the WM that it did so) <rant> Long story short: The NETWM spec still SUCKS. It's written poorly and apparently quite misunderstandable :-( WMs deviate from it, clients deviate from it. Every single client (toolkit) has to reimplement it and then "verification" is done by testing against the WM de toujours. </rant>
Ok, you consider I should use the same fix than NEWT. I will speak about it to the OpenJDK AWT dev team.
Whether the window is mapped or not, I should call XSendEvent, is it what you mean? According to you, whether the window is mapped or not, I should call XChangeEvent too as NEWT does, am I wrong?
Anyway, a window not on top of the stack (see _NET_WM_STATE_ABOVE) should be allowed to go to the exclusive fullscreen mode, I hope we agree with that.
(In reply to comment #20) > Anyway, a window not on top of the stack (see _NET_WM_STATE_ABOVE) should be > allowed to go to the exclusive fullscreen mode, I hope we agree with that. _NET_WM_STATE_ABOVE is "stay above", not "on top of stack", but other than this - yes, it's currently only worked around in KWin. So the current behaviour is not entirely correct but works with a minor side-effect in rare use cases (and didn't require major code changes with uncertain side effects...) (In reply to comment #19) > Whether the window is mapped or not, I should call XSendEvent, is it what you > mean? No, the current spec requires to call XSendEvent after changing _NET_WM_STATE for a MAPPED WINDOW ONLY. Calling it for unmapped windows is certainly NOT required for kwin since it reads the property anyway when this happens. > According to you, whether the window is mapped or not, I should call > XChangeEvent too as NEWT does, am I wrong? No, you're not and yes you should, but not that ;-) The spec as I would read it says: a) use XChangeProperty to alter the _NET_WM_STATE when required b) if the window is already mapped, call XSendEvent on _NET_WM_STATE and the changed state values as attributes. -------------- I cannot really say what the spec anctually "wants to say" in this case, but the presence of the terms xsendEVENT and _net_wm_STATE sounds dumb enough :-( As the term implies, _NET_WM_STATE is a (persistant) "state" and not a (temporary) "event" and since changing properties triggers an event anyway, i don't know what this was meant to be in the first place (i doubt that a client is supposed to send a request to the WM to set props like _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER or even _NET_WM_STATE_DEMANDS_ATTENTION. === WARNING: THE FOLLOWING IS NOT NETWM AND ATM NOT SUPPORTED BY KWIN ======== ------------------------------------------------------------------------------ imho the client should always just set the state and the WM should handle those changes of this property "the right way". There's really no need to mess up with an extra event here and on top one can by this change more than even two state atrributes at once ;-)
Created attachment 61461 [details] Test of the FSEM, xprop output on KDE 4.6.3
Created attachment 61463 [details] Test of the FSEM, xprop output on GNOME 2.32.1
After reading through the complete report again I do not see anything what should be changed in KWin.