[PATCH 1/2] dxgi/tests: Add test for enumerating display adapters using SetupAPI.

[Zebediah Figura]

On 12/03/2018 12:52 PM, Józef Kucia wrote:
> Signed-off-by: Józef Kucia <jkucia at codeweavers.com>
> ---
> 
> Shows that display adapter LUIDs are stored in SetupAPI device
> properties. It might be useful information to fix LUIDs in Wine.
> We could register display adapters and assign LUIDs to them.
> DXGI, winevulkan and wined3d could retrieve LUIDs using SetupAPI.
> 

Just to sort of continue the discussion here, what are we imagining to 
be responsible for creating display devices (and hence allocating LUIDs)?

These are, as I understand, kernel devices on Windows, which means that 
an application could (in theory) open a device handle with 
SetupDiGetDeviceInstanceId()/SetupDiGetDeviceInterfaceDetail(). I'm not 
aware of any application that does this, unless one of those attached to 
bug 35345 [1] does.

If there's no demand for these actually being kernel devices, we could 
instead just create them in the user driver, though this might lead to 
some complexity if we want DIGCF_PRESENT to actually work.

This is related, IIUC, to the perennial problem of EnumDisplayDevices(), 
which is likely just a thin wrapper around SetupDiEnumDeviceInfo(). 
Alexandre has stated that this should be handled in the explorer.exe 
process, despite objections. [2] These objections wouldn't be helped by 
making it a kernel driver, mind, but I'd also like to push to somehow 
resolve them as well :-)

[1] https://bugs.winehq.org/show_bug.cgi?id=35345
[2] https://www.winehq.org/pipermail/wine-devel/2014-March/103685.html