[PATCH v7 1/7] winex11.drv: Add Xinerama display device handler.

[Zhiyi Zhang]

On 5/29/19 7:26 PM, Huw Davies wrote:
> On Wed, May 29, 2019 at 07:12:31PM +0800, Zhiyi Zhang wrote:
>> On 5/29/19 6:31 PM, Huw Davies wrote:
>>> What's going to happen with two seats running on the same
>>> wineserver?
>> What do you mean by "two seats"? do you mean processes?
> No, two sessions.  e.g. a local user and that same user sshing in
> from a remote X server.  To make things interesting, the local
> user could be using the mac driver.
>
> Huw.
>
>
In terms of X server, currently it will use the latest X connection to initialize
the registry, if needed.

For example, if at first a local user doesn't have X connection and then a remote
user ssh in from a remote X server. The registry will be initialized with the
remote X connection. If local user have already initialized the registry, then
remote user login shouldn't trigger a reinitialization, unless the remote user
uses desktop mode, then registry will be initialized again with the remote
X connection, overriding the local one.

On Windows, the adapter data stored in registry is always local.
With X being a network protocol, there is no local or remote clients. So the first
connection is treated as local.

I am not sure how much we can do about this since Windows graphics driver stack
didn't build with X in mind. We could make EnumDisplayDeviceW report different
adapters according to different X connection. But then that means EnumDisplayDeviceW
may need to use a different approach, e.g., via user driver backend directly instead of
storing the information under specific registry keys. And still we need to put a version
of adapter information in registry as well because e.g., SetupAPI may be used to query
the registry, so the problem didn't go away completely.

P.S. Alexandre didn't like the EnumDisplayDeviceW via user driver backend approach,
which is how it was implemented the very first version.