Red Hat Bugzilla – Bug 46645
right mouse button doesn't work in "quest foglight" application
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Windows NT 5.0; I)
Description of problem:
right mouse button does not work in one of my critical applications : foglight by quest software
right mouse button works fine in all other applications
left mouse mouse button works fine in all applications
right mouse button works within the foglight application un redhat 7.0
foglight 2.7.1r is a network server monitoring application program running on solaris 2.6
the display is exported back to my red hat professional server 7.1
Steps to Reproduce:
1.install custom-class red hat 7.1 professional server for i686
2. config mouse for two button (with three button emulation) ms intellimouse
3. reboot server and start kde
4. start terminal session and execute xhost +
5. login to remote solaris 2.6 server
6. export DISPLAY=peach.isd.state.in.us:0
7. start foglight applications with sudo su foglight ./foglight
8. navigate graphical applilcation with mouse using left buttom
9. attempt to open server host icons with right mouse button to view data
10. right mouse button does not open host server icons to view data
11. one time the peach redhat 7.1 server crashed with at stop 11 fatal error
Actual Results: right mouse will not work within the foglight application
Expected Results: the right mouse button should work as it does within all other applications and
as is does with the foglight application under red hat 7.0
Maintainers will need to know what type of mouse do you have: exact model,
please - not just PS/2. In addition, please "Create a new attachement" using
the link below with your /etc/X11/XF86Config-4 and /var/log/XFree86.*.log
I doubt it is mouse related, but more likely whatever the right mouseclick
is supposed to do in the app is likely triggering some driver bug or XAA
bug. Please provide the files requested above.
Also, can you try disabling XAA in your config to see if that is the problem?
man XF86Config for details if unsure. If noaccel fixes it, then XAA is
probably at fault. What specific version of XFree86 are you using?
rpm -q XFree86
Created attachment 22588 [details]
Created attachment 22589 [details]
Created attachment 22590 [details]
I think I figured out what you meant by XAA and - Option "Noaccel"
I vi(ed) the peach:/etc/X11/XF86Config file
I placed - Option "Noaccel" within the following section:
# The accelerated servers (S3, Mach32, Mach8, P9000, AGX, W32, Mach64, I128,
Option "Noaccel" - this is the line I added
Device "ATI Mach64"
Monitor "ViewSonic G810"
ViewPort 0 0
Is this what you wanted me to do? If it is, and I did reboot peach (the machine name) and restart X, this suggestion did NOT fix the problem.
Again, the right mouse button does NOT work within the work with the Quest Foglight application but does work elsewhere and does work within the
Quest Foglight application under Red Hat Linux 7.0
I have included three files; two of these are the ones you requested.
The specific version of XFree86 I am using is XFree86-4.0.3-5
The mouse model is Microsoft IntelliMouse 1.1A PS/2 Compatible.
I have used the used the following packaged Red Hat Linux Professional
Server 7.1 mouse drivers: 1) Generic Mouse (PS/2), 2) Generic 3 Button Mouse
(PS/2), and 3) Microsoft IntelliMouse (PS/2).
The current contents of the peach:/etc/sysconfig/mouse file are:
FULLNAME="Microsoft IntelliMouse (PS/2)"
I have enabled and disabled the 3 mouse button emulation too.
I have tried using different mice on the dev/psaux port (PS/2). I have not tried serial mice on com1 or com2.
What do you mean by disabling the XAA within the config? What configuration file are you talking about? What is XAA and what does affect? Where
do I put the "Noaccel" option?
What options can I enable within XF86Config and XF86Config-4 that might
affect and troubleshoot this mouse problem?
I am eagerly awaiting your reply.
Tyson V. Whitcomb
Thanks, your logs and config look fine, so it must be a driver bug,
at least that is what it looks like to me. To answer your questions
above, the options should be put into the config file for the version
of X that you're using. The XF86Config-4 is for XFree86-4.0.3, and the
XF86Config is for 3.3.6. You are using 4.x and so your options were
added to the wrong file which has no effect.
Add the following in the Device section:
Let me know if that fixes it.
Is this application you're using a Motif application? I ask because it
sounds like there might be a bug in X triggered by motif applications.
Look at bug #31846, does it sound similar?
If the noaccel option fixes the problem, then we can narrow down just
which XAA feature is goofing up, and I can track it down.
I vi(ed) the the /etc/X11/XF86Config-4 file and added the line 'Option "Noaccel"' within the Device section:
Option "Noaccel" " this is the line I added
Identifier "ATI Mach64"
Then, I restarted X and ran my Quest Foglight application.
No success. The right mouse button still does not work.
The right mouse does work properly when executing Quest Foglight from Hummingbird Exceed runnging run on Windows 2000.
Is there anything else you would like for me to test or try?
Tyson V. Whitcomb
I think the proper syntax is supposed to be all lowercase like so:
Excerpt from http://www.xfree86.org/4.0.2/ati5.html#17
5.8. Option ``noaccel''
By default, the driver will accelerate draw operations if a Mach64 CRTC is used
to drive the display. As implemented in this driver, acceleration does not
require a linear video memory aperture. This option disables this acceleration.
I made the proper syntax changes within /etc/X11/XF86Config-4
Waiting for your reply.
Actually the case and whitespace shouldn't matter. X ignores case on
options in the config files and strips all whitespace, so "noaccel",
"NoAccel", "No acceL" should all be the same.
Does X display any error messages when it dies, or generate a core dump?
If it does not core, can you try putting the following in your XF86Config-4
in the ServerFlags section:
Option "NoTrapSignals" "1"
Now run X again and trigger the behaviour. You should get a core dump now.
If not, run X as root and trigger the failure. Once you get a core,
can you get a gdb backtrace? (gdb --core core, then hit "bt")
X does not display any error messages when the right mouse buttom does not work.
X died only once with a stop fatal 11 error and I forget if it was due to the mouse or the right mouse button not working.
X has not died since and the Quest Foglight application has never died or crashed.
There are no core files within any of the Foglight subdirectories or path.
The right mouse button on any mouse make or model just does not function with Foglight running on Sun Solaris 5.6 exporting its display
out to my packaged Linux 7.1 professional server distribution host.
There is not a "ServerFlags" section in my /etc/X11/XF86Config-4 file. Do you want me to create that section and add the option(s) you request?
Where where in the file do you want me to place the section, at the top or bottom?
Option "NoTrapSignals" "1"
Is the above the correct syntax?
Yes, add the above to your XF86Config-4 at the top or bottom, doesn't
really matter. No space in EndSection though. Does this foglight
application availabl for Linux also? Either way, is there a way I
can obtain a copy legally to use for debugging? I don't have access
to Solaris but I will try to gain access if we have any Solaris
boxes running internally. Better yet if it can be totally reproduced
with a Linux client.
Also.. do you have other Linux machines available with different video
hardware that you could test this out with? I would like to narrow down
if it is a generic X problem or driver specific. If you could
test on other machines or with different video hardware, that would help
immensely. If you can do this, please attach server logs from any
cards that you try, and wether it works or not. This may be a mach64 driver
Since we last communicated, I did add the section "ServerFlags" with with your stated option and did provide the proper syntax (no space in
EndSection). This addition to the XF86Config-4 file made no difference.
The Foglight application is developed to run on a Solaris 2.5, 2.6.and 2.7 and eventually on Windows NT and Windows 2000 servers.
The server part of the application consists of a rules engine and a database. The client software, installed on any unix or MS Windows host sends data
back to the Foglight application server (Solaris). Since I do want to configure and operate Foglight directly on its server host, which sits in a restricted
room and is far from my work area, all I want is export the display back to a Linux 7.1 packaged server professional 686 workstatioin because I do not
have a Solaris workstation on my desk. The Foglight application executes and display fine except that the right mouse button does not open windows
within Foglight. The right mouse button does work fine and correctly in all other application running under Red Hat 7.1 packaged professtional server.
And Red Hat 7.1 packaged professional server is running fine in all other aspects and operations.
The right mouse buttom problem with Foglight does not occur under 7.0 or 6.2 Red Hat Linux which both were was running on my same workstation with
no changes,deletions or additions to system configuration or hardware in between. And the right mouse button does work with Read Hat Linux 6.2 on a
differently configured Intel 686 workstation owned by another user.
The Foglight application has a strict licensing agreement. I will attempt to send you a copy or talk to Quest Software to have them send you a copy.is this
is acceptable to Quest.
I believe the fault may be within the the 7.1 XFree86 libraries pertaining to the mouse. I have not tried using a different video card and related driver.
I will see if I can obtain some additional video equipment.
Also, this right mouse button problem exist both in Gnome (with all its windows managers), in KDE and in failsafe; again, only in Red Hat 7.1.
The NoTrapSignals just increases the chance of getting a core dump if
X dies. You also need to make sure you haven't disabled coring with ulimit.
System default is to allow cores so if you haven't changed it then it should
I have visited the Quest homepage looking for a trial version for debugging
purposes but they do not seem to have one. Please do not send me one as
that would violate their licensing agreement likely. If you have contact
information with someone at Quest, that would be great. I will try to find
contact info on their homepage as well.
From what info you've supplied so far, my current thought is that this is
either a video driver related bug or a device independant X server bug. I
do not think it is mouse related, but that something the app does when you
click the right button triggers some operation that then locks. Testing on
other video hardware can help narrow it down.
What would be best right now is if I can get contact with Quest, as this
will be easier to fix with their help even if it is just supplying software
sample, or even software running remotely on one of their machines over
the net would be fine. That in conjunction with your info, and possible
tests with other video hardware should help.
Update: I have emailed email@example.com requesting contact info,
and await their reply.
I removed my current video ATI Mach64 video care and place pci Matrox MGA 2164W Millennium II card in a different pci slot and kept the same
monitor. Still the right mouse button does not funtion within my Quest Foglight application.
Also, I notice that when configuring X both /etc/X11XF86Config and /etc/X11/XF86Config-4 files are modified. And the XF86Config files does
have "ServerFlags" section although it is commented out. Again, should I be modifying /etc/X11XF86Config or etc/X11/XF86Config-4 or both files?
What should I do now? Test more video cards and/or monitors?
I tested another video card in a different pci slot and user different modes and color depth. Nothing improves makes the right mouse button function.
This all video cards I test are pci and Red Hat Linux 7.1 2.4.3-12 has loaded correct video drivers for all these card. The cpu pc workstation is a NEC
Powermate 8100 series.
Waiting for your reply,
Again, I have described previously, what each config file is for, please
reread the bug report for this information.
Easy access to a debuggable environment with which to debug this has
prevented any progress in diagnosing the problem. Given the information
that has been supplied so far, it is my belief that the bug is a bug in
the X server in device independant code somewhere, and most likely it
is a bug in code that is not used by many applications as I've been unable
to find any to reproduce with.
Someone with the technical ability to debug this, and access to the software
will need to debug the X server, by rebuilding it as a static build, with
debug info, and running it in gdb and reproducing the problem.
Prior to any debugging however, I *strongly* suggest using the latest
XFree86 4.0.3 RPM packages, and dependancies on a test system in a
non-production environment to see if the problem has been solved already,
and if not, trying 4.1.0 out.
No sense debugging a potentially already fixed issue. You might also
want to consider taking this issue upstream with the XFree86 project
itself. Being more familiar with the codebase, someone might be able
to more easily debug the problem and find a solution more quickly.
We believe this issue to be resolved in our currently shipping
OS releases. Please upgrade to Fedora Core 2 or later, and if this
issue turns out to still be reproduceable, please file a bug report
in the X.Org bugzilla located at http://bugs.freedesktop.org in the
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.