Date
1 - 1 of 1
Change GOP mode runtime
Konstantin Aladyshev
Hello!
I have written an UEFI shell application that can set a mode for GOP.
And I try to use this app to increase the resolution of a display on
OVMF under QEMU.
I connect to the QEMU via VNC.
By default resolution is 800x600 (mode 2): https://pasteboard.co/KcponHH.png
If I change it to something bigger (mode 6: 1024x786) the display
changes its size, but the text area doesn't really change:
https://pasteboard.co/KcpowA5.png
My guess it is because the text area is controlled by a different
protocol: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. I can see its modes via
internal `mode` command:
```
FS0:\> mode
Available modes for console output device.
Col 80 Row 25 *
Col 100 Row 31
```
But this protocol always has only two modes. So I can't really change
its mode to fill all the display with the bigger resolution.
It looks like both modes were calculated for the default 800x600
screen (with/without padding).
What driver is responsible for this protocol?
Is there a way to somehow recalculate available modes for a console
output device runtime?
Best regards,
Konstantin Aladyshev
I have written an UEFI shell application that can set a mode for GOP.
And I try to use this app to increase the resolution of a display on
OVMF under QEMU.
I connect to the QEMU via VNC.
By default resolution is 800x600 (mode 2): https://pasteboard.co/KcponHH.png
If I change it to something bigger (mode 6: 1024x786) the display
changes its size, but the text area doesn't really change:
https://pasteboard.co/KcpowA5.png
My guess it is because the text area is controlled by a different
protocol: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL. I can see its modes via
internal `mode` command:
```
FS0:\> mode
Available modes for console output device.
Col 80 Row 25 *
Col 100 Row 31
```
But this protocol always has only two modes. So I can't really change
its mode to fill all the display with the bigger resolution.
It looks like both modes were calculated for the default 800x600
screen (with/without padding).
What driver is responsible for this protocol?
Is there a way to somehow recalculate available modes for a console
output device runtime?
Best regards,
Konstantin Aladyshev