United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4661156 : Full screen exclusive mode and display change are not supported under Linux

Details
Type:
Enhancement
Submit Date:
2002-04-02
Status:
Resolved
Updated Date:
2005-05-31
Project Name:
JDK
Resolved Date:
2005-05-31
Component:
client-libs
OS:
solaris_2.5.1,linux
Sub-Component:
2d
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Relates:

Sub Tasks

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
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-10-02
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



Hardware and Software, Engineered to Work Together