VBE protected mode interface?

[clementttttttttt]

Is there any documentation for that? (YES, I understand that I would need to go through a lot of trouble to set it up and it may not be supported on every graphics card, I just wanted to experiment with it)

[Octocontrabass]

Here's the latest version of the specification. You're probably looking for the sections titled "Obtaining the Protected Mode Entry Point" and "Calling the Protected Mode Entry Point".

[nullplan]

Hmmm... now here's a fun question: Is the segment descriptor cache updated in 64-bit mode when a new segment is loaded? The linked document details that you need to pass memory buffers in ES:DI as valid 16-bit pointers. While I can prepare a GDT entry for ES and can load ES with the appropriate value in 64-bit mode, this is not going to help a lot when I switch to 16-bit mode and find that ES:DI does not point to the buffer I need. And if I need to be in 16-bit mode to load ES, then every VBE function call would have to go through two far calls: One to my own routine to update ES, and then another call into VBE.

EDIT: I also noticed that in 64-bit mode, all my kernel mode addresses are > 0xffff_8000_0000_0000. In order to use VBE, I would need at least some addresses <4GB, and the only thing I have that can map those addresses is a userspace task. This means I would have to have a VBE task and direct requests to it. Having full-blown userspace support of 16-bit mode would open a can of worms I would like to remain closed for a while longer, though. So I would probably have to create a special type of kernel task. One that does have its own lower half, but is still executing at ring 0. This is getting more complicated by the second.

[bzt]

Is there any documentation for that? (YES, I understand that I would need to go through a lot of trouble to set it up and it may not be supported on every graphics card, I just wanted to experiment with it)

It's better to say it's miracle if you can find a card that supports it. It really doesn't worth the effort imho.

Cheers,
bzt

[rdos]

Hmmm... now here's a fun question: Is the segment descriptor cache updated in 64-bit mode when a new segment is loaded? The linked document details that you need to pass memory buffers in ES:DI as valid 16-bit pointers. While I can prepare a GDT entry for ES and can load ES with the appropriate value in 64-bit mode, this is not going to help a lot when I switch to 16-bit mode and find that ES:DI does not point to the buffer I need. And if I need to be in 16-bit mode to load ES, then every VBE function call would have to go through two far calls: One to my own routine to update ES, and then another call into VBE.

EDIT: I also noticed that in 64-bit mode, all my kernel mode addresses are > 0xffff_8000_0000_0000. In order to use VBE, I would need at least some addresses <4GB, and the only thing I have that can map those addresses is a userspace task. This means I would have to have a VBE task and direct requests to it. Having full-blown userspace support of 16-bit mode would open a can of worms I would like to remain closed for a while longer, though. So I would probably have to create a special type of kernel task. One that does have its own lower half, but is still executing at ring 0. This is getting more complicated by the second.

If the protected mode interface actually worked in protected mode, which it typically won't, you would need to switch to compatibility mode if you are in long mode. Selectors don't work in long mode.

In reality though, you will need to switch from long mode to protected mode (or even real mode) and call VBE from there. Long mode doesn't support V86 mode.

As for loading selectors in long mode, this actually does work, and the cached vaules will take affect once you switch to compatibility mode, but I don't see what the advantage of doing this in long mode would be.

As for buffers, you will need to keep them below 1 MB, but you can achieve this with paging. However, since the protected mode interface typically won't work, you will need to switch to real mode, or setup PAE paging in protected mode and use V86 mode. If you go for real mode, then you need buffers with physical addresses below 1MB, while in protected mode, they can reside anywhere if you setup PAE paging.

PAE paging isn't that bad given that it is compatible with long mode paging. Still, you will need linear addresses below 4G to be mapped (or rather below 1MB since the protected mode interface typically won't work).

[nullplan]

If the protected mode interface actually worked in protected mode, which it typically won't, you would need to switch to compatibility mode if you are in long mode. Selectors don't work in long mode.

In reality though, you will need to switch from long mode to protected mode (or even real mode) and call VBE from there. Long mode doesn't support V86 mode.

As for loading selectors in long mode, this actually does work, and the cached vaules will take affect once you switch to compatibility mode, but I don't see what the advantage of doing this in long mode would be.

As for buffers, you will need to keep them below 1 MB, but you can achieve this with paging. However, since the protected mode interface typically won't work, you will need to switch to real mode, or setup PAE paging in protected mode and use V86 mode. If you go for real mode, then you need buffers with physical addresses below 1MB, while in protected mode, they can reside anywhere if you setup PAE paging.

PAE paging isn't that bad given that it is compatible with long mode paging. Still, you will need linear addresses below 4G to be mapped (or rather below 1MB since the protected mode interface typically won't work).

Oh wow. The more I learn about VBE, the less I like it. If I have to switch to PM, that essentially means I have to disable my OS for some time (because my interrupt handlers can't run in PM). Then it really does not matter if I switch to PM or RM, and RM is the more compatible choice. So might as well use that. I had hoped to use compatibility mode for this, yes, but since that is not an option, back to real mode we go, I suppose.

I have to concur with bzt, it really seems not worth the effort. Might as well let the bootloaders handle it, as they are doing right now. Oh well, it was just idle musings, anyway.

[rdos]

Oh wow. The more I learn about VBE, the less I like it. If I have to switch to PM, that essentially means I have to disable my OS for some time (because my interrupt handlers can't run in PM). Then it really does not matter if I switch to PM or RM, and RM is the more compatible choice. So might as well use that. I had hoped to use compatibility mode for this, yes, but since that is not an option, back to real mode we go, I suppose.

I have to concur with bzt, it really seems not worth the effort. Might as well let the bootloaders handle it, as they are doing right now. Oh well, it was just idle musings, anyway.

Kind of. Initially, I was against the idea of setting up the video mode at boot time, but with EFI I had to support this setup anyway, and nowadays I typically do this with VBE too. The ability to setup any video-mode with VBE might seem attractive, but it is better to permanently setup the native resolution of the display.

The drawback is that on old hardware without modern VBE I would need to use text mode at boot time, and so I will probably keep the possibility to boot to text mode.

Also, text mode is much easier & faster to implement than creating bitmapped graphics on the command line, and so if the system only needs text mode then there is no use in setting up VBE at boot time as text mode will be much faster.

[Octocontrabass]

Is the segment descriptor cache updated in 64-bit mode when a new segment is loaded?

Yes. The cached descriptor values apply as soon as you jump to compatibility mode.

Having full-blown userspace support of 16-bit mode would open a can of worms I would like to remain closed for a while longer, though.

I prefer to use an x86 emulator. That way, VBE works in odd situations like multiple display adapters (provided the PCI bus is configured to forward legacy VGA accesses to the appropriate device for each option ROM) and non-x86 systems (assuming a VBE option ROM exists in the first place).

You can do something similar with UGA and GOP option ROMs. UGA was specifically designed to work this way!