[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE

http://bugs.winehq.org/show_bug.cgi?id=6971

--- Comment #296 from Paul "TBBle" Hampson   2009-12-08 21:38:31 ---
(In reply to comment #295)
> A basic list of possible approaches:
> XInput2 - not relevant yet.

To whom? Ubuntu's pulled Xorg 7.5 for Lucid, Fedora 12 shipped with Xorg 7.5.
Gentoo has it available, to the best of my limited knowledge. Debian only has
it in experimental, but it's pretty danged close to hitting unstable from what
I've seen.
> DGA Mouse - warp pointer to emulate real mouse movement.

If _I_ was writing the patch, I'd do the XInput 2 version, because it's the
least work in Wine and also cleans up the somewhat messy DInput exclusive-mode
handling, and then see if I could implement a DGA fallback usefully under the
resulting structure. If neither of those was available, I'd suggest Wine just
refuse to provide whatever mode the application is asking for.
> Hidden Mouse - hide real mouse pointer, capture mouse movement and display a
> fake mouse pointer using additional drawing commands before glXSwapBuffers each
> frame (this is okay because cooperative mouse is chiefly used by games which
> continuously refresh the window).

This one sounds like a DInput/WineD3D-specific hack, which relies on certain
features ("capture mouse movement" for example), the lack of which prompted us
to focus on XInput2 in the first place. The key for spotting a hack is the
parenthetical qualification which addresses the chief use only.

What games use co-operative mouse, anyway? I thought co-operative mouse would
generally be used by non-game things that want to read the mouse while
something else is nominally in charge (VoIP software, things like that program
with the cat chasing your mouse cursor around the screen)