Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes
Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  Print  
  Bad piece of news: fullscreen mode broken in KDE 4.3/4.4  (Read 2653 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« on: 2010-03-13 11:05:20 »

Hi!

As you can see there, the fullscreen mode does not work under Linux with KDE 4.3/4.4. I have tested some applications that use JOGL and the task bar is drawn onto the application. I'm very sad Sad I don't know if all applications are concerned. Pure Java applications that does not rely on OpenGL are concerned too. However, when I switch Firefox into fullscreen mode, it works.

N.B: applications using LWJGL are not concerned, I don't know why.

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #1 on: 2011-06-21 04:52:26 »

Hi!

Sorry to refresh this old thread. This bug has not been fixed in the case of Java applications. It is still not working in KDE SC 4.6.1. I wrote a separate bug report here (as the previous one has been marked as resolved and the guys who fixed did not consider Java):
https://bugs.kde.org/show_bug.cgi?id=276159

Please could some people vote for it?

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #2 on: 2011-06-21 18:32:01 »

The bug comes from Java, not from KDE. Java does not respect the specification of KDE, the fullscreen window is not marked as fullscreen. I have written another bug report for Oracle this time. I will post the link later. Good night.

Julien Gouesse
Games published by our own members! Go get 'em!
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #3 on: 2011-06-22 07:34:42 »

Hi!

The correct behavior (updating the atom so that it is marked as fullscreen) had already been implemented in NEWT (JOGL 2.0) and earlier in LWJGL. I hope it won't be hard to get a fix for this bug.

Julien Gouesse
Offline kappa
« League of Dukes »

JGO Kernel
*****

Posts: 2357
Medals: 59


★★★★★


« Reply #4 on: 2011-06-22 07:55:14 »

maybe you can just access the variable of the AWT window via JNI and set it yourself?
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #5 on: 2011-06-23 07:19:00 »

maybe you can just access the variable of the AWT window via JNI and set it yourself?
What do you mean exactly? I need to do something like this in C/C++ in the method NewtWindows_setFullscreen in https://github.com/sgothel/jogl/blob/master/src/newt/native/X11Window.c. Do you think I could access this variable by using sun.awt.X11.XToolkit? Thank you for the tip.

Edit.: You're right, I can even use sun.awt.X11.XClientMessageEvent and some other Java calls to do it.

Julien Gouesse
Offline princec
« League of Dukes »

JGO Kernel
*****

Posts: 8076
Medals: 91


Eh? Who? What? ... Me?


« Reply #6 on: 2011-06-23 11:19:27 »

Sounds like you might have the makings of a hacky workaround there then Smiley

Cas Smiley

Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #7 on: 2011-06-23 14:32:43 »

Sounds like you might have the makings of a hacky workaround there then Smiley
It is not very complicated, only between 5 and 10 lines of code to enter fullscreen mode and the same at exit by using XLibWrapper. Something like this workaround is already used both in LWJGL and in JOGL 2.0 (NEWT), the only difference is that I won't have to write C code if I use XLibWrapper.

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #8 on: 2011-06-25 02:39:24 »

Hi!

The bug report in Oracle bug tracker is here and has been accepted:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057287

I cannot vote yet, something is wrong when I login.

Julien Gouesse
Offline nsigma

Sr. Member
**

Posts: 342
Medals: 18



« Reply #9 on: 2011-06-25 06:01:29 »

Hi Julien,

Could I clarify whether you're using FSEM or just trying to set the size of the window - your KDE bug report suggests you've tried both, but the Java bug report only shows the latter?

As per my comment here - http://www.java-gaming.org/topics/java-sound-api-java-full-screen-exclusive-mode-api-amp-linux/22661/msg/187353/view.html#msg187353 and the linked to bug report, this is meant to be fixed!  I haven't used KDE for a number of years, but on GNOME using gd.setFullScreenWindow(frame); works correctly and sets the required _NET_WM_STATE_FULLSCREEN atom on the window already (this is on Oracle JDK not OpenJDK at the moment, but fairly sure it wasn't a bug there last time I checked).

Best wishes, Neil

Games published by our own members! Go get 'em!
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #10 on: 2011-06-25 07:48:37 »

Hi Julien,

Could I clarify whether you're using FSEM or just trying to set the size of the window - your KDE bug report suggests you've tried both, but the Java bug report only shows the latter?

As per my comment here - http://www.java-gaming.org/topics/java-sound-api-java-full-screen-exclusive-mode-api-amp-linux/22661/msg/187353/view.html#msg187353 and the linked to bug report, this is meant to be fixed!  I haven't used KDE for a number of years, but on GNOME using gd.setFullScreenWindow(frame); works correctly and sets the required _NET_WM_STATE_FULLSCREEN atom on the window already (this is on Oracle JDK not OpenJDK at the moment, but fairly sure it wasn't a bug there last time I checked).

Best wishes, Neil
Hi Neil

I have succeeded in updating the bug report after trying during more than 2 hours. I have tried using both the simulated fullscreen mode and the fullscreen exclusive mode, both work everywhere on Linux except on KDE 4. I tested with Oracle JVM and OpenJDK. The required _NET_WM_STATE_FULLSCREEN is not set anymore if both case but it does not break anything on GNOME. I have not tested with 3D desktop (Kompiz, etc...). I reproduced this bug on Mageia Linux 1 but it can be reproduced on a recent version of KUbuntu. To sum up, Oracle does not respect the EWMH specification, I don't know when they broke that. KDE 4 respects more strictly this specification and it fixed some problems on netbooks. I have almost given all elements to provide a fix in the bug report.

Don't hesitate to ask me some other questions about this bug. I really do my best but if I don't get enough votes, my bug fix won't be integrated.

I have to be more precise. This bug affects only applications relying on the standard API, neither the LWJGL native windowing system, nor NEWT (JOGL 2.0). Is it clear now?

If you want, I can do some more tests on GNOME monday or sunday night. Someone close to me is waiting for something not related with computer science  Kiss Bye.

Julien Gouesse
Offline nsigma

Sr. Member
**

Posts: 342
Medals: 18



« Reply #11 on: 2011-06-25 08:19:16 »

Well, won't expect a reply anytime soon!  Grin

Like I said, this works on GNOME for me so no need to test it.  I'm on 6u24 until I can do a system upgrade next week, so I don't know if anything has changed.  It is following the EWMH spec for me - xprop shows right settings.

However, quick flick through the OpenJDK source suggests this code path might require XRandR.  Do you have it installed?  Found this through Google - https://bugs.mageia.org/show_bug.cgi?id=1680

If not this, then I've no further ideas ...

Neil

Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #12 on: 2011-06-25 12:49:17 »

I have no problem with GNOME, it was broken only several years ago (see Metacity bug). XrandR 2 is installed but not the package allowing to use it in command line.

Edit.: installing this package does not fix the bug.

Julien Gouesse
Offline nsigma

Sr. Member
**

Posts: 342
Medals: 18



« Reply #13 on: 2011-06-25 16:13:15 »

Assuming you're using the same install with GNOME then this seems really strange.  You might try xprop on GNOME - for me this shows the right flags set.  The OpenJDK source file I looked at earlier is openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c - my download of the source is quite old now, but assuming it hasn't changed then you could try getting the trace to print out - might point you in the right direction.

I have my own problems with GNOME and window hints mind you - modal dialogs sometimes cause the main window to disappear from the window list (thank goodness for Alt-TAB) - but that's another story ...  Smiley

Best, N

Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #14 on: 2011-06-27 05:48:18 »

Hi!

Assuming you're using the same install with GNOME then this seems really strange.  
Actually, you're right, I use the same install.

You might try xprop on GNOME - for me this shows the right flags set.  The OpenJDK source file I looked at earlier is openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c - my download of the source is quite old now, but assuming it hasn't changed then you could try getting the trace to print out - might point you in the right direction.
It is an excellent idea Smiley I will do this at home. I'm going to look at the source code.

I have my own problems with GNOME and window hints mind you - modal dialogs sometimes cause the main window to disappear from the window list (thank goodness for Alt-TAB) - but that's another story ...  Smiley
I didn't know this one, thank you for this piece of info.

Edit.: In the source code, in 2007, it worked properly, I looked at this:
http://icedtea.classpath.org/hg/openjdk/file/ce9dde984c21/j2se/src/solaris/native/sun/awt/awt_GraphicsEnv.c in X11GD_SetFullscreenMode.

Edit.: this is the current version:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
static void
X11GD_SetFullscreenMode(Window win, jboolean enabled)
{
    Atom wmState = XInternAtom(awt_display, "_NET_WM_STATE", False);
    Atom wmStateFs = XInternAtom(awt_display,
                                 "_NET_WM_STATE_FULLSCREEN", False);
    Window root, parent, *children = NULL;
    unsigned int numchildren;
    XEvent event;
    Status status;

    if (wmState == None || wmStateFs == None) {
        return;
    }

    /*
     * Note: the Window passed to this method is typically the "content
     * window" of the top-level, but we need the actual shell window for
     * the purposes of constructing the XEvent.  Therefore, we walk up the
     * window hierarchy here to find the true top-level.
     */

    do {
        if (!XQueryTree(awt_display, win,
                        &root, &parent,
                        &children, &numchildren))
        {
            return;
        }

        if (children != NULL) {
            XFree(children);
        }

        if (parent == root) {
            break;
        }

        win = parent;
    } while (root != parent);

    memset(&event, 0, sizeof(event));
    event.xclient.type = ClientMessage;
    event.xclient.message_type = wmState;
    event.xclient.display = awt_display;
    event.xclient.window = win;
    event.xclient.format = 32;
    event.xclient.data.l[0] = enabled ? 1 : 0; // 1==add, 0==remove
   event.xclient.data.l[1] = wmStateFs;

    XSendEvent(awt_display, root, False,
               SubstructureRedirectMask | SubstructureNotifyMask,
               &event);
    XSync(awt_display, False);
}


Edit.: The missing lines in /jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c are:
1  
2  
3  
4  
5  
6  
7  
Atom wmStateAbove = XInternAtom(awt_display, "_NET_WM_STATE_ABOVE", False);
event.xclient.data.l[2] = wmStateAbove;
Atom types[2]={0};
int ntypes=0;
types[ntypes++] = wmStateFs;
types[ntypes++] = wmStateAbove;
XChangeProperty( awt_display, win, wmState, XA_ATOM, 32, PropModeReplace, (unsigned char *)&types, ntypes);

The previous code works on GNOME but not on KDE because KDE accepts fullscreen windows only when they are on top... and GNOME is more laxist.

@nsigma I remember now that a guy from the KDE team asked me to test with GNOME and the properties were not set. Thank you for pointing the good source file.

Julien Gouesse
Offline nsigma

Sr. Member
**

Posts: 342
Medals: 18



« Reply #15 on: 2011-06-27 15:32:42 »

The previous code works on GNOME but not on KDE because KDE accepts fullscreen windows only when they are on top... and GNOME is more laxist.

My reading of the spec would be that KDE is at fault here if that's the case, but I'm no expert on this!!!  Smiley  The spec says that _NET_WM_STATE_ABOVE "should not be used by applications", and the spec and the examples I've seen state that the _NET_WM_STATE_FULLSCREEN should apply to the focused window.

Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #16 on: 2011-06-27 16:51:15 »

I have to speak about that to the KDE team.

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #17 on: 2011-06-29 05:42:21 »

Hi!

@nsigma You were right, on GNOME 2.16.1, the atom is set to the correct fullscreen test. It is then an old KDE bug as I explain there at the bottom of the page:
https://bugs.kde.org/show_bug.cgi?id=276159

My patch will be useless except if the KDE team refuses to fix it.

Julien Gouesse
Offline nsigma

Sr. Member
**

Posts: 342
Medals: 18



« Reply #18 on: 2011-06-29 06:39:56 »

@nsigma You were right, on GNOME 2.16.1, the atom is set to the correct fullscreen test. It is then an old KDE bug as I explain there at the bottom of the page:
https://bugs.kde.org/show_bug.cgi?id=276159
GNOME 2.16?  You should upgrade! Smiley  Confirm same result on 2.28.1

Sometimes people are too quick to blame Java (ie. comment #9 in your KDE bug report) - it ain't always the problem!  persecutioncomplex

Offline ra4king

JGO Kernel
*****

Posts: 3149
Medals: 196


I'm the King!


« Reply #19 on: 2011-06-29 09:47:55 »

A bit offtopic, I tried running your TUER jnlp using "javaws http://tuer.sourceforge.net/tuer.jnlp" on the command line, and Java threw an exception:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1/webstart/jogl.jnlp
  at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
   at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
   at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
   at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
   at com.sun.deploy.net.DownloadEngine.getCachedFile(Unknown Source)
   at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(Unknown Source)
   at com.sun.javaws.LaunchDownload.downloadExtensions(Unknown Source)
   at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
   at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
   at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
   at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
   at com.sun.javaws.Launcher.launch(Unknown Source)
   at com.sun.javaws.Main.launchApp(Unknown Source)
   at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
   at com.sun.javaws.Main$1.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)

Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #20 on: 2011-06-29 09:50:30 »

GNOME 2.16?  You should upgrade! Smiley  Confirm same result on 2.28.1

Sometimes people are too quick to blame Java (ie. comment #9 in your KDE bug report) - it ain't always the problem!  persecutioncomplex
At home, I use KDE SC 4.6 and GNOME 2.28 Wink

When the window is already mapped, we will use the same code and when it isn't, we will call XChangeProperty. If KDE4 only promotes windows on top of its stack, the KDE team will have to fix it.

A bit offtopic, I tried running your TUER jnlp using "javaws http://tuer.sourceforge.net/tuer.jnlp" on the command line, and Java threw an exception:
1  
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1/webstart/jogl.jnlp

Error 503--Service Unavailable

It is not my fault. Thanks for reporting.

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #21 on: 2011-06-29 18:15:44 »

I use GNOME 2.32.1 at home, I have updated the test results here:
https://bugs.kde.org/show_bug.cgi?id=276159

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #22 on: 2011-07-03 09:10:30 »

Hi!

I have succeeded in building OpenJDK 1.6 and 1.7, the fix will be available soon  Grin

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #23 on: 2011-07-11 04:41:18 »

Hi!

I have tried to use the same bug fix than in NEWT but in AWT and unfortunately, it does not work. I will have to investigate a bit deeper to fix this bug.

Julien Gouesse
Offline gouessej

JGO Kernel
*****

Posts: 3558
Medals: 30


TUER


« Reply #24 on: 2011-07-12 19:26:43 »

Hi

The bug seems to have several root causes  Cry

There are some problems of bad use of XSync and the window handles might be obtained by the wrong way. NEWT uses the screen identifier and only a very little bit XQueryTree whereas AWT uses only XQueryTree in a loop to get the root window. Best regards.

Julien Gouesse
Pages: [1]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.201 seconds with 20 queries.