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):
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.
Created attachment 123349 [details]
My X configuration
Initial description should read "Moving the mouse cursor to the very lower
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
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 firstname.lastname@example.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
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
2) release a server grab and send a kill signal to the application that had
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.