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):
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?
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.
I’m just saying that downloading vesa_live_mode_patching-0.0-1-x86_gcc2.hpkg would be much easier for users to test Someone could then provide 86_64 version too.
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.
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.
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.
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.
NVIDIA GPU is detected and the list of higher resolutions is available.
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.
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.
There were one more sporadic KDL, usually on first restart after failed mode setting.
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.
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.
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.
Tracker horizontal position indicates the right-most margin of the second extended screen. A window is cut past this position.
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.
