On 11/10/21 15:01, Jacek Caban wrote:
On 11/10/21 12:47 AM, Rémi Bernon wrote:
On 11/10/21 00:41, Rémi Bernon wrote:
On 11/9/21 13:55, Jacek Caban wrote:
Signed-off-by: Jacek Caban jacek@codeweavers.com
dlls/user32/driver.c | 209 +---------------------------- dlls/win32u/driver.c | 310 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 310 insertions(+), 209 deletions(-)
A little bit related to my previous comment, this patch introduces a reset to "null" graphics driver on driver unload.
I think it could also add the same
__wine_set_display_driver( &null_driver, WINE_GDI_DRIVER_VERSION );
call when the "null" driver is explicitly requested and loaded, possibly addressing my previous comment too (as the pointer would not be lasy_load_driver anymore).
Also, regarding EnumDisplayMonitors and GetMonitorInfo, for which you added some FIXME, I have some patches to move the default implementation back to the corresponding user32 functions.
I intended to send them after the previous nulldrv display device cache series I sent a week ago but I don't think they actually depend on it.
(Similarly, I used the monitor cache to keep the default and initial monitor for GetMonitorInfo implementation)
I rebased and pushed the patches there if you're interested, although only the commit up to c998fbadab6aa33e3bd2740b0651a0c0509d4c02 are really relevant for this:
I have null driver functions and some other sysparams.c functions moved to win32u in my tree. Those needed to be changed due to to advapi32 and setupapi calls. I used a cache as well, but instead of having two caches, I extended adapters cache to contain missing monitor rects informations. There are a few functions that need to enumerate monitors, they would look like this:
update_display_cache();
pthread_mutex_lock( &display_lock );
LIST_FOR_EACH_ENTRY( adapter, &adapters, struct display_device, entry ) { LIST_FOR_EACH_ENTRY( monitor, &adapter->children, struct monitor, dev.entry ) {
/* .... */
} }
pthread_mutex_unlock( &display_lock );
What do you think about such approach?
Do you actually need to move the display device cache to win32u or is it just because of the non-trivial nulldrv functions being moved there too?
In the tree I linked above, in the end after all the changes, the nulldrv functions are all mostly no-op and the default implementation lives in user32, updating the cache by enumerating setupapi devices.
It also moves several things out of graphics drivers, such as reading / writing current display mode, to the user32 EnumDisplaySettingsExW / ChangeDisplaySettingsEx generic code.
Overall I think it makes everything much simpler, and reduce the amount of entry points graphics driver would need, and reduce the amount of changes needed if you need to replace all setupapi / advapi32 calls.
Cheers,