Bug 178149 - Mouse behavior odd after snes9x fullscreen mode
Summary: Mouse behavior odd after snes9x fullscreen mode
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: powerpc Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-18 02:03 UTC by W. Michael Petullo
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-01 00:14:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
My X configuration (2.62 KB, text/plain)
2006-01-18 02:04 UTC, W. Michael Petullo
no flags Details

Description W. Michael Petullo 2006-01-18 02:03:21 UTC
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):

How reproducible:

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:

Comment 1 W. Michael Petullo 2006-01-18 02:04:37 UTC
Created attachment 123349 [details]
My X configuration

Comment 2 W. Michael Petullo 2006-01-18 02:06:18 UTC
Initial description should read "Moving the mouse cursor to the very lower
RIGHT-hand corner..."

Comment 3 Mike A. Harris 2006-01-18 02:35:48 UTC
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 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


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.

Comment 4 Mike A. Harris 2006-02-01 00:14:12 UTC
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.

Comment 5 W. Michael Petullo 2006-02-01 01:43:48 UTC
Sounds fair.  Thanks.

Note You need to log in before you can comment on or make changes to this bug.