VBE disscussion

[Jezze]

I went to the #nouveau channel and asked a few questions about how they deal with mode settings now when KMS is in place. After reading the osdev wiki about VBE and the difficulties in finding a simple way to change video modes once you are in 32 bit protected mode I had to ask them how they handle it.

Appearently VBE isn't used at all these days for Nvidia chips and probably not for most others. Nvidia gets it's mode information from KMS but KMS does not use VBE to obtain the possible modes. Instead it looks at what the monitor supports. Appearently a Nvidia chip can handle just about any mode as long as it is reasonable so the limitations are set by the monitor. It makes perfect sense really.

I also took a look at the code to see just how they change it. From what I could see it was not difficult at all. Not that different from what you would do if you wrote a driver for BGA actually. My preconception was that the only option you have if you do not want to use VBE is to write a driver for every graphic card out there. Now I know this sounds like a huge task but for me and probably a few others we are just interested in writing drivers for the cards we own, and not even complete drivers, just enough so they can change mode and put a pixel.

Now I'm just telling you this because I had no idea it worked like that and I think that writing mode settings for each graphic card might actually be a less difficult and more appropriate task than getting a running VM86 just for parsing the VBE especially since you still need to look at what the monitor supports.

Do you think we should add some information about this on the wiki?

[Combuster]

VBE just has a wrapper on the DDC/I2C bus that's part of a standard monitor cable. If you can program the hardware, you can program the I2C bus controller and ask the monitor for it's EDID yourself. Basically, if you have the information to switch modes without VBE (which usually is world's biggest problem), you will also be able to find the information on grabbing EDIDs.

But since VBE is a generic interface for a video card, it should be obvious that a native driver would be able to supersede all capabilities of that interface. And the fact that one-driver-per-card is a true alternative for VBE should have given that hint too.

The Video Signals And Timing page references EDID in a few places, because it's the least interesting part of manually setting a mode. It might still be useful to add some additional information to the page on the topic besides a link.

[guyfawkes]

First thanks for the info.
But switching VESA MODES from Pmode is about 20 lines of ASM code.
So its not a problem.

[Combuster]

But switching VESA MODES from Pmode is about 20 lines of ASM code.

Where did the C code go? I have four times that in lines of assembly code just for v8086 support, and that excludes the VM monitor and the code that actually sets up the calls...

Sure, you can jump to real mode and call the BIOS. It's the simplest and shortest solution, but also the most broken and the least professional solution you can get.

[guyfawkes]

Sure, you can jump to real mode and call the BIOS. It's the simplest and shortest solution, but also the most broken and the least professional solution you can get.

You say its most broken, but i have never had a problem with that part of my code, its never crashed in any tests i have done or anyone else when switching modes.
I always say 'if it's not broke, than do not fix it.

And v8086 support to me is just a glory form of switching back

[Brendan]

Hi,

Sure, you can jump to real mode and call the BIOS. It's the simplest and shortest solution, but also the most broken and the least professional solution you can get.

You say its most broken, but i have never had a problem with that part of my code, its never crashed in any tests i have done or anyone else when switching modes.
I always say 'if it's not broke, than do not fix it.

And v8086 support to me is just a glory form of switching back

When you start implementing device drivers and find out that none of them are reliable because IRQs are lost when you switch back to real mode to change video modes; will you decide that all your device drivers (and any IO APIC/MSI code, and anything you do to PCI configuration space) is broken and have an OS that has no device drivers and no support for modern hardware; because using real mode to switch video modes "worked" and therefore couldn't possibly be the problem?


Cheers,

Brendan

[guyfawkes]

Hi,

Sure, you can jump to real mode and call the BIOS. It's the simplest and shortest solution, but also the most broken and the least professional solution you can get.

You say its most broken, but i have never had a problem with that part of my code, its never crashed in any tests i have done or anyone else when switching modes.
I always say 'if it's not broke, than do not fix it.

And v8086 support to me is just a glory form of switching back

When you start implementing device drivers and find out that none of them are reliable because IRQs are lost when you switch back to real mode to change video modes; will you decide that all your device drivers (and any IO APIC/MSI code, and anything you do to PCI configuration space) is broken and have an OS that has no device drivers and no support for modern hardware; because using real mode to switch video modes "worked" and therefore couldn't possibly be the problem?


Cheers,

Brendan

When you switch vesa modes your not doing it very often, also all such drivers in my OS use Poll, just like they do in OS's like menuetos, for example.

[Brendan]

Hi,

When you switch vesa modes your not doing it very often, also all such drivers in my OS use Poll, just like they do in OS's like menuetos, for example.

Do you own a car? What if the manufacturer told you "It doesn't explode and kill all the people inside very often"?

If all your drivers poll, then the OS is crap. It's impossible to poll without getting severe latency problems (not polling constantly), or severe overhead problems (not polling rarely enough), or a combination of both (bad latency and bad overhead).

Menuet does use IRQs.


Cheers,

Brendan

[gerryg400]

Do you own a car? What if the manufacturer told you "It doesn't explode and kill all the people inside very often"?

Then it would be a Ford Pinto.

[guyfawkes]

Hi,

When you switch vesa modes your not doing it very often, also all such drivers in my OS use Poll, just like they do in OS's like menuetos, for example.

Do you own a car? What if the manufacturer told you "It doesn't explode and kill all the people inside very often"?

If all your drivers poll, then the OS is crap. It's impossible to poll without getting severe latency problems (not polling constantly), or severe overhead problems (not polling rarely enough), or a combination of both (bad latency and bad overhead).

Menuet does use IRQs.


Cheers,

Brendan

What if i was to say the death toll for UK roads, was 2,222 in 2009.
But we all still use the roads.

And when i said menuet or my OS does not use IRQ, i did not mean for things like keyboard or mouse, but ethernet cards and such like, which are polled in both OS's, yes it has its disadvantages, but theres advantages too.

[Combuster]

Do you own a car? What if the manufacturer told you "It doesn't explode and kill all the people inside very often"?

What if i was to say the death toll for UK roads, was 2,222 in 2009.
But we all still use the roads.

Of which at least 90% is attributable to people being stupid, I'm sure. I challenge you to name one case that was caused that year by a manufacturing error.

Yes you can make a boat out of duct tape. No you would never ferry people across the channel with it. Real mode may float your boat but expect that we make fun of you if you happen to sink.

[guyfawkes]

There seem to be problems with "toyota cars crashing"

And i am not into realmode.
But a PC is designed to switch from realmode to pmode (maybe then Long mode).
It can also switch back .
You are not pouring water in to the motherboard, you are switching between pmode and realmode and back.
Its as simple as task switching.
You as a low level programmer have that power.

I think some of you, take your selfs too seriously, your not coding a all bells and whistle desktop OS.
I am trying to teach and help you.
Do you know how long freedos has been coded for ? and thats just a dos clone, so how many 100 years do you think it will take 1 or 2 coders to code a full desktop ?.
Keep it real.

I will try to help you, but you need to listen more.

[NickJohnson]

You are not pouring water in to the motherboard, you are switching between pmode and realmode and back.
Its as simple as task switching.
You as a low level programmer have that power.

And the fact that all major x86 OSes switch back and forth through real mode all the time makes this clearly the best option! How could we have been so stupid?

I will try to help you, but you need to listen more.

guyfawkes, I think you, take your selfs too seriously, your not trolling a forum full of inexperienced idiots.

[guyfawkes]

You are not pouring water in to the motherboard, you are switching between pmode and realmode and back.
Its as simple as task switching.
You as a low level programmer have that power.

And the fact that all major x86 OSes switch back and forth through real mode all the time makes this clearly the best option! How could we have been so stupid?

And major x86 OSes have 100 of device drivers, your not coding major x86 OS.
You need to stop thinking you are or are going too.
Your coding a hobby OS.

Try it for your selfs, its switch 100 a time a second to realmode to pmode, use a slow emulator to test it if you want.
But it works http://www.dex-os.com/Switching/freedos2.img

[NickJohnson]

And major x86 OSes have 100 of device drivers, your not coding major x86 OS.
You need to stop thinking you are or are going too.
Your coding a hobby OS.

There are multiple flaws in your reasoning.

First, nobody really wants a hobby OS, even its creator. If you decide your project is just a "hobby" OS (which is a term that has been debated endlessly, and I'm going to use here as meaning amateurish and limited, which is what you seem to mean in your posts) then it can't be anything other than amateurish and limited. Therefore, if someone has the motivation to write a hobby OS, it's not for the product, but for the experience. Taking shortcuts, like switching back through real mode to change video modes, decreases the amount of legitimate OS code you end up writing, and therefore decreases the amount of experience you get from writing the hobby OS.

If you decide that you want your project to exceed this label of "amateurish and limited", you then have a motivation to make the components as robust and well-designed as possible, so that the final product will be of better quality. Ironically, if you also want to get the project done quickly (which is not a property of a hobby project) then you may have a legitimate motivation to cut corners, but only ones that will not give you major problems in the future. Either way the rational decision generally leans toward quality, which means regardless of your goals, you're being stupid and stubborn, and should listen to the advice given here.

Also, who says I'm not coding a major OS?

Try it for your selfs, its switch 100 a time a second to realmode to pmode, use a slow emulator to test it if you want.
But it works http://www.dex-os.com/Switching/freedos2.img

Clearly you didn't even read any of the things other people posted. Nobody said anything about that switch being slow.
Also, why so many links to DexOS...?