[Bug 45917] New: battle.net launcher and mouse position on high DPI monitor

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=45917

            Bug ID: 45917
           Summary: battle.net launcher and mouse position on high DPI
                    monitor
           Product: Wine
           Version: 3.17
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: wine-bugs at winehq.org
          Reporter: kdt3rd at gmail.com
      Distribution: ---

In both wine 3.16 and 3.17, and both vanilla and wine-staging wine, the cursor
/ mouse position is scaled inside the Battle.net launcher application. I
initially thought it was only temporary since it seemed there were a bunch of
changes for correctly passing the DPI in the change sets for 3.16, but it has
persisted, so thought to file a bug.

Basically, when running on a (single) UHD monitor (nvidia graphics card, asus
uhd monitor) where xdpyinfo returns 157 dpi (xdpyinfo|grep resolution gives
157x161 dots per inch), the Battle.net launcher application thinks the mouse is
in the wrong position, meaning to click on a particular button, I need to move
the window such that the button is in the upper left of the screen, or have the
mouse be ~1.5x of the distance from the upper left from where the button
actually is and have mouse still be inside the application (otherwise it
switches focus to the application under the mouse). And even then, the "play"
button is mouse-over highlighted wider than the actual button. When the button
is just in from the top left of the display, it doesn't become active
(mouse-over highlight or clickable) until the mouse is moved more than the
distance from the top left. Which is flat strange, because I haven't resized
the window, just moved, so the upper left of the toplevel app window is still
offset by the same amount from the button. Of course, I don't know if it is
computing position from the upper left of the top window or somehow querying
the global cursor position and comparing that to the perceived global position
of the widgets in the window. Basically, my attempt to naively find what is
being scaled by dpi and what has been missed in that step have failed.

Interestingly, if I do the above to move the window such that I can click the
Play button and then launch a game, the mouse position seems fine when the game
is running and in full screen - Of course, that's a different app, and as it is
fullscreen, I presume because it forces itself to be at 0,0, and probably uses
xrandr to reset the screen coordinates and figures itself out.

If there is any other information that would be helpful, or if someone can
point out code to look at / traces to turn on, I am happy to help.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.