docs: fix syntax highlighting on shell commands

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27010>

docs/android.rst

@@ -41,7 +41,7 @@ Then, create your Meson cross file to use it, something like this
 Now, use that cross file for your Android build directory (as in this
 one cross-compiling the turnip driver for a stock Pixel phone)
 
-.. code-block:: console
+.. code-block:: sh
 
     meson setup build-android-aarch64 \
         --cross-file android-aarch64 \
@@ -61,7 +61,7 @@ read-only disk image on ``/vendor``.  To be able to replace them for
 driver development, we need to unlock the device and remount
 ``/vendor`` read/write.
 
-.. code-block:: console
+.. code-block:: sh
 
     adb disable-verity
     adb reboot
@@ -69,7 +69,7 @@ driver development, we need to unlock the device and remount
 
 Now you can replace drivers as in:
 
-.. code-block:: console
+.. code-block:: sh
 
     adb push build-android-aarch64/src/freedreno/vulkan/libvulkan_freedreno.so /vendor/lib64/hw/vulkan.sdm710.so
 
@@ -91,7 +91,7 @@ using scp from outside the container.
 On your device, you'll want to make ``/`` read-write.  ssh in as root
 and run:
 
-.. code-block:: console
+.. code-block:: sh
 
     crossystem dev_boot_signed_only=0
     /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 4
@@ -100,7 +100,7 @@ and run:
 Then, we'll switch Android from using an image for ``/vendor`` to using a
 bind-mount from a directory we control.
 
-.. code-block:: console
+.. code-block:: sh
 
     cd /opt/google/containers/android/
     mkdir vendor-ro
@@ -123,7 +123,7 @@ change it to::
 
 Now, restart the UI to do a full reload:
 
-.. code-block:: console
+.. code-block:: sh
 
     restart ui
 
@@ -136,7 +136,7 @@ then the ``mount`` command should show::
 Now, replacing your DRI driver with a new one built for Android should
 be a matter of:
 
-.. code-block:: console
+.. code-block:: sh
 
     scp msm_dri.so $HOST:/opt/google/containers/android/vendor-rw/lib64/dri/
 
@@ -149,7 +149,7 @@ available to the NDK, assuming you're building anything but the
 Freedreno Vulkan driver for KGSL.  You can mostly put things in place
 with:
 
-.. code-block:: console
+.. code-block:: sh
 
     scp $HOST:/opt/google/containers/android/vendor-rw/lib64/libdrm.so \
         NDKDIR/sysroot/usr/lib/aarch64-linux-android/lib/
@@ -166,6 +166,6 @@ find you need to reload the whole Android container.  To do so without
 having to log in to Chrome again every time, you can just kill the
 container and let it restart:
 
-.. code-block:: console
+.. code-block:: sh
 
     kill $(cat /run/containers/android-run_oci/container.pid )

docs/application-issues.rst

@@ -35,7 +35,7 @@ than the given year.
 
 For example, if the game was released in 2001, do
 
-.. code-block:: console
+.. code-block:: sh
 
    export MESA_EXTENSION_MAX_YEAR=2001
 

docs/ci/bare-metal.rst

@@ -138,7 +138,7 @@ Setup
 Each board will be registered in freedesktop.org GitLab.  You'll want
 something like this to register a fastboot board:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo gitlab-runner register \
         --url https://gitlab.freedesktop.org \
@@ -194,7 +194,7 @@ Caching downloads
 To improve the runtime for downloading traces during traces job runs, you will
 want a pass-through HTTP cache.  On your runner box, install nginx:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo apt install nginx libnginx-mod-http-lua
 
@@ -213,7 +213,7 @@ your devices are on.
 
 Enable the site and restart nginx:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo rm /etc/nginx/sites-enabled/default
    sudo ln -s /etc/nginx/sites-available/fdo-cache /etc/nginx/sites-enabled/fdo-cache

docs/ci/index.rst

@@ -64,13 +64,13 @@ Farm management
 
 When the farm starts failing for any reason (power, network, out-of-space), it needs to be disabled by pushing separate MR with
 
-.. code-block:: console
+.. code-block:: sh
 
    git mv .ci-farms{,-disabled}/$farm_name
 
 After farm restore functionality can be enabled by pushing a new merge request, which contains
 
-.. code-block:: console
+.. code-block:: sh
 
    git mv .ci-farms{-disabled,}/$farm_name
 
@@ -279,7 +279,7 @@ command`` instead of ``run -it $IMAGE bash`` (which you may also find
 useful for debug).  Extract your build setup variables from
 .gitlab-ci.yml and run the CI meson build script:
 
-.. code-block:: console
+.. code-block:: sh
 
    IMAGE=registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11
    sudo docker pull $IMAGE
@@ -288,7 +288,7 @@ useful for debug).  Extract your build setup variables from
 All you have left over from the build is its output, and a _build
 directory.  You can hack on mesa and iterate testing the build with:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo docker run --rm -v `pwd`:/mesa $IMAGE meson compile -C /mesa/_build
 

docs/ci/local-traces.rst

@@ -12,7 +12,7 @@ Running single trace
 --------------------
 A simple run to see the output of the trace can be done with
 
-.. code-block:: console
+.. code-block:: sh
 
    apitrace replay -w name_of_trace.trace
 
@@ -20,7 +20,7 @@ For more information, look into the `Apitrace documentation <https://github.com/
 
 For comparing checksums use:
 
-.. code-block:: console
+.. code-block:: sh
 
    cd piglit/replayer
    export PIGLIT_SOURCE_DIR="../"
@@ -34,7 +34,7 @@ Sometimes it's useful to be able to test traces on your local machine instead of
 
 Download the YAML file from your driver's ``ci/`` directory and then change the path in the YAML file from local proxy or MinIO to the local directory (url-like format ``file://``)
 
-.. code-block:: console
+.. code-block:: sh
 
    # The PIGLIT_REPLAY_DEVICE_NAME has to match name in the YAML file.
    export PIGLIT_REPLAY_DEVICE_NAME='your_device_name'

docs/codingstyle.rst

@@ -126,7 +126,7 @@ Basic formatting guidelines
 -  This GNU indent command generally does the right thing for
    formatting:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
 

docs/download.rst

@@ -28,13 +28,13 @@ Mesa releases are available in two formats: ``.tar.xz`` and ``.tar.gz``.
 
 To unpack the tarball:
 
-.. code-block:: console
+.. code-block:: sh
 
       tar xf mesa-Y.N.P.tar.xz
 
 or
 
-.. code-block:: console
+.. code-block:: sh
 
       tar xf mesa-Y.N.P.tar.gz
 

docs/drivers/asahi.rst

@@ -307,14 +307,14 @@ useful for exercising the compiler. To build, use options:
 
 Then run an OpenGL workload with environment variable:
 
-.. code-block:: console
+.. code-block:: sh
 
    LD_PRELOAD=~/mesa/build/src/asahi/drm-shim/libasahi_noop_drm_shim.so
 
 For example to compile a shader with shaderdb and print some statistics along
 with the IR:
 
-.. code-block:: console
+.. code-block:: sh
 
    ~/shader-db$ AGX_MESA_DEBUG=shaders,shaderdb ASAHI_MESA_DEBUG=precompile LIBGL_DRIVERS_PATH=~/lib/dri/ LD_PRELOAD=~/mesa/build/src/asahi/drm-shim/libasahi_noop_drm_shim.so ./run shaders/glmark/1-12.shader_test
 

docs/drivers/freedreno.rst

@@ -346,7 +346,7 @@ though going here is the last resort and likely won't be helpful.
 The ``PC`` value is an instruction address in the current firmware.
 You would need to disassemble the firmware (/lib/firmware/qcom/aXXX_sqe.fw) via:
 
-.. code-block:: console
+.. code-block:: sh
 
   afuc-disasm -v a650_sqe.fw > a650_sqe.fw.disasm
 
@@ -373,14 +373,14 @@ send to the kernel.  Mesa itself doesn't implement a way to stream them out
 (though it maybe should!).  Instead, we have an interface for the kernel to
 capture all submitted command streams:
 
-.. code-block:: console
+.. code-block:: sh
 
   cat /sys/kernel/debug/dri/0/rd > cmdstream &
 
 By default, command stream capture does not capture texture/vertex/etc. data.
 You can enable capturing all the BOs with:
 
-.. code-block:: console
+.. code-block:: sh
 
   echo Y > /sys/module/msm/parameters/rd_full
 
@@ -400,7 +400,7 @@ Additionally it is geared towards analyzing the GPU state at the moment of the c
 Alternatively, it's possible to obtain the whole submission with all command
 streams via ``/sys/kernel/debug/dri/0/hangrd``:
 
-.. code-block:: console
+.. code-block:: sh
 
   sudo cat /sys/kernel/debug/dri/0/hangrd > logfile.rd // Do the cat _before_ the expected hang
 
@@ -421,17 +421,17 @@ Dumping rendering results or even just memory is currently unsupported.
 
 Replaying is done via `replay` tool:
 
-.. code-block:: console
+.. code-block:: sh
 
   ./replay test_replay.rd
 
 More examples:
 
-.. code-block:: console
+.. code-block:: sh
 
   ./replay --first=start_submit_n --last=last_submit_n test_replay.rd
 
-.. code-block:: console
+.. code-block:: sh
 
   ./replay --override=0 --generator=./generate_rd test_replay.rd
 
@@ -453,7 +453,7 @@ The workflow would look like this:
 1. Find the cmdstream № you want to edit;
 2. Decompile it:
 
-.. code-block:: console
+.. code-block:: sh
 
   ./rddecompiler -s %cmd_stream_n% example.rd > generate_rd.c
 
@@ -461,7 +461,7 @@ The workflow would look like this:
 4. Compile it back, see rdcompiler-meson.build for the instructions;
 5. Plug the generator into cmdstream replay:
 
-.. code-block:: console
+.. code-block:: sh
 
   ./replay --override=%cmd_stream_№% --generator=~/generate_rd
 
@@ -529,7 +529,7 @@ because it would require much less breadcrumb writes and syncs.
 
 Breadcrumbs settings:
 
-.. code-block:: console
+.. code-block:: sh
 
   TU_BREADCRUMBS=%IP%:%PORT%,break=%BREAKPOINT%:%BREAKPOINT_HITS%
 
@@ -544,26 +544,26 @@ A typical work flow would be:
 
 - Start listening for breadcrumbs on a remote host:
 
-.. code-block:: console
+.. code-block:: sh
 
    nc -lvup $PORT | stdbuf -o0 xxd -pc -c 4 | awk -Wposix '{printf("%u:%u\n", "0x" $0, a[$0]++)}'
 
 - Start capturing command stream;
 - Replay the hanging trace with:
 
-.. code-block:: console
+.. code-block:: sh
 
    TU_BREADCRUMBS=$IP:$PORT,break=-1:0
 
 - Increase hangcheck period:
 
-.. code-block:: console
+.. code-block:: sh
 
    echo -n 60000 > /sys/kernel/debug/dri/0/hangcheck_period_ms
 
 - After GPU hang note the last breadcrumb and relaunch trace with:
 
-.. code-block:: console
+.. code-block:: sh
 
    TU_BREADCRUMBS=%IP%:%PORT%,break=%LAST_BREADCRUMB%:%HITS%
 
@@ -589,7 +589,7 @@ Finding instances of stale reg reads
 Turnip has a debug option to stomp the registers with invalid values to catch
 the cases where stale data is read.
 
-.. code-block:: console
+.. code-block:: sh
 
   MESA_VK_ABORT_ON_DEVICE_LOSS=1 \
   TU_DEBUG_STALE_REGS_RANGE=0x00000c00,0x0000be01 \

docs/drivers/llvmpipe.rst

@@ -31,7 +31,7 @@ Requirements
 
    For Linux, on a recent Debian based distribution do:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       aptitude install llvm-dev
 
@@ -42,7 +42,7 @@ Requirements
 
    For a RPM-based distribution do:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       yum install llvm-devel
 
@@ -76,7 +76,7 @@ Building
 
 To build everything on Linux invoke meson as:
 
-.. code-block:: console
+.. code-block:: sh
 
    mkdir build
    cd build

docs/drivers/panfrost.rst

@@ -118,7 +118,7 @@ Additional GPU IDs are enumerated in the ``panfrost_model_list`` list in
 As an example: assuming Mesa is installed to a local path ``~/lib`` and Mesa's
 build directory is ``~/mesa/build``, a shader can be compiled for Mali-G52 as:
 
-.. code-block:: console
+.. code-block:: sh
 
    ~/shader-db$ BIFROST_MESA_DEBUG=shaders \
    LIBGL_DRIVERS_PATH=~/lib/dri/ \
@@ -128,7 +128,7 @@ build directory is ``~/mesa/build``, a shader can be compiled for Mali-G52 as:
 
 The same shader can be compiled for Mali-T720 as:
 
-.. code-block:: console
+.. code-block:: sh
 
    ~/shader-db$ MIDGARD_MESA_DEBUG=shaders \
    LIBGL_DRIVERS_PATH=~/lib/dri/ \
@@ -148,7 +148,7 @@ and various flags to dEQP mimic the surfaceless environment that our
 continuous integration (CI) uses. This eliminates window system dependencies,
 although it requires a specially built CTS:
 
-.. code-block:: console
+.. code-block:: sh
 
    ~/VK-GL-CTS/build/external/openglcts/modules$ PAN_MESA_DEBUG=trace,dump \
    LIBGL_DRIVERS_PATH=~/lib/dri/ \

docs/drivers/venus.rst

@@ -51,7 +51,7 @@ vtest
 The simplest way to test Venus is to use virglrenderer's vtest server.  To
 build virglrenderer with Venus support and to start the vtest server,
 
-.. code-block:: console
+.. code-block:: sh
 
     $ git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git
     $ cd virglrenderer
@@ -63,7 +63,7 @@ build virglrenderer with Venus support and to start the vtest server,
 
 In another shell,
 
-.. code-block:: console
+.. code-block:: sh
 
     $ export VK_ICD_FILENAMES=<path-to-virtio_icd.x86_64.json>
     $ export VN_DEBUG=vtest
@@ -84,7 +84,7 @@ driver, which was upstreamed in kernel 5.16.
 crosvm is written in Rust.  To build crosvm, make sure Rust has been installed
 and
 
-.. code-block:: console
+.. code-block:: sh
 
  $ git clone --recurse-submodules \
        https://chromium.googlesource.com/chromiumos/platform/crosvm
@@ -97,7 +97,7 @@ Note that crosvm must be built with ``default-no-sandbox`` or started with
 
 This is how one might want to start crosvm
 
-.. code-block:: console
+.. code-block:: sh
 
  $ sudo LD_LIBRARY_PATH=<...> VK_ICD_FILENAMES=<...> ./target/debug/crosvm run \
        --gpu vulkan=true \
@@ -126,7 +126,7 @@ the `Chrome OS kernel
 
 To build minigbm and to enable minigbm support in virglrenderer,
 
-.. code-block:: console
+.. code-block:: sh
 
  $ git clone https://chromium.googlesource.com/chromiumos/platform/minigbm
  $ cd minigbm
@@ -141,7 +141,7 @@ Make sure a host Wayland compositor is running.  Replace
 
 In the guest, build and start sommelier, the special Wayland compositor,
 
-.. code-block:: console
+.. code-block:: sh
 
  $ git clone https://chromium.googlesource.com/chromiumos/platform2
  $ cd platform2/vm_tools/sommelier

docs/egl.rst

@@ -18,7 +18,7 @@ Build EGL
 #. Configure your build with the desired client APIs and enable the
    driver for your hardware. For example:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       $ meson configure \
               -D egl=enabled \

docs/gallium-nine.rst

@@ -20,7 +20,7 @@ Build
 
 Beware: Most Direct3D games are 32-bit, and thus need a 32-bit version of Mesa.
 
-.. code-block:: console
+.. code-block:: sh
 
    $ meson configure \
          -D gallium-nine=true \
@@ -43,6 +43,6 @@ Run
 
 Before running your application in Wine, verify that everything works as expected by running:
 
-.. code-block:: console
+.. code-block:: sh
 
    $ wine ninewinecfg

docs/gpuvis.rst

@@ -14,7 +14,7 @@ Any traces can be made with trace-cmd. The Gpuvis repository contains
 `scripts <https://github.com/mikesart/gpuvis/tree/master/sample>`__ for
 configuring the markers needed for GPU events. To start tracing:
 
-.. code-block:: console
+.. code-block:: sh
 
    sh trace-cmd-setup.sh && sh trace-cmd-start-tracing.sh
    # Start your game etc. Then to capture a trace
@@ -30,7 +30,7 @@ Run on Steamos
 Steamos includes a script (`gpu-trace <https://github.com/lostgoat/gpu-trace>`__)
 to capture traces.
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo gpu-trace
    # Press Ctrl+C to stop capture and open report in gpuvis
@@ -39,7 +39,7 @@ Note that on Steamos gpuvis is actually not installed by default, but the
 script does write a gpu-trace.zip file in the current working directory. To
 open it you'll want to do the following on your development machine:
 
-.. code-block:: console
+.. code-block:: sh
 
    scp sd-host:gpu-trace.zip ./
    unzip gpu-trace.zip
@@ -60,7 +60,7 @@ PRESSURE_VESSEL_DEVEL=1 to set up the tracing filesystem so the trace marker
 can be written. This can e.g. be done by going to the game properties in
 Steam and setting the command line to
 
-.. code-block:: console
+.. code-block:: sh
 
    PRESSURE_VESSEL_DEVEL=1 %command%
 

docs/install.rst

@@ -46,7 +46,7 @@ Third party/extra tools.
    respectively, (or later) should work. On Windows with MinGW, install
    Flex and Bison with:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       mingw-get install msys-flex msys-bison
 
@@ -68,7 +68,7 @@ configure error message.
 Here are some common ways to retrieve most/all of the dependencies based
 on the packaging tool used by your distro.
 
-.. code-block:: console
+.. code-block:: sh
 
      zypper source-install --build-deps-only Mesa # openSUSE/SLED/SLES
      yum-builddep mesa # yum Fedora, OpenSuse(?)
@@ -84,7 +84,7 @@ for \*nix systems like Linux and BSD, macOS, Haiku, and Windows.
 
 The general approach is:
 
-.. code-block:: console
+.. code-block:: sh
 
      meson setup builddir/
      meson compile -C builddir/
@@ -92,7 +92,7 @@ The general approach is:
 
 On Windows you can also use the Visual Studio backend
 
-.. code-block:: console
+.. code-block:: sh
 
      meson setup builddir --backend=vs
      cd builddir
@@ -108,7 +108,7 @@ It's often necessary or useful when debugging driver issues or testing new
 branches to run against a local build of Mesa without doing a system-wide
 install. Meson has built-in support for this with its ``devenv`` subcommand:
 
-.. code-block:: console
+.. code-block:: sh
 
      meson devenv -C builddir glxinfo
 
@@ -126,7 +126,7 @@ assume ``$MESA_INSTALLDIR`` is an absolute path to this location.
 
 First, configure Mesa and install in the temporary location:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir/ -Dprefix="$MESA_INSTALLDIR" OTHER_OPTIONS
    meson install -C builddir/
@@ -135,7 +135,7 @@ where ``OTHER_OPTIONS`` is replaced by any meson configuration options you may
 want.  For instance, if you want to build the LLVMpipe drivers, it would look
 like this:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir/ -Dprefix="$MESA_INSTALLDIR" \
       -Dgallium-drivers=swrast -Dvulkan-drivers=swrast
@@ -148,7 +148,7 @@ Which variable you have to set depends on the API.
 OpenGL
 ~~~~~~
 
-.. code-block:: console
+.. code-block:: sh
 
    LD_LIBRARY_PATH="$MESA_INSTALLDIR/lib64" glxinfo
 
@@ -159,7 +159,7 @@ contains ``libGL.so`` and use that one.
 Vulkan
 ~~~~~~
 
-.. code-block:: console
+.. code-block:: sh
 
    VK_ICD_FILENAMES="$MESA_INSTALLDIR/share/vulkan/icd/my_icd.json" vulkaninfo
 
@@ -170,7 +170,7 @@ is named ``lvp_icd.x86_64.json``.
 OpenCL
 ~~~~~~
 
-.. code-block:: console
+.. code-block:: sh
 
    OCL_ICD_VENDORS="$MESA_INSTALLDIR/etc/OpenCL/vendors" clinfo
 
@@ -247,6 +247,6 @@ determine the proper compiler and linker flags.
 
 For example, compiling and linking a GLUT application can be done with:
 
-.. code-block:: console
+.. code-block:: sh
 
       gcc `pkg-config --cflags --libs glut` mydemo.c -o mydemo

docs/meson.rst

@@ -25,13 +25,13 @@ Unix-like OSes
 If Meson is not already installed on your system, you can typically
 install it with your package installer. For example:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo apt-get install meson   # Ubuntu
 
 or
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo dnf install meson   # Fedora
 
@@ -51,20 +51,20 @@ modules (Mako). You also need pkg-config (a hard dependency of Meson),
 Flex, and Bison. The easiest way to install everything you need is with
 `Chocolatey <https://chocolatey.org/>`__.
 
-.. code-block:: console
+.. code-block:: sh
 
    choco install python3 winflexbison pkgconfiglite
 
 You can even use Chocolatey to install MinGW and Ninja (Ninja can be
 used with MSVC as well)
 
-.. code-block:: console
+.. code-block:: sh
 
    choco install ninja mingw
 
 Then install Meson using pip
 
-.. code-block:: console
+.. code-block:: sh
 
    py -3 -m pip install meson packaging mako
 
@@ -87,7 +87,7 @@ for each configuration you might want to use.
 
 Basic configuration is done with:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup build/
 
@@ -98,7 +98,7 @@ build options at the end.
 
 To review the options which Meson chose, run:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson configure build/
 
@@ -112,7 +112,7 @@ With additional arguments ``meson configure`` can be used to change
 options for a previously configured build directory. All options passed
 to this command are in the form ``-D "option"="value"``. For example:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson configure build/ -Dprefix=/tmp/install -Dglx=true
 
@@ -125,7 +125,7 @@ an empty list (``-D platforms=[]``).
 Once you've run the initial ``meson`` command successfully you can use
 your configured backend to build the project in your build directory:
 
-.. code-block:: console
+.. code-block:: sh
 
    ninja -C build/
 
@@ -133,7 +133,7 @@ The next step is to install the Mesa libraries, drivers, etc. This also
 finishes up some final steps of the build process (such as creating
 symbolic links for drivers). To install:
 
-.. code-block:: console
+.. code-block:: sh
 
    ninja -C build/ install
 
@@ -168,7 +168,7 @@ Developers will often want to install Mesa to a testing directory rather
 than the system library directory. This can be done with the --prefix
 option. For example:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson --prefix="${PWD}/build/install" build/
 
@@ -191,7 +191,7 @@ they are guaranteed to persist across rebuilds and reconfigurations.
 This example sets -fmax-errors for compiling C sources and -DMAGIC=123
 for C++ sources:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir/ -Dc_args=-fmax-errors=10 -Dcpp_args=-DMAGIC=123
 
@@ -206,7 +206,7 @@ a new build dir for a different compiler.
 This is an example of specifying the Clang compilers and cleaning the
 build directory before reconfiguring with an extra C option:
 
-.. code-block:: console
+.. code-block:: sh
 
    CC=clang CXX=clang++ meson setup build-clang
    ninja -C build-clang
@@ -230,7 +230,7 @@ CMake finder it will only find static libraries, it will never find
 which points to the root of an alternative installation (the prefix).
 For example:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir -Dcmake_module_path=/home/user/mycmake/prefix
 
@@ -248,7 +248,7 @@ to find llvm-config:
 
 Then configure Meson:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir/ --native-file custom-llvm.ini
 
@@ -268,7 +268,7 @@ Obviously, only CMake or llvm-config is required.
 
 Then configure Meson:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir/ --cross-file cross-llvm.ini
 

docs/osmesa.rst

@@ -23,7 +23,7 @@ Building OSMesa
 
 Configure and build Mesa with something like:
 
-.. code-block:: console
+.. code-block:: sh
 
    meson setup builddir -Dosmesa=true -Dgallium-drivers=swrast -Dvulkan-drivers=[] -Dprefix=$PWD/builddir/install
    meson install -C builddir

docs/perfetto.rst

@@ -61,7 +61,7 @@ To capture a trace with Perfetto you need to take the following steps:
    `convenience script <https://perfetto.dev/docs/quickstart/linux-tracing#capturing-a-trace>`__
    to start the tracing service:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       cd subprojects/perfetto
       CONFIG=<path/to/gpu.cfg> OUT=out/linux_clang_release ./tools/tmux -n
@@ -83,7 +83,7 @@ To capture a trace with Perfetto you need to take the following steps:
 To be a bit more explicit, here is a listing of commands reproducing
 the steps above :
 
-.. code-block:: console
+.. code-block:: sh
 
    # Configure Mesa with perfetto
    mesa $ meson . build -Dperfetto=true -Dvulkan-drivers=intel,broadcom -Dgallium-drivers=
@@ -124,7 +124,7 @@ actually collecting traces.
 This can be achieved by setting the :envvar:`MESA_GPU_TRACES`
 environment variable before starting a Vulkan application :
 
-.. code-block:: console
+.. code-block:: sh
 
    MESA_GPU_TRACES=perfetto ./build/my_vulkan_app
 
@@ -139,7 +139,7 @@ Freedreno / Turnip
 The Freedreno PPS driver needs root access to read system-wide
 performance counters, so you can simply run it with sudo:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo ./build/src/tool/pps/pps-producer
 
@@ -150,13 +150,13 @@ The Intel PPS driver needs root access to read system-wide
 `RenderBasic <https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2023-0/gpu-metrics-reference.html>`__
 performance counters, so you can simply run it with sudo:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo ./build/src/tool/pps/pps-producer
 
 Another option to enable access wide data without root permissions would be running the following:
 
-.. code-block:: console
+.. code-block:: sh
 
    sudo sysctl dev.i915.perf_stream_paranoid=0
 
@@ -165,7 +165,7 @@ Alternatively using the ``CAP_PERFMON`` permission on the binary should work too
 A particular metric set can also be selected to capture a different
 set of HW counters :
 
-.. code-block:: console
+.. code-block:: sh
 
    INTEL_PERFETTO_METRIC_SET=RasterizerAndPixelBackend ./build/src/tool/pps/pps-producer
 
@@ -173,7 +173,7 @@ Vulkan applications can also be instrumented to be Perfetto producers.
 To enable this for given application, set the environment variable as
 follow :
 
-.. code-block:: console
+.. code-block:: sh
 
    PERFETTO_TRACE=1 my_vulkan_app
 
@@ -188,7 +188,7 @@ To run the producer, follow these two simple steps:
 
 1. Enable Panfrost unstable ioctls via kernel parameter:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       modprobe panfrost unstable_ioctls=1
 
@@ -196,7 +196,7 @@ To run the producer, follow these two simple steps:
 
 2. Run the producer:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       ./build/pps-producer
 
@@ -210,7 +210,7 @@ If the convenience script ``tools/tmux`` keeps copying artifacts to your
 ``SSH_TARGET`` without starting the tmux session, make sure you have ``tmux``
 installed in your system.
 
-.. code-block:: console
+.. code-block:: sh
 
    apt install tmux
 

docs/releasing.rst

@@ -177,7 +177,7 @@ to stabilization and bugfixing.
 
 Setup the branchpoint:
 
-.. code-block:: console
+.. code-block:: sh
 
    # Make sure main can carry on at the new version
    $EDITOR VERSION # bump the version number, keeping in mind the wrap around at the end of the year
@@ -194,7 +194,7 @@ Once it has been merged, note the last commit *before* your "VERSION:
 bump to X.Y" as this is the branchpoint. This is ``$LAST_COMMIT`` in the
 command below:
 
-.. code-block:: console
+.. code-block:: sh
 
    VERSION=X.Y
 
@@ -206,7 +206,7 @@ command below:
 Now that we have an official branchpoint, let's push the tag and create
 the branches:
 
-.. code-block:: console
+.. code-block:: sh
 
    git push origin $VERSION-branchpoint
    git checkout $VERSION-branchpoint
@@ -220,7 +220,7 @@ and altered in way necessary, with the caveat that anything pushed to
 the ``X.Y`` branch must not be altered anymore. A convenient command
 to perform an interactive rebase over everything since the last release is:
 
-.. code-block:: console
+.. code-block:: sh
 
    git rebase -i mesa-$(cat VERSION)
 
@@ -255,7 +255,7 @@ Most of the testing should already be done during the
 
 Here is one solution:
 
-.. code-block:: console
+.. code-block:: sh
 
    __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
    __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
@@ -307,7 +307,7 @@ Use the release.sh script from X.Org `util-modular <https://gitlab.freedesktop.o
 
 Start the release process.
 
-.. code-block:: console
+.. code-block:: sh
 
    ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
 
@@ -329,7 +329,7 @@ in the ``mesa-X.Y.Z.announce`` template. Commit this change.
 Don't forget to push the commits to both the ``staging/X.Y`` branch and
 the ``X.Y`` branch:
 
-.. code-block:: console
+.. code-block:: sh
 
    git push origin HEAD:staging/X.Y
    git push origin HEAD:X.Y
@@ -340,14 +340,14 @@ Back on mesa main, add the new release notes into the tree
 
 Something like the following steps will do the trick:
 
-.. code-block:: console
+.. code-block:: sh
 
    git cherry-pick -x X.Y~1
    git cherry-pick -x X.Y
 
 Then run the
 
-.. code-block:: console
+.. code-block:: sh
 
    ./bin/post_version.py X.Y.Z
 
@@ -356,7 +356,7 @@ docs/relnotes.rst and docs/release-calendar.csv. It will then generate
 a Git commit automatically. Check that everything looks correct and
 push:
 
-.. code-block:: console
+.. code-block:: sh
 
       git push origin main X.Y
 

docs/repository.rst

@@ -26,19 +26,19 @@ To get the Mesa sources anonymously (read-only):
 #. Install the Git software on your computer if needed.
 #. Get an initial, local copy of the repository with:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git clone https://gitlab.freedesktop.org/mesa/mesa.git
 
 #. Later, you can update your tree from the upstream repository with:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git pull origin
 
 #. If you also want the Mesa demos/tests repository:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git clone https://gitlab.freedesktop.org/mesa/demos.git
 
@@ -77,7 +77,7 @@ tokens <https://gitlab.freedesktop.org/profile/personal_access_tokens>`__
 to push over HTTPS if ssh does not suit your needs. In this case, create
 a token, and put it in the URL as shown here:
 
-.. code-block:: console
+.. code-block:: sh
 
    git remote set-url --push origin https://USER:TOKEN@gitlab.freedesktop.org/your~user~name/mesa.git
 
@@ -89,7 +89,7 @@ Windows <https://git-scm.com/book/en/v2/Getting-Started-Installing-Git#_installi
 you'll want to enable automatic CR/LF conversion in your local copy of
 the repository:
 
-.. code-block:: console
+.. code-block:: sh
 
    git config --global core.autocrlf true
 
@@ -118,7 +118,7 @@ Developer Git Tips
    If you try to do a pull by just saying\ ``git pull`` and Git
    complains that you have not specified a branch, try:
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git config branch.main.remote origin
       git config branch.main.merge main
@@ -137,7 +137,7 @@ Developer Git Tips
 
    If it has been awhile since you've done the initial clone, try
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git pull
 
@@ -145,7 +145,7 @@ Developer Git Tips
 
    Make your changes and use
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git add <files to commit>
       git commit
@@ -161,7 +161,7 @@ Developer Git Tips
 
    To avoid this,
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git pull --rebase
       git push
@@ -181,7 +181,7 @@ Developer Git Tips
 
    If you want the rebase action to be the default action, then
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git config branch.main.rebase true
       git config --global branch.autosetuprebase=always

docs/shading.rst

@@ -144,7 +144,7 @@ installed as the binary ``glsl_compiler``.
 Here's an example of using the compiler to compile a vertex shader and
 emit :ext:`GL_ARB_vertex_program`-style instructions:
 
-.. code-block:: console
+.. code-block:: sh
 
        src/compiler/glsl/glsl_compiler --version XXX --dump-ast myshader.vert
 

docs/submittingpatches.rst

@@ -174,7 +174,7 @@ to test this is to make use of the \`git rebase\` command, to run your
 tests on each commit. Assuming your branch is based off
 ``origin/main``, you can run:
 
-.. code-block:: console
+.. code-block:: sh
 
    $ git rebase --interactive --exec "meson test -C build/" origin/main
 
@@ -433,7 +433,7 @@ Git tips
 -  ``git rebase -i ...`` is your friend. Don't be afraid to use it.
 -  Apply a fixup to commit FOO.
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git add ...
       git commit --fixup=FOO
@@ -441,6 +441,6 @@ Git tips
 
 -  Test for build breakage between patches e.g last 8 commits.
 
-   .. code-block:: console
+   .. code-block:: sh
 
       git rebase -i --exec="ninja -C build/" HEAD~8

docs/xlibdriver.rst

@@ -85,7 +85,7 @@ Hardware overlay planes are supported by the Xlib driver. To determine
 if your X server has overlay support you can test for the
 SERVER_OVERLAY_VISUALS property:
 
-.. code-block:: console
+.. code-block:: sh
 
    xprop -root | grep SERVER_OVERLAY_VISUALS