[Bug 2593] New: Mouse wheel's WM_MOUSEWHEEL requires screen, not client, coordinates

[Wine Bugs]

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

Summary: Mouse wheel's WM_MOUSEWHEEL requires screen, not client,
                    coordinates
           Product: Wine
           Version: 20041201
          Platform: HP
               URL: http://www.ssontech.com
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-x11driver
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]

The WM_MOUSEWHEEL message is specified to have absolute screen coordinates,
unlike the WM_LBUTTONDOWN etc messages, which are client coordinate system.
x11drv/mouse.c and windows/input.c treat them all identically (client). So
WM_MOUSEWHEEL messages are delivered to the correct window (and appear to work),
but have the wrong coordinates, so programs that use the coordinates to
redistibute the MOUSEWHEEL message (ie to override the focus) wind up delivering
the MOUSEWHEEL messages to grossly incorrect windows, so much so that the mouse
scroll is unusable. The SynthEyes program at www.ssontech.com shows this
clearly, you can find multiple images of the overall screen-wide scroll wheel
mapping within each subwindow, because the MOUSEWHEEL coordinates are being sent
in client coordinates, not screen coordinates.

This problem should be fixable with a slight modification to mouse.c::get_coords
 to allow the client rectangle mapping to be turned off for WM_MOUSEWHEEL. I'm
not entirely sure what the story is with the two mappings in the routine without
running a debugger on it, or I'd propose a patch. (Sorry, no experience to be
able to do this.)

For future note, I think the mapping to client coordinates for the LBUTTONDOWN
etc messages should actually be in windows\input.c::queue_mouse_event with no
mapping in get_coords. The hardware message between the two is intended to
always pass screen coordinates in screen-normalized coordinates, not to be
normalizing the client-coordinate values as is currently done.

But that's a fine point for now, the key point is to fix this bug so SynthEyes
can be run under Linux... tnx.