Many thanks for Simone Lombardo for pointing to the code needing attention
and providing a working proof-of-concept solution.
CORE-12377
CORE-18084
CORE-13889
CORE-17932
[ENG] Implement DirectDraw management in switch display mode functions
(e.g. resolution change, color depth, display frequency etc.):
- Switch DirectDraw instances between the two PDEVs (the current one and
the new one allocated by ourselves) by calling dxg!DxDdDynamicModeChange
function.
- Suspend them before and resume after the display mode switch, by calling
dxg!DxDdsuspendDirectDraw and dxg!DxDdResumeDirectDraw appropriately.
We currently don't have these functions implemented, but MS DXG has, so
it allows to properly manage DirectDraw PDEVs using this driver, similarly
to Windows.
My analysis confirms that these functions are always called in XP/2k3 on
display mode switch, even when there is no any DirectX app running at the
moment. Analyzing their prototypes show that my guesses are correct.
- Initialize hDev and dhpdev members for EDD_DIRECTDRAW_GLOBAL for newly
created surfaces, switch them during mode change and re-initialize after
it also. They are commonly used by DirectDraw stack.
In addition, enable DirectDraw for old and new PDEVs, by calling
dxg!DxDdEnableDirectDraw function.
[NTDDRAW] Additionally, fix usage of DirectDraw lock count in the PDEVOBJ
structure.
- Enable cDirectDrawDisableLocks member for storing its value, instead of
DxDd_nCount, which is marked as ROS-specific.
- Use it in win32k!DxEngGet/SetHdevData for getting/setting DirectDraw
count appropriately.
My analysis also shows that in Windows, the PDEVOBJ::cDirectDrawDisableLocks
method calls DxEngGetHdevData with type 8, which corresponds to our DxDd_nCount.
So there are no doubts that this member is used there.
- Rename DxEngGetHdevData_dd_count alias of type 8 to DxEngGetHdevData_dd_locks,
to match more accurately an actual member name. Update the enumeration
and fix all code parts appropriately.
All these changes allow to properly change display mode during executing
DirectDraw applications, when they try to switch in full-screen mode.
At least a bugcheck that happened before my changes, does no longer appear.
There are still some games that don't run correctly, as if there is no
3D acceleration (which actually exists). This requires further investigations.
CORE-18221
Load the DirectX graphics kernel driver (dxg.sys) by win32k at WINSRV
initialization time, in NtUserInitialize(). Keep it always loaded in
memory, as on Windows, instead of loading it only by DirectX dlls.
This fixes the problem of acessing this driver: we need only to call
DxDdEnableDirectDraw() and do other stuff when DirectDraw/Direct3D is
required by anything. In other cases, it is called from win32k PDEV
functions when changing display mode (as in Windows). Since it's used
by other things too, it needs to be always loaded.
Otherwise, if it's not loaded, its APIs are not accessible when needed,
and execution fails.
For example, it fixes display mode change problem in VMWare, when a
new mode fails to be applied. Indeed, when it manages DirectDraw stuff,
it calls DXG routines, and therefore fails if dxg.sys isn't loaded
in memory at this moment.
- Implement InitializeGreCSRSS() initialization routine, that initializes
supplemental NTGDI/GRE data once CSRSS and WINSRV are loaded:
* Call DxDdStartupDxGraphics() inside it, which loads dxg.sys.
* Additionally, move fonts and language ID initialization there, from
win32k!DriverEntry. Confirmed by analysis on Windows.
- Call InitializeGreCSRSS() in NtUserInitialize() main initialization routine
(called by WINSRV initialization).
Moved to NTGDI from previously NTUSER place:
Co-authored-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Currently, LDEVOBJ_bUnloadImage always returns FALSE due to missing functionality in ntoskrnl.
LDEVOBJ_vFreeLDEV contains an assert that driver is correctly unloaded before freeing it.
Prevent this assert by calling LDEVOBJ_vFreeLDEV only if LDEVOBJ_bUnloadImage succeed.
This can be easily triggered if DrvEnableDriver function (called in LDEVOBJ_bEnableDriver) fails.
This allows DevExpress Ribbon Notepad sample to start.
Also add a fat DPRINT1 suggested by Timo Kreuzer,
because there is a lot wrong in the code.
CORE-18091 CORE-18558
Rotation and shearing transformation of font/text is now available. Retrial of PR #1207.
- Rename ftGdiGetTextWidth as IntGetTextDisposition and add a Y parameter.
- Apply lfEscapement values (by multiplying matrices).
- Add IntEngFillPolygon and IntEngFillBox helper functions.
CORE-11848
- Add lfWidth member into FONTGDI structure.
- Delete IntWidthMatrix function.
- Fix IntRequestFontSize behavior for processing lfWidth value.
- Apply lfWidth in GetTextMetrics and GetCharWidth.
- Ignore the XFORM values in GetTextMetrics and GetCharWidth.
CORE-11848
- Modify FONT_CACHE_ENTRY structure to use hash.
- Use hash in ftGdiGlyphCacheGet and ftGdiGlyphCacheSet functions.
- Reduce function call overheads by using FONT_CACHE_ENTRY, in getting glyph.
CORE-11848
- Use FT_Matrix instead of MATRIX in FONT_CACHE_ENTRY structure.
- Use FtMatrixFromMx and FT_Set_Transform instead of FtSetCoordinateTransform.
CORE-11848
That way, we don't have anymore the VGA device together with primary device in device list.
Change also EngpUnlinkGraphicsDevice() function to add back VGA device to device list
when removing its parent from device list.
CORE-18522
- Delete some IntRequestFontSize function calls.
- Enable cache on font size requests.
- Add two members into FONTGDI structure, for font size cache.
CORE-15554
Otherwise, use software pointer functions.
This fixes graphical glitches on cursor change, when the display driver
provides accelerated pointer functions (DrvSetPointerShape/DrvMovePointer),
but refuses to handle a certain cursor.
These graphical glitches may be reproduced:
- by using Voodoo driver SFFT 1.9
- by using framebuf_new.dll instead of framebuf.dll
- by using the panning driver (setting DefaultSettings.XPanning and
DefaultSettings.YPanning in registry)
Implement the following DxEng* functions:
- DxEngAltLockSurface
- DxEngDeleteSurface
- DxEngReferenceHdev
- DxEngSelectBitmap
- DxEngSetBitmapOwner
- DxEngUnreferenceHdev
Update their prototypes and call the appropriate win32k functions
inside them, since they are already implemented. Also get rid of
now unused IntGdi(Un)ReferencePdev, whose were called only by dxeng,
and whose are not used anymore. In Windows, DxEng(Un)ReferenceHdev calls
PDEVOBJ_vReferencePDEV and PDEVOBJ_vDeferencePDEV directly (those
correspond to our PDEVOBJ_vReference and PDEVOBJ_vRelease accordingly).
Required by MS DirectDraw stack (ddraw.dll & dxg.sys). CORE-17561
- [VIDEOPRT] Return the real PhysicalDeviceObject in Win32k callbacks.
- [WIN32SS:ENG] Pass PhysDeviceObject into the GraphicsDevice structure
and rename the destination field accordingly.
- [WIN32SS:NTUSER] Request hardware identifiers from device PDO and
fill DISPLAY_DEVICE's DeviceID field with the first identifier.
Now it's correctly passed to the usermode, and Desktop Propertes applet
can open the video adapter device properties.
Thanks to Hervé Poussineau for the help.
CORE-18197 CORE-11715
Search the display mode having the smallest difference with the requested one.
We can then remove the hardcoded values of 60 Hz and 32 bpp by default.
CORE-18189
- use EngpGetDisplayDriverParameters to get display settings from registry
- update searched display settings with the provided ones (+ add missing SEH2)
- then, search exact mode
User can now change only one display setting, without specifying other ones.
This can be configured in registry with DefaultSettings.XPanning and
DefaultSettings.YPanning, which describe the real screen resolution.
DefaultSettings.XResolution and DefaultSettings.YResolution describe
the resolution of the virtual screen.
