https://bugs.winehq.org/show_bug.cgi?id=51590
Bug ID: 51590 Summary: services:service fails when the KDE taskbar is at the top Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
services.exe:service checks the values returned by GetMonitorInfoA() when called from a service. This test fails on Linux when the desktop environment places the taskbar / dock at the top of the screen. For instance on fg-deb64:
https://test.winehq.org/data/patterns.html#services.exe:service
service.c:422: Test failed: service: Unexpected monitor rcWork values: {0,30,3840,2160}
Here rcWork.top == 30 which is exactly the height of the KDE taskbar.
Notes: * We probably would have a similar failure if the KDE taskbar was placed on the left side because then rcWork.left would probably no longer be zero. * Placing the Windows taskbar at the top or on the left does not cause a failure: in all cases rcMonitor == rcWork == (0, 0, 1024, 768) == full screen size in the TestBot VMs. This probably means the bug is in Wine's GetMonitorInfoA() implementation. * Interestingly user32:monitor does not fail, but then it does not seem to expect left and top to be zero.
https://bugs.winehq.org/show_bug.cgi?id=51590
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
--- Comment #1 from François Gouget fgouget@codeweavers.com --- Bug 43187 describes the rationale behind this test and has two associated commits (a8a2c0b9c587 and f5bb76f69a96).
Also running user32:monitor on Windows when the taskbar is on the top or left side shows that Wine's GetMonitorInfo() implementation is correct:
Windows taskbar on top: monitor.c:1360: primary monitor rcWork=(0,40)-(1024,768)
Windows taskbar on left: monitor.c:1365: work area (62,0)-(1024,768)
So the problem is more that the service is supposed to be non-interactive and thus should not return real work-area information but some default value. It seems like in Wine this is meant to fall into the NULLDRV_DEFAULT_HMONITOR case which returns hardcoded (0,40)-(640,480) values, though on Windows this should still match the real screen size.
https://bugs.winehq.org/show_bug.cgi?id=51590
--- Comment #2 from François Gouget fgouget@codeweavers.com --- The NULLDRV_DEFAULT_HMONITOR issue is probably the cause of the services.exe:service failures on debiant2:
service.c:422: Test failed: service: Unexpected monitor rcMonitor values: {1024,0,2048,735} service.c:422: Test failed: service: Unexpected monitor rcWork values: {1024,0,2048,735} service.c:422: Test failed: service: Unexpected szDevice received: \.\DISPLAY2 service.c:422: Test failed: service: Unexpected secondary monitor info. service.c:422: Test failed: service: Callback got called less or more than once. 2
Again these are real values coming from the multi-monitor configuration, particularly \.\DISPLAY2, when they should instead be some sort of generic values, and like the \.\DISPLAY1 returned in the NULLDRV_DEFAULT_HMONITOR case.
On Windows[1] we always get 1024x768 + WinDisc for dual-screen configurations, even when the monitor sizes are 1280x1024 and 800x600 respectively. This does mean Windows returns fake monitor information (but not 640x480!).
[1] Actually this is true starting with Windows Vista. Windows XP / 2003 returned the real monitor information.
https://bugs.winehq.org/show_bug.cgi?id=51590
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |95be042be3f116db38eb4a255c2 | |667a6b46fcc1e Keywords| |regression
--- Comment #3 from François Gouget fgouget@codeweavers.com --- The failure was introduced in commit 95be042be3f1. Starting with that commit nulldrv_EnumDisplayMonitors() no longer checks the winstation and in particular its WSF_VISIBLE flag.
This is why nulldrv_EnumDisplayMonitors() no longer goes through the fallback code (NULLDRV_DEFAULT_HMONITOR) to return dummy monitor information.
https://bugs.winehq.org/show_bug.cgi?id=51590
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
--- Comment #4 from Zhiyi Zhang zzhang@codeweavers.com --- Thanks for the investigation, François. Should I send a patch or do you already have a fix?
https://bugs.winehq.org/show_bug.cgi?id=51590
--- Comment #5 from François Gouget fgouget@codeweavers.com --- If you can send a patch that would be great.
https://bugs.winehq.org/show_bug.cgi?id=51590
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=51590
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f8ce819ab57b42329b52d18fa29 | |e5a79cfd1abf6 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #6 from Zhiyi Zhang zzhang@codeweavers.com --- Fixed by f8ce819ab57b42329b52d18fa29e5a79cfd1abf6
https://bugs.winehq.org/show_bug.cgi?id=51590
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.16.
https://bugs.winehq.org/show_bug.cgi?id=51590
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=51590
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |---
--- Comment #8 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.3.
-
WineHQ Bugzilla