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.