Just got Haiku up-and-running on bare metal for the first time, but it seems to prefer Framebuffer for my graphics driver. I have a newer Nvidia card, so vesa is more than acceptable, but I’d like to see if I can change the resolution to something more useful than 1280x1020. Where can I change the setting for the system to use vesa rather than framebuffer? Thanks!
1 Like
If you boot from MBR you will get VESA
If you boot from EFI (UEFI) you will get Framebuffer
You should try to boot with MBR if you can. If it is a new Laptop or Computer you will likely stick to Framebuffer if I am not wrong.
1 Like
GPT is a preferred drive type on this system. I multi-boot a lot of OS’s, though I want to really dig into Haiku.
Can resolutions be changed under FrameBuffer?
you can only chose the resolutions offered by FrameBuffer in ScreenPreferences.
The developer are working on a solution to make VESA resolutions available with FrameBuffer.
So you have to wait for a solution, sorry.
They are the same driver.
If you boot with efi the system may give you a different resolution that with mbr, but it cant be changed afterwards (not that a GPT table doesnt force efi by itself, you still nedd to use the efi loader properly)
Yeah I’m not sure what this means yet except I’m out of luck for the time being. I’m trying to trick grub into improving my framebuffer but I don’t think I can in efi. You learn something new everyday. I’ll just have to virtualize for a while and leave the bare metal install to rest until I can figure something out. Thanks.
You could try Clover instead of grub. But afair the Haiku detection code is still broken.
Are they? There is no way to do this.
UEFI can setup a mode for you, and if you disable compability mode (CSM) in UEFI you should get the best resolution UEFI can give you. That is all you can get without graphics drivers.
Forgive my curiosity, is using an EFI boot loader implicitly restrictive on if a graphics driver, even vesa, can take over rendering?
The efi way of booting exposes a different interface, the resolution then cannot be changed after booting, it is ideally supposed to be the native resolution. For vesa the redolution depends on what the firmware exposes aswell, so in that regard thise two ways arent that different.
UEFI can only do some basic mode setting at boot, but cannot be used after boot.
VESA functionality depends on the computer firmware, and was mostly functions you could call in real mode (16 bit addressing: what DOS used). Haiku uses a nice trick* to be able to call even though we do not use real mode. With the move from BIOS to UEFI and from 16 to 32 to 64 bits of addressing, VESA no longer exist or is hard to make use of.
So we need to have graphics drivers for most cards as VESA support is getting less useful. Vesa and framebuffer use the same driver. If we detect VESA modes at boot you get mode swtiching.
- The driver switches to real mode and calls VESA. A few firmwares could use VESA in protected mode without this trick as well.
2 Likes
EFI and VESA are mutually exclusive. The reason for that is VESA is tied with the BIOS (we call it “VESA” but the full name is “VESA BIOS Extensions” or VBE).
We use either EFI and the framebuffer driver, or VBE and the VESA driver, for the boot screen in all cases. When app_server start, if there is a native driver, we will switch to that, if there is none compatible with your hardware, we remain in framebuffer/vesa mode which at least allows us to display something.
4 Likes
Then I wait for nouveau! No worries.
Hi, so… I just expanded the intel_extreme driver to accept my microsoft surface 3 graphics chipset. when I type ls /dev/graphics, vesa and the intel driver are there indeed. When I expand logging in the kernel driver for intel I see that there are no errors whatsoever sofar.
So why does the accelerant not gets called and still I am stuck with the framebuffer thing? What am I missing?
Thanks for any pointers you might have…
EDIT: hmm. So from the sources it’s clear that the vesa driver and the framebuffer driver are indeed the same thing. The only diff seems to be the fact that there are no modes to set (framebuffer).
But: since the name starts now with a ‘f’ instead of a ‘v’ I am beginning to think that the special logic that this driver should -only- be used as a fallback driver, is missing from the system.
Since ‘f’ comes before ‘i’ (from intel), but ‘v’ comes after ‘i’ that would be the reason intel takes over with vesa, but -not- with framebuffer…
just a thought… 
I think having vesa and framebuffer in the same driver is more complicated than having them as two. Almost every function needs to check if it is vesa or framebuffer, and vesa depends on ISA and other things.
I tried to debug why app-server crashes with framebuffer on my hdi screen (3000x2000). It is two problems: app-server don’t like high frequencies of hidpi it seems, and tries to do modesetting, and since vesa has no guards for framebuffer it tries to call VBE which does not exist on UEFI fw.
Initially the framebuffer driver was separate. Then it was merged with VESA because app_server is not able to handle two fallback drivers.
The first commit here seems to describe exactly the problem you’re having with framebuffer unexpectedly “winning” over other drivers: https://git.haiku-os.org/haiku/log/?qt=range&q=hrev51206..hrev51207
If the VESA driver did not change too much since then, it should be possible to revert these two commits and try a better fix on app_server side?
You can see in app_server code where we handle the avoidance of the VESA driver explicitly: AccelerantHWInterface.cpp « local « interface « drawing « app « servers « src - haiku - Haiku's main repository
My understanding is that for this to work, the device really has to be named vesa, so if you have a /dev/graphics/framebuffer, you’re in trouble. But it does not look so hard to change this code to handle that case?
1 Like
Thanks for the pointers, I will fiddle a bit here to see what I need to do to get the intel accelerant to load, and if my thoughts are correct or not…
Anyhow, the surface only boots the 64bit uefi version. The bootmenu shows 640x480 upto/incl 1920x1200 (my panel’s native resolution). It would be nice if the vesa/framebuffer driver would be able to use the VESA bios even though we are in 64bit uefi mode: but I never looked at this stuff yet so I have no idea if that would be feasable. The (nice) fallback on the fallback vesa would indeed be the option to set another mode with screenprefs (writing the vesa settings file) and doing a reboot to let it take effect.
The vesa driver says it’s called ‘framebuffer’ in the Screenprefs panel. When doing ls /dev/graphics it still is called vesa. While I personally don’t like the framebuffer name (it throws me off track thinking some other solution is running, while in fact it’s still the same driver and accelerant), I understand the discussion about VBE and UEFI etc.
BTW I remember I tricked the app_Server to load the driver I wanted long ago (BeOS) by just preceding the kerneldriver name with a ‘_’ as it is sooner in the ‘alphabet’ and was therefore selected by app_server.
Anyhow: so if the alphabet thing is causing trouble, it’s not on the exported kernel name atm as that is still called vesa.
I’ll dig some more and hopefully find something…
Thanks again!
Oh EDIT:
There seems to be a problem besides this with app_server sometimes trying to set modes twice, where the first one is invalid: that can cause crashes sometimes in the accelerants I think, at least it’s a bad idea to not request a valid mode when modesetting is done.
Beware of 'revert’ing modes as well…
3 Likes
Is it possible that this is what’s causing the accelrants to crash taking the app_server with it in this ticket?.
Hi, maybe. Can you upload a previous syslog file if there to the ticket? Thanks!