Call for testing - VESA driver with custom video modes

Hello there!

During the coding sprint I have worked on improving our VESA driver to allow custom video modes. However, I only have Intel graphics card here so I was unable to test the code for NVidia and AMD cards (the code is specific for each card). So, I need your help in testing this.

What you need

  • A system that can boot in VESA mode (that means using legacy BIOS, not EFI)
  • An intel video card, or AMD using AtomBIOS, or NVidia (on other cards you can check if nothing is broken)
  • Ability to build Haiku yourself (at the moment there isn’t a prebuilt driver

How to test

Get the branch containing these changes (from your haiku git checkout directory):

git fetch "https://review.haiku-os.org/haiku" refs/changes/50/4650/2 && git checkout FETCH_HEAD
  • Build an image
  • Boot it, when booting use the boot menu and enable “use failsafe graphics driver”
  • After booting, go to Screen preferences
  • Note the name of the video card reported on the top left (it should say VESA driver and specify Intel, AMD or NVidia now)
  • Check if you get all the video resolutions you need
  • Try switching between different video resolutions and if they all work
  • If something doesn’t work, let me know your setup (in particular your graphics card model) and send me a syslog

Thanks for your help! If we get some success with this, I will merge it in nightlies for wider testing.

18 Likes

Suppose, the positive feedback is also accepted?

2 Likes

Yes, in the unlikely event that everything works first try, I’d like to know too :slight_smile:

2 Likes

Very cool! Although, I think that having a package with updated vesa driver could be much easier for users to test and would provide for broader testing. I wonder it such package would override system vesa driver though?

2 Likes

The buildbot may provide a prebuilt haiku.hpkg for testing, but it has not built this particular change yet (I’m not sure if it build all changes in a patch series, maybe it build just the first one). Until then, manual building will be needed, which I think is ok for a first test run. If I get some positive feedback on ATI and nVidia, we can merge this and then it will get wider testing.

1 Like

I’m just saying that downloading vesa_live_mode_patching-0.0-1-x86_gcc2.hpkg would be much easier for users to test :slight_smile: Someone could then provide 86_64 version too.

2 Likes

Would the vesa driver be pulled from user add-ons anyway?

Maybe adding a blacklist file to the package could help with that?

I built haiku-nightly-anyboot.iso from git (this is the first time I ever build Haiku). It works in qemu as expected, although the qemu test is probably irrelevant.

qemu

I have an ageing system with BIOS and NVIDIA GTX 1050. Unfortunately, it only has USB 1.1 and 2.0 and doesn’t boot from USB. Then I burned the image to DVD and checked it is well written. Unfortunately, the system fails to boot from DVD. I will try to flash the image to a HDD partition and boot it in this way.

1 Like

I tried on my AMD box here but the nvidia VBIOS don’t contain the patterns it’s searching for. Replacing them by similar ones I noticed inside seems to trigger a modeswitch but the framebuffer resolution didn’t actually change so the right side wraps over the left one.

I tried extending the envytools nvbios command but it doesn’t help much, since most interesting tables it points to aren’t documented in the only thing nvidia ever published. I couldn’t make up which of those patterns come from which tables. And the Nouveau code using the vbios is also quite obscure.

I might try on my T510 but that means rebooting, then rebooting again 15 times until it stops freezing…

Tried this version on BIOS based AMD Phenom (from 2010) with NVIDIA GTX 1050. Unfortunately, no resolution above 1280x1024 is available. Tried in live session and installed.

Monitor supports up to 4K.

IMG_20211030_232459

How can I upload syslog?

UPDATE:
Graphics card is NVIDIA GP107 [GeForce GTX 1050] with 2 GB of memory. Together with 4K monitor it able to work at resolution 3840x2160.

This screenshot shows “VESA Driver (VESA)” which means the new driver is not being used. It should show “VESA Driver (NVidia)”, or “VESA Driver (Unknown)” if it didn’t manage to identify the video card.

Also AboutSystem shows a normal revision number, there should be a +5 or so to notify that the 5 commits from the driver were added to your sources before building. This means you are just testing the code as it was before, and not my work in progress changes.

Well, maybe I checked out the wrong version then. I will try to rebuild the image.

Tested again, hopefully the right revision :smiley:

NVIDIA GPU is detected and the list of higher resolutions is available.

IMG_20211031_162209

However, the list of resolutions seems to not be provided by GPU or the available monitor modes (e.g. no 3840x2160). Additionally, the list of refresh frequencies also seems to not be provided by hardware, as many of them are unavailable on both GPU and monitor.

IMG_20211031_162309

The worst part is… only standard VESA modes actually work: 640x480, 800x600, 1024x768 and 1280x1024. All other (higher or between them) lead to kernel panic.

IMG_20211031_162350

There were one more sporadic KDL, usually on first restart after failed mode setting.

IMG_20211031_162546

I have saved the system logs if necessary.

4 Likes

Thanks for your help with testing!

Yes, unfortunately, for nVidia cards, even with this method, it is not possible to inject arbitrary resolutions since the data structures of their BIOS aren’t fully decoded/documented.

You can try this new version of the patch, which should fix the first KDL: https://review.haiku-os.org/c/haiku/+/4629 (patchset version 6)

git fetch "ssh://pulkomandy@git.haiku-os.org/haiku" refs/changes/29/4629/6 && git checkout FETCH_HEAD

I have no idea about the second one, it seems to be a problem with USB and wacom tablets, which should not be related to my changes?

Thank you for for the work!

The system I tested really has a hardware problems with USB.

I will test also the next iteration.

I modified git link to:

git fetch “https://review.haiku-os.org/haiku” refs/changes/29/4629/6 && git checkout FETCH_HEAD

For some reason, the new image doesn’t start Tracker (in qemu). The greeting window is shown allowing to install or try out Haiku. When I choose Try out, the window closes and the screen remains blank. Did I do something wrong?

UPDATE: Install option seems to work. After that if I cancel installation, the Tracker loads properly. I will test it in bare metal.

Tested the last update. This time there is no KDL :smiley:

However, except from standard VESA modes, no screen scaling actually happens. Instead, the following behaviour is observed.

Horizontal size. The screen is extended by necessary horizontal space to itself. That is, if the mouse crosses the right margin of the screen, it immediately appears at the left margin of it at the same vertical position. The same is true for any window.

IMG_20211101_203521

Tracker horizontal position indicates the right-most margin of the second extended screen. A window is cut past this position.

IMG_20211101_203604

It happens that on the same screen area live 2 virtual planes of screen: left and right. In case the mouse covers a window from another plane, it erases the window with background color.

Vertical size. The screen is just not available past its bottom, no extension on top or bottom is available. However, if new non-VESA screen resolution height is smaller than previously set, the screen is cut vertically at this vertical position.

IMG_20211101_203209

2 Likes

Ok, so we’re almost there, but not quite :slight_smile:
Can you provide the corresponding syslog?

1 Like

Same as what happens here with the different patterns I tried for nvidia.