to the workaround in last commit 0.4.12-RC-19-g
700779e643
Many thanks to reviewer jimtabor for this very prompt review!
I tested, the new state still succeeds in CORE-15477, CORE-14979, CORE-15599, CORE-15600, CORE-15654
Fixes 'multiple apps leaving the taskbar visible erroneously when switching into fullscreen.'
Please note that the problem with taskbar staying visible is only fixed for some, but not all apps
(see CORE-11242 for some still failing examples, e.g: Bound Around).
We now have the same state in 0.4.12RCs, that we just have committed to master in 0.4.13-dev-247-g
0f29b3faa7
Fixes 'multiple apps leaving the taskbar visible erroneously when switching into fullscreen.'
Please note that the problem with taskbar staying visible is only fixed for some, but not all apps (see CORE-11242 for examples).
This partially reverts commit 09ab5ea7ed (SVN r75407)
I applied this interim solution into 0.4.12RCs for the very first time and rls-tests still
have to prove it being free of obvious side-effects.
Theoretically we could still switch to a better solution at any time.
The workaround never was applied to master to date.
https://reactos.org/testman/compare.php?ids=67536,67539
This helps when e.g. changing the resolution on the Dell Latitude D531,
which reports that it supports large resolutions (e.g. 1920x1440x32 and
others larger than 1024x768x32) but fails to apply these.
This usually happens because PDEVOBJ_pSurface(), and more precisely
ppdev->pldev->pfn.EnableSurface(), fails for these resolutions.
- PDEVOBJ_bSwitchMode(): Set the new video mode, or restore the original
one in case of failure + release the allocated ppdevTmp if previous
calls fail. Also unlock in reverse order of locking order.
- UserChangeDisplaySettings(): In case PDEVOBJ_pSurface() fails (but has
reverted the original video mode), we still need to refresh the
display since the display may have been messed up.
