- 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)
MSVC amd64
'...\dll\win32\winmm\midimap\midimap.c(474): warning C4133: 'function': incompatible types - from 'LPDWORD' to 'DWORD_PTR *''
Import missed parts of
29b00e1a8c
Addendum to b40e7f0 (r47900).
CORE-7538
CORE-18140
This was introduced historically in commit 583de66b3 (r7460) to
workaround some compiler problems (or replace already existing
GCC-specific __attribute__((packed)) annotations); however these
structures are in-memory-only, do not describe any on-disk data
format and don't describe hardware-specific data. So they should
have the "natural" alignment of the target platform.
They also have to match the documented layouts at:
https://reactos.org/wiki/Techwiki:Win32k/THREADINFOhttps://www.geoffchappell.com/studies/windows/km/win32k/structs/threadinfo/index.htm
at least for the compatible parts that ReactOS shares.
This also removes the following warnings, that were present because,
as the ACPICA acpi.h header was used as PCH (instead of none, or the
hal's own main header), it was "included" before any other header
-- and in particular, before hal.h -- and as a result, colliding defines
were still defined even if the #undef tricks were used for them.
rosbuilds\sdk\include\reactos\mc\bugcodes.h(1417): warning C4005: 'ACPI_BIOS_ERROR': macro redefinition
reactos\drivers\bus\acpi\acpica\include\acoutput.h(243): note: see previous definition of 'ACPI_BIOS_ERROR'
reactos\hal\halx86\include\hal.h(41): warning C4109: unexpected identifier '_read'
reactos\hal\halx86\include\hal.h(42): warning C4109: unexpected identifier '_read'
Typos introduced in commit 4d1ea554c.
These had the effect of enumerating "NetworkProviderRemoteValidation"
and "Extended BasePCI Configuration" as groups, which were of course
invalid/non-existent.
The actual groups are: "NetworkProvider", "RemoteValidation",
"Extended Base", and "PCI Configuration".
Fixing this may correct the loading order of drivers that belong to
these groups (if we do have such drivers).
In MS Windows all control panel applets are started in single instance.
This prevents conflicts of concurrent accesses to the configuration data.
Before starting applets, look up the dialog window of the existing instance
by checking several atoms, such as the applet path, CPLName, and CPLFlags.
If the dialog is found, it's brought to the foreground, and a new applet
instance not started.
CORE-7921 CORE-17025
Signed-off-by: Raymond Czerny <chip@raymisoft.de>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Joachim Henze <joachim.henze@reactos.org>
Reviewed-by: Mark Jansen <mark.jansen@reactos.org>
