On 12/03/2018 12:52 PM, Józef Kucia wrote:
Signed-off-by: Józef Kucia jkucia@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