CORE-12149
VIDEOPRT:
=========
Improve interfacing with INBV, so as to detect when an external module
acquired INBV display ownership, and whether ownership is being released
later on. (This does NOT rely on hooking!)
For this purpose we improve the IntVideoPortResetDisplayParameters(Ex)
callback that gets registered with an InbvNotifyDisplayOwnershipLost()
call during initialization, and we add a monitoring thread.
The callback is called whenever an external module calls
InbvAcquireDisplayOwnership(), for example the bugcheck code or the KDBG
debugger in SCREEN mode. When this happens, a flag that tells the
monitoring thread to start monitoring INBV is set (ReactOS-specific),
and the display adapters get reset with HwResetHw() (as done on Windows).
Due to the fact that this INBV callback can be called at *ANY* IRQL, we
cannot use dispatcher synchronization mechanisms such as events to tell
the INBV monitoring thread to start its operations, so we need to rely
instead on a flag to be set. And, since INBV doesn't provide with any
proper callback/notification system either, we need to actively monitor
its state by pooling. To reduce the load on the system the monitoring
thread performs 1-second waits between each check for the flag set by
the INBV callback, and during checking the INBV ownership status.
When the INBV ownership is detected to be released by an external module,
the INBV callback is re-registered (this is *MANDATORY* since the
external module has called InbvNotifyDisplayOwnershipLost() with a
different callback parameter!), and then we callout to Win32k for
re-enabling the display.
This has the virtue of correctly resetting the display once the KDBG
debugger in SCREEN mode is being exited, and fixes CORE-12149 .
The following additional fixes were needed:
VIDEOPRT & WIN32K:
==================
Remove the registration with INBV that was previously done in a ReactOS-
specific hacked IRP_MJ_WRITE call; it is now done correctly during the
video device opening done by EngpRegisterGraphicsDevice() in the VIDEOPRT's
IRP_MJ_CREATE handler, as done on Windows.
WIN32K:
=======
- Stub the VideoPortCallout() support, for VIDEOPRT -> WIN32 callbacks.
This function gets registered with VIDEOPRT through an
IOCTL_VIDEO_INIT_WIN32K_CALLBACKS call in EngpRegisterGraphicsDevice().
- Only partially implement the 'VideoFindAdapterCallout' case, that just
re-enables the primary display by refreshing it (using the new function
UserRefreshDisplay()).
VIDEOPRT:
=========
- PVIDEO_WIN32K_CALLOUT is an NTAPI (stdcall) callback.
- In the IntVideoPortResetDisplayParameters(Ex) callback, reset all the
"resettable" adapters registered in the HwResetAdaptersList list.
We thus get rid of the global ResetDisplayParametersDeviceExtension.
- Make the IntVideoPortResetDisplayParameters(Ex) callback slightly more
robust (using SEH) against potential HwResetListEntry list corruption
or invalid DriverExtension->InitializationData.HwResetHw() that would
otherwise trigger a BSOD, and this would be disastrous since that
callback is precisely called when INBV is acquired, typically when the
BSOD code initializes the display for displaying its information...
Extras:
- Validate the IrpStack->MajorFunction in IntVideoPortDispatchDeviceControl()
and implement IRP_MJ_SHUTDOWN handling. Stub out the other IOCTLs that
are handled by VIDEOPRT only (and not by the miniports).
- VIDEOPRT doesn't require IRP_MJ_INTERNAL_DEVICE_CONTROL (unused).
- Implement IOCTL_VIDEO_PREPARE_FOR_EARECOVERY that just resets the
display to standard VGA 80x25 text mode.
- Delete ItalicFromStyle and WeightFromStyle functions.
- Don't use FT_FaceRec.style_name for font style but pOS2->fsSelection, pOS2->usWeightClass, WinFNT.italic and WinFNT.weight.
- Don't use the bitmap glyph as possible if the glyph will be oblique'd.
- Tahoma Italic is working!
CORE-9614
CORE-15655
If the owner window doesn't exist or is invisible or has WS_EX_TOOLWINDOW style, HSHELL_WINDOWCREATED regards the window a non-owned window. You can watch the shell hook information by using CORE-15655 ShellHookChecker.zip.
DM_REPOSITION is dialog message that can reposition the dialog to the workarea when the dialog is partially/entirely in outside of the workarea. CORE-16490
Upon mouse message generation, The states of Shift key and/or Ctrl key must be used. If Shift key is pressed, it enables MK_SHIFT flag of the mouse message. If Ctrl key is pressed, it enables MK_CONTROL flag of the mouse message. CORE-16279
When Themesvc was disabled, some Window titlebar
frames were drawn too thin until the window
was actively resized in y by the user.
That and similar symptoms started to show up after SVN r68904 ==
6dfa71c487
Many thanks to patches author Doug Lyons.
We leave the ticket unresolved still due to explicit request of
James Tabor, who wants to continue working in that context.
I will merge that back into 0.4.13RCs as well.
Need to cross check these changes with WINE ComCtl32 before you PANIC
HACK!!!!
Not in order:
Piotr Caban : Remove unneeded RECT parameter from CBPaintText helper.
Don't invalidate ComboBox on CB_SETCURSEL message.
Don't invalidate ComboBox on LBN_SELCHANGE and
LBN_SELCANCEL.
Add more CB_SETCURSEL tests on ComboBox.
Redraw combo text field even if it's empty.
Let ComboBox edit control handle the redraw even if
CBF_NOREDRAW is set.
Don't do the painting if combobox is not visible in
CBPaintText.
Dmitry Timoshkov : Don't force a combobox repaint on WM_SIZE.
This breaks z-order based painting and causes side effects
for
applications that during the WM_PAINT processing reference
internal
data associated with a not fully initialized window.
Ref :
2d9e3236ea
Fabian Maurer : Set listbox popup height correctly and add tests.
Properly set dropdown height.
Now that user32 and comctl32 combo are separated,
this won't lead to a regression anymore
Ref :
3d0be0bad8
Info by Sebastian Lackner Ref:
f0fc034997
Nikolay Sivov : Remove some misleading TODOs and confusing comments.
The submenu of desktop popup menu was erroneously shown at first right click.
- Fix the hit test position that was modified by window style change.
CORE-16382
This fixes regression CORE-16289 where we could not longer
move the taskbar at a different than default location,
as WindowSnap would interfere.
Many Thanks to the patches author Doug Lyons.
Eventually the heuristic that we use here to identify the
taskbar via used window-styles could be improved later.
Theoretically possible that it bails out on some other windows.
The regression was introduced by 0.4.12-dev-373-g
7e396787ed
