linuxyne wrote:
zaval wrote:
There is no "text" mode in UEFI.
UEFI hasn't deprecated/outlawed text-mode. In fact, the spec requires all output
devices to implement 80x25 text-mode, at least.
STOP explicitly says it is meant for controlling "text-based ConsoleOut device".
GOP says:
"A unique Graphics Output protocol must represent each video frame buffer in
the system that is driven out to one or more video output devices."
The spec does not mandate that the ConOut be based on a frame-buffer, or
have its framebuffer be the same as, the GOP provided framebuffer.
Hence, it should be okay for the firmware to expose the VGA text-mode as ConOut,
or to utilize a ConOut framebuffer different in size than that setup by GOP.
In both of these cases, either ConsoleControlProtocol.SetMode, or GOP.SetMode,
or LocateProtocol for GOP, or some other out-of-band indication is required, in
order to inform the firmware that its client wants to switch away from the
ConOut.
But those words are descriptions what the protocols are in essence, it's not refering to assumed hardware internals. For UEFI, there is no VGA text mode and graphical mode of some hardware. The protocol you are constantly referring to (CCP) doesn't even exist in the spec (>2.xx). STOP and GOP are abstractions. the 1st represents an 2D array of characters, the latter 2D array of pixels on a linear buffer. No further assumptions on the internal organization. No VGA stuff. STOP's SetMode sets matrix width/height in characters, GOP's one is more low level and operates on pixel resolution. If you use a STOP
instance and GOP instance on the same output device, the mode in effect would be that set by the last call to GOP.SetMode for pixels and by STOP.SetMode for characters. ConOut is mutiinstance, it sends STOP based output to many devices, including GOP capable display system and text only serial (terminal) connection.
GOP and STOP coexist in the straight sense, that fw allows you to both print text (via ConOut e.g.) to a monitor and paint/draw your stuff to the same monitor at the same time. there is never any prohibition (nor preparation) on doing so. except maybe self censoring.
The belliash case is a fw bug. it really lies about what exactly resolution the FB is in. What is the cause of this, only the bug introducers know, but it's not sure, even they do.
Quote:
I think CCP must have been introduced specifically for this purpose: switching
between text-mode and graphics-mode.
Forget this outdated or non-standard invention, it only makes further confusions.
This is what I wanted to disagree with: again there is no such a "switching" in UEFI. You can you use both. All you need is to get a corresponding protocol instance. ConOut is particularly not very useful because of being noisy - it broadcasts its output to all suitable out devices, trashing cuteness on the screen, so I for example specifically search a STOP instance on a serial interface to send there trace print, leaving the display for the Boot Screen.
The only switches in UEFI are between modes, for both text and pixel resolutions. The former is being done via STOP.SetMode the latter via GOP.SetMode.
Quote:
zaval wrote:
The spec doesn't require from loaders to worry about STOP and GOP coexistence. If there are no bugs, they coexist normally.
Given that Windows has no troubles with its bootup screens on this laptop, do we
think it assumes that STOP and GOP coexist? If it did, it would have run into
the same problem as belliash and limine did.
As I've said, Windows loader most probably, knowing the oddities of implementations, explicitly requests available resolutions (GOP ones) and sets what it likes. This is what I suggested to belliash as well. Or even using some BIOS compatibility magic.
It's not the 1st time when Windows loader works when your one doesn't no matter, how hard it followed the spec. We discussed recently a similar bug with that Device Path Protocol-less handle for one of 2 GOP instances. On my HP Probook 4530s, this thing doesn't want to draw, while reporting success on Blt() calls. Windows's loader does draw successfully. After picking the other, DPP containing handle and using its GOP instance, the drawing appears on the screen. For the former, it appears only after the loader exits to firmware back!
And btw, both GOP instances report the same FB base! So, it's a bug. Just like here.
Quote:
STOP isn't necessarily pixel-addressible, while GOP is. They cannot be assumed
to coexist on a single output device.
They can be assumed to coexist. And ConOut variable is the proof. It is an embodiment of their coexistence on your main monitor. That's why you can use STOP printing and GOP painting to your display in parallel. Note, this simultaneous usage works in a vast majority of cases, so isn't it a practical proof that it is supposed to be so, if the spec formulations aren't clear enough for you? STOP isn't pixel addressable at all. It's characted based, but it doesn't expose any VGA-isms to you, it's just an abstract 2D matrix of characters. The only "control" is the already mention setting different text resolutions. ah and fooling around with colors. Apparently STOP is made atop of GOP. At least from the logical perspective.
Quote:
Edit: edk2 has "Graphics Console Driver" [3], that consumes GOP and produces
an STOP. But this is specifically implemented as such; it does not rely on the
assumption that GOP and STOP coexist on the same output device.
It's rather a proof of my above conclusions on their relations. This "specificalty" is a logical consequence.
Modern hardware doesn't use VGA, but rather some flat linear pixel buffers, so you first implement GOP,
and then produce STOP, that consumes GOP.