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

Alexandre Julliard julliard at winehq.org
Fri Mar 8 02:03:02 CST 2019


Zhiyi Zhang <zzhang at codeweavers.com> writes:

> 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.

You can use the Mac driver and the X11 driver at the same time for
instance. This can be necessary if you want to run an app remotely.

Also desktop mode requires multiple explorer instances, and presumably
multiple adapters, even with the same driver. Also you can run multiple
X11 explorer sessions connected to different remote displays. You can't
assume that the adapters are limited to the physical adapters of the
local display.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list