On 4/21/21 8:15 PM, Rémi Bernon wrote:
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.
c84fd7cd861d83c9afe63a3255c90693b2ee2e66 shows that monitor enumeration is not related to winstations or desktops. I am guessing it's stored in some internal user session struct. For example, a remote desktop connection reports the enumerated monitor as 1 and it has the same dimension as local window size.