A mouse pointer keeps reappearing during video playback in smplayer

Have you checked if this bug is present in version 0.6.8?

https://launchpad.net/~rvm/+archive/smplayer

@rvm
I've checked Your version, behaviour is the same.

I can confirm this with some additional details:
- the mouse pointer behaves like this also on the "black borders", if the option is turned on in smplayer
- if you launch smplayer, open a movie, and then do not touch the mouse after it starts playing, the pointer behaves normally. Once the mouse pointer is moved, the mouse pointer keeps popping up every every 30 secs or so while smplayer is running.
- in Jaunty the bug was not present.
it is version 0.6.8 as well as the one in the Karmic repos.

If the problem is not present in jaunty, I guess the problem may be caused by the new version of Qt in karmic.

I'll try to install karmic on a virtual machine and see if I can fix the issue.

I've just installed karmin on a virtual machine. I was able to reproduce the problem.

At first sight it seems a bug in Qt, sometimes QCursor::pos() returns a different position of the mouse cursor even if it didn't move.

Ok, I think I found out where the problem is. It seems it's related to the option to disable the screensaver.

If you turn off the option "Disable screensaver" (under Preferences->General->Video) the problem doesn't happen.

When that option is on, smplayer passes to mplayer the option -stop-xscreensaver, and I guess mplayer moves the mouse cursor from time to time to avoid the screensaver to turn on. And smplayer detects that move and shows the cursor...

This actually seems to be a bug in the karmic package of mplayer. I guess that package is patched to support the gnome screensaver. The problem doesn't happen with my own build of mplayer that you can find here:
https://launchpad.net/~rvm/+archive/mplayer

So summing up, this is not a bug in smplayer.

The fault here lies with mplayer, specifically 22disable-xscreensaver.patch

https://code.launchpad.net/~ubuntu-branches/ubuntu/karmic/mplayer/karmic

revision 54 the patch was turned off
revision 56 it was turned back on

Affects me also. Not only that the mouse appears and disappears, but it also changes location to left and right a bit, so it doesn't help if I move the mouse to the edge of the screen because it keeps popping up left/right nevertheless.

It seems it doesn't happen if you don't move the mouse after going to fullscreen. Once you move it, you need to go off and back on to fullscreen if you want to stop it popping up every 7-8 seconds.

Has someone noticed/reported other bugs about SMPlayer on Karmic about playback? It often refuses to play after pausing (you need to stop the file and press play again) and with me playback with sound muted isn't possible at all.

"Has someone noticed/reported other bugs about SMPlayer on Karmic about playback? It often refuses to play after pausing (you need to stop the file and press play again) and with me playback with sound muted isn't possible at all."

I had the same problem, setting the audio output driver from alsa to pulse fixed it.

Quote: "It seems it doesn't happen if you don't move the mouse after going to fullscreen. Once you move it, you need to go off and back on to fullscreen if you want to stop it popping up every 7-8 seconds."

I was wrong, it still happens. Only unchecking 'Disable screensaver' stops it, but then, but then screensaver appears on set time.

@Mr. Blonde: Thank you! That fixed it.

Thankyou Mr. Blonde, solved it for me too.

Still having the problem with the mouse appearing though.

I can confirm #9. It actually does not happen if the mouse it not noved after the transition to full-screen.

setting the audio output driver from alsa to pulse fixed it for me too

@Søren Holm
I cannot confirm that.

P.S. I use pure ALSA output.
P.S.2. Pure ALSA doesn't mean ALSA through PulseAudio.

You are right Michael. It's does not work.

Anyway disabling "Screensaver disable" fixes it. But then the screensaver kicks in aafter a while ;(

It is not even fixed in 0.6.9 :(

I guess smplayer is the bad guy. OR at least smplayer makes mplayer behave bad.

Forgot to specify that mplayer does not make the cursor reappear, thus the change of "affects"

As stated in previous posts, the problem is caused by a ubuntu patch in the mplayer package. That patch tries to avoid the screensaver to turn on by moving the mouse cursor from time to time. smplayer receives that mouse event and shows the cursor because it thinks it has been moved by the user.

Yeah I saw that, but it does not seem like mplayer by itself makes the cursor appear. Maybe default is to *not* to disable screensave in mplayer, or maybe mplayer does not show the cursor during very small movements.

I don't get it. Shouldn't the original, unpatched mplayer behave correctly with the -stop-xscreensaver switch?

I read all 21 comments and neither I'm sure who is the culprit nor what is the remedy...
Disabling -stop-screensaver is obviously not useful.

The -stop-screensaver option may not work. According to the mplayer manpage, it's a problem of the screensavers:

       -stop-xscreensaver (X11 only)
              Turns off xscreensaver at startup and turns it on again on exit.
              If your screensaver supports neither the XSS nor XResetScreen-
              Saver API please use -heartbeat-cmd instead.

       -heartbeat-cmd
              Command that is executed every 30 seconds during playback via
              system() - i.e. using the shell.

              NOTE: MPlayer uses this command without any checking, it is your
              responsibility to ensure it does not cause security problems
              (e.g. make sure to use full paths if "." is in your path like on
              Windows). It also only works when playing video (i.e. not with
              -novideo but works with -vo null).

              This can be "misused" to disable screensavers that do not sup-
              port the proper X API (also see -stop-xscreensaver). If you
              think this is too complicated, ask the author of the screensaver
              program to support the proper X APIs.

IMO the ubuntu developers should try to fix the screensavers instead of trying to "fix" mplayer.

OK, then the bug is definitely in mplayer - it is obviously not smplayer's role to hack mplayer's hacks. The bug should return to mplayer package then.

(it would be nice if some Ubuntu dev at least looked at it...)

this bug is very related to #505149. In short, we ship a patch to mplayer that disables the screensaver by moving the mouse a bit every few seconds. This patch (not upstream of course) is causing this side effect.

The activity on this bug looks as if the bug in gnome-screensaver, which is surely at the root of this mess, has been resolved: https://bugs.edge.launchpad.net/ubuntu/+source/vlc/+bug/428884

Might we not adopt the way VLC inhibits gnome-screensaver? Also, isn't calling "xdg-screensaver" the way to go here?

I can confirm this bug on new Ubuntu 10.04 LL (amd64)

Move the cursor to the upper left corner and leave it there. That works for me.

well i've found a little better workaround for this

go to preferences -> interface -> floating control then set Margin value to 1

now you can move the cursor to the lower right corner instead and it wont bother you at all

@#29:
Nice trick!

@rvm:
Even if this is a distro patch which triggers this ghost moving of the cursor, you mention twice that "smplayer receives the mouse event and shows the cursor". Specifically, that the patch causes the mouse event to be sent to smplayer, but that smplayer has the decision to show the cursor or not. Might it be a good idea to set a threshold on mouse movement before deciding to show the cursor then? This would also help people with sensitive mouses which see the cursor appear as a result of the impact on the mouse from loud bass from loudspeakers, vibrations in the computer table, etc.

Basically a "fix" with an improvement added on for free? I know from experience that when I grab the mouse or finger the pad to get at controls, I move the mouse a lot, like at least half the screen. A threshold on how much movement would be required to trigger the display of the cursor seems a good idea in any case, and is standard behavior on many other players.

Just an idea. Which I hope you'll like, cause this problem is a showstopper for me, even if it isn't your doing ;)