#359 Jumping mouse control axis when mouse cursor is re-centered at screen boundaries

[Anonymous]

Originally created by: gijsrooy
Originally owned by: gijsrooy

What steps will reproduce the problem?
1. Launch FlightGear as usual.
2. Go to crosshair-mode.
3. Move the mouse all the way to the left or right with the LMB pressed (so you move the rudder).

Also "works" in view-mode.

What is the expected output? What do you see instead?
I used to be able to move my mouse right to the edge of the FlightGear window. These days, the cursor position is "reset" to the center of the window, when I go outside the red-area (see screenshot). Which quickly results in crashes due to sudden maximum rudder/elevator deflection.

What FlightGear version (or GIT date)?
Today's Git and Jenkins win32-intaller #353. Not sure if I had this before we switched to OSG 3.0.0; it might be related to issue 354.

What operating system and graphics card?
Windows Vista

[Anonymous]

Originally posted by: vivian.m...@lineone.net

Yup - reproducible on WinXP/Git. Here the cursor movement has been limited for a while, but I don't remember it jumping back to the centre. However, I might be wrong on both counts.

What is certain is that the cursor movement is disconcerting in View mode, and make it near impossible to fly using the cursor.

[Anonymous]

Originally posted by: grtht... (code.google.com)@gmail.com

yes we have it also with Linux.
Isn't it a good feature ?
Limiting the crosshair on an area is good mainly when we have a large screen definition.

[Anonymous]

Originally posted by: grtht... (code.google.com)@gmail.com

And forgot to say that feature is not new. at least existing 3 months ago.

[Anonymous]

Originally posted by: gijsrooy

No, it is not a "good feature". It makes it impossible to keep an aircraft airborn with the mouse.

Setting priority to high, because we will get a lot of complaints of people being unable to fly, if this isn't fixed before the release.

Labels: Priority-High

[Anonymous]

Originally posted by: lauri.pe... (code.google.com)@gmail.com

Iirc this used to work so that the cursor would not go over screen, but always return to the center. But the "jump" would not cause any deflection on the control surfaces.

Does the jump cause rapid movement in aelerons or elevators too, or is it just with rudder?

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

I'm not seeing "sudden rudder deflection" as reported above. Neither rudder, ailerons, nor elevator is affected when the cursor jumps (on Linux). Maybe a Windows-specific issue.

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

I don't normally use the mouse - but for me it seems to work as expected. Personally, I'd prefer the mouse cursor to be invisible in "mouse control mode" though (which is what it was like in MSFS ;-) ). I don't see why the cursor is displayed in this mode, since the moving cursor icon doesn't provide any useful feedback. Hiding the cursor would also solve the distracting optical effect of a "jumping cursor" - which I think is necessary, to avoid the window/screen size limits from blocking mouse movements.

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Checked git history: the mouse cursor range is limited since at least 2009, when the mouse module was last refactured (border is 1/4 window size) - so it was already part of FG2.0. The range limitation was already present in the previous module, so this feature is probably much older (likely since the beginning of fgfs mouse support).
I can even see reasons for limiting it: some systems (like mine) automatically rotate the desktop to the left/right/up/down when the mouse touches the screen borders. So keeping the cursor away from the borders is a good idea. Also, fgfs would loose keyboard focus with many Window managers, when the mouse cursor left the Window area. Keeping the cursor within the Window's center area should guarantee that this can never happen in "crosshair" mode - even when moving the mouse very fast.

Suggesting to set this to "Wontfix", unless the rudder is indeed moved on Windows platforms when the cursor warps to the center (looking at the code, I doubt it does).

Cc: cumuluni...@gmail.com

[Anonymous]

Originally posted by: gijsrooy

It is a little more complicated than I thought at first. It only happens when the control is not in its maximum position on boundary-hit. You can easily recreat this by:

1. Move your mouse all the way to the left, so the ailerons are full left.
2. Center your mouse (switch to view mode and back to crosshair).
3. Move your mouse all the way to the right. The moment you hit the right-boundary (aileron is ca. centered by then), the mouse will be reset to the center (which is okay), but at the same time the ailerons are set to full-right (that is the "jump").

It also occurs like this on the elevator and rudder.

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

I'm still unable to reproduce it (Linux). Maybe Windows-specific indeed.

[Anonymous]

Originally posted by: cumuluni... (code.google.com)@gmail.com

I can't reproduce what is written im Comment#9 - neither Linux nor Windows.
After step 1. and 2., I observe the mouse-jump to the center but not the immediate full-right deflection of the aileron.
FWIW: This is with osg v2.9.9 on windows.
Maybe OSG 3.0 issue?

[Anonymous]

Originally posted by: gijsrooy

Yeah, I also thought about OSG 3.0. It could be slightly related to issue 354, as I said in comment#1.

Let's see if Fred knows more ;)

Cc: frbo...@gmail.com

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Apparently more (Windows?) users see the "jumping" mouse controls issue that gijs reported, see:
http://www.flightgear.org/forums/viewtopic.php?f=11&t=12772&p=132792#p132788

Remember, this is not about the jumping mouse cursor (jumps to the center, which is normal), but about jumping control axis also.

It'd be ugly to release with mouse control not working reliably. So raising priority - hoping we can somehow reproduce this on Windows after all.

Labels: -Priority-High Priority-Immediate
Status: Accepted

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Summary: Jumping mouse control axis when mouse cursor is re-centered at screen boundaries
Labels: Windows

[Anonymous]

Originally posted by: greenmup... (code.google.com)@gmail.com

When in mouse mode 1, when the cross hair reaches it's boundary, it centers again. This is actually normal. So normally when pulling on the mouse in order to gain altitude, you can continue to pull back smoothly in one gesture as the cross hair returns to the center and is pulled back even more. However in this pre-release, it seems as though when the cross hair returns to center, FG skips/pops up the nose even more, leaving out everything smooth in-between. This goes for all directions with the cross hair. As long as I keep the cross hair within its boundaries, there won't be any jerky movements. I changed the constraint to false in the mice.xml, which fixes the jerky movement issue, but just wondering why the latest version of FG suddenly created this phenomenon.

I tested it out on different planes, and the same effect occurs.  It definitely occurs after you make a sharp bank turn which seems to offset this weird mouse behaviour. 

Using Win 7 64bit, full screen, full rendering except wireframe. 

[Anonymous]

Originally posted by: cumuluni... (code.google.com)@gmail.com

I can reproduce this on Windows XP with current git and osg 3.x but do not have time to look into it this weekend.

Cc: -cumuluni...@gmail.com

[Anonymous]

Originally posted by: aeitsch...@yahoo.de

Indeed with setting "constrained" to false in crosshair-mode fixes the jerky movement.

Can't confirm it right now, but it seems to me that former FG-versions didn't had any boundary. Can someone confirm it?

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

git history shows the mouse "constrained" mode was introduced on "2002-04-09 by david". It's enabled by default ever since. See "fgdata/mice.xml".

Still not seeing an issue on Linux. I think what happened is something about OSG changed for Windows, affecting the mouse event queue or setting the mouse cursor position.

FG "warps" the cursor to the center when it touches the boundary. A comment in the code correctly says that (old) mouse movement events may still be pending in the queue, and that OSG lacks a method to flush events. Instead, all mouse movements are ignored, until the next "frame" is started - a hack assuming that all old movement events should be processed by then. Possibly OSG now reports a frame event earlier somehow.
Finally, FG relies on the mouse pointer being "warped" to the exact position requested. If any kind of offset is added by OSG or OS, e.g. Window origin, then that offset would be detected as a movement.
Both potential issues can be solved easily, but I can't test it. I'll push an experimental patch for the second issue first. I'll need someone to test this then.

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

I have pushed a first experimental patch. May fix the issue - or may not. Patch is only in the fg2.4.0 release branch (not in "next" yet). Anyone who saw the issue, please test the latest Windows build:

http://flightgear.simpits.org:8080/job/Windows-release/lastSuccessfulBuild/artifact/flightgear/projects/VC90/Win32/Release/

Start fgfs with the command-line option
   --log-level=debug
When fgfs is running, open the property browser and configure the property
   /sim/logging/classes
to "input" only (limits debug information). This will provide some debug output whenever the mouse cursor is re-centered.

Let me know if this fixes/changes the issue - and please provide the debug output. Remember, the mouse cursor is supposed to re-center (avoids getting stuck at the window border), but it's not normal for any control axis to jump.

Status: Testing

[Anonymous]

Originally posted by: gijsrooy

Awesome, works here!!!!

I'm unable to launch FlightGear with debug-level, apparently this lappy cannot handle the amount of output... :P

Status: Verified

[Anonymous]

Originally posted by: cumuluni... (code.google.com)@gmail.com

Looks good here, too. Kudo to ThorstenB!

[Anonymous]

Originally posted by: greenmup... (code.google.com)@gmail.com

I feel very incompetent with debugging output so that I can post it here.  I followed instructions and changed my log level to debug, waited awhile, changed the sim/logging/class to input and started flying and tested to see if the mouse reacted the same way as stated above.  Unfortunately it did.  I was watching the console and notice that it said "running main loop".  However there were moments when I would go into a spin and see that something different was written in the console, however since the logging is going supderduper fast, I was not able to see what was written.  Can anyone help me figure out how I can get the debug logging into a file format so that I can look at it later?

[Anonymous]

Originally posted by: gijsrooy

Issue 422 has been merged into this issue.