diff options
| author | marha <marha@users.sourceforge.net> | 2010-12-28 16:10:20 +0000 |
|---|---|---|
| committer | marha <marha@users.sourceforge.net> | 2010-12-28 16:10:20 +0000 |
| commit | 807c6931fe683fd844ceec1b023232181e6aae03 (patch) | |
| tree | 1a131ed95fe2200d0ad33da8f7755a7ed2364adc /mesalib/docs/egl.html | |
| parent | 973099dda7e49e5abe29819a7124b3b1e7bd8b92 (diff) | |
| download | vcxsrv-807c6931fe683fd844ceec1b023232181e6aae03.tar.gz vcxsrv-807c6931fe683fd844ceec1b023232181e6aae03.tar.bz2 vcxsrv-807c6931fe683fd844ceec1b023232181e6aae03.zip | |
xserver and mesa git update 28-12-2010
Diffstat (limited to 'mesalib/docs/egl.html')
| -rw-r--r-- | mesalib/docs/egl.html | 631 |
1 files changed, 323 insertions, 308 deletions
diff --git a/mesalib/docs/egl.html b/mesalib/docs/egl.html index d38f2dd7b..28ade1567 100644 --- a/mesalib/docs/egl.html +++ b/mesalib/docs/egl.html @@ -1,308 +1,323 @@ -<html> - -<title>Mesa EGL</title> - -<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> - -<body> - -<h1>Mesa EGL</h1> - -<p>The current version of EGL in Mesa implements EGL 1.4. More information -about EGL can be found at -<a href="http://www.khronos.org/egl/" target="_parent"> -http://www.khronos.org/egl/</a>.</p> - -<p>The Mesa's implementation of EGL uses a driver architecture. The main -library (<code>libEGL</code>) is window system neutral. It provides the EGL -API entry points and helper functions for use by the drivers. Drivers are -dynamically loaded by the main library and most of the EGL API calls are -directly dispatched to the drivers.</p> - -<p>The driver in use decides the window system to support. For drivers that -support hardware rendering, there are usually multiple drivers supporting the -same window system. Each one of of them supports a certain range of graphics -cards.</p> - -<h2>Build EGL</h2> - -<ol> -<li> -<p>Run <code>configure</code> with the desired state trackers and enable -the Gallium driver for your hardware. For example</p> - -<pre> - $ ./configure --enable-gles-overlay --with-state-trackers=egl,vega --enable-gallium-intel -</pre> - -<p>The main library and OpenGL is enabled by default. The first option enables -<a href="opengles.html">OpenGL ES 1.x and 2.x</a>. The <code>egl</code> state -tracker is needed by a number of EGL drivers. EGL drivers will be covered -later. The <a href="openvg.html">vega state tracker</a> provides OpenVG -1.x.</p> -</li> - -<li>Build and install Mesa as usual.</li> -</ol> - -<p>In the given example, it will build and install <code>libEGL</code>, -<code>libGL</code>, <code>libGLESv1_CM</code>, <code>libGLESv2</code>, -<code>libOpenVG</code>, and one or more EGL drivers.</p> - -<h3>Configure Options</h3> - -<p>There are several options that control the build of EGL at configuration -time</p> - -<ul> -<li><code>--enable-egl</code> - -<p>By default, EGL is enabled. When disabled, the main library and the drivers -will not be built.</p> - -</li> - -<li><code>--with-egl-driver-dir</code> - -<p>The directory EGL drivers should be installed to. If not specified, EGL -drivers will be installed to <code>${libdir}/egl</code>.</p> - -</li> - -<li><code>--with-egl-platforms</code> - -<p>List the platforms (window systems) to support. Its argument is a comma -seprated string such as <code>--with-egl-platforms=x11,drm</code>. It decides -the platforms a driver may support. The first listed platform is also used by -the main library to decide the native platform: the platform the EGL native -types such as <code>EGLNativeDisplayType</code> or -<code>EGLNativeWindowType</code> defined for.</p> - -<p>The available platforms are <code>x11</code>, <code>drm</code>, -<code>fbdev</code>, and <code>gdi</code>. The <code>gdi</code> platform can -only be built with SCons.</p> - -</li> - -<li><code>--with-state-trackers</code> - -<p>The argument is a comma separated string. It is usually used to specify the -rendering APIs, such as OpenVG, to build. But it is also used to specify -<code>egl</code> state tracker that <code>egl_gallium</code> depends on.</p> - -</li> - -<li><code>--enable-gles-overlay</code> - -<p>OpenGL and OpenGL ES are not controlled by -<code>--with-state-trackers</code>. OpenGL is always built. To build OpenGL -ES, this option must be explicitly given.</p> - -</li> - -<li><code>--enable-gles1</code> and <code>--enable-gles2</code> - -<p>Unlike <code>--enable-gles-overlay</code>, which builds one library for each -rendering API, these options enable OpenGL ES support in OpenGL. The result is -one big library that supports multiple APIs.</p> - -</li> - -</ul> - -<h2>Use EGL</h2> - -<h3>Demos</h3> - -<p>There are demos for the client APIs supported by EGL. They can be found in -mesa/demos repository.</p> - -<h3>Environment Variables</h3> - -<p>There are several environment variables that control the behavior of EGL at -runtime</p> - -<ul> -<li><code>EGL_DRIVERS_PATH</code> - -<p>By default, the main library will look for drivers in the directory where -the drivers are installed to. This variable specifies a list of -colon-separated directories where the main library will look for drivers, in -addition to the default directory. This variable is ignored for setuid/setgid -binaries.</p> - -</li> - -<li><code>EGL_DRIVER</code> - -<p>This variable specifies a full path to an EGL driver and it forces the -specified EGL driver to be loaded. It comes in handy when one wants to test a -specific driver. This variable is ignored for setuid/setgid binaries.</p> - -<p><code>egl_gallium</code> dynamically loads hardware drivers and client API -modules found in <code>EGL_DRIVERS_PATH</code>. Thus, specifying this variable -alone is not sufficient for <code>egl_gallium</code> for uninstalled build.</p> - -</li> - -<li><code>EGL_PLATFORM</code> - -<p>This variable specifies the native platform. The valid values are the same -as those for <code>--with-egl-platforms</code>. When the variable is not set, -the main library uses the first platform listed in -<code>--with-egl-platforms</code> as the native platform</p> - -</li> - -<li><code>EGL_LOG_LEVEL</code> - -<p>This changes the log level of the main library and the drivers. The valid -values are: <code>debug</code>, <code>info</code>, <code>warning</code>, and -<code>fatal</code>.</p> - -</li> - -<li><code>EGL_SOFTWARE</code> - -<p>For drivers that support both hardware and software rendering, setting this -variable to true forces the use of software rendering.</p> - -</li> -</ul> - -<h2>EGL Drivers</h2> - -<ul> -<li><code>egl_gallium</code> - -<p>This driver is based on Gallium3D. It supports all rendering APIs and -hardwares supported by Gallium3D. It is the only driver that supports OpenVG. -The supported platforms are X11, KMS, FBDEV, and GDI.</p> - -</li> - -<li><code>egl_glx</code> - -<p>This driver provides a wrapper to GLX. It uses exclusively GLX to implement -the EGL API. It supports both direct and indirect rendering when the GLX does. -It is accelerated when the GLX is. As such, it cannot provide functions that -is not available in GLX or GLX extensions.</p> -</li> - -<li><code>egl_dri2</code> - -<p>This driver supports the X Window System as its window system. It functions -as a DRI2 driver loader. Unlike <code>egl_glx</code>, it has no dependency on -<code>libGL</code>. It talks to the X server directly using DRI2 protocol.</p> - -</li> -<li><code>egl_dri</code> - -<p>This driver lacks maintenance and does <em>not</em> build. It is similiar -to <code>egl_dri2</code> in that it functions as a DRI(1) driver loader. But -unlike <code>egl_dri2</code>, it supports Linux framebuffer devices as its -window system and supports EGL_MESA_screen_surface extension. As DRI1 drivers -are phasing out, it might eventually be replaced by <code>egl_dri2</code>.</p> - -</li> -</ul> - -<h2>Developers</h2> - -<p>The sources of the main library and the classic drivers can be found at -<code>src/egl/</code>. The sources of the <code>egl</code> state tracker can -be found at <code>src/gallium/state_trackers/egl/</code>.</p> - -<p>The suggested way to learn to write a EGL driver is to see how other drivers -are written. <code>egl_glx</code> should be a good reference. It works in any -environment that has GLX support, and it is simpler than most drivers.</p> - -<h3>Lifetime of Display Resources</h3> - -<p>Contexts and surfaces are examples of display resources. They might live -longer than the display that creates them.</p> - -<p>In EGL, when a display is terminated through <code>eglTerminate</code>, all -display resources should be destroyed. Similarly, when a thread is released -throught <code>eglReleaseThread</code>, all current display resources should be -released. Another way to destory or release resources is through functions -such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p> - -<p>When a resource that is current to some thread is destroyed, the resource -should not be destroyed immediately. EGL requires the resource to live until -it is no longer current. A driver usually calls -<code>eglIs<Resource>Bound</code> to check if a resource is bound -(current) to any thread in the destroy callbacks. If it is still bound, the -resource is not destroyed.</p> - -<p>The main library will mark destroyed current resources as unlinked. In a -driver's <code>MakeCurrent</code> callback, -<code>eglIs<Resource>Linked</code> can then be called to check if a newly -released resource is linked to a display. If it is not, the last reference to -the resource is removed and the driver should destroy the resource. But it -should be careful here because <code>MakeCurrent</code> might be called with an -uninitialized display.</p> - -<p>This is the only mechanism provided by the main library to help manage the -resources. The drivers are responsible to the correct behavior as defined by -EGL.</p> - -<h3><code>EGL_RENDER_BUFFER</code></h3> - -<p>In EGL, the color buffer a context should try to render to is decided by the -binding surface. It should try to render to the front buffer if the binding -surface has <code>EGL_RENDER_BUFFER</code> set to -<code>EGL_SINGLE_BUFFER</code>; If the same context is later bound to a -surface with <code>EGL_RENDER_BUFFER</code> set to -<code>EGL_BACK_BUFFER</code>, the context should try to render to the back -buffer. However, the context is allowed to make the final decision as to which -color buffer it wants to or is able to render to.</p> - -<p>For pbuffer surfaces, the render buffer is always -<code>EGL_BACK_BUFFER</code>. And for pixmap surfaces, the render buffer is -always <code>EGL_SINGLE_BUFFER</code>. Unlike window surfaces, EGL spec -requires their <code>EGL_RENDER_BUFFER</code> values to be honored. As a -result, a driver should never set <code>EGL_PIXMAP_BIT</code> or -<code>EGL_PBUFFER_BIT</code> bits of a config if the contexts created with the -config won't be able to honor the <code>EGL_RENDER_BUFFER</code> of pixmap or -pbuffer surfaces.</p> - -<p>It should also be noted that pixmap and pbuffer surfaces are assumed to be -single-buffered, in that <code>eglSwapBuffers</code> has no effect on them. It -is desirable that a driver allocates a private color buffer for each pbuffer -surface created. If the window system the driver supports has native pbuffers, -or if the native pixmaps have more than one color buffers, the driver should -carefully attach the native color buffers to the EGL surfaces, re-route them if -required.</p> - -<p>There is no defined behavior as to, for example, how -<code>glDrawBuffer</code> interacts with <code>EGL_RENDER_BUFFER</code>. Right -now, it is desired that the draw buffer in a client API be fixed for pixmap and -pbuffer surfaces. Therefore, the driver is responsible to guarantee that the -client API renders to the specified render buffer for pixmap and pbuffer -surfaces.</p> - -<h3><code>EGLDisplay</code> Mutex</h3> - -The <code>EGLDisplay</code> will be locked before calling any of the dispatch -functions (well, except for GetProcAddress which does not take an -<code>EGLDisplay</code>). This guarantees that the same dispatch function will -not be called with the sample display at the same time. If a driver has access -to an <code>EGLDisplay</code> without going through the EGL APIs, the driver -should as well lock the display before using it. - -<h3>TODOs</h3> - -<ul> -<li>Pass the conformance tests</li> -<li>Reference counting in main library?</li> -<li>Mixed use of OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0 is supported. But -which one of <code>libGL.so</code>, <code>libGLESv1_CM.so</code>, and -<code>libGLESv2.so</code> should an application link to? Bad things may happen -when, say, an application is linked to <code>libGLESv2.so</code> and -<code>libcairo</code>, which is linked to <code>libGL.so</code> instead.</li> - -</ul> - -</body> -</html> +<html>
+
+<title>Mesa EGL</title>
+
+<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
+
+<body>
+
+<h1>Mesa EGL</h1>
+
+<p>The current version of EGL in Mesa implements EGL 1.4. More information
+about EGL can be found at
+<a href="http://www.khronos.org/egl/" target="_parent">
+http://www.khronos.org/egl/</a>.</p>
+
+<p>The Mesa's implementation of EGL uses a driver architecture. The main
+library (<code>libEGL</code>) is window system neutral. It provides the EGL
+API entry points and helper functions for use by the drivers. Drivers are
+dynamically loaded by the main library and most of the EGL API calls are
+directly dispatched to the drivers.</p>
+
+<p>The driver in use decides the window system to support.</p>
+
+<h2>Build EGL</h2>
+
+<ol>
+<li>
+<p>Run <code>configure</code> with the desired client APIs and enable
+the driver for your hardware. For example</p>
+
+<pre>
+ $ ./configure --enable-gles2 --enable-openvg --enable-gallium-nouveau
+</pre>
+
+<p>The main library and OpenGL is enabled by default. The first option above
+enables <a href="opengles.html">OpenGL ES 2.x</a>. The second option enables
+<a href="openvg.html">OpenVG</a>.</p>
+
+</li>
+
+<li>Build and install Mesa as usual.</li>
+</ol>
+
+<p>In the given example, it will build and install <code>libEGL</code>,
+<code>libGL</code>, <code>libGLESv1_CM</code>, <code>libGLESv2</code>,
+<code>libOpenVG</code>, and one or more EGL drivers.</p>
+
+<h3>Configure Options</h3>
+
+<p>There are several options that control the build of EGL at configuration
+time</p>
+
+<ul>
+<li><code>--enable-egl</code>
+
+<p>By default, EGL is enabled. When disabled, the main library and the drivers
+will not be built.</p>
+
+</li>
+
+<li><code>--with-egl-driver-dir</code>
+
+<p>The directory EGL drivers should be installed to. If not specified, EGL
+drivers will be installed to <code>${libdir}/egl</code>.</p>
+
+</li>
+
+<li><code>--with-egl-platforms</code>
+
+<p>List the platforms (window systems) to support. Its argument is a comma
+seprated string such as <code>--with-egl-platforms=x11,drm</code>. It decides
+the platforms a driver may support. The first listed platform is also used by
+the main library to decide the native platform: the platform the EGL native
+types such as <code>EGLNativeDisplayType</code> or
+<code>EGLNativeWindowType</code> defined for.</p>
+
+<p>The available platforms are <code>x11</code>, <code>drm</code>,
+<code>fbdev</code>, and <code>gdi</code>. The <code>gdi</code> platform can
+only be built with SCons. Unless for special needs, the build system should
+select the right platforms automatically.</p>
+
+</li>
+
+<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
+
+<p>These options enable OpenGL ES support in OpenGL. The result is one big
+internal library that supports multiple APIs.</p>
+
+</li>
+
+<li><code>--enable-gles-overlay</code>
+
+<p>This option enables OpenGL ES as separate internal libraries. This is an
+alternative approach to enable OpenGL ES.</p>
+
+<p>This is only supported by <code>egl_gallium</code>. For systems using DRI
+drivers, <code>--enable-gles1</code> and <code>--enable-gles2</code> are
+suggested instead as all drivers will benefit.</p>
+
+</li>
+
+<li><code>--enable-openvg</code>
+
+<p>OpenVG must be explicitly enabled by this option.</p>
+
+</li>
+
+<li><code>--enable-gallium-egl</code>
+
+<p>Explicitly enable or disable <code>egl_gallium</code>.</p>
+
+</li>
+
+</ul>
+
+<h2>Use EGL</h2>
+
+<h3>Demos</h3>
+
+<p>There are demos for the client APIs supported by EGL. They can be found in
+mesa/demos repository.</p>
+
+<h3>Environment Variables</h3>
+
+<p>There are several environment variables that control the behavior of EGL at
+runtime</p>
+
+<ul>
+<li><code>EGL_DRIVERS_PATH</code>
+
+<p>By default, the main library will look for drivers in the directory where
+the drivers are installed to. This variable specifies a list of
+colon-separated directories where the main library will look for drivers, in
+addition to the default directory. This variable is ignored for setuid/setgid
+binaries.</p>
+
+</li>
+
+<li><code>EGL_DRIVER</code>
+
+<p>This variable specifies a full path to an EGL driver and it forces the
+specified EGL driver to be loaded. It comes in handy when one wants to test a
+specific driver. This variable is ignored for setuid/setgid binaries.</p>
+
+</li>
+
+<li><code>EGL_PLATFORM</code>
+
+<p>This variable specifies the native platform. The valid values are the same
+as those for <code>--with-egl-platforms</code>. When the variable is not set,
+the main library uses the first platform listed in
+<code>--with-egl-platforms</code> as the native platform.</p>
+
+<p>Extensions like <code>EGL_MESA_drm_display</code> define new functions to
+create displays for non-native platforms. These extensions are usually used by
+applications that support non-native platforms. Setting this variable is
+probably required only for some of the demos found in mesa/demo repository.</p>
+
+</li>
+
+<li><code>EGL_LOG_LEVEL</code>
+
+<p>This changes the log level of the main library and the drivers. The valid
+values are: <code>debug</code>, <code>info</code>, <code>warning</code>, and
+<code>fatal</code>.</p>
+
+</li>
+
+<li><code>EGL_SOFTWARE</code>
+
+<p>For drivers that support both hardware and software rendering, setting this
+variable to true forces the use of software rendering.</p>
+
+</li>
+</ul>
+
+<h2>EGL Drivers</h2>
+
+<ul>
+<li><code>egl_dri2</code>
+
+<p>This driver supports both <code>x11</code> and <code>drm</code> platforms.
+It functions as a DRI driver loader. For <code>x11</code> support, it talks to
+the X server directly using (XCB-)DRI2 protocol.</p>
+
+<p>This driver can share DRI drivers with <code>libGL</code>.</p>
+
+</li>
+
+<li><code>egl_gallium</code>
+
+<p>This driver is based on Gallium3D. It supports all rendering APIs and
+hardwares supported by Gallium3D. It is the only driver that supports OpenVG.
+The supported platforms are X11, DRM, FBDEV, and GDI.</p>
+
+<p>This driver comes with its own hardware drivers
+(<code>pipe_<hw></code>) and client API modules
+(<code>st_<api></code>).</p>
+
+</li>
+
+<li><code>egl_glx</code>
+
+<p>This driver provides a wrapper to GLX. It uses exclusively GLX to implement
+the EGL API. It supports both direct and indirect rendering when the GLX does.
+It is accelerated when the GLX is. As such, it cannot provide functions that
+is not available in GLX or GLX extensions.</p>
+</li>
+</ul>
+
+<h2>Packaging</h2>
+
+<p>The ABI between the main library and its drivers are not stable. Nor is
+there a plan to stabilize it at the moment. Of the EGL drivers,
+<code>egl_gallium</code> has its own hardware drivers and client API modules.
+They are considered internal to <code>egl_gallium</code> and there is also no
+stable ABI between them. These should be kept in mind when packaging for
+distribution.</p>
+
+<p>Generally, <code>egl_dri2</code> is preferred over <code>egl_gallium</code>
+when the system already has DRI drivers. As <code>egl_gallium</code> is loaded
+before <code>egl_dri2</code> when both are available, <code>egl_gallium</code>
+may either be disabled with <code>--disable-gallium-egl</code> or packaged
+separately.</p>
+
+<h2>Developers</h2>
+
+<p>The sources of the main library and the classic drivers can be found at
+<code>src/egl/</code>. The sources of the <code>egl</code> state tracker can
+be found at <code>src/gallium/state_trackers/egl/</code>.</p>
+
+<p>The suggested way to learn to write a EGL driver is to see how other drivers
+are written. <code>egl_glx</code> should be a good reference. It works in any
+environment that has GLX support, and it is simpler than most drivers.</p>
+
+<h3>Lifetime of Display Resources</h3>
+
+<p>Contexts and surfaces are examples of display resources. They might live
+longer than the display that creates them.</p>
+
+<p>In EGL, when a display is terminated through <code>eglTerminate</code>, all
+display resources should be destroyed. Similarly, when a thread is released
+throught <code>eglReleaseThread</code>, all current display resources should be
+released. Another way to destory or release resources is through functions
+such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p>
+
+<p>When a resource that is current to some thread is destroyed, the resource
+should not be destroyed immediately. EGL requires the resource to live until
+it is no longer current. A driver usually calls
+<code>eglIs<Resource>Bound</code> to check if a resource is bound
+(current) to any thread in the destroy callbacks. If it is still bound, the
+resource is not destroyed.</p>
+
+<p>The main library will mark destroyed current resources as unlinked. In a
+driver's <code>MakeCurrent</code> callback,
+<code>eglIs<Resource>Linked</code> can then be called to check if a newly
+released resource is linked to a display. If it is not, the last reference to
+the resource is removed and the driver should destroy the resource. But it
+should be careful here because <code>MakeCurrent</code> might be called with an
+uninitialized display.</p>
+
+<p>This is the only mechanism provided by the main library to help manage the
+resources. The drivers are responsible to the correct behavior as defined by
+EGL.</p>
+
+<h3><code>EGL_RENDER_BUFFER</code></h3>
+
+<p>In EGL, the color buffer a context should try to render to is decided by the
+binding surface. It should try to render to the front buffer if the binding
+surface has <code>EGL_RENDER_BUFFER</code> set to
+<code>EGL_SINGLE_BUFFER</code>; If the same context is later bound to a
+surface with <code>EGL_RENDER_BUFFER</code> set to
+<code>EGL_BACK_BUFFER</code>, the context should try to render to the back
+buffer. However, the context is allowed to make the final decision as to which
+color buffer it wants to or is able to render to.</p>
+
+<p>For pbuffer surfaces, the render buffer is always
+<code>EGL_BACK_BUFFER</code>. And for pixmap surfaces, the render buffer is
+always <code>EGL_SINGLE_BUFFER</code>. Unlike window surfaces, EGL spec
+requires their <code>EGL_RENDER_BUFFER</code> values to be honored. As a
+result, a driver should never set <code>EGL_PIXMAP_BIT</code> or
+<code>EGL_PBUFFER_BIT</code> bits of a config if the contexts created with the
+config won't be able to honor the <code>EGL_RENDER_BUFFER</code> of pixmap or
+pbuffer surfaces.</p>
+
+<p>It should also be noted that pixmap and pbuffer surfaces are assumed to be
+single-buffered, in that <code>eglSwapBuffers</code> has no effect on them. It
+is desirable that a driver allocates a private color buffer for each pbuffer
+surface created. If the window system the driver supports has native pbuffers,
+or if the native pixmaps have more than one color buffers, the driver should
+carefully attach the native color buffers to the EGL surfaces, re-route them if
+required.</p>
+
+<p>There is no defined behavior as to, for example, how
+<code>glDrawBuffer</code> interacts with <code>EGL_RENDER_BUFFER</code>. Right
+now, it is desired that the draw buffer in a client API be fixed for pixmap and
+pbuffer surfaces. Therefore, the driver is responsible to guarantee that the
+client API renders to the specified render buffer for pixmap and pbuffer
+surfaces.</p>
+
+<h3><code>EGLDisplay</code> Mutex</h3>
+
+The <code>EGLDisplay</code> will be locked before calling any of the dispatch
+functions (well, except for GetProcAddress which does not take an
+<code>EGLDisplay</code>). This guarantees that the same dispatch function will
+not be called with the sample display at the same time. If a driver has access
+to an <code>EGLDisplay</code> without going through the EGL APIs, the driver
+should as well lock the display before using it.
+
+<h3>TODOs</h3>
+
+<ul>
+<li>Pass the conformance tests</li>
+<li>Mixed use of OpenGL, OpenGL ES 1.1, and OpenGL ES 2.0 is supported. But
+which one of <code>libGL.so</code>, <code>libGLESv1_CM.so</code>, and
+<code>libGLESv2.so</code> should an application link to? Bad things may happen
+when, say, an application is linked to <code>libGLESv2.so</code> and
+<code>libcairo</code>, which is linked to <code>libGL.so</code> instead.</li>
+
+</ul>
+
+</body>
+</html>
|