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:
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.
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
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.
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
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
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