[PATCH 2/9] winemac.drv: EnumDisplayDevices placeholder implementation

[Ken Thomases]

Hi,

Thanks for taking this up again…

On Apr 24, 2017, at 3:48 PM, Donat Enikeev <donat at enikeev.net> wrote:
> 
> Based on Ken Thomases <ken at codeweavers.com> staging patches
> 
> Signed-off-by: Donat Enikeev <donat at enikeev.net>
> ---
> dlls/winemac.drv/display.c        | 51 +++++++++++++++++++++++++++++++++++++++
> dlls/winemac.drv/winemac.drv.spec |  1 +
> 2 files changed, 52 insertions(+)

This doesn't build:

display.c:1007:13: error: use of undeclared identifier 'monitors'
        if (monitors[iDevNum].dwFlags & MONITORINFOF_PRIMARY)
            ^
display.c:1010:80: error: use of undeclared identifier 'monitors'
        memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice));
                                                                               ^
display.c:1010:45: error: use of undeclared identifier 'monitors'
        memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice));
                                            ^

Is this patch written on the assumption that some other staging patches have already been applied?


Beyond that, can you explain the rationale of moving the implementation of EnumDisplayDevices to the drivers?  My patches implemented it in user32 based on EnumDisplayMonitors() and GetMonitorInfoW().  It may be somewhat clunky, but has the advantage that it ensures all three functions return mutually consistent results.  Since you appear to have dropped my patches which caused GetMonitorInfoW() to return unique names for the displays, they are no longer consistent.  GetMonitorInfoW() always uses "\\.\DISPLAY1" for all monitors while this implementation of EnumDisplayDevices() attempts to use "\\.\DISPLAY2", etc., for secondary and subsequent monitors.

For what it's worth, my original patches were rejected because Alexandre wanted the tracking and management of displays and display modes centralized in the explorer process[1].  I have my reservations about that approach, mind you. ;)
[1] https://www.winehq.org/pipermail/wine-devel/2014-March/103680.html


Issues with other patches in the series:

Patch 1: \ No newline at end of file

Patches 1 and 2 ought to come after 3.  In the current order, they introduce dead code.

-Ken