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 How reproducible: Always 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 Additional info:
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? Option "Noaccel" 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 Thanks
Created attachment 22588 [details] peach:/etc/X11/XF86Config file
Created attachment 22589 [details] peach:/etc/X11/XF86Config-4
Created attachment 22590 [details] peach:/var/log/XFree86.0.log
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, and S3V) Section "Screen" Driver "accel" Option "Noaccel" - this is the line I added Device "ATI Mach64" Monitor "ViewSonic G810" DefaultColorDepth 16 Subsection "Display" Depth 16 Modes "1280x1024" ViewPort 0 0 EndSubsection EndSection 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: MOUSETYPE="imps2" XMOUSETYPE="IMPS/2" FULLNAME="Microsoft IntelliMouse (PS/2)" XEMU3=yes 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. Thanks, Tyson V. Whitcomb 317-233-8496 twhitcomb.in.us 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: Option "Noaccel" 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: Section "Device" Option "Noaccel" " this is the line I added Identifier "ATI Mach64" Driver "ati" BoardName "Unknown" EndSection 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 317-233-8496 whitcomb
I think the proper syntax is supposed to be all lowercase like so: Option "noaccel" 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 Restarted X No success. 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") TIA
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? Section "ServerFlags" Option "NoTrapSignals" "1" End Section 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 problem.
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 be ok.. 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 info 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 "xorg" component. 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.