UEFI firmware appears to support GOP or UGA graphics protocols. GOP is newer and has replaced UGA. On my machine which does not have an integrated graphics adapter (only a discrete graphics adapter NVIDIA GTX 965m), I found that upon live booting a Linux installation CD, there is no kernel module driving my graphics card (I checked lspci and X logs).

After doing some research on UEFI, I found these 2 kinds of graphics protocols, and I was wondering if there was a way (a command line query) to find out which of the 2 is being used, because it seems that it is the UEFI firmware that is providing the ability to drive my machine's display (probably through my "VGA compatible" discrete graphics card).

Furthermore, at the BIOS settings (is it still called a BIOS settings when using UEFI firmware?), I was also able to change my Video Op Rom settings to "BIOS compatibility mode". When I left it as "UEFI only", I got full resolution at the BIOS configuration settings and at the POST display, and boot loader display. When choosing "BIOS compatibility mode", I got a much smaller resolution. Does this basically mean the firmware was able to use the VGA protocol instead?

  • 1
    AFAIK, everything but Macs uses GOP? Though none of that matters; Linux does not use UEFI drivers at all – the firmware unloads all drivers during ExitBootServices() and talks to the graphics card directly via PCI. – user1686 Jan 24 '16 at 13:23
  • If that was true, then how come my lspci shows no "Kernel drivers in use" for my NVIDIA graphics card? And switching between BIOS and UEFI in my Video Op Rom settings changes the resolution for my entire session. And also I'm booting a Live CD which doesn't load any nvidia or nouveau drivers for the NVIDIA card. – CMCDragonkai Jan 24 '16 at 14:27
  • Hmm, I may be wrong about that, considering @Rod's post. (efifb would have to know which protocol it speaks, after all.) – user1686 Jan 25 '16 at 7:35

To elaborate on grawity's answer, there are several issues, of varying degrees of relevance, to your question:

  • UGA vs. GOP -- As you say, there are two EFI video systems, UGA and GOP. The latter was introduced with EFI 2.x (aka UEFI), IIRC, and AFAIK all UEFI-based systems use GOP. In principle, all EFI 1.x systems should use UGA; however, Apple (which still uses EFI 1.x, even in its most recent products) has ported UGA to its EFI, so some (but not all) Macs have EFI 1.x with GOP. There may be other oddball exceptions. As grawity says, this distinction is important at the firmware level, but not really at the OS level, at least not AFAIK.
  • Linux framebuffer devices -- Whether it's UGA or GOP, the firmware gives the OS access to its video hardware, which Linux exposes via a framebuffer device -- specifically, efifb. On EFI-based systems, this is often the basis for text-mode operation (if you don't start X or if you hit Ctrl+Alt+F1 through Ctrl+Alt+F6). OTOH, there are also framebuffer devices provided by some kernel drivers for specific video chipsets, so you might not end up using the efifb device. I don't know offhand if there are any differences in the way UGA and GOP present themselves to the OS. Certainly I know of no differences at a higher level, like commands you'd use in Linux.
  • X Window System drivers -- X drivers can rely on kernel video drivers or be basically independent of them. In most cases, you use an X driver that's written for a specific video chipset (ATI, Nvidia, Intel, etc.), and these don't work through the firmware. Thus, these drivers should not be affected by UGA vs. GOP (or even BIOS vs. EFI, although there are some caveats about that). That said, there is an X framebuffer driver that will work via whatever framebuffer device is active, including the efifb device. Thus, you could be driving a display via the EFI's UGA or GOP modes. This is definitely a sub-optimal way to do it, though, because the framebuffer drivers tend to be slow. Modern windowing environments, including Ubuntu's Unity, are increasingly relying on video acceleration features that aren't accessible through a framebuffer.

You can see some of this at work by examining the kernel ring buffer via dmesg, as in:

$ dmesg | grep fb
[    0.625015] efifb: probing for efifb
[    0.625207] efifb: framebuffer at 0xc0000000, mapped to 0xffffc90010880000, using 3072k, total 3072k
[    0.625208] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    0.625209] efifb: scrolling: redraw
[    0.625210] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.627994] fb0: EFI VGA frame buffer device
[    6.086695] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
[    6.689526] [drm] fb mappable at 0xC1488000
[    6.689531] [drm] fb depth is 24
[    6.689610] fbcon: radeondrmfb (fb0) is primary device
[    6.804904] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device

This example shows a number of framebuffer-related messages on a system with an AMD/ATI GPU. You'll note there's no mention of UGA vs. GOP, but the efifb device is referenced, as is fbcon (the framebuffer console) and radeondrmfb (the framebuffer device for ATI/AMD Radeon devices). The removing generic driver message denotes a handoff from the efifb driver to the radeondrmfb driver. You can also examine /var/log/Xorg.0.log for messages related to the X server. In the case of my system, these are less interesting, but if you're having problems with X starting up, Xorg.0.log may be of more interest to you.

One more point: When asking for help on hardware issues, it's generally important that you specify what your hardware is -- "a discrete graphics adapter" is insufficiently specific when soliciting help on your video problem. For that matter, it's not clear what your problem is -- or are you simply looking for information on how it all fits together so as to further your understanding?

| improve this answer | |
  • Great detailed answer, made a lot of sense. My specific problem was trying to understand why X display-manager wouldn't start on my live CD (NIXOS) when I was booting via UEFI Video OpROM, while booting through Legacy Video OpROM, the X display-manager could then start (and the logs indicate it uses VESA VBE). I'll check my kernel logs and get back to you. Also my discrete GPU is NVIDIA GTX 965m. – CMCDragonkai Jan 25 '16 at 8:17
  • So I found efifb and fb0 in the kernel logs. But you mentioned that X can use efifb to display things, but checking the X logs, there's no mention of efifb at all? – CMCDragonkai Jan 25 '16 at 9:34
  • This sounds like either a bug in your motherboard's firmware or an issue of lacking or buggy EFI support in your video card's firmware. You might get more help if you post four files to a pastebin site: Your dmesg and Xorg.0.log file from both video option settings in your firmware. (That is, two dmesg outputs and two Xorg.0.log files.) I myself am not an expert at debugging video problems, so I may not be able to help; but perhaps somebody will. You may want to start a new question that provides the relevant pointers up front. – Rod Smith Jan 25 '16 at 17:29
  • It does seem that NVIDIA has poor support for UEFI Video Op ROM. So I switched to legacy video op rom, and the NVIDIA driver has full resolution on tty7, while tty1 is at low resolution atm. – CMCDragonkai Jan 26 '16 at 4:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.