OSDev.org

A Linux website claims that VESA mode setting is only possible in real mode. Is that true? And is it true for (U)EFI graphics, too?

Greetings
Peter

VESA means VBE - VESA BIOS extensions. Yes, there's a pmode interface in VBE 3.0, but you can't rely on it being supported.
Practically, yes, you need to set video mode in real mode.

UEFI is a completely different ball game. You can set video mode before ExitBootServices(). My OS loader loads the video mode from an INI file, or, if no matching setting is found, it offers a prompt with a list of supported modes!

Sort of.

If you can locate the appropriate option ROM, you can run it in an emulator and pass the video-card-related I/O to the actual hardware while emulating everything else. This can even work with multiple video cards, if you reconfigure the PCI VGA legacy support to direct legacy VGA accesses to the correct video card before running its ROM. This can even work with different types of option ROMs - you can emulate the UEFI option ROM on a legacy BIOS system, or the legacy option ROM on a UEFI system.

All of that is a massive pain, though, so it's easier to say you need to set the video mode in real mode for VBE, and prior to calling ExitBootServices() for UEFI.

Yes. (Or as others have pointed out, you can also use a real mode emulator)
Now this question makes no sense, because there's no VGA nor VESA under (U)EFI. Read this. What Octorontrabass wrote works only on UEFI machines that also has CSM mode (but I'm not sure it works on all firmware where CSM exists, but disabled).

Otherwise you'll have to use UGA on EFI (ReactOS' source, and some Nvidia ROMs) or with UEFI the GOP protocol. This latter superseded both UGA and VESA, and soon will be the only one to be supported by video card manufacturers.

It looks like we don't have much on GOP in our wiki, but this Assembly code shows how to query the modes, iterate on them and set one of them (pretty much the same functionality with VESA/VBE). For a C example, I can recommend my boot loader's relevant GetLFB(). This code basically iterates on available modes, looking for the resolution reqwidth x reqheight x 32bit RGBA. It also does some other things that would seem insane at first, but required to workaround buggy firmware (e.g. setting the current, active resolution to get the current mode value). If compiled with GOP_DEBUG, it will also list available modes.

Cheers,
bzt