GOP: Difference between revisions

Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
m (Bot: Replace deprecated source tag with syntaxhighlight)
m (Added some information on how to add UEFI GOP compatibility to kernel's using the Multiboot2 protocol)
Line 8: Line 8:
=== Detecting GOP ===
=== Detecting GOP ===
As with other UEFI protocols, you have to locate a structure with the function pointers first using the protocol's GUID.
As with other UEFI protocols, you have to locate a structure with the function pointers first using the protocol's GUID.
<syntaxhighlight lang="c">
<source lang="c">
EFI_GUID gopGuid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
EFI_GUID gopGuid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
Line 15: Line 15:
if(EFI_ERROR(status))
if(EFI_ERROR(status))
PrintLn(L"Unable to locate GOP");
PrintLn(L"Unable to locate GOP");
</source>
</syntaxhighlight>
GOP is the default protocol, so you should be able to locate it on all UEFI firmware. It can probably only fail if you're on an old EFI (pre-UEFI) machine, like an Itanium-based computer or a Mac released before 2009.
GOP is the default protocol, so you should be able to locate it on all UEFI firmware. It can probably only fail if you're on an old EFI (pre-UEFI) machine, like an Itanium-based computer or a Mac released before 2009.

If your kernel uses GRUB, you need to insert a module called "all_video" before loading the kernel to add UEFI GOP compatibility. Not doing so will display a message saying "WARNING: no console will be available to OS".
<source lang="c">
insmod all_video

menuentry "Example OS" {
multiboot2 /boot/kernel.bin
boot
}
</source>


=== Get the Current Mode ===
=== Get the Current Mode ===
In order to get the mode code for the current video mode, you must set the mode as well to circumvent some buggy UEFI firmware. Otherwise this is done using the QueryMode function, and then gop->Mode->Mode will contain the code.
In order to get the mode code for the current video mode, you must set the mode as well to circumvent some buggy UEFI firmware. Otherwise this is done using the QueryMode function, and then gop->Mode->Mode will contain the code.
<syntaxhighlight lang="c">
<source lang="c">
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *info;
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *info;
UINTN SizeOfInfo, numModes, nativeMode;
UINTN SizeOfInfo, numModes, nativeMode;
Line 34: Line 44:
numModes = gop->Mode->MaxMode;
numModes = gop->Mode->MaxMode;
}
}
</source>
</syntaxhighlight>


=== Query Available Video Modes ===
=== Query Available Video Modes ===
Similarly to VESA, there's no standard mode codes, rather you have a function to query the available modes. Now you know how many modes there are (numModes above), and which one is currently set (nativeMode). You can iterate on the modes and query the information structure for each:
Similarly to VESA, there's no standard mode codes, rather you have a function to query the available modes. Now you know how many modes there are (numModes above), and which one is currently set (nativeMode). You can iterate on the modes and query the information structure for each:
<syntaxhighlight lang="c">
<source lang="c">
for (i = 0; i < numModes; i++) {
for (i = 0; i < numModes; i++) {
status = uefi_call_wrapper(gop->QueryMode, 4, gop, i, &SizeOfInfo, &info);
status = uefi_call_wrapper(gop->QueryMode, 4, gop, i, &SizeOfInfo, &info);
Line 49: Line 59:
);
);
}
}
</source>
</syntaxhighlight>


=== Set Video Mode and Get the Framebuffer ===
=== Set Video Mode and Get the Framebuffer ===
This is pretty easy. The mode argument is between 0 and numModes.
This is pretty easy. The mode argument is between 0 and numModes.
<syntaxhighlight lang="c">
<source lang="c">
status = uefi_call_wrapper(gop->SetMode, 2, gop, mode);
status = uefi_call_wrapper(gop->SetMode, 2, gop, mode);
if(EFI_ERROR(status)) {
if(EFI_ERROR(status)) {
Line 67: Line 77:
);
);
}
}
</source>
</syntaxhighlight>
To get the same value as scanline in VESA (also commonly called pitch in many graphics libraries), you have to multiply PixelsPerScanLine by the number of bytes per pixel. That can be detected by examining the gop->Mode->Info->PixelFormat field. For example with 32 bit packed pixel formats,
To get the same value as scanline in VESA (also commonly called pitch in many graphics libraries), you have to multiply PixelsPerScanLine by the number of bytes per pixel. That can be detected by examining the gop->Mode->Info->PixelFormat field. For example with 32 bit packed pixel formats,
<syntaxhighlight lang="c">
<source lang="c">
pitch = 4 * gop->Mode->Info->PixelsPerScanLine;
pitch = 4 * gop->Mode->Info->PixelsPerScanLine;
</source>
</syntaxhighlight>


=== Plotting Pixels ===
=== Plotting Pixels ===
Line 77: Line 87:
Now you can use the returned framebuffer exactly the same way as you would with VESA, there's absolutely no difference.
Now you can use the returned framebuffer exactly the same way as you would with VESA, there's absolutely no difference.
To calculate the offset for an (X,Y) coordinate on screen, do pitch*Y+pixelbytes*X. For example for 32 bit true-color (where pixelbytes is 4):
To calculate the offset for an (X,Y) coordinate on screen, do pitch*Y+pixelbytes*X. For example for 32 bit true-color (where pixelbytes is 4):
<syntaxhighlight lang="c">
<source lang="c">
static inline void PlotPixel_32bpp(int x, int y, uint32_t pixel)
static inline void PlotPixel_32bpp(int x, int y, uint32_t pixel)
{
{
*((uint32_t*)(gop->Mode->FrameBufferBase + 4 * gop->Mode->Info->PixelsPerScanLine * y + 4 * x)) = pixel;
*((uint32_t*)(gop->Mode->FrameBufferBase + 4 * gop->Mode->Info->PixelsPerScanLine * y + 4 * x)) = pixel;
}
}
</source>
</syntaxhighlight>
For drawing characters, you can use the same method described in [[VGA Fonts]].
For drawing characters, you can use the same method described in [[VGA Fonts]].