Qestions about VESA/VBE

[MadZarx]

Hello everyone
I'm struggling to enable high res graphics on early startup without V86 emulator. I have searched on forums and they said I can do it by switching back to real mode or do it in the bootloader. But I'm using grub as bootloader and I saw on some forums that they said grub has some modules for initializing VBE. I seached for grub modules and saw there are some modules named vbe, video and gfx. So can anyone tell me how to use these modules to setup VBE and draw pixels on screen or set and get supported screen resolutions and change them please?

I dont want that ugly 16 color 80x25 Text mode screen. I want to write my own colorful text gui

[tristanseifert]

If your kernel is multiboot-compliant, you can simply extend your multiboot header to specify a graphics mode for GRUB to switch into:

Code: Select all

.set ALIGN,    1 << 0
.set MEMINFO,  1 << 1
.set VIDINFO,  1 << 2
.set FLAGS,    ALIGN | MEMINFO | VIDINFO
.set MAGIC,    0x1BADB002
.set CHECKSUM, -(MAGIC + FLAGS)

.section .multiboot
.long MAGIC
.long FLAGS
.long CHECKSUM
.long 0, 0, 0, 0, 0
.long 0 # 0 = set graphics mode
.long 1024, 768, 32 # Width, height, depth

(See this file for some more detailed explanations)

You will probably also need to access the multiboot structure that GRUB gives you a pointer to in EBX (it's a physical address!) to get the VBE info structure, in which you can locate where in memory (physical, again, so you'll need to map this to your virtual address space) the linear framebuffer is. From there, if you have either 16bpp or 32bpp modes, it's as simple as writing an RGB value to that memory location.

I also wrote a framebuffer console, here, which may be of interest to you.

[dansmahajan]

If your kernel is multiboot-compliant, you can simply extend your multiboot header to specify a graphics mode for GRUB to switch into:

this doesn't work with legacy grub

[MadZarx]

@dansmahajan I'm using GRUB2. I know that, GRUB legacy needs a patch for this. But I don't know how to use that module in GRUB2

@tristanseifert my kernel is multiboot-compliant. I want to ask if you allow me to see and use some pieces of your svga.c and fb_console.c codes. They are the exact thing I have allways been looking for
And 1 other question. If I setup an ISO image of my kernel with GRUB as bootloader, how should I tell it to use VGA or SVGA modules and what screen resolution should it setup VBE with?

And one last question. Should I detect the framebuffer offset or its allways at 0xD0000000 or the VBE info tells me where is it?

[dansmahajan]

And 1 other question. If I setup an ISO image of my kernel with GRUB as bootloader, how should I tell it to use VGA or SVGA modules and what screen resolution should it setup VBE with?

@tristanseifert has already explained this..look at the last

Code: Select all

.long 0, 0, 0, 0, 0
.long 0 # 0 = set graphics mode
.long 1024, 768, 32 # Width, height, depth

If your kernel is multiboot-compliant, you can simply extend your multiboot header to specify a graphics mode for GRUB to switch into:

Code:
.set ALIGN, 1 << 0
.set MEMINFO, 1 << 1
.set VIDINFO, 1 << 2
.set FLAGS, ALIGN | MEMINFO | VIDINFO
.set MAGIC, 0x1BADB002
.set CHECKSUM, -(MAGIC + FLAGS)

.section .multiboot
.long MAGIC
.long FLAGS
.long CHECKSUM
.long 0, 0, 0, 0, 0
.long 0 # 0 = set graphics mode
.long 1024, 768, 32 # Width, height, depth

(See this file for some more detailed explanations)

You will probably also need to access the multiboot structure that GRUB gives you a pointer to in EBX (it's a physical address!) to get the VBE info structure, in which you can locate where in memory (physical, again, so you'll need to map this to your virtual address space) the linear framebuffer is. From there, if you have either 16bpp or 32bpp modes, it's as simple as writing an RGB value to that memory location.

[MadZarx]

So there should be no special parameters or other stuff when creating the iso image with grub. Right?
Then how can I change the resolution later?

[tristanseifert]

So there should be no special parameters or other stuff when creating the iso image with grub. Right?
Then how can I change the resolution later?

You would use the VBE graphics BIOS calls. You could drop back into real mode, use V8086 mode and write a BIOS monitor to let you access other BIOS functions.

[MadZarx]

You would use the VBE graphics BIOS calls. You could drop back into real mode, use V8086 mode and write a BIOS monitor to let you access other BIOS functions.

Yeah. Thanks alot for your help. Now I can have my own fonts and gui.
Thank you guys so much

[Brendan]

Hi,

For multi-boot 1 (which is supported by GRUB, GRUB2, and a few other things); you can put the "preferred video mode" in your file's multiboot header. This "preferred video mode" is only a recommendation and the boot loader is free to ignore it or choose a similar video mode. For example, if kernel doesn't support 15-bpp modes at all and asks for "800*600 with 32 bits per pixel", then you might get 800*600 with 15 bits per pixel (there's no way to prevent the boot loader from choosing video modes you don't support). Also note that the code in most boot loaders is crap and won't (e.g.) use the monitor's EDID to ensure that the video mode you've requested is actually supported by the monitor; which means that even if you do get what you asked for it may be unusable.

For multi-boot 1, the specification says that the boot loader has to "leave the environment usable" but does not say what that environment might be, and there's no way to determine what the environment was. If you switch back to real mode and use BIOS functions then it will work if the boot loader was booted from a BIOS environment; but it will crash if the boot loader was booted from anything else (e.g. UEFI) and there's no way to prevent that.

Finally, for some cases (e.g. a decent UEFI system) the environment supports multiple monitors. Neither of these options will ever be able to support this.


Cheers,

Brendan

[MadZarx]

Hi,

For multi-boot 1 (which is supported by GRUB, GRUB2, and a few other things); you can put the "preferred video mode" in your file's multiboot header. This "preferred video mode" is only a recommendation and the boot loader is free to ignore it or choose a similar video mode. For example, if kernel doesn't support 15-bpp modes at all and asks for "800*600 with 32 bits per pixel", then you might get 800*600 with 15 bits per pixel (there's no way to prevent the boot loader from choosing video modes you don't support). Also note that the code in most boot loaders is crap and won't (e.g.) use the monitor's EDID to ensure that the video mode you've requested is actually supported by the monitor; which means that even if you do get what you asked for it may be unusable.

For multi-boot 1, the specification says that the boot loader has to "leave the environment usable" but does not say what that environment might be, and there's no way to determine what the environment was. If you switch back to real mode and use BIOS functions then it will work if the boot loader was booted from a BIOS environment; but it will crash if the boot loader was booted from anything else (e.g. UEFI) and there's no way to prevent that.

Finally, for some cases (e.g. a decent UEFI system) the environment supports multiple monitors. Neither of these options will ever be able to support this.


Cheers,

Brendan

So as you said, the kernel might be loaded with wrong bbp. So whats the best way to use graphics (If possible in early stages). I know I can use V86 mode but for that, It should be in user space and I haven't arrived to user space. One other choise is to switch back to real mode and call BIOS interrupts. But as you said I cannot do it if I use GRUB or other bootloaders. One last possible way is to write a vga driver. But I need at least the 800x640 resolution
So what is the best way to get it working??

[Combuster]

I need at least the 800x640 resolution

Why exactly those sizes?

So what is the best way to get it working??

Design how you want it to work in the end, then implement a subset of it that happens to work for just the cases you're interested in. Simply painting the screen red and stopping if the bit depth isn't 32 after grub is done with it will still mean you get a working environment on most hardware (and an obvious todo message otherwise).

[MadZarx]

I want this resolution because the font gets smaller in higher resolutions.
Sorry my English is a little weak and i didnt understand a part of your post. You meam if the screen gets painted in red, it means grub has give me the exact resolution? :O

[MadZarx]

Guys when I want to use the graphics mode, the qemu gives me this error:

Code: Select all

    qemu: multiboot knows VBE. We don't.

I have also used "-vga vmware" in qemu arguments but it gives me the same result.
I cant get the graphics working. But still I can use text mode

I have no idea that whats wrong with it but here is the multiboot code I use to enable VBE:

Code: Select all

## the multiboot header
.set ALIGN,     1 << 0
.set MEMINFO,   1 << 1
.set VIDINFO,   1 << 2
.set FLAGS,     ALIGN | MEMINFO | VIDINFO
.set MAGIC,     0x1BADB002
.set CHECKSUM,  -(MAGIC + FLAGS)

.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM
.long 0 # unused
.long 0 # .
.long 0 # .
.long 0 # .
.long 0 # unused
.long 0 # set graphics mode
.long 800 # screen witdh
.long 600 # screen height
.long 24 # bpp

[Combuster]

qemu -kernel is ugly. It also doesn't work that way on real hardware. Therefore, don't use it.

[MadZarx]

qemu -kernel is ugly. It also doesn't work that way on real hardware. Therefore, don't use it.

You mean I shouldn't use -kernel argument? So what should I do to get the graphics working? I'm sure there's no problem with my code. I think qemu cant load it, maybe?