Re: [PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().
Ken Thomases <ken(a)codeweavers.com> writes:
For <http://bugs.winehq.org/show_bug.cgi?id=34978>. --- dlls/user32/misc.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 84 insertions(+), 12 deletions(-)
I think it should be the other way around, with EnumDisplayDevices being the main function, with some sort of centralized management of display devices. -- Alexandre Julliard julliard(a)winehq.org
On Mar 28, 2014, at 10:58 AM, Alexandre Julliard wrote:
I think it should be the other way around, with EnumDisplayDevices being the main function, with some sort of centralized management of display devices.
EnumDisplayMonitors() + GetMonitorInfo() provides the information necessary to implement EnumDisplayDevices(), but not vice versa. Can you elaborate on what you envision? What management do you want centralized, besides the enumeration and querying of properties represented by those three functions? Do you also mean enumerating and changing display settings/modes? Would the centralized management be in the wineserver? In user32? In the graphics driver? It's easy enough to imagine adding a new driver entry point for EnumDisplayDevices(), alongside EnumDisplayMonitors() and GetMonitorInfo(), if you'd prefer that it be implemented directly in the graphics driver like the others. That could be more efficient and less kludgy, although entails more code duplication between the drivers. Alternatively, I can envision a new hybrid entry point, something such as: BOOL EnumDisplayMonitorInfo(DWORD devnum, MONITORINFOEX *info); Like EnumDisplayDevices(), this takes a device ordinal and returns FALSE when there are no more devices. User32 could take responsibility for mapping between such ordinals and HMONITORs. Given that mapping, this entry point is obviously sufficient to implement GetMonitorInfo(). User32 could implement EnumDisplayMonitors() as a loop around that, doing the clip rect testing. And EnumDisplayDevices() could also be implemented in terms of this entry point, filling in the DISPLAY_DEVICE from the monitor info. It would be like the implementation in my patch except it wouldn't entail extraneous looping to get to the requested device. I know you don't like entry points that aren't direct analogs for Win32 functions, though. I suspect that neither of these is what you're looking for. If not, then I need a push in the right direction. One note: I think that the graphics driver needs to be aware of the mapping between device names (e.g. "\\.\DISPLAY2") and whatever it uses internally to identify specific displays. I envision the driver needing to look up the display of a DC. So, I've been planning on making the CreateDC() entry point look up the display from the device name and record it in the *_PDEVICE structure. -Ken
Ken Thomases <ken(a)codeweavers.com> writes:
On Mar 28, 2014, at 10:58 AM, Alexandre Julliard wrote:
I think it should be the other way around, with EnumDisplayDevices being the main function, with some sort of centralized management of display devices.
EnumDisplayMonitors() + GetMonitorInfo() provides the information necessary to implement EnumDisplayDevices(), but not vice versa.
Can you elaborate on what you envision? What management do you want centralized, besides the enumeration and querying of properties represented by those three functions? Do you also mean enumerating and changing display settings/modes? Would the centralized management be in the wineserver? In user32? In the graphics driver?
Yes, display settings/modes, adding/removing monitors, managing work area, restoring resolution on process exit, etc. There would be parts in user32, parts in the driver, but it should all run in the context of the explorer process. Normal processes should retrieve the info from explorer instead of using graphics driver calls. -- Alexandre Julliard julliard(a)winehq.org
On Mar 31, 2014, at 5:20 AM, Alexandre Julliard wrote:
Yes, display settings/modes, adding/removing monitors, managing work area, restoring resolution on process exit, etc. There would be parts in user32, parts in the driver, but it should all run in the context of the explorer process. Normal processes should retrieve the info from explorer instead of using graphics driver calls.
That can't work with the Mac driver. In order to be a good citizen, the Mac driver captures the display before changing the display mode. As a consequence, only the process which actually changed the mode can display anything until the mode is reset. Furthermore, the reason for capturing the display is to prevent other processes from receiving notification that the desktop has changed size, so they don't re-layout their windows or, in the case of the Finder, desktop icons. So, it's not even possible for the explorer to observe the change without the process that made the change telling it directly. I'm not certain, but I suspect that what you suggest also doesn't match what Direct3D does on Windows. My impression is that when an app uses D3D to enter exclusive full-screen mode, that other apps aren't informed about the mode change. (If I'm right, then Wine behaves incorrectly currently.) -Ken
On Mar 31, 2014, at 1:38 PM, Ken Thomases wrote:
I'm not certain, but I suspect that what you suggest also doesn't match what Direct3D does on Windows. My impression is that when an app uses D3D to enter exclusive full-screen mode, that other apps aren't informed about the mode change. (If I'm right, then Wine behaves incorrectly currently.)
I was wrong about this part. I ran Guild Wars in full-screen mode and a test program did receive WM_DISPLAYCHANGE and saw the new values for monitor rects, etc. -Ken
participants (2)
-
Alexandre Julliard -
Ken Thomases