JDK-4661156 : Full screen exclusive mode and display change are not supported under Linux
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_2.5.1
  • CPU: x86
  • Submitted: 2002-04-02
  • Updated: 2017-05-16
  • Resolved: 2005-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 6
6 betaFixed
Related Reports
Duplicate :  
Relates :  
Description

Name: gm110360			Date: 04/01/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


FULL OPERATING SYSTEM VERSION :
Linux 2.4.18
glibc-2.2.4-13
Red Hat Linux release 7.2 (Enigma)

EXTRA RELEVANT SYSTEM CONFIGURATION :
KDE 2.2
XFree86 4.1.0
ATI Rage LT Pro video card (8M VRAM, using 'Mach64' driver)


A DESCRIPTION OF THE PROBLEM :
Full screen exclusive mode and display change don't work in
Linux. The attached program, using to GraphicsDevice methods
isDisplayChangeSupported() and isFullScreenSupported(),
reports that neither is supported.

Display change isn't supported by the JDK, in spite of the
fact that I have four video modes set up in X, which I can
switch any time by pressing Ctrl-Alt-KeypadMinus/KeypadPlus.
GraphicsDevice reports one GraphicsConfiguration, for the
current mode only. But it does get that right, it correctly
reports what mode I am in.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Execute the attached code. See that fullscreen exclusive
mode and display change are not supported.

EXPECTED VERSUS ACTUAL BEHAVIOR :
When I run the example program attached, I get this output:

Device 0: ID string=:0.0
  Available accelerated memory: -1
  Fullscreen supported: false
  Display change supported: false

The expected output would indicate that fullscreen and
display change are supported (=true).


This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;

public class FSETest {
    public static void main(String[] args) {
        GraphicsDevice[] devices =
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
        for (int i = 0; i < devices.length; i++) {
            GraphicsDevice device = devices[i];
            System.out.println("Device " + i + ": ID string=" +
device.getIDstring());
            System.out.println("  Available accelerated memory: " +
device.getAvailableAcceleratedMemory());
            System.out.println("  Fullscreen supported: " +
device.isFullScreenSupported());
            System.out.println("  Display change supported: " +
device.isDisplayChangeSupported());
            System.out.println();
        }
    }
}

---------- END SOURCE ----------
(Review ID: 143928) 
======================================================================

Comments
EVALUATION The implementation for this feature would most likely require use of DGA2.0, which is implemented in XFree86 4.x. Basically, it has almost all functionality we need: ftp://ftp.xfree86.org/pub/XFree86/4.2.1/doc/README.DGA One of the caveats is: " XDGAOpenFramebuffer() maps the framebuffer memory. The client needs sufficient privledges to be able to do this." So it looks like, unfortunately, it still requires priveleged access to run to use direct access, and the drivers support is rather limited. Another possibility is to use VidMode extension. ###@###.### 2002-10-03 We will be using the VidMode extension, as that is the accepted approach to doing display mode switching on X11 (used by games such as Quake and many media playing apps). This mechanism will work equally well with both the X11 and OGL-based pipelines. The VidMode extension is only responsible for querying and switching between display modes. The only display modes available to the application are those listed in the XF86Config file (or xorg.conf, in the case of Xorg). We have to employ a few tricks in order to make it appear as if the fullscreen window is in "fullscreen exclusive mode", as there is no such concept on X11, even with the VidMode extension. The biggest problem is that XFree86 automatically pans the desktop if you switch to a display mode that is larger than the "viewport" setting in the XF86Config file. So if we simply created a window the size of the new display mode, if one moves the mouse cursor to the edges of that window, the desktop would pan to reveal the rest of the virtual desktop. There is no way to disable this behavior in XFree86, so we have no choice but to workaround it. One way is to do an XGrabPointer and XGrabKeyboard so that all mouse and keyboard events are confined to the active fullscreen window. This approach makes it difficult to trigger the auto-panning behavior and actually works fairly well. This is the same approach used in other fullscreen applications on Linux, such as Quake. There are a few restrictions for using the fullscreen and display mode APIs on Linux. It will only be available if: - the VidMode extension is available - the VidMode function symbols can be dynamically loaded (*) - Xinerama is not enabled (there are potentially bad interactions between these two extensions) - you are on the primary screen (in a multiscreen environment) The last two restrictions are there to prevent any major problems in multiscreen configurations. It's too difficult and error-prone to support these configurations at this time, which shouldn't be much of an issue since multiscreen Linux configs are relatively rare. (*) XFree86 only ships with .a (static) version of the libXxf86vm library, but we attempt to dlopen the .so (shared) version of that library. This shouldn't be a problem by the time Mustang ships since most people should be using the Xorg server by that point, and the Xorg server includes the .so library. But for legacy configurations, there is a workaround to create a .so from the .a: % cd /usr/X11R6/lib % ld --whole-archive -shared -o libXxf86vm.so.1 libXxf86vm.a % ln -s libXxf86vm.so.1 libXxf86vm.so % /sbin/ldconfig So we just need to document that issue in the release notes... It's not pretty, but it's better than having a build time dependency on Linux only, and it will allow this stuff to work on Solaris (x86 and sparc) once the Xorg server is included on those platforms. ###@###.### 2004-08-26 While investigating this RFE, a couple issues have surfaced that should be addressed in the Mustang timeframe (outside the scope of this RFE, but important to have fixed): 4941351: OGL: detect pbuffer clobber events This is important because pbuffer clobber events are more likely to occur now that it is possible for an app to change the display mode (which tends to invalidate VRAM resources). The current display mode switching implementation is prepared to restore managed images and VolatileImages in the event of a display change initiated by the current JVM process. However, a fix for 4941351 is necessary for the OGL pipeline to restore pbuffer-based surfaces in the event of a display change initiated by another process (or the operating system). 5094347: clarify GraphicsDevice.setDisplayMode() spec regarding BIT_DEPTH_MULTI This is important because existing fullscreen apps might be making some bad assumptions about the meaning of BIT_DEPTH_MULTI (which is used on Linux/Solaris), and we should update the spec/implementation to account for those issues. ###@###.### 2004-08-30 Just a quick update on the progress of this RFE... While the code has been ready for a couple months, there was a prolonged internal review that caused a delay in its integration into Mustang. Now that the review has been completed, I'll sync up the code with the latest Mustang sources and do some final testing. That way we can get this into an upcoming Mustang snapshot and get some feedback from developers. ###@###.### 2004-12-21 23:30:14 GMT The fix has finally been putback to the 2D workspace and should appear soon in Mustang b39 (if all goes well). ###@###.### 2005-05-18 22:53:02 GMT
2004-12-21

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
2004-10-02