[PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().

[Ken Thomases]

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