Xgl Troubleshooting

From openSUSE

Revision as of 06:50, 27 March 2006

Xgl is highly experimental code, it has been tested on only a few hardware platforms, and depending on driver state it may even crash your computer. This code is not for the faint of heart. Said that, it works remarkably well on several platforms.

For more information about Xgl in general, please read the Xgl overview. For information how to use Xgl on openSUSE Linux, please read the Xgl on SUSE advisory.

Visit #Xgl at irc.freenode.org for more support.

Common configuration errors

• Xgl does not need the Composite extension enabled in xorg.conf - in fact this is counter-productive, as e.g. the NVIDIA driver disables OpenGL by default when Composite is enabled. The Composite extension is provided by Xgl itself, without the need to configure anything.
  If you get an error about missing Composite extension when starting compiz, you probably tried to start it on the base Xorg server (which shouldn't be used for any program any more except for starting Xgl itself) and not on the Xgl server. Set your DISPLAY variable accordingly.

Software issues

• A bug in SDL causes SDL applications to be transparent.
  Insert into the commandline 'export XLIB_SKIP_ARGB_VISUALS=1' before launching the SDL app to remove the transparency. This is a temporary fix.

General hardware dependent issues

• XVideo will be very slow if hardware acceleration (pixel shaders) is not available. If using a composite manager, it will only be fast if FBOs or pBuffers are available and activated.
• Programms using unaccelerated OpenGL (that is, the graphics hardware does neither support pBuffers or FBOs, or Xgl has been started without -accel glx) may display incorrectly or even crash Xgl. This is fixed in CVS and upcoming openSUSE packages.
• With some drivers screen refreshs do not work properly.
  The screen only seems to be refreshed when explicitely requested, e.g. by calling xrefresh or by sending expose events to Xgl by obscuring the Xgl(!) window with another window. This seems to be a bug in the drivers, which is currently been investigated. Upcoming openSUSE packages will have a workaround for this bug.

ATI / open source driver "radeon"

• Driver does not accelerate blits from back buffer to front buffer which makes it very slow, and screen updates may flicker. The driver will soon be updated and should then work OK.
• Driver has neither pBuffer nor FBO support. When using a composite manager all windows are rendered in software and only compositing is hardware accelerated. Astonishingly, this works well enough for most use cases.

ATI / proprietary driver "fglrx"

• Starting Xgl by default with DISPLAYMANAGER_XSERVER will not work with current drivers including 8.23.7, because 'DISPLAY=:93 Xgl :0' wrongly tries to XOpenDisplay (:0.0) due to a xglQueryVersion, and as the Xgl's server port is already open, the connection does not immediately fail. This is a deadlock. ATI has been investigating, a fix is pending (see openSUSE bugzilla entry #129999).
  If you are using gdm, the problem can be worked around by changing the line 0=Standard to 1=Standard in /etc/opt/gnome/gdm/gdm.conf. You can also start Xgl manually by yourself. Log into the system with a trivial window manager (e.g. twm), open an xterm, and start Xgl -fullscreen :1 & sleep 2 && DISPLAY=:1 kde
  Substitute kde by gnome or fvwm2 or your other favorite desktop you would like to start.
• SL10.1 Beta8 configures Xorg with Option "EnablePrivateBackZ" "yes" - for which Xgl fails with the latest drivers (8.23.7). Please set this option to "no". There is no known drawback from disabling this option.
• When no composite manager (e.g. compiz) is running, the driver can be pretty slow. Do not use Xgl without a composite manager.
• To get Xgl working on SLED Beta8 and ati/fglrx follow these instructions readme.beta8

Intel / open source driver "i810"

• Driver does not accelerate blits from back buffer to front buffer which makes it very slow, and screen updates may flicker. The driver will soon be updated and should then work OK.
• Driver has neither pBuffer nor FBO support. When using a composite manager all windows are rendered in software and only compositing is hardware accelerated. Astonishingly, this works well enough for most use cases. FBO support is supposed to be added to the driver in the near future.
• XVideo YV12 surfaces are hardware accelerated (when no composite manager is used), but due to a bug in the driver the video will miss one of the color channels, leading to false greenish/purple colors. This has to be investigated.

NVIDIA / open source driver "nv"

• Does not support 3D acceleration at all. Xgl will not work well with software emulation, refrain from using this combination.

NVIDIA / proprietary driver "nvidia"

• OpenGL acceleration does not work well with Composite being active. This option in /etc/X11/xorg.conf should be disabled if it had been enabled before. Note: Xgl supports Composite anyway, even if it is disabled in xorg.conf. FBO's can be used with this driver instead of pbuffers for XVideo acceleration. Enable this by changing
  DISPLAYMANAGER_XGL_OPTS="-accel glx:pbuffer -accel xv:pbuffer" to
  DISPLAYMANAGER_XGL_OPTS="-accel glx:pbuffer -accel xv:fbo" in /etc/sysconfig/displaymanager.
• The NVIDIA driver installer typically removes all libglx.so in /usr/X11R6, including /usr/X11R6/lib/xorg/modules/xgl/libglx.so -- which is part of the xgl package. Thus you currently have to reinstall xgl after installing the NVIDIA driver.

Glossary

Composite Extension

This extension to X causes an entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers.

FBO

Frame Buffer Object (FBO) is an OpenGL extension that defines a simple interface for drawing to rendering destinations other than the buffers provided to the GL by the window system. This interface is newer and cleaner than pBuffers, but considered less stable at the moment.

pBuffer

Pixel buffers (pBuffers for short) are additional non-visible rendering buffers for an OpenGL renderer.