SDL_MOUSEMOTION bug?

Hello to all, I jst finished to port my tiny 3d game under Linux. Here I
found some very strange problems wich I couldn’t solve yet.
I use SDL 1.2.11 under Linux SUSE 10.0 on Acer Aspire 3020 Laptop,
RadeonX700:
When the application starts if the mouse is hidden and happens to be over
the window then the xrel/yrel contain actually the absolute and not the
relative position of the mouse. If I start the application so that the mouse
happens to be outside of the window or the mouse is not hidden the problem
disappears. So the two condition must be met: mouse hidden + grab mouse
while the pointer is in the window.

Also I found in the documentation that:
“If the cursor is hidden (SDL_ShowCursor(0)) and the input is grabbed
(SDL_WM_GrabInput(SDL_GRAB_ON)), then the mouse will give relative motion
events even when the cursor reaches the edge of the screen. This is
currently only implemented on Windows and Linux/Unix-alikes.” ( see
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fMouseMotionEvent )

Actually what happens, at least with my system, is that the documented
behaviour is valid only on Windows and not on Linux where the xrel and yrel
are clipped to zero. (by the way on windows if you move fast enough the
mouse outside of the window it looses the grab… )

My question is: does anybody ever experienced the same problem? am I missing
something? its really a bug? its a feature? its something connected to my X
server? …

Here comes a little program I did to replicate the same behaviour in a
scientific way :smiley:
You can see that the behaviour always appears when the mouse is grabbed
meanwhile being in the window area AND its hidden.
As you can see from the program: s/h = show/hide the mouse, g/u =
grab/ungrab the mouse, any other key exits.
Notice that during the “strange” behaviour the absolute mouse position are
blocked for some reason to the maximum window’s-client-area value (even if
the mouse is actually moving…)
Well at least this is valid with my system… this is why I would like any
body to try it out…

// --------------------- starts weird.c -------------------------------
#include <SDL.h>

int main() {
if ( SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO) < 0 ) {
printf(“Unable to init SDL: %s\n”, SDL_GetError());
exit(1);
}

SDL_Surface * screen = SDL_SetVideoMode(400, 400,
SDL_GetVideoInfo()->vfmt->BitsPerPixel, 0 );

SDL_WM_GrabInput(SDL_GRAB_ON);
SDL_ShowCursor(0);

int gameover = 0;
while(!gameover) {
SDL_Event ev;
SDL_PumpEvents();
while ( SDL_PollEvent(&ev) ) {
switch (ev.type) {
case SDL_KEYDOWN:
if (ev.key.keysym.sym == SDLK_g) {
SDL_WM_GrabInput(SDL_GRAB_ON);
} else
if (ev.key.keysym.sym == SDLK_u)
SDL_WM_GrabInput(SDL_GRAB_OFF);
else
if (ev.key.keysym.sym == SDLK_h) {
SDL_ShowCursor(0);
} else
if (ev.key.keysym.sym == SDLK_s)
SDL_ShowCursor(1);
else
gameover = 1;
break;

		case SDL_MOUSEMOTION:
			printf("MOUSE MOTION abs=%d %d, rel=%d %d\n", ev.motion.x, ev.motion.y,

ev.motion.xrel, ev.motion.yrel);
break;
}
}
}

SDL_Quit();
return 0;
}
// --------------------- ends weird.c -------------------------------

I compile this way:
gcc -o weird.exe weird.c sdl-config --cflags sdl-config --libs -Wall -g

Thanks
Michele Bosi–
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Refill s.r.l. - Cartucce compatibili e kit di ricarica per tutti i modelli
di stampante. Acquista al telefono o online: consegna in tutta Italia in 48
ore!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5190&d=20061017

When the application starts if the mouse is hidden and happens to be over
the window then the xrel/yrel contain actually the absolute and not the
relative position of the mouse. If I start the application so that the mouse
happens to be outside of the window or the mouse is not hidden the problem
disappears. So the two condition must be met: mouse hidden + grab mouse
while the pointer is in the window.

Actually, it doesn’t appear to be the grab itself…if I remove the
calls to SDL_ShowCursor() and SDL_WM_GrabInput(), it still gives the
bogus motion event, if the cursor is in the area where the window gets
created.

This is a bug in SDL, but the quickest fix is to add this to your code,
right after SDL_SetVideoMode()…

{ SDL_Event e; while (SDL_PollEvent(&e)) {} }

…which will flush any existing events before your program really gets
started. A proper fix would probably do something similar at the end of
SDL_SetVideoMode() inside SDL itself.

This is in the bug tracker now:
http://bugzilla.libsdl.org/show_bug.cgi?id=347

…and also related:
http://bugzilla.libsdl.org/show_bug.cgi?id=348

–ryan.

Thanx very much Ryan! :smiley:
I noticed the bugus mouse motion event but didn’t consider it a bug since it
was easily avoidable in the way you showed. I only wanted to point out that
the bug 348 mentions the “clipping” problem, that is the mouse doesn’t give
"endless" mousemove events when the input is gabbed, but doesn’t mention the
fact that xrel/yrel report not the relative but the absolute mouse position
under the condition reported in my original mail. So if am not wrong the
bugs in the end are 3: the bogus mouse motion event (also on windows), the
non endless mousemotion event when grabbing & hidden (not on windows), and
the absolute values in xrel/yrel under the conditions described in my
previous mail (not on windows). Probably they are all related, but I don’t
know X11 well enough to check the sdl source myself. What do you think?

Thanx in advance.
Michele–
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Video-Corsi.com : Vuoi scoprire un modo rapido e veloce per imparare?
Scopri i nostri VideoCorsi professionali
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5141&d=20061018