Is your document available online somewhere,and is it understandable without being a driver expert?
No need for AI nonsense here,I guess Yandex Translate or some other traditional translation service will get the job done good enough so I can understand it without adding hallucinations.
Speaking about browsers and the forum,there’s r3dfox,a Firefox fork based on the latest version that maintains support for older Windows versions:
That said,I still find it ridiculous that something as simple as a forum has such high demands for a up-to-date browser and locks out everyone who doesn’t fulfill its high requirements.
I also think it became even slower/more sluggish on my phone running latest IronFox on Android,but it has never been exceptionally fast there.
I have to proofread that I think. I am completely unaware it is actually fully finished! It has been there for years while the last half or so was missing, and the first half missed some finer details, though I certainly never blamed anyone for that since it’s rather technical in nature all in all.
Can someone tell me since when it’s finished and who worked on that? I like to hear the details of what exactly was done by them?
edit: Oh, I should probably mention that the translation to English was -not- done by me..
Since the document seems to be improved in English, I would say have a look at chapter six
Thanks for the pointer on yet another browser that should be useable on good old (but for me still actual) Windows 7..
Oh, you can find my original work on my old site which I keep running:
Look at the downloads page, bottom. So, it’s in Dutch unfortunately. I asked if I could do my thesis in English since that would be much better, but the teachers were very afraid I would just copy and paste texts from other people.. Silly them..
Edit: hmm, aparantly I also myself did a partial translation, it’s also on that same downloads page. I think I should review all the english stuff compared to the original in Dutch..
If you don’t mind, I would also like to move these pages from the main website to Welcome to Haiku internals’s documentation! — Haiku internals documentation where it may be easier to find them. The (very) long term goal is to make the main website less technical and more user oriented, and have a better organized place for developer documentation.
I don’t know if I should keep the “original” (english translated) one under ‘legacy docs’ as well.
I think the best current option is to keep probably what you just pointed me at. I like to proofread and update it to become closer to the original dutch version, where things that might be missing or are incorrect should get updated.
It’s still largely BeOS based, of course. As I don’t currently know exactly what mods/expansions are done in Haiku specifically, I don’t know if I can update it for that (fully). OTOH I guess things will get clearer in my head on the go..
I think relatively few things changed in that area. 2D acceleration is not used by app_server but can still be implemented by drivers (for use with apps that access accelerant hooks directly). There are some extensions for multimonitor support, but they are unofficial and not implemented by any of the modern drivers, and largely undocumented.
The main thing may be extra flags for better securing of areas, and use of user_memcpy for SMAP/SMEP (both of these are about making sure the userspace doesn’t access kernel memory that it shouldn’t). But these could be documented separately, they are not specific to video cards.
OK, in that case I am still upto date I think. The unofficial multimonitor support is not in the document, but it -is- in the matrox and nvidia drivers though.
Thanks for the update/info!
Update: Thomas Kurschel created the ATI driver around the same time I was working on nVidia. We have had very very long night talks over at BeGeistert back then. He created the unofficial multimonitor support as is currently inside Haiku. I was using another method back then, which is also still supported in the Matrox and nVidia drivers. This one uses a seperate setmode app. Later on I added partial support for the (current) Haiku method since that app is on all systems anyway.
I’ve read chapter six and now I do know how I would progress when writing a graphics driver,but I still don’t really know the process of finding the cause of the problem in the current driver and fixing it.
I mean,given the symptoms I pointed out,which sections of the driver are most likely to cause this?
Are there some variables I can try changing and see if it makes a difference?
Sorry if I’m asking stupid questions,but that driver stuff is so different compared to normal programs,I have zero ideas how to debug that without more help.
OK. Come to think of it, the most convenient way to find the error is probably being able to set a working mode for Haiku without the use of the Nvidia driver. You stated that VESA is a nogo. How about framebuffer driver? If both fail for you then I would suggest fixing the VESA stuff first after all.
The reason is this: if you can set a mode succesfully without driver, you can later on instruct the driver to set that same mode. If you now disable parts of the card programming, or disable all, and re-enable piece by piece, you should be able to discover which parts are operational and which parts are not.
After that is known as precise as is possible, a focussed search and trial-and-error sequence might get you up and running.
Then again, it might even be if the VESA modes work, the driver suddenly also fully works. Apparantly there’s a rather big fault in your cardBIOS.. And the driver -does- rely on that BIOS ‘coldstarting’ the card correcty. Once that’s done, the driver can change all settings (hopefully) succesfully.
Note though that I guess it’s more or less dangerous flashing the BIOS..
Another option could be starting windows if that’s on your system, and then warm-restart into Haiku (without power-off). Chances are some card programming remains active over a reboot..
Welcome to the difficult world of creating graphics drivers…
(maybe organize a BeGeistert and meet in Dusseldorf? )
Is it really? You’re sending commnds to the hardware and getting replies. That’s not any dnfferent from calling code in a library, or a REST API from some webservice. Sure, the interface is a bit different, it’s reading and writing to specific locations in the hardware that will trigger things, rather than calling functions or sending network packets.
If you have good documentation and a well designed piece of hardware, it’s not difficult. If you don’t have documentation or the interface is badly designed, then it becomes super complex. But the same canbe true if you have a library or REST API without documentation or super complicated endpoints and bad error reporting.
)
)