Features Still Being Sought By Open-Source AMD Users

[chrno]

Just to be clear, are we only talking about the time between power-up and kernel driver initializing (when the driver takes over) ?

Indeed we are!

[bridgman]

You also need to consider the complexity (and costs) associated with the current solution. Both (all?) drivers must have options to turn underscan off. This is code that needs to be written and maintained. In addition, users must be able figure out how to use the option.

AFAIK the drivers don't have to "turn underscan off", they can simply not implement it. Nothing to maintain.

If the driver *does* implement it, and provide an option to turn it on and off, then that *does* need to be maintained but AFAIK that was taken out of the open source driver a long time ago... shortly after it was added IIRC

[agd5f]

I think it is. ;-) Having to run UEFI setup in 720p with a black border on my 1080p monitor is annoying and I did go through the trouble of disabling overscan on the monitor.

You had to go through the trouble of disabling overscan on the monitor in the first place. The problem is most hdmi TVs enable overscan by default, so unless you know enough to disable it, you will lose part of your screen at boot.

You also need to consider the complexity (and costs) associated with the current solution. Both (all?) drivers must have options to turn underscan off. This is code that needs to be written and maintained. In addition, users must be able figure out how to use the option. Both the former and the latter seem troublesome.

The open source radeon driver has an option to enable underscan, but it's off by default so you don't have to do anything once the driver loads. It can also be disabled in the catalyst drivers in both windows and Linux. So all you are really left with underscan by the vbios for the 5-10 seconds at boot before the driver loads.

[GreatEmerald]

Hmm, speaking about this problem, I've always been wondering about it: my screen, connected via digital DVI, in UEFI or GRUB always has an incorrect aspect ratio and is scaled down by the display (adding black bars), if using either AMD or NVIDIA cards; but if I use the integrated Intel GPU, it shows everything just fine, with the correct aspect ratio and without any black bars. IIRC the display shows the size as being 1920x1080 when using all three, so it's probably not an issue with the VESA modes supported by the hardware, but something else. So what could make the Intel IGP special in that regard?

Oh, and talking about VESA modes, what does their support depend on? Why don't so many cards have support for the most common resolutions, 1920x1080 and 1366x768?

[agd5f]

Hmm, speaking about this problem, I've always been wondering about it: my screen, connected via digital DVI, in UEFI or GRUB always has an incorrect aspect ratio and is scaled down by the display (adding black bars), if using either AMD or NVIDIA cards; but if I use the integrated Intel GPU, it shows everything just fine, with the correct aspect ratio and without any black bars. IIRC the display shows the size as being 1920x1080 when using all three, so it's probably not an issue with the VESA modes supported by the hardware, but something else. So what could make the Intel IGP special in that regard?

Oh, and talking about VESA modes, what does their support depend on? Why don't so many cards have support for the most common resolutions, 1920x1080 and 1366x768?

Vesa modes are sort of virtual modes provided by the vbios; they don't actually map directly to the timing sent to the monitor. The vbios fetches the edid from the monitor(s) and always programs the monitors' native timing. Non-native modes uses the scaler on the GPU. Otherwise, you couldn't use the vesa modes because a lot of monitors don't actually natively support them.

It's up the vbios to decide what to do in the case of hdmi TVs. Since most hdmi TV's overscan by default, the vbios (in the AMD case and it sounds like the NV case as well) downscales the image to compensate for the overscan on the TV. It sounds like the Intel vbios does not underscan. Note that there is no way to tell if an hdmi TV has enabled overscan or not, so neither the driver not the vbios knows whether the TV is overscanning or not.

As to the "modes" exposed as vesa modes, most vbioses just use a static list of common modes that were defined in early versions of the vesa vbe spec IIRC. Since most people use native OS gpu drivers, there was not much incentive to example the list of vesa modes as common monitor sizes changed. Also with UEFI, the the system now boots up with the native mode of the display by default in gfx mode rather than vga text mode.

[GreatEmerald]

It's up the vbios to decide what to do in the case of hdmi TVs. Since most hdmi TV's overscan by default, the vbios (in the AMD case and it sounds like the NV case as well) downscales the image to compensate for the overscan on the TV. It sounds like the Intel vbios does not underscan. Note that there is no way to tell if an hdmi TV has enabled overscan or not, so neither the driver not the vbios knows whether the TV is overscanning or not.

That's interesting. But as I mentioned, my monitor is not an HDMI TV, it's a DVI-D regular monitor. Does the same apply to them as well?

As to the "modes" exposed as vesa modes, most vbioses just use a static list of common modes that were defined in early versions of the vesa vbe spec IIRC. Since most people use native OS gpu drivers, there was not much incentive to example the list of vesa modes as common monitor sizes changed. Also with UEFI, the the system now boots up with the native mode of the display by default in gfx mode rather than vga text mode.

Huh, so in theory it would be possible to mod the VBIOS to allow for higher resolution or completely custom VESA modes? As for UEFI, what difference does it make? As far as I can see, UEFI still relies on the VESA modes provided by the card's VBIOS. I couldn't get the boot sequence to use the correct resolution on my AMD APU system with Catalyst, short of using uvesafb, despite the fact that it uses UEFI.

[curaga]

Huh, so in theory it would be possible to mod the VBIOS to allow for higher resolution or completely custom VESA modes? As for UEFI, what difference does it make? As far as I can see, UEFI still relies on the VESA modes provided by the card's VBIOS. I couldn't get the boot sequence to use the correct resolution on my AMD APU system with Catalyst, short of using uvesafb, despite the fact that it uses UEFI.

See i915resolution if you're interested; it does runtime patching of old Intel video BIOS just for that reason, to get proper resolutions.

[agd5f]

That's interesting. But as I mentioned, my monitor is not an HDMI TV, it's a DVI-D regular monitor. Does the same apply to them as well?

I think it depends on the native mode. If the connection is digital and the mode is an hdtv mode (1080p, 720p, etc.), then I suspect the vbios applies the underscan.

Huh, so in theory it would be possible to mod the VBIOS to allow for higher resolution or completely custom VESA modes? As for UEFI, what difference does it make? As far as I can see, UEFI still relies on the VESA modes provided by the card's VBIOS. I couldn't get the boot sequence to use the correct resolution on my AMD APU system with Catalyst, short of using uvesafb, despite the fact that it uses UEFI.

Vesa and UEFI only apply prior to the OS loading unless you are not using a native OS driver. Once the native driver has loaded it probes the displays directly. Also if you have an older PCIE/AGP card without a UEFI vbios, it will still use the legacy vesa vbios even if your system is UEFI since that is all there is to set up the display prior to the OS loading. As I said, once the OS loads the native driver, it takes over.

[GreatEmerald]

See i915resolution if you're interested; it does runtime patching of old Intel video BIOS just for that reason, to get proper resolutions.

It is interesting, yes. So apparently they take one of the existing, useless VESA modes and make it into a useful resolution. Unfortunately, that doesn't help with any modern hardware...

I think it depends on the native mode. If the connection is digital and the mode is an hdtv mode (1080p, 720p, etc.), then I suspect the vbios applies the underscan.

Well, my screen has something it calls "AV mode" that I can toggle. It changes the stretching a bit, and when it's on and set to 16:9, the picture is slightly bigger outside of OS, and is way too enlarged inside. It feels like it's doing overscanning or something. But yea, it's very possible that the monitor is reporting something really strange to the graphics cards, and only intel correctly interprets it.

Vesa and UEFI only apply prior to the OS loading unless you are not using a native OS driver. Once the native driver has loaded it probes the displays directly. Also if you have an older PCIE/AGP card without a UEFI vbios, it will still use the legacy vesa vbios even if your system is UEFI since that is all there is to set up the display prior to the OS loading. As I said, once the OS loads the native driver, it takes over.

Oh, so you mean that the VBIOS can by itself be UEFI? How do you tell if it is or isn't? And yes, I'm aware that the OS driver takes over as soon as it can, but it's always nice to have the same resolution throughout the boot process.

[agd5f]

Well, my screen has something it calls "AV mode" that I can toggle. It changes the stretching a bit, and when it's on and set to 16:9, the picture is slightly bigger outside of OS, and is way too enlarged inside. It feels like it's doing overscanning or something. But yea, it's very possible that the monitor is reporting something really strange to the graphics cards, and only intel correctly interprets it.

More likely either the vbios always enables underscan for native hdtv modes, or the monitor's edid has hdmi extension blocks (likely if it supports any sort of AV features beyond just display) which the vbios detects and enables underscan. Also, the Intel driver may be using a UEFI GOP driver while the add in cards may be using legacy vesa bioses.

Oh, so you mean that the VBIOS can by itself be UEFI? How do you tell if it is or isn't? And yes, I'm aware that the OS driver takes over as soon as it can, but it's always nice to have the same resolution throughout the boot process.

Most modern vbioses have both a legacy vbios and a GOP driver for UEFI. Which one gets uses depends on the the system bios (whether you are booting legacy, hybrid or native UEFI). If it uses the GOP driver, Linux will use efifb in the absense of a native driver, if it uses the legacy vbios, linux will use vesafb in the absense of a native driver.