Mouse not returned to X11

[elyk1212]

Hi all,

When I use zsnes and quit from fullscreen mode the mouse remains forever frozen in X11. If I minimize to windowed mode, then quit, all is well. (But if I reinvoke zsnes and minimize then quit, I can regain control. To do this I must have a console open, to tab over to using the keyboard).

I am not sure if this is a bug with X11, but it is not present in the 1.51 version from the website, but only the experimental 1.51b and the rpm packaged from PLF (mandriva), maybe also from this experimental source?.

http://board.zsnes.com/phpBB2/viewtopic.php?t=11513

Also, I am using Mandriva 2008.0 and I do have 2 mice on the comp at a time (one wireless). I can dump more details here as needed.



Logs are like this for failing to relinquish the mouse:

Code: Select all

./zsnes: /usr/lib/libz.so.1: no version information available (required by ./zsnes)
ZSNES v1.51, (c) 1997-2007, ZSNES Team
Be sure to check http://www.zsnes.com/ for the latest version.

ZSNES is written by the ZSNES Team (See AUTHORS.TXT)
ZSNES comes with ABSOLUTELY NO WARRANTY.  This is free software,
and you are welcome to redistribute it under certain conditions;
please read 'LICENSE.TXT' thoroughly before doing so.

Use ZSNES -? for command line definitions.

Starting Mouse detection.
Unable to poll /dev/input/event0. Make sure you have read permissions to it.
ManyMouse: 2 mice detected.
Using ManyMouse for:
Mouse 0: Logitech USB-PS/2 Optical Mouse
Mouse 1: ImPS/2 Generic Wheel Mouse

Audio Opened.
Driver: aRts output
Channels: 2
Rate: 44100

Device 0 Logitech WingMan Cordless Gamepad
  7 axis, 11 buttons, 0 hats, 0 balls
pure virtual method called
terminate called without an active exception
Aborted

And when giving up the mouse (normal expected behavior)

Code: Select all

ZSNES v1.51, (c) 1997-2007, ZSNES Team
Be sure to check http://www.zsnes.com/ for the latest version.

ZSNES is written by the ZSNES Team (See AUTHORS.TXT)
ZSNES comes with ABSOLUTELY NO WARRANTY.  This is free software,
and you are welcome to redistribute it under certain conditions;
please read 'LICENSE.TXT' thoroughly before doing so.

Use ZSNES -? for command line definitions.

This is a work in progress build. It contains code which
May or may not be complete

If this is supposed to be an official release, you forgot to
run configure with --enable-release, go rebuild.

Starting Mouse detection.
Unable to poll /dev/input/event0. Make sure you have read permissions to it.
ManyMouse: 2 mice detected.
Using ManyMouse for:
Mouse 0: Logitech USB-PS/2 Optical Mouse
Mouse 1: ImPS/2 Generic Wheel Mouse

Audio Opened.
Driver: Simple DirectMedia Layer output
Channels: 2
Rate: 44100

Device 0 Logitech WingMan Cordless Gamepad
  7 axis, 11 buttons, 0 hats, 0 balls

Anyhow, I just need a working binary version that has aRts sound sever support due to a default mixer issue I am having in Mandriva 2008.0. I tried compiling from source and ran into issues, but will try again.



I haven't dug into the code, but from the looks of it, it seems some clean up code isn't called and it exits "abnormally". This issue is present even if using the default sound sever, so the invocation method does not appear to matter.


Thanks in advance!

[Nach]

You're having a crash when you exit, which is leading to your mouse not being released. It seems you don't have all the dependencies needed for the recompiled ZSNES builds. You can load up a ZSNES which doesn't crash on exit, and then immediately exit it for your mouse to be relinquished after a ZSNES session crashed on exit.

To fix your problem, grab the 1.51b source, and compile it properly.

Code: Select all

./configure --enable-release --enable-libao

[elyk1212]

Thanks, sounds as I suspected, the clean up code is not being called on exit.

BTW, there is only an issue when using in fullscreen. The crash doesn't cause any problems when exiting from a windowed mode.

I will attempt again to compile the bugger. I think I had a odd issue last time that could be a simple library dependency, but wasn't caught by configure. Eh, I shouldn't say anything since I don't recall. I'll post results.

[elyk1212]

Right, now I remember, this was the problem I ran into (even in 1.51). Automake and friends were not producing proper makefiles and I had to edit by hand. It still left me with issues though (I will have to play and let you know what they where, once I fix the mangled makefiles/(makefile dependencies) ):

Code: Select all

/zpng.o > makefile.dep
makefile.dep:85: *** target pattern contains no `%'.  Stop.

line causing the issue:

Code: Select all

jma/iiostrm.o: jmavideo/makev16b.o: video/makev16b.asm macros.mac video/vidmacro.mac

Looks like two make targets jumbled together.

[Nach]

There's something wrong with your shell and/or C lib. Piping is being mishandled in it, there's nothing I can do about that.

[elyk1212]

This branches in to a few different questions.

... it seems you don't have all the dependencies needed for the recompiled ZSNES builds.

1) What dependencies do you think I am lacking, or what made you think of this?

2) What leads you to believe a broken libc or shell is to blame? I ask so I may look into correcting this and testing.

I have many C++ projects I've been working on for some time (academic and otherwise) on this machine, and some using Autotools (although some may be trivially small that use auto tool). As well, I have compiled many large GNU projects, that use Autotools, on this machine. None have presented a makefile issue, or auto dependency generation issue.

Are you doing anything strange with Automake or configure script hacks that would produce a corner case like this that is not present within these other (successfully compiled) projects?

I noticed this makefile.dep error, is not an isolated issue (though is easy enough to fix).

Thanks for your input!

[grinvader]

As well, I have compiled many large GNU projects, that use Autotools, on this machine. None have presented a makefile issue, or auto dependency generation issue.

Are you doing anything strange with Automake or configure script hacks that would produce a corner case like this that is not present within these other (successfully compiled) projects?

We're past simply using autotools. The custom tool we use to spit dependencies out of source files sends a stream that works fine on every platform we tested it on. So far it has this issue with a dozen people in all the linux userbase, so we still think it's a user-setup issue.

You can have a look at src/tools/depbuild.cpp and try to find the issue, we couldn't find any.

[Nach]

This branches in to a few different questions.

... it seems you don't have all the dependencies needed for the recompiled ZSNES builds.

1) What dependencies do you think I am lacking, or what made you think of this?

./zsnes: /usr/lib/libz.so.1: no version information available (required by ./zsnes)

Is it zlib 1.2.3? Since it needs to be that (and not a distro which lies either). There's also the chance that some other lib isn't the right version which it needs to be, since you are getting a pure virtual method error. Hence you should compile it yourself, and not really on a dynamically linked binary.

2) What leads you to believe a broken libc or shell is to blame? I ask so I may look into correcting this and testing.

Look at the command to make makefile.dep, it should be tools/depbuild ... > makefile.dep, if you run it without the "> makefile.dep" part, you'll see the output is fine. Meaning that the redirection of stdout "piping" it to makefile.dep is screwing up the output. Why do you think it's happening? I can't really see a reason in my source why it should happen. My only guess is that some distros somewhere are using a broken implementation of the pipe() function in something. You're free to draw your own conclusions if they cover the facts.