I noticed in one of the Prop questions, that support for at least higher resolutions on all video cards was a “must have” for R1. At least I think it was a must have. My question is, will it be ready in time? Not that I am trying to rush or be impatient, but I noticed nothing in the activities of the source code to show anything about it. Even though it’s a mild annoyance to switch video cards in the BIOS, and inputs on the monitor when I boot into Haiku, it’s still an annoyance. I would love for the process to be really simple to switch to another OS. I can’t stay on the onboard Intel card if I want to play games, so I only use it for Haiku (which I am using at least 70% of the time).
I did want to repeat, I’m really not trying to rush, nag, or be impatient, I am just curious if work is being done, or plan on being done. I realize the official R1 is still a ways off.
As far as I know there is not a single soul working on native nVidia drivers for Haiku right now. I know the pain, I own a few modern GeForce cards myself. To get correct resolution and aspect ratio on widescreen displays I’d boot Haiku from Clover bootloader, enabling “Patch VBIOS” option. Perverted way to do it, I agree.
From what I could understand, Haiku can’t directly benefit from open source Noveau display drivers of Linux. It’s not like in case of Haiku’s compatibility layer with FreeBSD WiFi drivers. I think one must write the nVidia driver from scratch specifically for Haiku, even though source code and hardware specs provided by Noveau project could probably help the developer if there will be one. Long story short, with Noveau in mind this is not so much of an uncharted territory anymore, but still a mountain of work.
For 3D acceleration there was some progress on Mesa / Gallium 3D, but I haven’t heard any news from it at least since 5/13/2014. Will be real sweet and dandy to get a Noveau-derived Haiku nVidia driver. Looks like Noveau Project made a helluva lot of progress this year and year prior. I don’t have much money, but I will donate if there is dedicated bounty just for nVidia drivers.
Wasn’t Gallium for 3D acceleration only? I was under the impression that mode setting, 2D acceleration and video overlay must be supported by a separate enitity, not included in Gallium 3D drivers.
I believe you are correct. There exists some documentation for writing an “accelerant” for BeOS and Rudolf Cornelissen has also documented the process of creating a driver - it is available here: https://www.haiku-os.org/legacy-docs/writing-video-card-drivers
Hi, I know this is an old thread but I thought I’d let know somehow that I am finally translating this document myself. About one third is done, which means I am now at the point where there will be more info in the new translation than exists in the old one.
Also while I am at it, some extra info and a few updates are coming (are there already) because since then my knowledge expanded a bit more and of course Haiku is much more complete than it was back then.
That being said it remains being a translation of the original work so it’s still about the BeOS. Though most stuff also (should) apply directly to Haiku.
I’ll keep working on the document and publish it again. Hopefully in a month or so it will be done.
It would be perfect if when it’s done someone could convert it to a handy online format and replace the old translation on the Haiku site with the new one…
Well, there was a problem at my daytime job which meant I had to work very hard at the company software unfortunately. Anyhow, still progressing on the document, almost halfway there. Hopefully I can find a bit more time in the near future. I guess I could post an intermediate version on my site in the meantime if people are interested?
@waddlesplash has had a pin in looking at a DRM/DRI compatibility layer for a while now. I attempted bits of it (mostly keeping the Mesa port alive upstream), but my opengl / programming skills just aren’t up to par with designing a direct rendering and buffering system.
In terms of basic mode setting, radeon_hd is pretty solid these days, intel is working for the most part with the latest stuff hit or miss… Nvidia is non-existent outside of vesa / framebuffer… nobody has the juice to reverse engineer their cards and reverse-engineer a driver into existence.
Driver development is hard enough with extensive documentation of gpu internals between generations. Without it’s almost impossible. Noveau on Linux is just becoming successful due to the huge number of eyes on it from users + businesses. Haiku just doesn’t have those eyeballs (yet)
BTW, I was testing the current state of ReactOS (0.4.12-dev) on 3 HP Intel systems (2 I just got from a flee market), for which I needed Haiku on a stick to patch it’s installation process ‘on the fly’ for my systems: and I (still) see that on none of these systems the Intel graphics driver outputs a picture on the attached (different) monitors. Also there are still a lot of tickets outthere describing the ‘same problem’ AFAICT. I am thinking a bit to look at the reason for this if it’s hard to tackle…
On a sidenote I read somewhere that some old patchcode was removed sometime thereby ‘introducing the problem’… (don’t know which exact Intel gfx driver comes into play on Haiku yet though)
Vesa is indeed working perfectly, even including widescreen native mode (1920x1080) on my system. Intel’s gfx BIOS is apparantly better in this respect than the nVidia versions (were)…
Another thing: I still have a few post GF7950 gfx cards here, maybe I’ll try to get those going for modesetting after all (unfortunately my bare driver for that was deleted from the repository, though I understand it after this long time no activity there )
And DRI/DRM is something I’d love to see on Haiku… I would be interested to test it alongside the old Haiku nVidia 2D driver (which works from TNT1 upto GF7950) as it probably needs some updates (actually donwgrades to not break the Linux driver’s programming to the hardware…
Oh: about ReactOS: It’s coming along nicely since my last testround. It runs our company’s software near perfectly now, including my own driver/DLL set that it uses to access hardware directly. I’ll be monitoring that the coming few years as well, maybe we can use it as a replacement OS by the time Windows 7 support is ended by my favorite company
The issue with radeon_hd driver is mainly in obtaining the default max resolution setting during bootup. This might be the nature of the other non-VESA drivers. The monitor info, video driver, and EDID info show up correctly in Screen preferences - but I had to change the max resolution to the correct selection (initially, it shows a higher max resolution selected not within the actual resolutions for the monitor).
NOTE: Seems like some drivers may reads/confuse the VIDEO BIOS (or driver) screen resolution capabilities versus the monitor’s screen resolution capabilities. SO, users may get higher max screen resolution settings upon bootup by default - outside a monitor’s max resolution specs (i.e. certain <1600x1200 monitors). Once in Screen preferences, this info seems corrected when reselectng screen resolutions.
As for Mesa, the Mesa 17.1.10 Haiku swpipe driver works. Just a few bugs I listed in Haikuports. The original swrast driver works better as the alternative driver - but much slower. For the most part, testing and using 3D apps works for me on Haiku minus known issues with the swpipe 3D driver. I’ve ported and tested Mesa and OpenGL-related implementations over many years - so if the Haiku implementation was terrible (still) I would mentioned it. SVG kinda bugs me though…
The 2D video drivers had default max resolution limiters. Nowadays, we have 2K monitors (i.e. 2048x1536x32 and 2560x1440x32->2560x1600x32 max. resolutions) not properly handled by certain video drivers (i.e. last time I checked). I went through the drivers months ago as I have or had Matrox/3dfx/NVIDIA/AMD/etc video cards.
Hopefully, Rudolf posts his latest notes. They are helpful in working with the drivers and getting around certain issues.
Wow, that I hadn’t expected… If I had, I’d sent you the doc version. I would expect that to be much more handy for such a task? Anyhow, thank you for working on this! Let me know If I should mail you the doc…
BTW I plan to work more on the document towards the end of coming May, I’ll try to reserve a few days in my upcoming vacation for that. Since doing the translation is also a big heap of work
)
to not break the Linux driver’s programming to the hardware…
