[Bug 45917] New: battle.net launcher and mouse position on high DPI monitor
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(a)winehq.org Reporter: kdt3rd(a)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.
https://bugs.winehq.org/show_bug.cgi?id=45917 zzzzzyzz(a)hacari.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz(a)hacari.org -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 lukas.schneiderbauer(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lukas.schneiderbauer(a)gmail. | |com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 --- Comment #1 from Kimball <kdt3rd(a)gmail.com> --- further update: If I regedit and change HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels from 161 (correct value for my monitor) to 96, then the UI interaction in the battle.net UI is correct, and I can click on the buttons without having to move the buttons to the 0,0 upper left corner of the monitor. This however makes the fonts and such incredibly tiny and unusable on things like regedit and winecfg. Which points to a missing scale somewhere in the code recently added in the previous few releases. In running with WINEDEBUG=-all,+win,+cursor, I notice the following pattern when moving the mouse around in the Battle.net app: 002b:trace:cursor:X11DRV_GetCursorPos pointer at (475,617) server pos (475,617) 002b:trace:win:GetWindowRect hwnd 0x600d6 (10,10)-(1167,666) 002b:trace:win:WINPOS_WindowFromPoint scope 0x600d6 (283,368) returning 0x600d6 002b:trace:win:TrackMouseEventProc point (283,368) hwnd 0x600d6 hittest 1 002b:trace:win:TrackMouseEventProc tracked pos (374,394), current pos (283,368), hover width 4, hover height 4 002b:trace:win:TrackMouseEventProc hwnd 0x600d6, msg 0118, id 7e93b844, time 218513192 0 when looking at the code for WindowFromPoint, I notice that it ends up calling point_thread_to_win_dpi, which then calls GetDpiForWindow, which then ends up calling either get_monitor_dpi or get_win_monitor_dpi based on which window is being queried. However, both of those have FIXME in them, and additionally, none of that code seems to pay attention to the DpiAwareness bits. So I presume this is just a missing segment of the DPI awareness implementation. I unfortunately don't know enough of how this is all intended to work to be able to propose a solution, although at first glance, it seems like changing the calls to get_monitor_dpi and get_win_monitor_dpi in GetDpiForWindow to using get_thread_dpi instead may work (although not sure what to do about get_win_monitor_dpi)? I will keep poking at it and see if I can figure out what it is all about, unless someone can pipe in and say "this is what it should be". -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 --- Comment #2 from lukas.schneiderbauer(a)gmail.com --- I can confirm this problem for wine 3.18 and 3.19. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 --- Comment #3 from Kimball <kdt3rd(a)gmail.com> --- So I have traced it somewhat more. It's definitely an issue with the fact that battle.net seems to set the process DPI awareness via SetProcessDpiAwarenessInternal / SetProcessDpiAwarenessContext / SetProcessDPIAware, setting it to "unaware" level awareness. This can be easily replicated by changing something such as regedit to call SetProcessDpiAwarenessContext( DPI_AWARENESS_CONTEXT_UNAWARE ) at the start of winmain. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |d3ca7db42e207e4f646865c39f4 | |7c987a8ac161a Resolution|--- |FIXED --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> --- Hopefully fixed by d3ca7db42e207e4f646865c39f47c987a8ac161a. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 --- Comment #5 from Kimball <kdt3rd(a)gmail.com> --- Yes, this changes fixes the behavior, see my email on wine-devel if you want more debugging info. thanks. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adwinebug(a)adrn.no-spam-allo | |wed.com --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- *** Bug 45776 has been marked as a duplicate of this bug. *** -- 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.
https://bugs.winehq.org/show_bug.cgi?id=45917 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 4.0-rc5. -- 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.
participants (1)
-
wine-bugs＠winehq.org