- search a graphic mode corresponding to real screen resolution (not virtual panning one)
- when capturing the selected mode, copy from input the virtual panning resolution
- when searching the best mode, also try without panning
When changing current devmode, we must not only change ppdev->pdmwDev
pointer, but also update lots of other structures. This work is done by
PDEVOBJ_lChangeDisplaySettings.
CORE-18169
- do not try to remove ppdev from gppdevList if gppdevList is NULL
- do not check (and maybe change) gpmdev, as it should be done only in MDEVOBJ_vDestroy
- introduce LDEVOBJ_vDisableDriver (reversal of LDEVOBJ_bEnableDriver)
- introduce LDEVOBJ_bUnloadImage (reversal of LDEVOBJ_pLoadDriver)
- introduce LDEVOBJ_vDereference, to remove a reference to a LDEVOBJ
Also:
- correctly handle success to unload the image, by removing it from pldev list
- correctly handle failure to unload the image, by re-enabling the driver
- simplify EngUnloadImage, as a wrapper around LDEVOBJ_vDereference
- move LDEVOBJ_ulGetDriverModes lower to prevent forward declaration of
LDEVOBJ_vDereference
Unfortunately, disable driver unloading as long as ntoskrnl can't reload
a driver it just unloaded...
- store the acceleration level in PDEVOBJ
- when searching a pdev, search a pdev with required acceleration level
- disable some functions when not at full acceleration level
(levels 3 and 5 are not implemented)
Initialization of device mode list will be done later, just before switching to graphics mode.
If no graphic display is available, we will now fail when starting first GUI application in
co_IntGraphicsCheck(). Add a bugcheck here to prevent frozen screen.
This function can create a MDEV for the whole display (maybe containing multiple
PDEVs), or update settings of a specific PDEV.
- call PDEVOBJ_lChangeDisplaySettings when switching to graphics mode.
- modify EngpGetPDEV to search requested PDEV only in current MDEV
This will be used (later) to store the list of all enabled display devices.
Add a global variable gpmdev (should really be stored in DISPLAYINFO structure)
Replace global variable gppdevPrimary by pmdev->ppdevGlobal.
- change first argument to be a PGRAPHICS_DEVICE instead of a device name
- add ldevtype (for now, only LDEV_DEVICE_DISPLAY is allowed)
- always pass a devmode if ldevtype is LDEV_DEVICE_DISPLAY
- insert the ppdev into gppdevList on success
- change callers to adapt them to new rules
- Change LDEVOBJ_bEnableDriver to directly take the entry point
(pGdiDriverInfo not required anymore)
- Add LDEVOBJ_pLoadInternal to load and start an internal driver
- make it return a new allocated PDEVMODEW instead of a pointer into
existing PGRAPHICS_DEVICE (usefull when available display modes can
dynamically change: VirtualBox, RDP, ...)
- update all callers
LDEVOBJ_bBuildDevmodeList() only queries the available display modes, without
choosing the one to use on the graphic device, and without immediately
creating a PDEV.
Replace first part of EngpPopulateDeviceModeList() function by a call
to this new function LDEVOBJ_bBuildDevmodeList().
Keep second part of EngpPopulateDeviceModeList() function, which
chooses the default display mode.
- implement LDEVOBJ_ulGetDriverModes (which get modes from a not yet loaded driver),
and use it in EngpPopulateDeviceModeList
- remove now useless LDEVOBJ_pdmiGetModes (replaced by LDEVOBJ_ulGetDriverModes)
CORE-17561
Set the API_BITMAP flag for bitmaps created by EngCreateBitmap().
This avoids failure when created bitmap is passed to NtGdiSelectBitmap(), since it checks for this flag and fails if it isn't set.
Otherwise, if failure occurs, the bitmap is hot handled properly.
Setting this flag outside of that function is not an option at all, because it is a public (exported) function, and in many cases it's called directly by the caller (in case with MS DDraw stack, it can be called also by dxg.sys from dxgthk!EngCreateBitmap, which directly calls win32k!EngCreateBitmap).
In particular, it allows Windows XP/2003 DirectDraw stack (ddraw.dll & dxg.sys) to properly work in ReactOS (in software emulation mode), even on real hardware. So now, a lot of DirectX 1-7 apps and games (whose can work withoug hardware acceleation), are working properly with ddraw.dll + dxg.sys replacement! Also Justin Miller (DarkFire01) confirmed that even Direct3D software emulation now also works correctly on real hardware!
It actually should look like '\\.\DISPLAY<n>' (since it comes from user mode),
which the function expects, and not '\\Device\\Video<n>', like done in the
kernel mode. Otherwise, passing wrong name causes a mismatch.
Fix the problem with video device access (failure with status 0xc0000022 when
trying to open it). Hence, it also fixes the following debug log spam:
'err: Could not open device \Device\Video0, 0xc0000022'.
Addendum to 77e891b8. CORE-17719 CORE-17786
- Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively
- Remove INIT_FUNCTION from function prototypes
- Remove alloc_text pragma calls as they are not needed anymore
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.
