3

Is there a generic way to reset the display on a borked X session? Let's say that you open your laptop screen after it's been put to sleep, and the display is blank, or scrambled beyond visibility. You can press ctrlaltf1 and see that the X session is running, but for whatever reason, you can't see the screen.

For a borked terminal, you can type reset or stty sane. xrefresh will re-paint the screen, but this won't help with display issues caused by the video card.

In Gnome 3, gnome --replace will do this, but I'm running XFCE4, and honestly, this is a global question... is there an xdg-* or x-* wrapper for this? I'm looking for something that I can set a key-binding for, on any-platform that I'm using.

4

There's no similar mechanism, because the reasons are completely different.

A garbled text terminal comes from having multiple sources all writing to the terminal, with no coordination between them. So you end up with text where it doesn't belong, which is solved by making the application whose text you do want to see redisplay what it wants. xrefresh is the analog of that. It's more rarely needed because the X server already manages coordination between applications: each application is supposed to draw only in its own window. xrefresh is only needed when an application behaves badly — as opposed to the situation in text terminals, where there is no way to behave better.

As for the equivalent of stty sane to restore input settings, this doesn't normally apply because applications aren't supposed to modify global parameters — here again each application is supposed to mess up only its own windows. There are a few bad things that come up, such as an application grabbing the pointer or the keyboard (xdotool key XF86Ungrab, or Ctrl+Alt+Keypad/ if enabled).

If the display remains blank or scrambled due to a driver bug, there's no generic recovery mechanism. Anyone who's done any serious programming knows that there's no completely generic recovery mechanism after a bug, because a bug is by definition something unexpected and since you can't predict the state of the system after the bug is detected, there's no way to be sure that whatever you do will work as intended to restore it. The only sure-fire way to recover from a bug is to appeal to a higher authority: for example, if a bug is detected in a process, kill it (because of process isolation, the bug should be confined to the process) and start a new instance. If the bug is detected in the kernel, the higher authority would be the hardware — reboot the computer. In the case of a display driver bug, usually what is affected is only the state of the GPU, so resetting the GPU would be enough. As far as I know, there's no generic way to tell X.org drivers to reset the GPU and reinitialize it to their tastes. There are a couple of things you can try, but they don't always work:

  • Switch to a text console (Ctrl+Alt+F1) and then switch back (Ctrl+Alt+F7). If the bug is strictly in the GPU state, that should solve it, because on the switch back the X server is supposed to reset the GPU to the previous state. But if the bug also affects the internals of the driver, or if the driver backed up an invalid state when switching away, that won't help.
  • Switch to a text console start another X server instance, kill it, and then switch back. That might work even if the simpler variant above didn't, if the bug was that the driver modified some setting which it failed to reinitialize properly. Yet another variant is to keep the other instance running; depending on the nature of the bug, this too an help.
  • Try disabling all of the displays with xrandr, e.g.

    export DISPLAY=:0
    xrandr
    # see what displays are listed, e.g. “DVI-0 connected …”
    xrandr --output DVI-0 --off
    xrandr --output DVI-0 --auto
    

    That can help occasionally, but not very often, because usually the bug is between the driver and the GPU and isn't affected by the displays.

  • If you're running Compiz, kill it (and restart it if you really must). Killing the window manager is unlikely to help where xrefresh doesn't, so I suspect that if gnome3 --replace helps, it's because it restarts Compiz.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.