Inspect DRI Screens and Driver Options with xdriinfo

xdriinfo tells you which Direct Rendering Infrastructure driver an X screen is actually using. That is the first thing worth knowing the moment an OpenGL app starts behaving oddly.

It also counts screens and can print a driver's XML option document. All of it is read-only: nothing here configures DRI or touches the X server. Allow about ten minutes. You need the x11-utils package and access to the X display you want to query, and ordinary user privileges are enough throughout.

Warning: do not use sudo to try to repair a display connection. Root does not make an unavailable X display available.

1. Check the installed command and version

Confirm which executable your shell will run first. This guide was checked against Debian's x11-utils package version 7.7+6build2, containing xdriinfo 1.0.7. Other releases can format diagnostics differently, so treat your installed version as the authority for your host.

$ command -v xdriinfo
/usr/bin/xdriinfo
$ xdriinfo -version
xdriinfo 1.0.7

Checkpoint: if command -v prints nothing, install x11-utils through your normal package management, then rerun this step. Installation is the only part of this guide that may need elevated privileges, and it is not part of the query itself.

2. Confirm which display will be queried

Unless you pass -display, xdriinfo uses the DISPLAY environment variable. Check it first:

$ printf 'DISPLAY=%s\n' "${DISPLAY:-<unset>}"
DISPLAY=:0

The value is host-specific: a local graphical session commonly shows something like :0, while an SSH session might show localhost:10.0. Do not copy the example blindly. If the variable is unset, ask the owner of the X session for the correct display and authorisation context.

To target a display for one command without changing your shell session, put -display before the command name:

$ xdriinfo -display :0 nscreens

Replace :0 with a real display. This affects only that one invocation; it does not set DISPLAY for anything that runs after it.

3. List the DRI driver reported for every screen

With no command argument, xdriinfo lists the DRI driver name for every screen on the selected display:

$ xdriinfo
radeonsi

One line is one screen. A machine with more screens prints more lines, and the driver name depends on the graphics hardware and installed Mesa stack. This is not a package inventory, and it does not prove every OpenGL application is actually using that driver.

Checkpoint: save or compare the exact driver name if you are chasing a graphics issue. Do not swap in a familiar name from a different machine just because it looks right.

4. Count screens before asking about one

Use nscreens to print the screen count for the display:

$ xdriinfo nscreens
1

Screen numbers are zero-based in the driver screen command. For the single-screen result above, the valid screen number is 0:

$ xdriinfo driver 0
radeonsi

Two screens means you query 0 and 1. A desktop monitor number, a connector name and a GPU index are not the same thing as an X screen number, so do not assume they line up.

5. Print configuration options for a screen or driver

The options command prints an XML document describing configuration options. You can identify the driver indirectly with a screen number:

$ xdriinfo options 0
<?xml version="1.0" encoding="UTF-8"?>
<driconf>
  ... driver-specific XML ...
</driconf>

The exact elements, whitespace and options are driver-specific: the abbreviated block above shows shape, not something to paste into a config file. Capture the full output when you actually need to inspect it:

$ xdriinfo options 0 > dri-options.xml
$ test -s dri-options.xml && echo 'wrote a non-empty XML document'
wrote a non-empty XML document

Redirection creates or truncates dri-options.xml before xdriinfo even runs. If that file matters, pick a new name or protect it first:

$ test ! -e dri-options.xml || cp --preserve=all dri-options.xml dri-options.xml.bak
$ xdriinfo options 0 > dri-options.xml.new
$ test -s dri-options.xml.new && mv dri-options.xml.new dri-options.xml

Recovery: if the final command fails, remove the incomplete dri-options.xml.new and keep the original. The backup is ordinary copied data; delete it only once you have checked the replacement and no longer need to fall back.

You can also name a driver directly:

$ xdriinfo options radeonsi > radeonsi-options.xml

The manual says a driver name can skip the X connection entirely, but the installed binary still needs a usable driver name and may report an error if it is unknown or the local DRI setup cannot answer. Treat a non-zero exit status and its diagnostic as the actual result, rather than guessing at a driver name until something prints.

6. Diagnose the common display failure

If the display cannot be opened, expect an error like this:

$ xdriinfo nscreens
Error: Couldn't open display

That means the query never reached the X server. Check DISPLAY, whether the X server is running, and whether your user has permission to connect. On a remote session, verify that X forwarding (or the intended local display) is actually configured, then retry with an explicit display:

$ xdriinfo -display DISPLAY_NAME nscreens

Replace DISPLAY_NAME with a real value such as :0. Be careful about putting an untrusted string into a script without understanding how your shell passes it. This command is read-only, but a wrong display can still waste time by having you inspect the wrong machine or session.

Done means