mirrors/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity.git synced 2025-01-23 18:02:05 -05:00
Code Issues Projects Releases Packages Wiki Activity

Kernel/Graphics: Simplify initialization flow explanation comment

Browse source 
Most of it was not relevant anymore to what we do in the initialization
method anyway, and now it represents it quite well and "to the point".
This commit is contained in:
Liav A 2022-07-09 09:13:00 +03:00 • committed by Linus Groh
parent 5824f30752
commit 4771917184
1 changed files with 8 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
Kernel/Graphics/GraphicsManagement.cpp
View file

@ -174,45 +174,18 @@ UNMAP_AFTER_INIT void GraphicsManagement::initialize_preset_resolution_generic_d
UNMAP_AFTER_INIT bool GraphicsManagement::initialize() UNMAP_AFTER_INIT bool GraphicsManagement::initialize()
{ {
/* Explanation on the flow when not requesting to force not creating any /* Explanation on the flow here:
* framebuffer devices: *
* If the user wants to use a Console instead of the graphical environment, * If the user chose to disable graphics support entirely, then all we can do
* they doesn't need to request text mode. * is to set up a plain old VGA text console and exit this function.
* Graphical mode might not be accessible on bare-metal hardware because * Otherwise, we either try to find a device that we natively support so
* the bootloader didn't set a framebuffer and we don't have a native driver * we can initialize it, and in case we don't find any device to initialize,
* to set a framebuffer for it. We don't have VBE modesetting capabilities * we try to initialize a simple DisplayConnector to support a pre-initialized
* in the kernel yet, so what will happen is one of the following situations:
* 1. The bootloader didn't specify settings of a pre-set framebuffer. The
* kernel has a native driver for a detected display adapter, therefore
* the kernel can still set a framebuffer.
* 2. The bootloader specified settings of a pre-set framebuffer, and the
* kernel has a native driver for a detected display adapter, therefore
* the kernel can still set a framebuffer and change the settings of it.
* In that situation, the kernel will simply ignore the Multiboot pre-set
* framebuffer. * framebuffer.
* 2. The bootloader specified settings of a pre-set framebuffer, and the
* kernel does not have a native driver for a detected display adapter,
* therefore the kernel will use the pre-set framebuffer. Modesetting is not
* available in this situation.
* 3. The bootloader didn't specify settings of a pre-set framebuffer, and
* the kernel does not have a native driver for a detected display adapter,
* therefore the kernel will try to initialize a VGA text mode console.
* In that situation, the kernel will assume that VGA text mode was already
* initialized, but will still try to modeset it. No switching to graphical
* environment is allowed in this case.
* *
* By default, the kernel assumes that no framebuffer was created until it * Note: If the user disabled PCI access, the kernel behaves like it's running
* was proven that there's an existing framebuffer or we can modeset the
* screen resolution to create a framebuffer.
*
* Special cases:
* 1. If the user disabled PCI access, the kernel behaves like it's running
* on a pure ISA PC machine and therefore the kernel will try to initialize * on a pure ISA PC machine and therefore the kernel will try to initialize
* a variant that is suitable for ISA VGA handling, and not PCI adapters. * a variant that is suitable for ISA VGA handling, and not PCI adapters.
*
* If the user requests to force no initialization of framebuffer devices
* the same flow above will happen, except that no framebuffer device will
* be created, so SystemServer will not try to initialize WindowServer.
*/ */
auto graphics_subsystem_mode = kernel_command_line().graphics_subsystem_mode(); auto graphics_subsystem_mode = kernel_command_line().graphics_subsystem_mode();