[PATCH v3 resend 1/4] winex11.drv: Store monitor information in the wineserver for EnumDisplayMonitors().

[Rémi Bernon]

On 4/21/21 5:09 AM, Zebediah Figura (she/her) wrote:
> On 4/20/21 8:44 PM, Zhiyi Zhang wrote:
>> Fix a regression that Office 2016/365 has a 640x480 main window.
>>
>> Office 2016/365 hooks NtOpenKeyEx() and prevents access to SetupAPI 
>> device properties.
>> After querying monitor information from SetupAPI failed, 
>> EnumDisplayMonitors() reports
>> a fallback monitor of size 640x480.
> 
> IIRC when this was last brought up, the proposed solution was to do it 
> remotely, via RPC to plugplay.exe. Arguably that's more work, but it 
> strikes me as potentially better than getting the wineserver involved...?
> 
>>
>> As to why store the monitor information in the wineserver, it seems 
>> that EnumDisplayMonitors()
>> reports monitors connected to current user logon session. For 
>> instance, EnumDisplayMonitors()
>> always report one monitor when called by services.
> 
> And this could just be handled in user32, perhaps by querying the 
> session ID or something.
> 
> Are there other reasons why it makes more sense to use the server?
> 

If services have different results, wouldn't it instead be something 
that is winstation / desktop dependent?

Could it then be implemented by creating a device in explorer.exe and 
communicate through ioctls? I believe wineandroid.drv does that already 
(well, not for monitor modes).

I think that using the desktop to factor some graphics driver 
functionality is something that would make sense more generally, 
especially if we want to loosen user32 dependency on the host.

I don't know at all what's planned regarding graphics driver PE split 
but I think moving some things to only live in explorer.exe could help.
-- 
Rémi Bernon <rbernon at codeweavers.com>