X11/Motif problems with Fedora

[philp]

I have been successfully running X11 applications on Fedora 3/4 for a few years now, with no problems. I run these applications using the motif window manager. Recently I have tryed running these applications using redhat enterprise and I get some strange results which I dont understand.

At the moment I am running the same binaries that I built on Fedora3/4. So I am not recompiling anything. I get lots of different graphical problems. This is an example:-
One of the applications loops around its event loop and updates a text tool (via X11) and displays
it inside the loop(with suitable delays). On Enterprise it does not generally update the text widget on the screen. However I can make it update the text widget on the screen simply by moving the mouse...or if I run a program inside a terminal that is doing continuos updates(e.g. top) to the screen then the widget will also be updated???

Why might this be??? Could it be because I have subtle X11 problems in my code(its worked for years), or is it something else??? I was kinda hoping that the binaries would work as is on the new distro, and indeed I will try building one of them with the new distro to see if that fixes the problems.

Has anybody got any ideas...compatability libraies or something???
Thanks for reading this.
Phil

[Rubberman]

Since FC3/4 a lot of system API's and shared libraries have changed considerably. Try rebuilding on the new platform and see if that fixes the problem. I assume you are running now on RHEL 5 or later? Are you still using MWM, or are you running a more current GUI, such as KDE or Gnome?

[philp]

Thankyou for your help. Yes, today we will try building one of our applications on the new platform and see if that fixes it. We are using RHEL6. Yes we are still using MWM. I'm not sure what version, but I believe it is very up to date(I was not involved in installing that). I will try and find out what version it is. I've got to say I am hoping that the rebuild will fix it. One problem that I had was that the applications use varargs a lot, so I have had to build gcc3.2.2 first.

Thanks again for your input

[philp]

We have now rebuilt one of the applications on the RHEL6 platform. Unfortunately we still have exactly the same problem. Has anyone got any ideas as to what might be causing our problems. We also notice that drop down menus fail to display the last entry until you move the mouse. And why do these problems go away if you are running another program which is updating the display e.g top. Could this be a motif problem or an X11 problem in our code?

Thanks

[Rubberman]

We have now rebuilt one of the applications on the RHEL6 platform. Unfortunately we still have exactly the same problem. Has anyone got any ideas as to what might be causing our problems. We also notice that drop down menus fail to display the last entry until you move the mouse. And why do these problems go away if you are running another program which is updating the display e.g top. Could this be a motif problem or an X11 problem in our code?

Thanks

These days, the variable arguments are defined elsewhere, so if you only #include <stdio.h>, you should be covered. So, try this:

1. Add to the CFLAGS and CPPFLAGS in your Makefile "-D HAVE_NEW_GCC"
2. In your code where you #include <varargs.h> do this:

#ifdef HAVE_NEW_GCC
# include <stdio.h>
#else
# include <varargs.h>
#endif

or more simply:

#include <stdio.h> /* probably already have this, but no problem doing it again */
#ifndef HAVE_NEW_GCC
# include <varargs.h>
#endif

Don't know if it will work (haven't tried it), but it's worth a try. If it does work, and you want to push bug fixes back to older systems, then you only need to tweak the Makefile to define, or not, that macro.

[philp]

Again thankyou very much for your help.
We have also noticed that xterm was not behaving correctly on RHEL6. In fact it also was doing something similar to what some of our applications were doing. If we highlighted some text inside of an xterm and then held the cursor very still and pasted using the middle button it would not update the screen until we moved the mouse. Also, if we had another program updating the screen continuosly then it would paste straight away.

We then thought that we would install Fedora 14....and we are in the process of checking that out....but so far it looks fine i.e. so far its working where RHEL6 was failing(including the xterm problem). However as I say we need to do more testing...also we are using different machines and so will need to use the same machine to take out any other possibilities. Note we have seen RHEL6 fail on several machines.

Thanks again for your valuable help.

[Rubberman]

The problem with the highlight and paste may be related to the use of MWM on SL6. I just tried doing that on a raw xterm under Gnome, with no problems, though that was a very quick test (no more than 5 minutes of futzing around with it). I also have had no problems with either the KDE or Gnome terminal programs. Have you considered moving to a more modern desktop manager?

[philp]

Thanks Rubberman for your help. I'v just noticed that my last post did not get to the list...I must have had finger trouble.

It has turned out that this problem does also occur on Fedora 14. Its also related to hardware,so it could be a combination of things. I have access to two Quad processor machines(different hardware)..it works on one, but not the other, so I am none the wiser. It works on some machines but not others.. I am wondering if it could be related to the graphics drivers?

I do have a couple of X11 questions that may be related to my problem:-
1. When the application does an XFlush() this I assume will flush the output out to the X-server. I assume that the XServer should then (in its own time) send any screen updates to the display. I assume that the application does not need to be told anything more about this update and so there will be no events sent to the application regarding them???
2. The application event queue is just about input events i.e. mouse or keyboard events?

Thanks again for reading this

[Rubberman]

Can you tell us what the video hardware and drivers are on the two systems; the one that works, and the one that doesn't?

[philp]

Thanks again Rubberman

My working machine is an AMD Quad Core which is using an ATI Radeon HD 5700 series graphics card. Its using the driver 2.1 Mesa 7.9
Unfortunately I do not have easy access to the failing machines. All my machines work.
There are at least 4 failing machines. I have been told that all of these 4 use nouvea drivers.
My colleague has a machine that it fails on and it is an intel Quad core which is using an nvidia GeForce 9600 GT.using the nouvea driver (part of Fedora 14 and RHEL6).

I am beginning to think that the problem is more likely the driver end. It was interesting, but I installed Fedora 14 onto a separate hard disk on my colleague's machine which showed the problem. I then, because I was feeling lazy, took that hard disk and plugged it straight into my machine and booted it. I half expected it to fall in a big heap!!! But it booted up ok, which amazed me. Ane what was even more wierd the problem does not happen on my machine.

Of course the motherboards are different so the problem could be elsewhere. Also I'm sure other people would have seen this problem. If it some kind of timing problem then I would expect it to be more intermitttant?? 'm really hoping that it is a driver problem!!!! If my colleague has time he will try and install the nvidea driver to see if his machine works any better.

Thanks for reading this
Phil