[CONTENT] NT6 Newsletter? 1 - June-Oct

[DarkFire01]

[UCRT] [PO? -George] [UEFI Framebuffer -Should probably mention distrohopper too] [WDDM - KMT/D3D Winesync]

Opening as a draft while i write up the WDDM entry and start the ucrt one

[reactos-buildbot]

Thanks for your contribution! I have built and deployed your changes to https://pr128.web-content.reactos.org and will also do that for your future changes.

[GeoB99]

Regarding the power manager part, here's my wording (it would need grammar/vocabulary improvements or corrections before shipping it to the newsletter):

ReactOS currently lacks in power management infrastructure. As a result, there is no support for system batteries, no thermal management, power states, etc. From a user's perspective, this results in a shorter battery life if ReactOS was used on a laptop, poor power management experience (no option for hibernation or sleeping) and increased electrical consumption.

George Bișoc (GeoB99) aims to solve all of this by working on the base foundation of the power manager in the kernel (see #5719). The goal is to build the infrastructure on par with Windows 8.1 in terms of API functions and power management framework (PoFx). Further details and information of future planning works and what's been done can be found on that PR.

George has worked on re-implementing the power request IRPs mechanism following the Vista+ style. On Windows 2000, XP and Server 2003, device drivers had to call PoStartNextPowerIrp every time they were done with the power IRP on completion. The function notifies the Power Manager that the device driver is ready to process a power request IRP that has been put in queue. In addition to that, drivers had to call PoCallDriver in order to forward their power IRPs down the device stack.

With George's work this is no longer the case, as the Power Manager is now fully responsible to de-queue any power IRPs that were submitted by a PDO or FDO, and drivers can now call IoCallDriver. This makes the relationship between Power and I/O managers more tight.

Furthermore, George has been working on a prototype of a "Red Screen of Hell" screen prompt alongside with his plans for the thermal management in the kernel, via thermal zones. Here is an early prototype of the Red Screen of Hell (aka RSOH):

--- SCREENSHOT HERE ---

The main purpose of such a screen is to warn the user that ReactOS had to critically shutdown the system due to overheating, and that the user is advised to take action at preventing further overheating situations. This is to not be confused with a Blue Screen of Death (BSOD) as the user can go past the screen.

George also worked on the implementation of idle detection for device drivers. This helps with reduction of power consumption of devices that are idling for a long time, by putting them in a sleep state. Devices can do this by registering their idle times via PoRegisterDeviceForIdleDetection call.

At the moment, George is working on implementing composite battery support for ReactOS which is responsible to report battery status and capacity to the user. More details on this and screenshots will come in the future.

And here's the screenshot of RSOH:

[learn-more]

@DarkFire01 @GeoB99 what shall we do with this?

[DarkFire01]

@DarkFire01 @GeoB99 what shall we do with this?

Ill salvage it, a lot of interesting things has happened since maybe its time to talk about it.