Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an old X application provided as a part of a complicated signal processing package. The application resides on the display-less server, and clients having different X-servers connect to it.

On old linux client systems, such as RHEL5, application draws fine, but on modern linux client systems, like RHEL6, Centos5, Ubuntu10 drawing is flawed - windows are blank, or not refreshing, or garbled, or have empty squares behind the previously obscured parts.

Problems partially perished when X server was tuned to use the BackingStore option, but that was only the minor improvement. How can I troubleshoot the application to make it draw the windows contents properly? Any specific extensions and/or workarounds must be enabled? Any old X bugs/specifics must be "supported"?

EDIT: I have uploaded a dump of xdpyinfo of a working client here: http://pastebin.com/W0WHQ8hx and non-working client here: http://pastebin.com/X49c6ckW. Looks like the major difference is in PseudoColor visuals existing on working client and absent on non-working client, but I'm not sure if that matters.

share|improve this question
Please tell us more about the application. What libraries (esp. toolkit libraries) does it require? What versions? What versions of these do you have installed on your modern system(s), versus RHEL5? – jmtd Jun 22 '11 at 8:44
The application is resided on the same server, only clients' computers differ. The application is displayed correctly on old clients (old X-servers), but incorrectly on modern clients (modern X-servers). I should update the question to clarify this. – mbaitoff Jun 22 '11 at 8:55
xtrace may be helpful if you want to investigate the data exchanged between the X server and the client. – Gilles Jun 22 '11 at 23:48
up vote 1 down vote accepted

(This is not a real answer, more a bunch of suggestions - but it's too long to fit into a comment.)

The command xdpyinfo provides a list of X server features, including the list of all registered extensions and visuals; you could start by comparing that.

However, your hint that re-enabling BackingStore fixes the problem makes me suspicious that this is a client problem: that the client makes some wrong assumption on the X11 workings, or somehow violates the ICCCM (Java is notorious for this) and thus is broken by a newer version of X11 that changed some defaults...

Two tentative workarounds:

  • Run x11vnc on the node where the application resides, and then connect to that over VNC from the newer hosts; you can size the x11vnc screen appropriately so to reduce bandwidth consumption.

  • Run Xnest on the newer nodes and let the troublesome application connect to the Xnest display; you should be able to compile a version of Xnest old enough to be compatible with the application.

share|improve this answer
We tried to use Nomachine NX server on the application side, and NX clients on the client side - this introduced even more incompatibilities. We will give VNC a try. – mbaitoff Jun 23 '11 at 1:03
I updated the post with xdpyinfo data. Do you have anything to comment on it? – mbaitoff Jun 24 '11 at 6:16
@mbaitoff Given the absence of PseudoColor visuals in the non-working X server, Gilles' suggestion might be the correct one - give it a try! – Riccardo Murri Jun 24 '11 at 10:23

(This isn't a definitive answer, but it's a possibility.)

It's possible to write X applications that only work on a display that supports a given number of colors. I have encountered a few old programs that simply didn't work on a display with anything but 8-bit colors. The working display provides PseudoColor visuals to enable applications to use 8-bit or 12-bit depth in addition to the native 24-bit depth. The non-working display only provides 24-bit and 32-bit visuals.

So this could be a bug in the application when it can't interact with a server using its favorite number of colors (most likely 256). I have no idea how hard fixing it might be.

Try running the application in VNC; Xvnc -depth 8 or Xvnc -cc 3 (on the RealVNC VNC server) might help.

share|improve this answer
I have tried running the application in the VNC, started at the server-side. Connecting to the server's VNC shows ugly TWM environment. Running the troublesome application in VNC window gives even worse result - no backing store, no redraws, empty windows etc. I also tried to run VNC server on the client side, then connecting to it, and logging in inside it ot the application server. And it worked! I achieved proper redraws and backing store even in truecolor. However, this kind of connection is very unstable - it drops here and there, and VNC server dies. Any help with this? – mbaitoff Jul 4 '11 at 5:28
@mbaitoff Hard to tell for sure, but I recommend running the VNC server on the same machine as the application. The environment shouldn't matter since you'd only run the one application inside it, but you can tune it by putting e.g. gnome-session & in ~/.vnc/xstartup. Try running the client's VNC server on the machine where the application is (copy the vncserver executable and any library it needs). – Gilles Jul 4 '11 at 6:44
'syslog' shows that the client's machine VNC server drops due to segfault in 'Xtightvnc'. I'm now trying to experiment with the server-side VNC server. – mbaitoff Jul 4 '11 at 7:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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