Red Hat Bugzilla – Bug 178149
Mouse behavior odd after snes9x fullscreen mode
Last modified: 2007-11-30 17:11:21 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.12) Gecko/20051215 Epiphany/1.9.4 Description of problem: I came across this issue when using the snes9x (snes9x.com) Super Nintendo Entertainment System emulator version 1.43. I compiled snes9x using DGA and Vidmode. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.0.0-3 How reproducible: Always Steps to Reproduce: 0. Configure X with two video modes: 1024x768 and 320x240. Default to 1024x768. 1. Start snes9x in fullscreen mode (snes9x -fs ROMPATH). This should cause X to change its vidmode from 1024x768 to 320x240. 2. Quit snes9x (press esc twice). X should restore to 1024x768. Actual Results: Once snes9x has exited, the X mouse behaves oddly. There is an invisible, vertical border across which the mouse will not cross. Moving the mouse from right to left "hits" this border and the cursor will not move any more to the left, even though there is more screen real estate. Moving the mouse cursor to the very lower left-hand corner of the screen stops this odd behavior. Once this corner has been touched by the cursor, everything works fine. Expected Results: The snes9x emulator should quit and X should behave. Additional info:
Created attachment 123349 [details] My X configuration
Initial description should read "Moving the mouse cursor to the very lower RIGHT-hand corner..."
This sounds like a bug in the emulator not restoring the previous video mode via the vidmode extension, or perhaps crashing during emulator shutdown prior to getting a chance to restore the video mode. That is a common occurance with buggy fullscreen games/emulators/etc. which use the vidmode extension. Another possibility is that the software is still in memory and has a server grab. In both of these cases, it is a bug in the software itself being ran, and not a bug in the X server. It is possible to restore the display/mouse with a minimal amount of fiddling by the user, but describing how to do that is outside the scope of what bugzilla is intended for. The best place to discuss problems of this nature is on the X.Org mailing lists, in particular xorg@lists.freedesktop.org Once you've discussed the problem there, you'll probably be able to determine for sure if this is a bug in the emulator software or not, and file a bug to the authors of the emulator software. After discussion on the Xorg mailing list, if you do end up discovering that there is a bug in the X server, the proper place to file a bug report is in the X.Org bugzilla, located at http://bugs.freedesktop.org in the "xorg" component. Another thing which you may find very helpful in diagnosing game related problems with respect to server grabs, and mouse problems of this nature, is to review the "Xorg", "Xserver", and "xorg.conf" manpages. One of those pages contains a couple of options which can be enabled in the config file to allow you a couple hotkeys on the numeric keypad which will: 1) release a server grab from any application or 2) release a server grab and send a kill signal to the application that had the grab. Both options are useful in diagnosing video game/emulator/wine/etc. problems of this nature, and save a lot of hair pulling. Keep in mind however that these 2 special key combos are disabled by default due to security reasons, as it is possible to bypass locked screensavers if the options are enabled. Use with caution. Hope this helps. Please update the report to indicate the results of your troubleshooting based on my above advice. Thanks in advance.
Setting status to "NOTABUG", as the details provided in the report seem to indicate it is a client-side bug that is occuring, and should thus be reported to the authors of the application that is causing the problem to manifest.
Sounds fair. Thanks.