- Initialize the device extension `IsVgaDriver` field with a single
`IntIsVgaSaveDriver()` call when the video device extension is first
initialized in `IntVideoPortCreateAdapterDeviceObject()`.
- The `IsVgaDriver` field can then be used wherever we previously
invoked `IntIsVgaSaveDriver()` (see e.g. in resource.c)
NOTE: It may be possible to move the `IsVgaDriver` field to the driver
extension structure instead, if it's not possible for miniport drivers
to influence this during calls `VideoPortInitialize()` with a custom-made
registry path (2nd parameter) containing a "\\VgaSave" substring...
(To be investigated.)
Addendum to commits 08a6834075 and 0511e9d869.
- Use the `DPFLTR_VIDEO_ID` debug filter ID, which is the same as what
Windows' videoprt.sys uses, so that tools and people who debug can
easily interoperate between the two.
Addendum to commits 11c95f7b5d (r19801) and 5b799176ba (r31477).
- Use SAL2 annotations.
This problem was noticed by Zombiedeth.
Addendum to commit 89d5a3dbb8 (PR #8451).
There exist buggy 3rd-party miniport drivers, like those for the NVIDIA GeForce
8400 GS card (`nv4_mini.sys` from `181.22_geforce_winxp_32bit_english_whql.exe`)
that invoke the VideoPort Int10 routines (either `VideoPortInt10()`, or the
INT10 interface via `VideoPortQueryServices()`) from their `HwFindAdapter()`
callback (invoked via `VideoPortInitialize()`) or from their `DriverEntry()`.
However, at this point, the VideoPort Int10 services are not fully initialized:
on the x86 port, the VDM memory isn't mapped until later, when the `\Device\VideoX`
is opened by Win32k as part of its initialization in the context of the CSRSS process.
Additionally on the x86 ReactOS port since commit 89d5a3dbb8 (PR #8451), the
X86 emulator is used by default, unless either a registry setting is set to
disable the emulator, or the HAL (e.g. the NT5.x HAL) doesn't export the X86
emulator routines; in these cases the VDM is employed instead.
In the NT5.x builds VideoPort imports the HAL X86 emulator routines at runtime,
since it has to handle their possible absence. However, this importing was
previously delayed up until VideoPort initialized the Int10 services (when
`\Device\VideoX` is opened the first time by Win32k from CSRSS), meaning,
these services and the X86 emulator imports weren't initialized until then.
When booting ReactOS in these conditions with the NVIDIA driver installed,
its too-early `VideoPortInt10()` call was invoking the X86 emulator with no
imports set up, which resulted in the invocation of a NULL function pointer,
leading to a BSOD.
## Proposed changes
- Make the existing `IntInitializeInt10()` function support two invocations:
* When invoked the first time, it initializes the X86 emulator support, by
importing the HAL emulator routines, if applicable.
* When invoked the second+ time, it maps the VDM memory space (done when
`Device\VideoX` is opened by Win32k/CSRSS initialization).
- Actually perform the first `IntInitializeInt10()` invocation in the
`if (!FirstInitialization)` block of `VideoPortInitialize()`.
- Set a `VDMAddressSpaceInitialized` flag to TRUE only when the VDM memory
space is mapped (during the second `IntInitializeInt10()` invocation).
Check this flag in both `IntInt10CallBiosV86()` and `IntInt10CallBiosEmu()`
(x86 build only).
- Adjust two returned status values in `IntInitializeVideoAddressSpace()`.
Stop pointless target_sources(xxx PRIVATE $<TARGET_OBJECTS:gcc_ssp_nt>). The only effect it has is to force the object file into the target, which was already done by specifying the libraries as OBJECT libraries, which is also pointless, and only leads to problems.
This commit attempts to resolve two regressions and improve realhw behavior
A PNP_DETECTED_FATAL_ERROR bug check caused by the monitor device instance being duplicated.
https://jira.reactos.org/browse/CORE-20410
this is mostly due to ChildID being overwritten with the same bus/slot when 2 monitors are attached to one GPU
And video drivers failing to startup after calling VideoPortCreateSecondaryDisplay
Co-authored-by: Dmitry Borisov <di.sean@protonmail.com>
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
Allows our upcoming PCIX driver to work correctly with it, and now the arbiter on Windows with our videoprt actually matches the behavior and improves video driver compatibility
- Add and use `CONST_STR_SIZE/LEN` macros to get the number of bytes and
characters for a static const string buffer, instead of invoking e.g.
`wcslen()`, which may or may NOT be optimized out (e.g. MSVC debug builds).
- Use `UNICODE_NULL` instead of `0`.
- Transform a `DPRINT` into an `INFO_(VIDEOPRT, ...)`
- Fix an x64 warning
`registry.c(689): warning C4267: '=': conversion from 'size_t' to 'USHORT', possible loss of data`
The choice is done by looking for the presence or absence of the
`HKLM\System\CurrentControlSet\Control\GraphicsDrivers\DisableEmulator`
registry key. For more details, see:
https://www.geoffchappell.com/studies/windows/km/hal/api/x86bios/call.htm
By default, use V86 in 32-bit Win2k3-compatible builds, otherwise
(Vista+) check the presence of the registry key.
The X86 emulator routines are exported by the HAL.DLL. They are always
exported by the non-x86 HAL. However, they may or may not be exported by
the x86 (32-bit) HAL: on NT 5.2 and below they are not exported, while
on NT 6.x (Vista+) they are.
Therefore:
- in our NT <= 5.2 x86 builds, we load the routines at runtime. If they
aren't found, we fail emulator support initialization and fall back to
VDM V86 support.
- in our NT 6.x (x86 or not) builds, we always directly link with the HAL
routines, since they are guaranteed to be present there.
- Make `IntAttachToCSRSS()` return a BOOLEAN to distinguish calls made
prior to `CsrProcess` being initialized.
- Adjust the callers of `IntAttachToCSRSS()` and make them returning a
proper error value if attaching failed (if `CsrProcess == NULL`).
- Make `IntDetachFromCSRSS()` just take a `PKPROCESS` parameter instead a
pointer to `PKPROCESS` -- the function won't need to modify its value.
Adjust its callers to reflect the change.
- SAL-ify `IntVideoPortGetProcAddress()`. Sadly its 2nd parameter needs
to stay `PUCHAR` to comply with the `PVIDEO_PORT_GET_PROC_ADDRESS` type.
- Append `VideoPortQuerySystemTime` to the array of exports (Vista+ compatibility).
Note that probably because of a copy-pasta error, Windows' VideoPrt
duplicates the `VideoPortMapDmaMemory` entry in between those of
`VideoPortFreeCommonBuffer` and `VideoPortReleaseBuffer`.
IntVideoPortMapMemory incorrectly returned a successful result if it
failed to map video memory. This caused a bugcheck when using VirtualBox
with Guest Additions with more than 128MB of VRAM assigned to VM.
- Return ERROR_NOT_ENOUGH_MEMORY instead of NO_ERROR
when mapping memory fails.
- Also add debug logging to help troubleshoot when MmMapIoSpace fails.
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/video/nf-video-videoportmapmemory#return-value
This fixes the crash, however the desktop does not render correctly.
Using videoprt.sys from Windows XP still results in the same behavior.
CORE-12130
- choose VGA adapter outside of driver initialization loop
- choose primary adapter outside of driver initialization loop
- link VGA adapter to primary adapter at the end
- only set DISPLAY_DEVICE_PRIMARY_DEVICE in this function
Also mark VgaSave driver as SystemStart instead of Disabled,
so it is available if main display driver doesn't work.
On x64 malloc needs to return a 16 byte aligned buffer, the previous code used an 8 byte header, making the allocations unaligned. This is now fixed with an improved header structure.
Also simplify realloc a bit and make it handle Object == NULL.
URLs are getting old. We have to
update URLs for documentation
purpose.
JIRA issue: CORE-19963
- Refresh old URLs.
- Add " (DEAD_LINK)" labels
to dead links.
- Use MS Learn links rather
than MSDN ones.
- Some dead links revived by
Web Archive.
- Don't change Wine Tests
and Wine Sync.
- Don't change 3rd party libraries.
- Don't append "redirected" labels.
Our FT_Bitmap_Convert function had a hack to make the
bitmap image compatible to ReactOS. I think the hack on
FT_Bitmap_Convert should be separated from our font
engine.
JIRA issue: CORE-16047
- Add FT_Bitmap_Convert_ReactOS_Hack function, that is
based on FT_Bitmap_Convert, and split the hack of
FT_Bitmap_Convert.
- Use FT_Bitmap_Convert_ReactOS_Hack in
IntGetBitmapGlyphWithCache function instead of
FT_Bitmap_Convert.
- Modify ftfd.spec to add
FT_Bitmap_Convert_ReactOS_Hack.
Revert "[PSDK][AFD][VGADDI] Further build and MS PSDK compatibility fixes."
This reverts commit 99efc2ae50.
Revert "[PSDK] Sync winresrc.h with wine-8.20"
This reverts commit 3e83562aa7.
Revert "[OSK][PROGMAN] Fix resource file build."
This reverts commit 84e4ad0a82.
Revert "[PSDK] Use the new .rh files in winresrc.h"
This reverts commit f6fb7c48c9.
- windows.h:
* should define _WINDOWS_ and _INC_WINDOWS instead of _WINDOWS_H
* include winresrc.h if RC_INVOKED and not NOWINRES (Wine also agrees
with that)
* also, some .h included from there should _not_ be included if their
respective NO*** flags are defined.
- batclass.h: Use correct _WINDOWS_ guard.
- winsnmp.h:
* should define _INC_WINSNMP instead of _WINSNMP_H
* use _INC_WINDOWS instead of _WINDOWS_H
- afd.h, vgaddi.h: Use the correct guards.
- winnt.rh: Define the (SUB)LANG_* exactly as they are in the winnt.h,
otherwise we get macro redefinition compile errors.
NOTE: Ideally these .rh files should be auto-generated from their
corresponding .h files.
- afxres.h: Do not include the whole windows.h, but instead, only
the winres.h file, and only if RC_INVOKED is defined.
NOTE: Both afxres.h and winres.h do not really belong to the PSDK,
but belong instead to MFC. The reason why we have them here is twofold:
1. Wine used to have also winres.h (from where we got ours). This is
because the .rc resource files of some non-MFC modules were generated
with Visual Studio, which always includes afxres.h for these, and the
solution was to use a slightly less MFC-specific header: winres.h
(Wine commit cb08c82244673f26842e7a0766de90f091b5a493).
However, this winres.h has been since removed from Wine tree
(Wine commit 197f4059ab2af5f13f9c56faa26e3b4af902f869).
2. Few of our modules either use afxres.h or winres.h in their resource
files, and we still want to be able to compile them.
CORE-19011
Fix a "bug" I introduced in commit 61012eb54.
VideoPortGetAccessRanges() expects the caller to specify at least the
total number of ranges the hardware exposes, otherwise it fails with
ERROR_MORE_DATA. (Tested also with the help of Windows' videoprt.sys.)
On real original XBOX there are three:
```
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV2A [XGPU] [10de:02a0] (rev a1)
Subsystem: Unknown [0000:0000]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 03
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at f0000000 (32-bit, prefetchable) [size=128M]
Memory at 00000000 (32-bit, prefetchable) [size=512K]
```
Thanks to Stanislav and Daniel for tests on the real XBOX.
These are specified for releasing the hardware resources previously
acquired by either a previous call to VideoPortVerifyAccessRanges()
or a call to VideoPortGetAccessRanges().
Contrary to what is (badly) written on MSDN, this parameter is
*mandatory* when the ranges looked for are on a PCI adapter.
Detected when testing with MS Windows' videoprt.sys on XBOX emulator;
thanks to Simone Lombardo for assistance!
Replace framebuf display driver by framebuf_new display driver
Compile framebuf_new as framebuf.dll, and add it to bootcd/livecd
Remove old framebuf from compilation, to not conflict
- deduplication of manufacturer strings
- at some places harmonizes the different length of separator lines within the same file, centers the words (as requested by hbelusca during review), harmonizes those lines to 74characters length each
- moving some strings that are not to be localized into the non-localization string section
- other minor formatting preferences coauthored by StasM
As IOCTL_VIDEO_GET_CURRENT_MODE returns 2 as ModeIndex, wait for the same value
in IOCTL_VIDEO_SET_CURRENT_MODE.
Also change vgaddi to send this hardcoded value.
vga_new also uses 2 as index for 640x480x16
