https://bugs.winehq.org/show_bug.cgi?id=37709
Bug ID: 37709 Summary: Qt 5 applications show menus & co. on wrong screen if outside primary screen Product: Wine Version: 1.6.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: matteo@mitalia.net Distribution: ---
Created attachment 50198 --> https://bugs.winehq.org/attachment.cgi?id=50198 If the menu is opened on the primary screen everything works fine
Qt 5 applications under Wine 1.6.2 have problems in positioning menus, the combobox dropdown and other "floating" elements in case of a multiple monitors setup.
In particular, the position of such elements seems to be clamped to the primary screen, as in attached figures.
The problem doesn't show with Qt 4 applications.
You can find a statically-linked demo application here (https://bitbucket.org/mitalia/qt5-wine-menubug/downloads/qt5-wine-menubug.ex...) - it just sports a QMainWindow with two menus and a combobox. Its source is at https://bitbucket.org/mitalia/qt5-wine-menubug/src.
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #1 from Matteo Italia matteo@mitalia.net --- Created attachment 50199 --> https://bugs.winehq.org/attachment.cgi?id=50199 If the menu is opened on another screen, its position is clamped to the primary screen
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #2 from Matteo Italia matteo@mitalia.net --- Created attachment 50200 --> https://bugs.winehq.org/attachment.cgi?id=50200 The same problem shows up in combo boxes
https://bugs.winehq.org/show_bug.cgi?id=37709
Matteo Italia matteo@mitalia.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|user32 |winex11.drv Distribution|--- |Ubuntu
--- Comment #3 from Matteo Italia matteo@mitalia.net --- The problem ultimately comes from wine-X11 implementation of GetMonitorInfo, which stores a hardcoded value (\.\DISPLAY1) in MONITORINFOEX::szDevice for any HMONITOR it is queried about.
Qt uses this string as the key in a map to track the screens, and in case of a duplicated key only the last-seen monitor survives (which in turns explains the symptoms - the menus and combos are moved to stay completely in a screen, but only one screen appears available to Qt).
Wine's broken behavior is still present in master/HEAD, both in winex11.drv and winemac.drv. It's interesting that in winex11.drv/xinerama.c there's already a
/* FIXME: using the same device name for all monitors for now */
and that there's a patch (http://markmail.org/thread/fulg4oa62wrjwtsl) floating around to fix winemac.drv.
Could the fix be as simple as doing something similar to what that patch does (=sprintf to generate correctly numbered names for the various modules)? Or is it necessary to do other modifications (e.g. to CreateDC and other functions that have to parse these names) to correctly support a multi-monitor setup?
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #4 from Matteo Italia matteo@mitalia.net --- Link to new test executable: https://bitbucket.org/mitalia/qt5-wine-menubug/downloads/qt5-wine-menubug.ex... (includes a test call to EnumDisplayMonitors/GetMonitorInfo).
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #5 from Matteo Italia matteo@mitalia.net --- The gdi32-MultiMonitor patch (https://github.com/wine-compholio/wine-staging/tree/master/patches/gdi32-Mul...) does fix the problem. I read that such patch has been rejected because it doesn't fully reproduce Windows behavior, but the current status (one hardcoded monitor name for every display provided by EnumDisplayMonitors) isn't much better and breaks every application using Qt5 out there.
https://bugs.winehq.org/show_bug.cgi?id=37709
Matteo Italia matteo@mitalia.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase Version|1.6.2 |1.7.33 Distribution|Ubuntu |---
https://bugs.winehq.org/show_bug.cgi?id=37709
Matteo Italia matteo@mitalia.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Qt 5 applications show |GetMonitorInfo returns |menus & co. on wrong screen |hardcoded device name, |if outside primary screen |breaking Qt 5 menu/combos | |positioning in multiple | |monitor setup
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #6 from Matteo Italia matteo@mitalia.net --- Here https://qt.gitorious.org/qt/qtbase/source/73a1e8c60d894701f34806cc4b847aa281... Qt assumes that different monitors will have different names. It wouldn't be complicated to patch Qt to detect the "broken names" scenario and avoid relying on the names as unique display IDs, but I'm not sure if they would accept such a patch to cover a remarkably strange corner case. Is there some estimate about the GetMonitorInfo patch above/someone working on it, or I would be better off trying to patch Qt?
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #7 from Matteo Italia matteo@mitalia.net --- This is probably being fixed in Qt (https://bugreports.qt-project.org/browse/QTBUG-43439)
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com --- Well, wine is what needs fixing obviously.
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #9 from Matteo Italia matteo@mitalia.net --- Of course, but the change that wine needs seems to be way more pervasive (we need to touch CreateDC, its name <-> driver mapping, as well as actually returning a DC to a single screen) and a patch has already been rejected. In Qt this is just a very localized change with virtually no downside (use the HMONITOR instead of the name to identify a monitor), so it's plausible that it will be accepted and will fix the most evident problems for Qt applications.
https://bugs.winehq.org/show_bug.cgi?id=37709
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=37709
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED CC| |michael@fds-team.de Ever confirmed|0 |1 Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/gdi32-MultiMon | |itor
https://bugs.winehq.org/show_bug.cgi?id=37709
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=37709
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks,
still present.
Refreshing links since https://gitorious.org went defunct some time ago.
https://bugreports.qt.io/browse/QTBUG-43439 (no inclusion of this Wine-workaround in QT, no activity for two years)
http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/windows/qwin...
Another app suffering from this: x64dbg - an open-source x64/x32 debugger for Windows which uses QT5 for user interface (http://x64dbg.com/)
$ wine --version wine-2.7
Regards
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #11 from Matteo Italia matteo@mitalia.net --- Currently for the applications of my employer I apply my patch to Qt before building them; as you can see I tried to upstream it, but after wasting a week or so changing it according to upstream's desires, it was thrown away because they already branched for that release. At that point I just gave up, I have better things to do other than setting up Gerrit accounts and recompiling yet another version of Qt for a 5 lines patch.
https://bugs.winehq.org/show_bug.cgi?id=37709
Sam Hanes sam@maltera.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sam@maltera.com
https://bugs.winehq.org/show_bug.cgi?id=37709
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/blob/mast |ster/patches/gdi32-MultiMon |er/patches/gdi32-MultiMonit |itor |or/0002-winex11-Make-GetMon | |itorInfo-give-a-different-d | |evice-.patch Summary|GetMonitorInfo returns |All Qt5 based applications |hardcoded device name, |have broken menu/combos |breaking Qt 5 menu/combos |positioning in multiple |positioning in multiple |monitor setup due to |monitor setup |GetMonitorInfo() returning | |the same hard-coded device | |name for all monitors URL| |http://x64dbg.com/
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello folks,
refining summary again and refreshing link to Wine-Staging patchset. Only refer to relevant patch for this ticket. Obviously still present and reproducible with any Qt 5.x application.
$ wine --version wine-3.5
Regards
https://bugs.winehq.org/show_bug.cgi?id=37709
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ostefanog@hotmail.com
--- Comment #13 from Anastasius Focht focht@gmx.net --- *** Bug 44937 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #14 from Stefano ostefanog@hotmail.com --- Does the patch in staging also apply to wine on OSX when using the quartz (no X11) driver?
https://bugs.winehq.org/show_bug.cgi?id=37709
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-sta |https://github.com/wine-sta |ging/wine-staging/blob/mast |ging/wine-staging/tree/mast |er/patches/gdi32-MultiMonit |er/patches/gdi32-MultiMonit |or/0002-winex11-Make-GetMon |or |itorInfo-give-a-different-d | |evice-.patch |
--- Comment #15 from Ken Thomases ken@codeweavers.com --- (In reply to Stefano from comment #14)
Does the patch in staging also apply to wine on OSX when using the quartz (no X11) driver?
I've changed the staging link to the whole patchset, which does include the fix for the Mac driver.
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #16 from Stefano ostefanog@hotmail.com --- (In reply to Ken Thomases from comment #15)
(In reply to Stefano from comment #14)
Does the patch in staging also apply to wine on OSX when using the quartz (no X11) driver?
I've changed the staging link to the whole patchset, which does include the fix for the Mac driver.
Thanks! Any chance the changeset will be merged, or is there anyway I can help to make it happen?
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #17 from Ken Thomases ken@codeweavers.com --- (In reply to Stefano from comment #16)
Any chance the changeset will be merged, or is there anyway I can help to make it happen?
Not in anything like its current form, no. Alexandre wants a different approach.
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #18 from Stefano ostefanog@hotmail.com --- (In reply to Ken Thomases from comment #17)
(In reply to Stefano from comment #16)
Any chance the changeset will be merged, or is there anyway I can help to make it happen?
Not in anything like its current form, no. Alexandre wants a different approach.
I see. Can you point to me the conversation you are referencing to?
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #19 from Ken Thomases ken@codeweavers.com --- (In reply to Stefano from comment #18)
(In reply to Ken Thomases from comment #17)
(In reply to Stefano from comment #16)
Any chance the changeset will be merged, or is there anyway I can help to make it happen?
Not in anything like its current form, no. Alexandre wants a different approach.
I see. Can you point to me the conversation you are referencing to?
https://www.winehq.org/pipermail/wine-devel/2014-March/103680.html
https://bugs.winehq.org/show_bug.cgi?id=37709
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #20 from Anastasius Focht focht@gmx.net --- Hello folks,
revisiting, still present. Very annoying because it affects a lot of apps.
Another one for testing: easyHDR 3.13.0
https://web.archive.org/web/20190518075044/https://www.easyhdr.com/download/...
$ sha1sum easyHDR_3130_setup-demo.exe 2002238e64859a290abdd523cb0755262ffa8e4e easyHDR_3130_setup-demo.exe
$ du -sh easyHDR_3130_setup-demo.exe 34M easyHDR_3130_setup-demo.exe
$ wine --version wine-4.8-202-g61aea5a987
Regards
https://bugs.winehq.org/show_bug.cgi?id=37709
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|STAGED |RESOLVED Fixed by SHA1| |23b28323cb904bc9823f422ac21 | |aa499690c4e21
--- Comment #21 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Fixed by https://source.winehq.org/git/wine.git/?a=commit;h=23b28323cb904bc9823f422ac...
https://bugs.winehq.org/show_bug.cgi?id=37709
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.12.
https://bugs.winehq.org/show_bug.cgi?id=37709
--- Comment #23 from Stefano ostefanog@hotmail.com --- This does not seem to be fixed in 4.14 on OSX (using the mac driver). The issue is still there. Should this be reopened?