Add or Remove X Colormaps with xstdcmap

An X11 client stuck with washed-out or garish colours is usually missing a standard colormap, and xstdcmap is the tool that sets one. It creates or removes standard colormap properties on an X server: nothing more. You will confirm the installed utility, target a display, create one property, then remove it again. The examples use xstdcmap 1.0.5 from Debian package x11-xserver-utils version 7.7+10build2.

Warning: colormap creation changes the X server's state. It is not a file edit and does not need sudo. Do not run the creation or deletion examples against a shared desktop until you know which display they target.

1. Confirm the installed command

Start with two ordinary, read-only checks. Neither touches an X server, so they are safe even in a shell with no graphical session at all:

$ command -v xstdcmap
/usr/bin/xstdcmap
$ dpkg-query -W -f='${Package} ${Version}\n' x11-xserver-utils
x11-xserver-utils 7.7+10build2
$ xstdcmap -version
xstdcmap 1.0.5

The version string belongs to the installed binary. Package versions vary by distribution, so keep this checkpoint handy if you are comparing output against another machine.

2. Check the display before changing anything

xstdcmap reads the DISPLAY environment variable when you do not pass -display. Print it first:

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

That value is only an example. Yours might carry a hostname, such as workstation.example:0. An unset variable means the command has nowhere to send its changes. Do not guess a display name, and do not copy :0 just because it appears here.

For a one-off operation, make the target explicit with -display:

$ xstdcmap -display "$DISPLAY" -version
xstdcmap 1.0.5

The version operation does not touch the connection, but this shows where the option goes. When you run a real operation, swap DISPLAY_VALUE for a display you are actually authorised to use:

$ xstdcmap -display DISPLAY_VALUE -verbose -default

Checkpoint: stop if the command reports that it cannot open the display. Fix the X authentication or display value first. Running it with elevated privileges can make authentication worse, because root may not hold your X authority credentials.

3. Create one standard colormap property

Pick the property that matches the client you are supporting:

For a focused test, create the default map with logging turned on:

$ xstdcmap -display DISPLAY_VALUE -verbose -default

Verbose output reports how the command parses its input and defines the property. The exact lines depend on the X server, its visuals, and the allocations available on that screen. A clean exit is the useful first signal:

$ printf 'exit status: %s\n' "$?"
exit status: 0

Do not treat a zero status as proof that every client will now use the map. Standard colormaps are an X11 compatibility mechanism, and not every screen has a meaningful visual for every property. xstdcmap chooses allocations and visuals where it can, not where it must.

4. Create all six maps only when you need them

-all defines all six standard colormap properties on each screen: default, best, red, green, blue and grey. It also replaces any that already exist. That replacement is exactly why -all should never be your reflexive first command.

If an older X11 client genuinely needs the complete set, run:

$ xstdcmap -display DISPLAY_VALUE -verbose -all
$ printf 'exit status: %s\n' "$?"
exit status: 0

Warning: this is a state change affecting every screen selected by the display. It can overwrite properties that another client or startup script created. Record the existing setup, use a test display where possible, and do not drop it blindly into a session startup file.

5. Remove a property when the test is over

Deletion is a state change too. -delete takes default, best, red, green, blue, gray or all. Remove only the property you actually created:

$ xstdcmap -display DISPLAY_VALUE -verbose -delete default
$ printf 'exit status: %s\n' "$?"
exit status: 0

There is no general undo history here. The practical recovery is rerunning whatever command your X startup configuration normally uses, or restarting the session if the properties get recreated at login. Do not reach for -delete all as a cleanup shortcut on a shared display.

6. Keep startup use deliberate

xstdcmap is meant to live in an X startup script, but that also makes the change persistent across every login. Test the exact command manually first, with the exact display and user that will run the session. Only then add a minimal line to the relevant startup mechanism.

Prefer one property when one client needs one property. If a script genuinely needs -all, document why, keep the display assumption visible, and place the command after the X server is available. A failed startup command should never take down the rest of the session, so test its error handling before you rely on it.

A common distraction here is mixing up X11 and Wayland troubleshooting. xstdcmap talks to an X server and defines X standard colormap properties; it does not configure a compositor, a Wayland protocol, or display hardware. If the misbehaving application is a native Wayland client, this is the wrong tool entirely.

Done means