Mesa (master): docs: remove leading spaces
GitLab Mirror
gitlab-mirror at kemper.freedesktop.org
Sat Jan 18 10:43:39 UTC 2020
Module: Mesa
Branch: master
Commit: 9954120b38e5dcff54bb73b0f0a56f158e050f35
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9954120b38e5dcff54bb73b0f0a56f158e050f35
Author: Erik Faye-Lund <erik.faye-lund at collabora.com>
Date: Thu Jan 16 20:18:07 2020 +0100
docs: remove leading spaces
There's no good reason to have leading space in these pre-formatted
blocks. It looks strange, so let's get rid of it.
Reviewed-by: Eric Engestrom <eric at engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3443>
---
docs/codingstyle.html | 80 +++++++++++++-------------
docs/llvmpipe.html | 28 ++++-----
docs/meson.html | 24 ++++----
docs/releasing.html | 136 ++++++++++++++++++++++----------------------
docs/repository.html | 20 +++----
docs/shading.html | 4 +-
docs/submittingpatches.html | 74 ++++++++++++------------
docs/vmware-guest.html | 84 +++++++++++++--------------
docs/xlibdriver.html | 32 +++++------
9 files changed, 241 insertions(+), 241 deletions(-)
diff --git a/docs/codingstyle.html b/docs/codingstyle.html
index 686d6a3ddf4..4e47769cbf3 100644
--- a/docs/codingstyle.html
+++ b/docs/codingstyle.html
@@ -41,11 +41,11 @@ as if you're defining a large, static table of information.
<li>Opening braces go on the same line as the if/for/while statement.
For example:
<pre>
- if (condition) {
- foo;
- } else {
- bar;
- }
+if (condition) {
+ foo;
+} else {
+ bar;
+}
</pre>
<li>Put a space before/after operators. For example, <code>a = b + c;</code>
@@ -53,7 +53,7 @@ and not <code>a=b+c;</code>
<li>This GNU indent command generally does the right thing for formatting:
<pre>
- indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
+indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
</pre>
<li>
@@ -63,47 +63,47 @@ follow <a href="http://www.doxygen.nl">Doxygen</a> conventions.
</p>
Single-line comments:
<pre>
- /* null-out pointer to prevent dangling reference below */
- bufferObj = NULL;
+/* null-out pointer to prevent dangling reference below */
+bufferObj = NULL;
</pre>
Or,
<pre>
- bufferObj = NULL; /* prevent dangling reference below */
+bufferObj = NULL; /* prevent dangling reference below */
</pre>
Multi-line comment:
<pre>
- /* If this is a new buffer object id, or one which was generated but
- * never used before, allocate a buffer object now.
- */
+/* If this is a new buffer object id, or one which was generated but
+ * never used before, allocate a buffer object now.
+ */
</pre>
We try to quote the OpenGL specification where prudent:
<pre>
- /* Page 38 of the PDF of the OpenGL ES 3.0 spec says:
- *
- * "An INVALID_OPERATION error is generated for any of the following
- * conditions:
- *
- * * <length> is zero."
- *
- * Additionally, page 94 of the PDF of the OpenGL 4.5 core spec
- * (30.10.2014) also says this, so it's no longer allowed for desktop GL,
- * either.
- */
+/* Page 38 of the PDF of the OpenGL ES 3.0 spec says:
+ *
+ * "An INVALID_OPERATION error is generated for any of the following
+ * conditions:
+ *
+ * * <length> is zero."
+ *
+ * Additionally, page 94 of the PDF of the OpenGL 4.5 core spec
+ * (30.10.2014) also says this, so it's no longer allowed for desktop GL,
+ * either.
+ */
</pre>
Function comment example:
<pre>
- /**
- * Create and initialize a new buffer object. Called via the
- * ctx->Driver.CreateObject() driver callback function.
- * \param name integer name of the object
- * \param type one of GL_FOO, GL_BAR, etc.
- * \return pointer to new object or NULL if error
- */
- struct gl_object *
- _mesa_create_object(GLuint name, GLenum type)
- {
- /* function body */
- }
+/**
+ * Create and initialize a new buffer object. Called via the
+ * ctx->Driver.CreateObject() driver callback function.
+ * \param name integer name of the object
+ * \param type one of GL_FOO, GL_BAR, etc.
+ * \return pointer to new object or NULL if error
+ */
+struct gl_object *
+_mesa_create_object(GLuint name, GLenum type)
+{
+ /* function body */
+}
</pre>
<li>Put the function return type and qualifiers on one line and the function
@@ -113,11 +113,11 @@ the opening brace goes on the next line by itself (see above.)
<li>Function names follow various conventions depending on the type of function:
<pre>
- glFooBar() - a public GL entry point (in glapi_dispatch.c)
- _mesa_FooBar() - the internal immediate mode function
- save_FooBar() - retained mode (display list) function in dlist.c
- foo_bar() - a static (private) function
- _mesa_foo_bar() - an internal non-static Mesa function
+glFooBar() - a public GL entry point (in glapi_dispatch.c)
+_mesa_FooBar() - the internal immediate mode function
+save_FooBar() - retained mode (display list) function in dlist.c
+foo_bar() - a static (private) function
+_mesa_foo_bar() - an internal non-static Mesa function
</pre>
<li>Constants, macros and enum names are <code>ALL_UPPERCASE</code>, with _
diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index c7d0dd4652a..9f5bd0be445 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -56,7 +56,7 @@ It's the fastest software rasterizer for Mesa.
For Linux, on a recent Debian based distribution do:
</p>
<pre>
- aptitude install llvm-dev
+aptitude install llvm-dev
</pre>
<p>
If you want development snapshot builds of LLVM for Debian and derived
@@ -68,7 +68,7 @@ It's the fastest software rasterizer for Mesa.
For a RPM-based distribution do:
</p>
<pre>
- yum install llvm-devel
+yum install llvm-devel
</pre>
<p>
@@ -120,15 +120,15 @@ It's the fastest software rasterizer for Mesa.
To build everything on Linux invoke scons as:
<pre>
- scons build=debug libgl-xlib
+scons build=debug libgl-xlib
</pre>
Alternatively, you can build it with meson with:
<pre>
- mkdir build
- cd build
- meson -D glx=gallium-xlib -D gallium-drivers=swrast
- ninja
+mkdir build
+cd build
+meson -D glx=gallium-xlib -D gallium-drivers=swrast
+ninja
</pre>
but the rest of these instructions assume that scons is used.
@@ -136,7 +136,7 @@ but the rest of these instructions assume that scons is used.
For Windows the procedure is similar except the target:
<pre>
- scons platform=windows build=debug libgl-gdi
+scons platform=windows build=debug libgl-gdi
</pre>
@@ -148,11 +148,11 @@ For Windows the procedure is similar except the target:
<code>libGL.so</code> into</p>
<pre>
- build/foo/gallium/targets/libgl-xlib/libGL.so
+build/foo/gallium/targets/libgl-xlib/libGL.so
</pre>
or
<pre>
- lib/gallium/libGL.so
+lib/gallium/libGL.so
</pre>
<p>To use it set the <code>LD_LIBRARY_PATH</code> environment variable
@@ -206,7 +206,7 @@ any OpenGL drivers):
To profile llvmpipe you should build as
</p>
<pre>
- scons build=profile <same-as-before>
+scons build=profile <same-as-before>
</pre>
<p>
@@ -221,8 +221,8 @@ On Linux, it is possible to have symbol resolution of JIT code with <a href="htt
</p>
<pre>
- perf record -g /my/application
- perf report
+perf record -g /my/application
+perf report
</pre>
<p>
@@ -255,7 +255,7 @@ Some of these tests can output results and benchmarks to a tab-separated file
for later analysis, e.g.:
</p>
<pre>
- build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
+build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
</pre>
diff --git a/docs/meson.html b/docs/meson.html
index 78507c1d39e..81607744735 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -68,15 +68,15 @@ The easiest way to install everything you need is with <a
href="https://chocolatey.org/">chocolatey</a>.
</p>
<pre>
- choco install python3 winflexbison pkgconfiglite
+choco install python3 winflexbison pkgconfiglite
</pre>
<p>You can even use chocolatey to install mingw and ninja (ninja can be used with MSVC as well)</p>
<pre>
- choco install ninja mingw
+choco install ninja mingw
</pre>
<p>Then install meson using pip</p>
<pre>
- py -3 -m pip install meson mako
+py -3 -m pip install meson mako
</pre>
You may need to add the python3 scripts directory to your path for meson.
@@ -283,7 +283,7 @@ which points to the root of an alternative installation (the prefix). For
example:
</p>
<pre>
- meson builddir -Dcmake_module_path=/home/user/mycmake/prefix
+meson builddir -Dcmake_module_path=/home/user/mycmake/prefix
</pre>
<p>
@@ -296,14 +296,14 @@ find llvm-config:
custom-llvm.ini
<pre>
- [binaries]
- llvm-config = '/usr/local/bin/llvm/llvm-config'
+[binaries]
+llvm-config = '/usr/local/bin/llvm/llvm-config'
</pre>
Then configure meson:
<pre>
- meson builddir/ --native-file custom-llvm.ini
+meson builddir/ --native-file custom-llvm.ini
</pre>
<p>
@@ -325,17 +325,17 @@ should be used. It uses the same format as the native file above:
<p>cross-llvm.ini</p>
<pre>
- [binaries]
- ...
- llvm-config = '/usr/lib/llvm-config-32'
- cmake = '/usr/bin/cmake-for-my-arch'
+[binaries]
+...
+llvm-config = '/usr/lib/llvm-config-32'
+cmake = '/usr/bin/cmake-for-my-arch'
</pre>
<p>Obviously, only cmake or llvm-config is required.</p>
<p>Then configure meson:</p>
<pre>
- meson builddir/ --cross-file cross-llvm.ini
+meson builddir/ --cross-file cross-llvm.ini
</pre>
See the <a href="#cross-compilation">Cross Compilation</a> section for more information.
diff --git a/docs/releasing.html b/docs/releasing.html
index 8f0882b9369..644486bf37b 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -46,10 +46,10 @@ while the latter have a non-zero one.
For example:
</p>
<pre>
- Mesa 10.1.0 - 10.1 branch, feature
- Mesa 10.1.4 - 10.1 branch, bugfix
- Mesa 12.0.0 - 12.0 branch, feature
- Mesa 12.0.2 - 12.0 branch, bugfix
+Mesa 10.1.0 - 10.1 branch, feature
+Mesa 10.1.4 - 10.1 branch, bugfix
+Mesa 12.0.0 - 12.0 branch, feature
+Mesa 12.0.2 - 12.0 branch, bugfix
</pre>
@@ -183,27 +183,27 @@ This should be noted in the <a href="#prerelease">pre-announce</a> email.
</p>
<pre>
- git show b10859ec41d09c57663a258f43fe57c12332698e
+git show b10859ec41d09c57663a258f43fe57c12332698e
- commit b10859ec41d09c57663a258f43fe57c12332698e
- Author: Jonas Pfeil <pfeiljonas at gmx.de>
- Date: Wed Mar 1 18:11:10 2017 +0100
+commit b10859ec41d09c57663a258f43fe57c12332698e
+Author: Jonas Pfeil <pfeiljonas at gmx.de>
+Date: Wed Mar 1 18:11:10 2017 +0100
- ralloc: Make sure ralloc() allocations match malloc()'s alignment.
+ ralloc: Make sure ralloc() allocations match malloc()'s alignment.
- The header of ralloc needs to be aligned, because the compiler assumes
- ...
+ The header of ralloc needs to be aligned, because the compiler assumes
+ ...
- (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
+ (cherry picked from commit cd2b55e536dc806f9358f71db438dd9c246cdb14)
- Squashed with commit:
+ Squashed with commit:
- ralloc: don't leave out the alignment factor
+ ralloc: don't leave out the alignment factor
- Experimentation shows that without alignment factor gcc and clang choose
- ...
+ Experimentation shows that without alignment factor gcc and clang choose
+ ...
- (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
+ (cherry picked from commit ff494fe999510ea40e3ed5827e7818550b6de126)
</pre>
<h2>Regression/functionality testing</h2>
@@ -236,8 +236,8 @@ A live branch, which contains the currently merge/rejected patches is available
in the main repository under <code>staging/X.Y</code>. For example:
</p>
<pre>
- staging/18.1 - WIP branch for the 18.1 series
- staging/18.2 - WIP branch for the 18.2 series
+staging/18.1 - WIP branch for the 18.1 series
+staging/18.2 - WIP branch for the 18.2 series
</pre>
<p>
@@ -271,15 +271,15 @@ Check if the version number is going to remain as, alternatively
To setup the branchpoint:
</p>
<pre>
- git checkout master # make sure we're in master first
- git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
- git checkout -b X.Y
- git checkout master
- $EDITOR VERSION # bump the version number
- git commit -as
- cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
- git commit -as
- git push origin X.Y-branchpoint X.Y
+git checkout master # make sure we're in master first
+git tag -s X.Y-branchpoint -m "Mesa X.Y branchpoint"
+git checkout -b X.Y
+git checkout master
+$EDITOR VERSION # bump the version number
+git commit -as
+cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
+git commit -as
+git push origin X.Y-branchpoint X.Y
</pre>
<p>
@@ -482,38 +482,38 @@ So we do a quick 'touch test'
</p>
<pre>
- __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
- __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
- __es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
- test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
- export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
- export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
- export LIBGL_DEBUG=verbose
- eval $__glxinfo_cmd
- eval $__glxgears_cmd
- eval $__es2info_cmd
- eval $__es2gears_cmd
- export LIBGL_ALWAYS_SOFTWARE=true
- eval $__glxinfo_cmd
- eval $__glxgears_cmd
- eval $__es2info_cmd
- eval $__es2gears_cmd
- export LIBGL_ALWAYS_SOFTWARE=true
- export GALLIUM_DRIVER=softpipe
- eval $__glxinfo_cmd
- eval $__glxgears_cmd
- eval $__es2info_cmd
- eval $__es2gears_cmd
- # Smoke test DOTA2
- unset LD_LIBRARY_PATH
- test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
- unset LIBGL_DRIVERS_PATH
- unset LIBGL_DEBUG
- unset LIBGL_ALWAYS_SOFTWARE
- unset GALLIUM_DRIVER
- export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
- steam steam://rungameid/570 -vconsole -vulkan
- unset VK_ICD_FILENAMES
+__glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
+__es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
+__es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
+test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
+export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
+export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
+export LIBGL_DEBUG=verbose
+eval $__glxinfo_cmd
+eval $__glxgears_cmd
+eval $__es2info_cmd
+eval $__es2gears_cmd
+export LIBGL_ALWAYS_SOFTWARE=true
+eval $__glxinfo_cmd
+eval $__glxgears_cmd
+eval $__es2info_cmd
+eval $__es2gears_cmd
+export LIBGL_ALWAYS_SOFTWARE=true
+export GALLIUM_DRIVER=softpipe
+eval $__glxinfo_cmd
+eval $__glxgears_cmd
+eval $__es2info_cmd
+eval $__es2gears_cmd
+# Smoke test DOTA2
+unset LD_LIBRARY_PATH
+test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
+unset LIBGL_DRIVERS_PATH
+unset LIBGL_DEBUG
+unset LIBGL_ALWAYS_SOFTWARE
+unset GALLIUM_DRIVER
+export VK_ICD_FILENAMES=`pwd`/test/usr/local/share/vulkan/icd.d/intel_icd.x86_64.json
+steam steam://rungameid/570 -vconsole -vulkan
+unset VK_ICD_FILENAMES
</pre>
<h3>Create release notes for the new release</h3>
@@ -538,7 +538,7 @@ Commit these changes and push the branch.
</p>
<pre>
- git push origin HEAD
+git push origin HEAD
</pre>
@@ -549,9 +549,9 @@ Start the release process.
</p>
<pre>
- # For the dist/distcheck, you may want to specify which LLVM to use:
- # export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
- ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
+# For the dist/distcheck, you may want to specify which LLVM to use:
+# export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
+../relative/path/to/release.sh . # append --dist if you've already done distcheck above
</pre>
<p>
@@ -572,8 +572,8 @@ Something like the following steps will do the trick:
</p>
<pre>
- git cherry-pick -x X.Y~1
- git cherry-pick -x X.Y
+git cherry-pick -x X.Y~1
+git cherry-pick -x X.Y
</pre>
<p>Then run the <code>./bin/post_verison.py X.Y.Z</code>, where X.Y.Z is the
@@ -582,8 +582,8 @@ docs/index.html. Remove docs/release-calendar.html. Then commit and push:
</p>
<pre>
- git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
- git push origin master X.Y
+git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
+git push origin master X.Y
</pre>
diff --git a/docs/repository.html b/docs/repository.html
index ad7f90b2604..e78ffc01fb4 100644
--- a/docs/repository.html
+++ b/docs/repository.html
@@ -102,7 +102,7 @@ using git on Windows</a> you'll want to enable automatic CR/LF conversion in
your local copy of the repository:
</p>
<pre>
- git config --global core.autocrlf true
+git config --global core.autocrlf true
</pre>
<p>
@@ -141,8 +141,8 @@ If you try to do a pull by just saying<code> git pull </code>
and git complains that you have not specified a
branch, try:
<pre>
- git config branch.master.remote origin
- git config branch.master.merge master
+git config branch.master.remote origin
+git config branch.master.merge master
</pre>
<p>
Otherwise, you have to say<code> git pull origin master </code>
@@ -161,7 +161,7 @@ unnecessary and distracting branch in master.
<p>
If it has been awhile since you've done the initial clone, try
<pre>
- git pull
+git pull
</pre>
<p>
to get the latest files before you start working.
@@ -169,8 +169,8 @@ to get the latest files before you start working.
<p>
Make your changes and use
<pre>
- git add <files to commit>
- git commit
+git add <files to commit>
+git commit
</pre>
<p>
to get your changes ready to push back into the fd.o repository.
@@ -185,8 +185,8 @@ where you did your last pull and merging it to a point after the other changes.
<p>
To avoid this,
<pre>
- git pull --rebase
- git push
+git pull --rebase
+git push
</pre>
<p>
If you are familiar with CVS or similar system, this is similar to doing a
@@ -207,8 +207,8 @@ those before doing the push.
<p>
If you want the rebase action to be the default action, then
<pre>
- git config branch.master.rebase true
- git config --global branch.autosetuprebase=always
+git config branch.master.rebase true
+git config --global branch.autosetuprebase=always
</pre>
<p>
See <a href="https://www.eecs.harvard.edu/~cduan/technical/git/">Understanding Git Conceptually</a> for a fairly clear explanation about all of this.
diff --git a/docs/shading.html b/docs/shading.html
index 839a61a0361..e36bab49c58 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -162,11 +162,11 @@ These issues will be addressed/resolved in the future.
<li>Use the built-in library functions whenever possible.
For example, instead of writing this:
<pre>
- float x = 1.0 / sqrt(y);
+float x = 1.0 / sqrt(y);
</pre>
Write this:
<pre>
- float x = inversesqrt(y);
+float x = inversesqrt(y);
</pre>
</li>
</ul>
diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index ce51141576c..97fae5484a3 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -56,27 +56,27 @@ log uses 4 spaces of indentation (4 + 75 < 80).
<li>The first line should be a short, concise summary of the change prefixed
with a module name. Examples:
<pre>
- mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG
+mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG
- gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY
+gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY
- i965: Fix missing type in local variable declaration.
+i965: Fix missing type in local variable declaration.
</pre>
<li>Subsequent patch comments should describe the change in more detail,
if needed. For example:
<pre>
- i965: Remove end-of-thread SEND alignment code.
+i965: Remove end-of-thread SEND alignment code.
- This was present in Eric's initial implementation of the compaction code
- for Sandybridge (commit 077d01b6). There is no documentation saying this
- is necessary, and removing it causes no regressions in piglit on any
- platform.
+This was present in Eric's initial implementation of the compaction code
+for Sandybridge (commit 077d01b6). There is no documentation saying this
+is necessary, and removing it causes no regressions in piglit on any
+platform.
</pre>
<li>A "Signed-off-by:" line is not required, but not discouraged either.
<li>If a patch addresses an issue in gitlab, use the Closes: tag
For example:
<pre>
- Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
+Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
</pre>
<p>Prefer the full url to just <code>Closes: #1</code>, since the url makes it
easier to get to the bug page from <code>git log</code></p>
@@ -85,7 +85,7 @@ easier to get to the bug page from <code>git log</code></p>
<li>If a patch addresses a issue introduced with earlier commit, that should be
noted in the patch comment. For example:
<pre>
- Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
+Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
</pre>
<li>You can produce those fixes lines by running
<pre>git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"</pre>
@@ -93,29 +93,29 @@ once and then using <pre>git fixes <sha1></pre>
<li>If there have been several revisions to a patch during the review
process, they should be noted such as in this example:
<pre>
- st/mesa: add ARB_texture_stencil8 support (v4)
-
- if we support stencil texturing, enable texture_stencil8
- there is no requirement to support native S8 for this,
- the texture can be converted to x24s8 fine.
-
- v2: fold fixes from Marek in:
- a) put S8 last in the list
- b) fix renderable to always test for d/s renderable
- fixup the texture case to use a stencil only format
- for picking the format for the texture view.
- v3: hit fallback for getteximage
- v4: put s8 back in front, it shouldn't get picked now (Ilia)
+st/mesa: add ARB_texture_stencil8 support (v4)
+
+if we support stencil texturing, enable texture_stencil8
+there is no requirement to support native S8 for this,
+the texture can be converted to x24s8 fine.
+
+v2: fold fixes from Marek in:
+ a) put S8 last in the list
+ b) fix renderable to always test for d/s renderable
+ fixup the texture case to use a stencil only format
+ for picking the format for the texture view.
+v3: hit fallback for getteximage
+v4: put s8 back in front, it shouldn't get picked now (Ilia)
</pre>
<li>If someone tested your patch, document it with a line like this:
<pre>
- Tested-by: Joe Hacker <jhacker at foo.com>
+Tested-by: Joe Hacker <jhacker at foo.com>
</pre>
<li>If the patch was reviewed (usually the case) or acked by someone,
that should be documented with:
<pre>
- Reviewed-by: Joe Hacker <jhacker at foo.com>
- Acked-by: Joe Hacker <jhacker at foo.com>
+Reviewed-by: Joe Hacker <jhacker at foo.com>
+Acked-by: Joe Hacker <jhacker at foo.com>
</pre>
<li>If sending later revision of a patch, add all the tags - ack, r-b,
Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the
@@ -225,11 +225,11 @@ When you've reviewed a patch, please be unambiguous about your review.
That is, state either
</p>
<pre>
- Reviewed-by: Joe Hacker <jhacker at foo.com>
+Reviewed-by: Joe Hacker <jhacker at foo.com>
</pre>
or
<pre>
- Acked-by: Joe Hacker <jhacker at foo.com>
+Acked-by: Joe Hacker <jhacker at foo.com>
</pre>
<p>
Rather than saying just "LGTM" or "Seems OK".
@@ -239,7 +239,7 @@ Rather than saying just "LGTM" or "Seems OK".
If small changes are suggested, it's OK to say something like:
</p>
<pre>
- With the above fixes, Reviewed-by: Joe Hacker <jhacker at foo.com>
+With the above fixes, Reviewed-by: Joe Hacker <jhacker at foo.com>
</pre>
<p>
which tells the patch author that the patch can be committed, as long
@@ -256,7 +256,7 @@ When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR,
enclose the tag in backticks:
</p>
<pre>
- `Reviewed-by: Joe Hacker <jhacker at example.com>`</pre>
+`Reviewed-by: Joe Hacker <jhacker at example.com>`</pre>
<p>
This is the markdown format for literal, and will prevent gitlab from hiding
the < and > symbols.
@@ -405,23 +405,23 @@ within the commit summary.
<li><code>git rebase -i ...</code> is your friend. Don't be afraid to use it.
<li>Apply a fixup to commit FOO.
<pre>
- git add ...
- git commit --fixup=FOO
- git rebase -i --autosquash ...
+git add ...
+git commit --fixup=FOO
+git rebase -i --autosquash ...
</pre>
<li>Test for build breakage between patches e.g last 8 commits.
<pre>
- git rebase -i --exec="ninja -C build/" HEAD~8
+git rebase -i --exec="ninja -C build/" HEAD~8
</pre>
<li>Sets the default mailing address for your repo.
<pre>
- git config --local sendemail.to mesa-dev at lists.freedesktop.org
+git config --local sendemail.to mesa-dev at lists.freedesktop.org
</pre>
<li> Add version to subject line of patch series in this case for the last 8
commits before sending.
<pre>
- git send-email --subject-prefix="PATCH v4" HEAD~8
- git send-email -v4 @~8 # shorter version, inherited from git format-patch
+git send-email --subject-prefix="PATCH v4" HEAD~8
+git send-email -v4 @~8 # shorter version, inherited from git format-patch
</pre>
</ul>
diff --git a/docs/vmware-guest.html b/docs/vmware-guest.html
index c4387398411..378b9c5797c 100644
--- a/docs/vmware-guest.html
+++ b/docs/vmware-guest.html
@@ -111,18 +111,18 @@ On the host, all you're doing is running VMware
<li>Xserver version at least 1.7
<li>Ubuntu: For ubuntu you need to install a number of build dependencies.
<pre>
- sudo apt-get install git-core
- sudo apt-get install ninja-build meson libpthread-stubs0-dev
- sudo apt-get install xserver-xorg-dev x11proto-xinerama-dev libx11-xcb-dev
- sudo apt-get install libxcb-glx0-dev libxrender-dev
- sudo apt-get build-dep libgl1-mesa-dri libxcb-glx0-dev
+sudo apt-get install git-core
+sudo apt-get install ninja-build meson libpthread-stubs0-dev
+sudo apt-get install xserver-xorg-dev x11proto-xinerama-dev libx11-xcb-dev
+sudo apt-get install libxcb-glx0-dev libxrender-dev
+sudo apt-get build-dep libgl1-mesa-dri libxcb-glx0-dev
</pre>
<li>Fedora: For Fedora you also need to install a number of build dependencies.
<pre>
- sudo yum install mesa-libGL-devel xorg-x11-server-devel xorg-x11-util-macros
- sudo yum install libXrender-devel.i686
- sudo yum install ninja-build meson gcc expat-devel kernel-devel git-core
- sudo yum install makedepend flex bison
+sudo yum install mesa-libGL-devel xorg-x11-server-devel xorg-x11-util-macros
+sudo yum install libXrender-devel.i686
+sudo yum install ninja-build meson gcc expat-devel kernel-devel git-core
+sudo yum install makedepend flex bison
</pre>
</ul>
@@ -137,27 +137,27 @@ Meson should tell you what's missing.
Begin by saving your current directory location:
<pre>
- export TOP=$PWD
+export TOP=$PWD
</pre>
<ul>
<li>Mesa/Gallium master branch. This code is used to build libGL, and the direct rendering svga driver for libGL, vmwgfx_dri.so, and the X acceleration library libxatracker.so.x.x.x.
<pre>
- git clone https://gitlab.freedesktop.org/mesa/mesa.git
+git clone https://gitlab.freedesktop.org/mesa/mesa.git
</pre>
<li>VMware Linux guest kernel module. Note that this repo contains the complete DRM and TTM code. The vmware-specific driver is really only the files prefixed with vmwgfx.
<pre>
- git clone git://anongit.freedesktop.org/git/mesa/vmwgfx
+git clone git://anongit.freedesktop.org/git/mesa/vmwgfx
</pre>
<li>libdrm, a user-space library that interfaces with drm.
Most distros ship with this but it's safest to install a newer version.
To get the latest code from git:
<pre>
- git clone https://gitlab.freedesktop.org/mesa/drm.git
+git clone https://gitlab.freedesktop.org/mesa/drm.git
</pre>
<li>xf86-video-vmware. The chainloading driver, vmware_drv.so, the legacy driver vmwlegacy_drv.so, and the vmwgfx driver vmwgfx_drv.so.
<pre>
- git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-vmware
+git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-vmware
</pre>
</ul>
@@ -172,29 +172,29 @@ the LIBDIR environment variable accordingly.
</p>
For 32-bit Ubuntu systems:
<pre>
- export LIBDIR=/usr/lib/i386-linux-gnu
+export LIBDIR=/usr/lib/i386-linux-gnu
</pre>
For 64-bit Ubuntu systems:
<pre>
- export LIBDIR=/usr/lib/x86_64-linux-gnu
+export LIBDIR=/usr/lib/x86_64-linux-gnu
</pre>
For 32-bit Fedora systems:
<pre>
- export LIBDIR=/usr/lib
+export LIBDIR=/usr/lib
</pre>
For 64-bit Fedora systems:
<pre>
- export LIBDIR=/usr/lib64
+export LIBDIR=/usr/lib64
</pre>
</li>
<li>Build libdrm:
<pre>
- cd $TOP/drm
- meson builddir --prefix=/usr --libdir=${LIBDIR}
- ninja -C builddir
- sudo ninja -C builddir install
+cd $TOP/drm
+meson builddir --prefix=/usr --libdir=${LIBDIR}
+ninja -C builddir
+sudo ninja -C builddir install
</pre>
<li>
<p>Build Mesa and the vmwgfx_dri.so driver, the vmwgfx_drv.so xorg driver, the X acceleration library libxatracker.
@@ -206,10 +206,10 @@ copy and video acceleration:
The following configure options doesn't build the EGL system.
<pre>
- cd $TOP/mesa
- meson builddir --prefix=/usr --libdir=${LIBDIR} -Dgallium-drivers=svga -Ddri-drivers=swrast -Dgallium-xa=true -Ddri3=false
- ninja -C builddir
- sudo ninja -C builddir install
+cd $TOP/mesa
+meson builddir --prefix=/usr --libdir=${LIBDIR} -Dgallium-drivers=svga -Ddri-drivers=swrast -Dgallium-xa=true -Ddri3=false
+ninja -C builddir
+sudo ninja -C builddir install
</pre>
<p>
@@ -221,34 +221,34 @@ if they're not installed in your system. You should be told what's missing.
building and replacing the current Xorg driver.
First check if your system is 32- or 64-bit.
<pre>
- cd $TOP/xf86-video-vmware
- ./autogen.sh --prefix=/usr --libdir=${LIBDIR}
- make
- sudo make install
+cd $TOP/xf86-video-vmware
+./autogen.sh --prefix=/usr --libdir=${LIBDIR}
+make
+sudo make install
</pre>
<li>vmwgfx kernel module. First make sure that any old version of this kernel module is removed from the system by issuing
<pre>
- sudo rm /lib/modules/`uname -r`/kernel/drivers/gpu/drm/vmwgfx.ko*
+sudo rm /lib/modules/`uname -r`/kernel/drivers/gpu/drm/vmwgfx.ko*
</pre>
Build and install:
<pre>
- cd $TOP/vmwgfx
- make
- sudo make install
- sudo depmod -a
+cd $TOP/vmwgfx
+make
+sudo make install
+sudo depmod -a
</pre>
If you're using a Ubuntu OS:
<pre>
- sudo update-initramfs -u
+sudo update-initramfs -u
</pre>
If you're using a Fedora OS:
<pre>
- sudo dracut --force
+sudo dracut --force
</pre>
Add 'vmwgfx' to the /etc/modules file:
<pre>
- echo vmwgfx | sudo tee -a /etc/modules
+echo vmwgfx | sudo tee -a /etc/modules
</pre>
Note: some distros put DRM kernel drivers in different directories.
@@ -259,7 +259,7 @@ For example, sometimes vmwgfx.ko might be found in
After installing vmwgfx.ko you might want to run the following command to
check that the new kernel module is in the expected place:
<pre>
- find /lib/modules -name vmwgfx.ko -exec ls -l '{}' \;
+find /lib/modules -name vmwgfx.ko -exec ls -l '{}' \;
</pre>
If you see the kernel module listed in more than one place, you may need to
move things around.
@@ -271,10 +271,10 @@ reinstall the vmwgfx.ko module again.
Now try to load the kernel module by issuing
<pre>
- sudo modprobe vmwgfx</pre>
+sudo modprobe vmwgfx</pre>
Then type
<pre>
- dmesg</pre>
+dmesg</pre>
to watch the debug output. It should contain a number of lines prefixed with "[vmwgfx]".
<p>
@@ -301,7 +301,7 @@ OpenGL version string: 2.1 Mesa 8.0
<p>
If you don't see this, try setting this environment variable:
<pre>
- export LIBGL_DEBUG=verbose</pre>
+export LIBGL_DEBUG=verbose</pre>
<p>
then rerun glxinfo and examine the output for error messages.
</p>
diff --git a/docs/xlibdriver.html b/docs/xlibdriver.html
index 0859bbaec49..e1740cd730e 100644
--- a/docs/xlibdriver.html
+++ b/docs/xlibdriver.html
@@ -64,12 +64,12 @@ The format of accepted values is: <code>visual-class depth</code>
Here are some examples:
</p>
<pre>
- using csh:
+using csh:
% setenv MESA_RGB_VISUAL "TrueColor 8" // 8-bit TrueColor
% setenv MESA_CI_VISUAL "PseudoColor 12" // 12-bit PseudoColor
% setenv MESA_RGB_VISUAL "PseudoColor 8" // 8-bit PseudoColor
- using bash:
+using bash:
$ export MESA_RGB_VISUAL="TrueColor 8"
$ export MESA_CI_VISUAL="PseudoColor 12"
$ export MESA_RGB_VISUAL="PseudoColor 8"
@@ -146,8 +146,8 @@ The defaults are all 1.0, effectively disabling gamma correction.
Examples:
</p>
<pre>
- % 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
+% 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
</pre>
<p>
The <code>demos/gamma.c</code> program in mesa/demos repository may help
@@ -183,7 +183,7 @@ determine if your X server has overlay support you can test for the
SERVER_OVERLAY_VISUALS property:
</p>
<pre>
- xprop -root | grep SERVER_OVERLAY_VISUALS
+xprop -root | grep SERVER_OVERLAY_VISUALS
</pre>
@@ -207,8 +207,8 @@ The following Mesa-specific extensions are implemented in the Xlib driver.
This extension adds the GLX function:
</p>
<pre>
- GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
- Pixmap pixmap, Colormap cmap )
+GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+ Pixmap pixmap, Colormap cmap )
</pre>
<p>
It is an alternative to the standard glXCreateGLXPixmap() function.
@@ -243,10 +243,10 @@ deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
just before an X window is destroyed. For example:
</p>
<pre>
- #ifdef GLX_MESA_release_buffers
- glXReleaseBuffersMESA( dpy, window );
- #endif
- XDestroyWindow( dpy, window );
+#ifdef GLX_MESA_release_buffers
+ glXReleaseBuffersMESA( dpy, window );
+#endif
+XDestroyWindow( dpy, window );
</pre>
<p>
<a href="specs/MESA_release_buffers.spec">GLX_MESA_release_buffers specification</a>
@@ -270,11 +270,11 @@ This extension was added in Mesa 2.6
<h2>Summary of X-related environment variables</h2>
<pre>
- MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
- MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
- MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
- MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
- MESA_GAMMA - gamma correction coefficients (X only)
+MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
+MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
+MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
+MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
+MESA_GAMMA - gamma correction coefficients (X only)
</pre>
</div>
More information about the mesa-commit
mailing list