openharmony/third_party_mesa3d
1
0
Fork 0
mirror of https://gitee.com/openharmony/third_party_mesa3d synced 2024-11-26 17:12:07 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: Remove no-longer-accurate text about the xlib driver

Browse Source 
Mesa hasn't supported color-index rendering in a long time, and
gallium's xlib target doesn't respect MESA_GAMMA.

Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14125>
This commit is contained in:
Adam Jackson 2021-12-08 10:12:11 -05:00
parent c5d731ac5c
commit 231ccb6100
2 changed files with 4 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/envvars.rst
View File

@ -224,12 +224,8 @@ the :doc:`Xlib software driver page <xlibdriver>` for details.
:envvar:`MESA_BACK_BUFFER`
specifies how to implement the back color buffer, either ``pixmap``
or ``ximage``
:envvar:`MESA_GAMMA`
gamma correction coefficients for red, green, blue channels
:envvar:`MESA_XSYNC`
enable synchronous X behavior (for debugging only)
:envvar:`MESA_GLX_FORCE_CI`
if set, force GLX to treat 8 BPP visuals as CI visuals
:envvar:`MESA_GLX_FORCE_ALPHA`
if set, forces RGB windows to have an alpha channel.
:envvar:`MESA_GLX_DEPTH_BITS`

47
docs/xlibdriver.rst
View File

@ -18,7 +18,8 @@ The unique features of the Xlib driver follows.
X Visual Selection
------------------
Mesa supports RGB(A) rendering into almost any X visual type and depth.
Mesa supports RGB(A) rendering into TrueColor and DirectColor visuals, for
any depth with a corresponding renderable OpenGL texture format.
The glXChooseVisual function tries to choose the best X visual for the
given attribute list. However, if this doesn't suit your needs you can
@ -36,11 +37,11 @@ Here are some examples:
using csh:
% setenv MESA_RGB_VISUAL "TrueColor 8" // 8-bit TrueColor
% setenv MESA_RGB_VISUAL "PseudoColor 8" // 8-bit PseudoColor
% setenv MESA_RGB_VISUAL "DirectColor 30" // 30-bit DirectColor
using bash:
$ export MESA_RGB_VISUAL="TrueColor 8"
$ export MESA_RGB_VISUAL="PseudoColor 8"
$ export MESA_RGB_VISUAL="DirectColor 30"
Double Buffering
----------------
@ -77,46 +78,6 @@ When sharing the root colormap, Mesa may be unable to allocate the
colors it needs, resulting in poor color quality. This can happen when a
large number of colorcells in the root colormap are already allocated.
Gamma Correction
----------------
To compensate for the nonlinear relationship between pixel values and
displayed intensities, there is a gamma correction feature in Mesa. Some
systems, such as Silicon Graphics, support gamma correction in hardware
(man gamma) so you won't need to use Mesa's gamma facility. Other
systems, however, may need gamma adjustment to produce images which look
correct. If you believe that Mesa's images are too dim, read on.
Gamma correction is controlled with the **MESA_GAMMA** environment
variable. Its value is of the form **Gr Gg Gb** or just **G** where Gr
is the red gamma value, Gg is the green gamma value, Gb is the blue
gamma value and G is one gamma value to use for all three channels. Each
value is a positive real number typically in the range 1.0 to 2.5. The
defaults are all 1.0, effectively disabling gamma correction. Examples:
.. code-block:: console
% export MESA_GAMMA="2.3 2.2 2.4" # separate R,G,B values
% export MESA_GAMMA="2.0" # same gamma for R,G,B
The ``demos/gamma.c`` program in mesa/demos repository may help you to
determine reasonable gamma value for your display. With correct gamma
values, the color intensities displayed in the top row (drawn by
dithering) should nearly match those in the bottom row (drawn as grays).
Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well on
HP displays using the HP-ColorRecovery technology.
Mesa implements gamma correction with a lookup table which translates a
"linear" pixel value to a gamma-corrected pixel value. There is a small
performance penalty. Gamma correction only works in RGB mode. Also be
aware that pixel values read back from the frame buffer will not be
"un-corrected" so glReadPixels may not return the same data drawn with
glDrawPixels.
For more information about gamma correction, see the `Wikipedia
article <https://en.wikipedia.org/wiki/Gamma_correction>`__
Overlay Planes
--------------