Noted other events e.g. from trackpads change event->x/y as well, but can't check atm, will do that later.

A few issues:

• The mouse cursor is drawn for the top (or left) eye only. That leads to a ghost/blinking cursor when viewing in a stereo display
• Shift + F (camera navigation) is no longer working

Re: cursor is drawn for the top (or left) eye only:
This doesn't change the cursor drawing it only changes the coords used for handling. If you move the cursor to the bottom half e.g. it is still in the bottom half. Also note that this patch works for both halves of the screen, so the handling always matches what the user sees, regardless of which half of the screen he is in (should really make comments in wm_stereo3d_mouse_offset_apply more clear :S)

However, I'm afraid that fixing the blinking cursor isn't that easy. Googled a bit but seems like cursor drawing is low level OS code which we can't influence (except of disabling it completely/changing appearance). Maybe this is just a limitation we have to live with :| (although we could do crazy things like using a custom cursor set that we can draw a second time, but don't think that's a good solution either)

Re: Camera navigation no longer working
Good catch, yeah. For such cases I had the idea of adding event->save_xy values which would always be the real mouse coordinates, so we can access them for corner cases like that one (would also make it possible to fix the WM_cursor_grab_disable issue described below)

PS: Not easy to describe these things, hope you get what I mean :D

The 'software' cursor would be the correct way to go indeed. But it may be too much work, and maybe your patch can provide a bad provisory solution.

Just to illustrate the issue with your approach:
Right now, not only the cursor shows only for one eye, but it will be perceived as twice as big as it should be.

Well even if we had a software cursor, the interface handling would still be done using window space mouse coordinates so we still had the same offset we have now if I'm not missing something. If we had a complete software cursor pipeline where we were able to offset the cursor drawing position, we'd have jumping cursors while entering/exiting the Blender window, entering/exiting multiview, etc - changing the cursor position without user input is really bad UX wise and should definitely be avoided. Instead, just a second cursor in the other window half should appear.

All proper fixes I can think of would consist out of two parts:

• The drawing part (draw cursor with half size and draw 2 ones)
• The handling part (converting events from window space to multiview space)

Whereby the second part is tackled with this patch. I agree that this isn't the solution for all problems, but think it is the first part of it.

@Dalai Felinto (dfelinto), what's your current opinion on this, still think it's okay as a fix.

@Julian Eisel (Severin) alright, but how about having a patch with the drawing part too? Is this something you plan to tackle eventually?

Changes in event system are always a bit risky, even if this patch shouldn't touch non-multiview mode. Will commit after release, just to be safe.