[PATCH v2 1/7] explorer: Create primary adapter key if user driver didn't create it.

Zhiyi Zhang zzhang at codeweavers.com
Thu Mar 7 21:10:49 CST 2019


On 08/03/2019 10:42, Zhiyi Zhang wrote:
> On 08/03/2019 02:11, Alexandre Julliard wrote:
>> Zhiyi Zhang <zzhang at codeweavers.com> writes:
>>
>>> This primary adapter key aims to replace the Atom mechanism currently
>>> used to store what registry key the primary adapter is using.
>>> This way we can let user drivers create the GUIDs for adapters if it's
>>> supported without treating primary adapter differently.
>>>
>>> Signed-off-by: Zhiyi Zhang <zzhang at codeweavers.com>
>> How is this going to handle multiple explorer processes, potentially
>> using different drivers?
>>
> I did assume explorer are all using the same driver when running on a platform.
>
> Could you give some examples on why using different drivers with multiple explorer is necessary?
>
> If we insist on running different user display drivers at the same time, there will be conflicts on the registry,
> making it difficult to get a coherent view of the registry, say when enumerating adapters via SetupAPI.
>
> If it's for other reasons. I think we can still keep the current graphics driver in explorer hwnd. Most of the
> time other code query the explorer hwnd just for which graphics driver is used. They don't really need the
> adapter key.
I should have mentioned this earlier. I put a repo at https://github.com/zzhiyi/wine/commits/user32/EnumDisplayDevices.

It should give some context regarding recent graphics driver changes. Comments are very appreciated.




More information about the wine-devel mailing list