On Tue Sep 27 03:01:49 2022 +0000, Zhiyi Zhang wrote:
Shouldn't you take the display_lock while accessing monitors?
I guess... though I'm thinking that we may need to make sure the cache update and virtual screen notification are kept atomic.
FWIW, I'm also considering changing the `VirtualScreenRectChanged` call to always call it, and only pass the new virtual screen rect and primary monitor rects. That way display drivers could keep them internally, to get the old rects, and remove the need for `NtUserGetVirtualScreenRect` / `NtUserGetPrimaryScreenRect` callbacks entirely.
Then all of this is going to be difficult because some of the calls may need to enter the display lock recursively. This is already the case when loading the display driver, as the lazy initialization will need to load icons for builtin window classes and get the lock for the display DC, but also for some of the things winex11 does when virtual screen is resized (like moving windows, etc).
Is there any reason not to use a recursive mutex for the display lock? It would solve the problem more easily. @jacek maybe has an opinion?
Alternatively I can acquire the display lock just for the monitor enumeration but it makes the cache update and notification racy.