(In reply to comment #0)
I just noticed that this bug also occurs when the mousewheel is turned very fast.

Incidentally, I observed similar issues in quake 4. I.e. turning the mouse wheel rapidly would lead to lagging input also involving keyboards strokes not being processed in time anymore.

The configuration I was running is Xorg 1.4.2 (Debian Lenny) with evdev mouse and dga extension disabled in the X server configuration.

Interestingly enough, setting SDL_VIDEO_X11_DGAMOUSE=0 seems to fix that issue - albeit dga already being disabled in the X server config - but unfortunately leads to a different mouse feel i'm not comfortable with.

I can confirm that the issue has been introduced with an Xorg upgrade, likely 1.3 -> 1.4 (can't pinpoint it precisely anymore).

Thanks for that note Raimund.
With xset m 1/2 I get similar behaviour to DGAMOUSE=1 at low speeds when I double the sensitivity ingame.
Unfortunately that screws with your desktop sensitivity and there seems to be some deceleration at high speeds.

Well, actually I start my games on a separate X server, so adjusting mouse accel does no harm to my desktop. I myself use m 1 1 and additionally SDL_VIDEO_X11_MOUSEACCEL="1/1/1". The latter didn't work properly with the libSDL shipped by ID software with q4, but fortunately they included a patch which I applied to a more recent SDL version.

All this taken into account I still feel the mouse behavior is somewhat different. In games like quake so much depends on split second timing, and being used to the "dga mouse" I feel like my skill being halved. Maybe it just needs some time to become accustomed to the X mouse.

Either way, I guess it wouldn't do no harm if this issue got fixed.

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

Typically this would be caused by a program only processing one event at a time.

e.g.
if (SDL_PollEvent(&event))
    HandleEvent(&event);
DrawFrame();

instead of:

while (SDL_PollEvent(&event))
    HandleEvent(&event);
DrawFrame();

Do you have a copy of that patch included with Quake 4?

The games in question handle the SDL events appropriately (see for example q3's HandleEvents in unix/sdl_glimp.c).
I believe the patch Raimund was talking about just included a newer SDL version to fix issues unrelated to this bug.

Hi,

I think SDL is chucking away x mouse motion events when it shouldn't.

... skip to end pass all the things I checked to see the reason.



Perhaps X is sending more events now?

Maximum number of events SDL can have queued is...
#define MAXEVENTS	128

Assuming 30 frames per second...
  30 * 128
  3840 events per second.

However, there's a maximum of 128 events in there... if you don't get an even 30fps then you can handle less events for a given time.


Old max speed mice were at 5,080 count/s.  Newer mice seem to go up to 90,000 counts/s (eg, 500hz mice and higher).

Gaming mice are at the top end of all mice too... so you'd expect them to be very fast.

source of fast mouse info:  http://wikis.jp/interfacedevice/index.php?MaximumSpeed_en

Perhaps increasing MAXEVENTS upwards would help.  Would also be useful for other things putting more events into the queue.



I don't have a fast mouse to test with... I don't see the event queue filling up on my ubuntu 9.04 laptop with a trackpad.  I can get a maximum of 5 mouse motion events per frame moving the trackpad really quickly.

Could be possible it's fixed now... with newer ubuntu(report was from 8.04).



With OSX leopard I only get 1 mouse motion event per frame.  With a different laptop.  

So maybe ubuntu is getting more mouse motion events in, and the game isn't prepared for that?  If it's getting 4/frame and only looking at event 0 instead of event 3, then it might not be the same feel.  Since before it would be looking at event 3(when only one motion event came in, and it picked the last one).  However I checked ioquake, and it just adds the relx and rely together for all the motion events.  So it's doing the right thing.


So it could be a bug with mouse motion handling in SDL of course.


It seems SDL calls XMaskEvent(SDL_Display, PointerMotionMask, xevent); up to 10 times and chucks away events.  However I'm not sure the logic is right in that section.  It seems to check the events away based on the width and height of the window.  I don't see why it's a good idea to do what it does.

So I think that's where the problem is.
SDL_x11_events.c line 364.

Since I was getting up to 4-5 SDL motion events per frame(on ubuntu, not osx), I imagine that those up to 10 X events being chucked away per one SDL event make the difference.

The fix would be to remove that code which chucks away events(untested).


cheers,

Rohan, can you rebuild SDL with this at the top of SDL_x11event.c:
#define DEBUG_XEVENTS
#define DEBUG_MOTION

and let me know what the output is?

Thanks!

I will do so when I get a chance. I am rather busy these days, so it could take some time. Have you tried removing CorePointer from one of your devices to replicate this? Rene's explanation misses out on the fact that once the system is "tumbling", it even slightest mouse movements keep it in that state and it takes a long time to recover (opposed to there being a different mouse behaviour for as long as it moves fast). That "tumbling" behaviour makes it very hard for me to imagine what is happening inside of SDL. I hope someone with more knowledge of its innards can come up with something.

--

So, debug info soon hopefully (unless you don't need it because you can replicate it by removing CorePointer).

Ryan, I'm leaving this one assigned to you.

> With OSX leopard I only get 1 mouse motion event per frame.  With a different
> laptop.  

Fwiw, Mac OS X and Windows set a flag when the mouse moves, so it knows to give you a _single_ mouse-motion event next time you query for events...they do so for exactly this reason. So if you query events once per frame, you'll never get more than one mouse event per frame, no matter how much you move the mouse.

Arguably, this is an x server bug if it is giving you every single mouse event it possibly can. It's bad if SDL is dropping events, since SDL is buffering the events...but things that don't buffer but just handle every event as it comes in will probably see a massive performance hit (could you imagine dragging a 3000x3000 image in Gimp, and having it redraw for each mouse event, when you get 90000 of them a second?

We could just take over the job of the X server, and merge all the mouse events we see in a given query into one, I guess?

--ryan.

Regardless of what we do we should probably bump the maximum number of events in the SDL queue a bit.

The problem with coalescing mouse events is that if you're implementing a drawing program, oh say TuxPaint, then any motion that you miss between frames is lost.  You have to implement some sort of curve-fitting algorithm to do a best guess on what the user was actually doing with the mouse.

If we wanted to be really fancy we could compress events that are along the same line of motion...

If we do compress mouse events, we need to make sure to accumulate relative deltas instead of just deleting old mouse events.

I agree we should up the event queue size (1024 isn't unreasonable, I think), but having looked at the code that Comment #8 pointed out, it _does_ look suspect...except it only runs in the non-DGA case, so it's not the cause of this specific bug.

--ryan.

*** Bug 717 has been marked as a duplicate of this bug. ***

...also, we shouldn't really be screwing with fancy curving and such...other OSes clamp mouse resolution to the efficiency of the app's event polling strategy, so it's not like this is unheard of.

Can those that are seeing this problem try the latest in subversion? svn revision #4889 might fix this, but I can't test it here. Please be sure to try it without setting SDL_VIDEO_X11_DGAMOUSE=0.

--ryan.

(In reply to comment #16)
> Can those that are seeing this problem try the latest in subversion? svn
> revision #4889 might fix this, but I can't test it here. Please be sure to try
> it without setting SDL_VIDEO_X11_DGAMOUSE=0.
> 
> --ryan.

I tried with SDL-1.2 branch revision 4893 and the problems I reported at bug #717 are _not_ fixed.  Upon using the mouse wheel, mouse motion (and other key events) surely are still messed.  They get back to normal eventually but it makes the game unplayable during those moments.

I can't reproduce it here, CorePointer or not.  Can you post your xorg.conf file, and tell us what kind of mouse you have?

Thanks,
--ryan.

(In reply to comment #18)
> I can't reproduce it here, CorePointer or not.  Can you post your xorg.conf
> file, and tell us what kind of mouse you have?
> 
> Thanks,
> --ryan.

The mouse is a very standard PS2 wheel mouse, from a4tech, nothing fancy.
The OS is i686-linux, fedora 9.  Relevant rpm versions:
xorg-x11-server-Xorg-1.5.2-7.fc9.i386
xorg-x11-server-common-1.5.2-7.fc9.i386
xorg-x11-drv-mouse-1.3.0-2.fc9.i386
xorg-x11-drv-evdev-2.0.8-1.fc9.i386
gcc-4.3.0-8.i386
binutils-2.18.50.0.6-7.fc9.i386
yasm-0.6.2-2.fc9.i386
nasm-2.03.01-1.fc9.i386

$ cat xorg.conf
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 1.0  (buildmeister@builder63)  Thu Jun  5 00:10:21 PDT 2008

# Xorg configuration created by pyxf86config

Section "ServerLayout"
    Identifier     "Default Layout"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# keyboard added by rhpxl
    Identifier     "Keyboard0"
    Driver         "kbd"
    Option         "XkbModel" "pc105"
    Option         "XkbLayout" "tr"
EndSection

Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    Option         "NvAGP"  "1"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Videocard0"
    DefaultDepth    24
EndSection

Tell me whatever else you need.

Is there a specific test case that we can use to reproduce this?  All the reports seem very vague.

e.g.
1. Run <game>
2. ???
3. Bug!

(In reply to comment #20)
> Is there a specific test case that we can use to reproduce this?  All the
> reports seem very vague.
> 
> e.g.
> 1. Run <game>
> 2. ???
> 3. Bug!

For me, it is like:

0. Run and go into the game, move your mouse and see it's normal
1. Turn the mouse wheel quickly, up/or down
2. Move your mouse again to see the jerky behavior,
3. and/or press a few keys on the keyboard to see the unresponsiveness/loss of events
4. This I experience with hexen2 (http://uhexen2.sf.net/) or hhexen/hheretic (http://hhexen.sf.net/)

If it would help, I also noticed that mouse wheel actions result in the same behavior in tyrquake (http://disenchant.net/) which does _not_ use SDL but use X directly.

I just tried with hhexen and hexen2 and didn't have those problems.  I suspect it's an X server bug that's fixed with newer releases of X.org.

Just to be sure though, I'm going to install Fedora 9 i386

I just did a fresh install of Fedora 9 i386 with no updates and built hhexen using the latest SDL 1.2 snapshot and it worked perfectly for me... well except for enabling the DGA mouse tweaking the color palette, but I think that's an X server bug.

At this point, the only thing I can think of to do is have someone who's seeing this problem do two things:
1. Print out the values for the mouse events you're getting from SDL
2. Upgrade your X server to XOrg 1.6 or newer

Thanks!

(In reply to comment #23)
> I just did a fresh install of Fedora 9 i386 with no updates and built hhexen
> using the latest SDL 1.2 snapshot and it worked perfectly for me... well except
> for enabling the DGA mouse tweaking the color palette, but I think that's an X

which means that you experienced the problem in dga mode? (forgive my lesser English skills.)

> server bug.
> 
> At this point, the only thing I can think of to do is have someone who's seeing
> this problem do two things:
> 1. Print out the values for the mouse events you're getting from SDL

Well, I did add printf calls in hexen2, like:

--- in_sdl.c~	2007-12-22 21:01:26.000000000 +0200
+++ in_sdl.c	2009-10-01 12:59:46.000000000 +0300
@@ -722,6 +722,7 @@ void IN_SendKeyEvents (void)
 			if (sym > 255)
 				sym = 0;
 			Key_Event (sym, state);
+			printf("key %d (%s)\n", sym, state ? "+" : "-");
 			break;
 
 		case SDL_MOUSEBUTTONDOWN:
@@ -736,10 +737,12 @@ void IN_SendKeyEvents (void)
 				break;
 			}
 			Key_Event(buttonremap[event.button.button - 1], event.button.state == SDL_PRESSED);
+			printf("button %d (%s)\n", event.button.button, (event.button.state == SDL_PRESSED) ? "+" : "-");
 			break;
 
 		case SDL_MOUSEMOTION:
 		//	SDL_GetMouseState (NULL, NULL);
+			printf("mouse motion\n");
 			break;
 
 #if USE_JOYSTICK

.. but the problem is, with the printf calls in, I can not reproduce the problem.  I bound wheel to inventory prev./next; without the printf calls, when I do mouse wheel, every following key press is interpreted as another wheel event as I see the inventory marker on the screen moves to the next (or previous) item.  I don't know how I can be more useful here.


> 2. Upgrade your X server to XOrg 1.6 or newer
> 
> Thanks!

It's me who should be thanking you for looking into this patiently.

--
Ozkan

I'm honestly thinking this is a bug in x.org that has since been fixed...upgrading to Fedora 11 will probably make this problem magically go away.

If we can't make some progress on this bug in the next few days, we're probably going to finish 1.2.14 without this and close the bug as WORKSFORME. I can't think of anything else we can do here, unfortunately.

--ryan.

(In reply to comment #25)
> I'm honestly thinking this is a bug in x.org that has since been
> fixed...upgrading to Fedora 11 will probably make this problem magically go
> away.
> 
> If we can't make some progress on this bug in the next few days, we're probably
> going to finish 1.2.14 without this and close the bug as WORKSFORME. I can't
> think of anything else we can do here, unfortunately.
> 
> --ryan.

I tried on fedora 10 / x86_64 and it seems I can't reproduce the issue. The X server rpm installed is -1.5.3-17.fc10.x86_64 and its changelog is interesting listing a dga specific fix (xserver-1.5.3-dga-crash-fix.patch in the srpm). Anyways, this issue seems erratic for me and may really be due to an X server bug.

--
Ozkan

Great, thank you for the feedback!