OSDev.org

It seems now that both Windows and Linux have native graphics drivers that doesn't rely on VBE, more and more BIOSes will lack important VBE video modes, and soon probably will have a totally broken VBE interface. To get around this it would be better to simply setup the LFB in a driver, while NOT bothering with the acceleration support or 3D. After all, this shouldn't be so hard to do. Anybody tried to do this, and if so, is it possible to do without enormous amount of work? I'm primarily interested in Intel's and possibly AMDs graphics chips.

GOP may be significantly less versatile than VBE, it does have the advantage that it works pretty universally. And even Windoze needs a way to support new video cards that aren't on your installation CD.

It's funny that you have to mention VESA going broken in the future. It has happened in the past. One of my PCs had intel's integrated video combined with the memory controller (I don't recall what chipset it was). It claimed to be VBE3.0 and yet provided no LFB. It was in 2000.

While I haven't seen any really broken VESA BIOSes yet, we have a case of an Intel BIOS that lacks wide-screen resolutions (including the actual LCD resolution). At the moment we have put pressure on the manufacturer to fix this bug, but it would be better to actually drop the requirement for a video BIOS.

What GOP and UEFI supports is totally uninteresting for the moment, as UEFI is an incredibly broken design.

Hi,

rdos wrote:While I haven't seen any really broken VESA BIOSes yet, we have a case of an Intel BIOS that lacks wide-screen resolutions (including the actual LCD resolution). At the moment we have put pressure on the manufacturer to fix this bug, but it would be better to actually drop the requirement for a video BIOS.

What GOP and UEFI supports is totally uninteresting for the moment, as UEFI is an incredibly broken design.

Ironically; part of the reason VBE typically only gives you crusty old "4:3" video modes is that there simply isn't enough space in the 64 KiB video ROM to do anything properly. To really fix the problem you'd want to let the video card's ROM have 128 KiB or more; but that's not possible because of legacy/BIOS limitations on the "option ROM" area. Basically; part of the reason UEFI exists is to fix this (e.g. the video driver's ROM can be huge, and can therefore do things properly).


Cheers,

Brendan

Brendan wrote: Ironically; part of the reason VBE typically only gives you crusty old "4:3" video modes is that there simply isn't enough space in the 64 KiB video ROM to do anything properly. To really fix the problem you'd want to let the video card's ROM have 128 KiB or more; but that's not possible because of legacy/BIOS limitations on the "option ROM" area.

I think it is possible. The whole area up to F0000 is typically available.

Brendan wrote: Basically; part of the reason UEFI exists is to fix this (e.g. the video driver's ROM can be huge, and can therefore do things properly).

It doesn't fix anything. Part of any native video driver is the setup-code to be able to define which resolution you work with, and when you have native graphics support including acceleration support, you have no use for the crappy UEFI GOP initialization anyway. So, IMHO, if you need native video drivers anyway, because VBE is broken and GOP and UEFI booting is too primitive, I see no reason to go any other way than to write native video drivers, and the first step in writing any native video driver is to be able to enumerate video modes and setup them. Besides, with GOP you cannot change video mode "on-the-fly" which is not acceptable.

To make thing worse, it appears that video chip designers still have the old VGA with palette support (which is an utterly useless video-mode), but no easy hardware support for setting up LFB. Thus, the niche that VESA supposedly should have supported with software now is increasingly more often broken, and with no hardware support for LFB, Windoze and Linux can take over the complete market due to their hardware acceleration support which also includes the mode-set code.

@rdos: So now, we're basically left with these possibilities:

• use VGA: seriously?
• use VBE: better, but does it even work in long mode/compatability mode?
• use (U)EFI: looks good; the libraries (Tianocore, gnu-efi etc.) are flawed, but that doesn't mean that you can't take the parts you need, modify them and use them, provided you do it with proper licencing. Changing the resolution on-the-fly is useless to me: you'll never get a dual-monitor setup to work with any of the first 3.
• Accelerated Graphic Cards: this is hobbyist OSdev, are you serious? I'd like to see a hobby OS running on both nVidia and AMD cards, as well as in Bochs/QEMU. gl with that one

Even though you say UEFI is flawed (which it honestly is), it's the best thing that we have. The only thing you have to do with it is to get the LFB, the memory map and ExitBootServices().

Hi,

rdos wrote:

Brendan wrote: Ironically; part of the reason VBE typically only gives you crusty old "4:3" video modes is that there simply isn't enough space in the 64 KiB video ROM to do anything properly. To really fix the problem you'd want to let the video card's ROM have 128 KiB or more; but that's not possible because of legacy/BIOS limitations on the "option ROM" area.

I think it is possible. The whole area up to F0000 is typically available.

No. The 64 KiB area from 0x000C0000 to 0x000CFFFF is the only area the video ROM can use; and the area from 0x000D0000 to 0x000EFFFF is reserved for other devices (SCSI/disk controllers, network cards, whatever). However; because the BIOS itself has the same "not enough space" problem, on some machines the BIOS will use part of the space reserved for option ROMs (e.g. from 0x000E0000 to 0x000FFFFF). This mostly means that other devices (SCSI/disk controllers, network cards, whatever); which also had the "not enough space" problems themselves before the BIOS vendors decided to take an extra chunk, are now completely hammered.

Basically; once upon a time (when nobody had disk or network and video was CGA and there wasn't any EDID or El-torito or USB or SMP or ACPI or power management for the firmware to care about; and IBM thought PC was a temporary thing that'd be obsolete within 5 years anyway) it seemed like a good idea. By around 1985 they realised it was a severe mistake; but fortunately 80386 came along and allowed the firmware to get relocated to below 0xFFFFFFFF so that all of the POST and initialisation stuff didn't need to be in the legacy BIOS area; which allowed them to work around the problem a little while longer. By around 1990 everyone was struggling again. Fortunately PCI came along, where devices could leave part of their code in their real ROM and only copy the part they can't live without into the legacy option ROM space; allowing people to work around the problem a little while longer. Then by about 1995 everyone was struggling again; but they'd run out of silly work-arounds and everyone started being extremely cautious - neglecting support for any new features and stripping out old features (have you ever wondered why no video card ever provided support for VBE-AF?). They struggled with this stupidity for another 15 years.

rdos wrote:

Brendan wrote:Basically; part of the reason UEFI exists is to fix this (e.g. the video driver's ROM can be huge, and can therefore do things properly).

It doesn't fix anything. Part of any native video driver is the setup-code to be able to define which resolution you work with, and when you have native graphics support including acceleration support, you have no use for the crappy UEFI GOP initialization anyway. So, IMHO, if you need native video drivers anyway, because VBE is broken and GOP and UEFI booting is too primitive, I see no reason to go any other way than to write native video drivers, and the first step in writing any native video driver is to be able to enumerate video modes and setup them.

You need both. You need native drivers to get the best out of the hardware; but you also need something you can use during boot (before you're able to start the native driver) and a sane fall-back in case there are no drivers .

rdos wrote:To make thing worse, it appears that video chip designers still have the old VGA with palette support (which is an utterly useless video-mode), but no easy hardware support for setting up LFB. Thus, the niche that VESA supposedly should have supported with software now is increasingly more often broken, and with no hardware support for LFB, Windoze and Linux can take over the complete market due to their hardware acceleration support which also includes the mode-set code.

I'll be one of the first people to agree that VGA compatibility should've been deprecated/removed from video cards 20 years ago.

I very much doubt there's a video card that doesn't support LFB. There may be some where their VBE doesn't support LFB even though the hardware does; but I only have your word on that because nobody else has ever seen it happen (which really makes me wonder if it's a problem with your software in the first place and not the video card's VBE to blame at all).

rdos wrote:Besides, with GOP you cannot change video mode "on-the-fly" which is not acceptable.

Needing to change video modes "on-the-fly" is a direct consequence of failing to provide a modern graphics API (e.g. with resolution independence).


Cheers,

Brendan

Even with a resolution-independent API there are still times you'll want to change the resolution.

Hi,

Rusky wrote:Even with a resolution-independent API there are still times you'll want to change the resolution.

Yes; when playing poorly designed 3D games that require hardware acceleration on old/slow hardware (where the GPU can't cope and you want to reduce resolution to get better frame rates); and for playing ancient DOS games (in DOSbox) that require a specific resolution (where you want to change video mode so you can run it full screen instead of in a window, until you realise the aspect ratio is all wrong); and when you replace the monitor (which happens so rarely that nobody minds too much if they need to reboot).

I very much doubt any of these are a valid reason for RDOS (because its intended for embedded systems, where users can't play games or change the hardware/screen).

Mostly; I agree that being able to change video modes after boot would be a nice feature; I just don't think it's sane to complain that the video support UEFI provides (which is only intended for use during boot and as a fall-back when there's no video driver) isn't designed to support this mostly irrelevant luxury.


Cheers,

Brendan

Rusky wrote:Even with a resolution-independent API there are still times you'll want to change the resolution.

The primary need is to be able to switch between text-mode and graphics mode, because you don't want to run the console in emulated mode.

Besides, even if you have only one application (running in graphics mode), you definitely wants it to exploit some native mode, and you don't want "resolution independence" and scaling everything. That's for windowing apps, not for full-screen embedded apps.

no92 wrote:use VBE: better, but does it even work in long mode/compatability mode?

No, you cannot run the real-mode VBE mode switch operation from long mode. You need to switch the processor core to protected mode in order to do that. Not a problem in my design though, as I can switch freely between protected mode and long mode based on the bitness of the running process/application.

no92 wrote:use (U)EFI: looks good; the libraries (Tianocore, gnu-efi etc.) are flawed, but that doesn't mean that you can't take the parts you need, modify them and use them, provided you do it with proper licencing. Changing the resolution on-the-fly is useless to me: you'll never get a dual-monitor setup to work with any of the first 3.

The main problem with many UEFI BIOSes is that they are "locked-down" to the OS the manufacturer intended everybody to run (mostly Windows). In my experience, it is much safer to just turn off UEFI than to try to get the UEFI BIOS to boot your EFI-loader (rather than Windows).

no92 wrote:Accelerated Graphic Cards: this is hobbyist OSdev, are you serious? I'd like to see a hobby OS running on both nVidia and AMD cards, as well as in Bochs/QEMU. gl with that one

True, but RDOS no longer belongs in the hobbyist category, so I wouldn't exclude the possibility to do accelerators for specific hardware.

There are of course, plenty of other reasons why you might want to change resolution at runtime. Here's a few that have nothing to do with games performance or text mode:

• User wants to watch a 60fps 1080p movie full-screen on their consumer-level 4k monitor that only supports its native resolution at 30Hz.
• Laptop user pulled their system out of the docking station and the now disconnected external monitor is a higher resolution than the built-in LCD.
• User plugs a projector into an external output splitter. Projector has a lower maximum resolution than their monitor.

rdos wrote:No, you cannot run the real-mode VBE mode switch operation from long mode.

rdos wrote:All you would do is to create a console that is painfully slow (and that lacks a hardware cursor unless you emulate that too).

I wrote a naive "OS" implementation in 2012 and I had a video mode set up by a BIOS/UEFI boot loader. I used very unoptimized procedures for writing raster fonts on the screen but it still scrolled the console blazingly fast. I wonder how it is possible to even have a "painfully slow" console.