Thank you! Still, I don’t know if I can come far enough with this, still poking around.
Next items found:
number of required lanes calculation in faulty (FDI), fixing it make all refreshrates and colordepths work in all resolutions, though resolution switching is still down. ‘Ceil’ is missing, or actually the integer version from the linux kernel. Apparantly it was forgotten since it -is- in the linux driver.
number of required lanes calculation is also faulty because for the required rates the code looks at the desktop colordepth instead of the pipe colordepth (which is for now fixed at 24 bit for us)
I don’t remember by heart at this moment, but I think link training did not work. Now it does (most of the time): this seems to be a matter of the correct order of things, and also items are missing (like disable PLL first…) I am now very busy poking around with this. While the training works (the auto version on my chipset), I still have no picture when I activate that… Once I have that: that would be very neat as we would be ’ in business’ then
That’s it for now. Once I have more info I’ll post it here.
Hi, I received an email from Gerrit with a patch from you. I guess I can apply that patch to my local tree somehow: but at this moment I will not yet do that as mixing up the current code will put me off-track and I still have some tests to do. Also I am unable to edit Gerrit from Webpositive within Haiku apparantly (it crashes constantly) so hence this short message here. Hope you don’t mind. I’ll get back to you asap.
No worries, I have just found this old patch on Gerrit and assigned it to you in case it is of any use. I think you have probably already re-done all the work in it and it can be removed when your version of the changes is ready.
I am just trying to keep track of who is working on things, as our Gerrit has a lot of old patches. And we recently added a build check bot that happened to test this change and point out that it did not even compile, which I fixed today.
Strange that Gerrit crashes for you, it is working fine here. I’d appreciate a bugreport about this (with the “save report” option from the crash dialog).
Ah Ok, I understand. Well actually the problem is Webpositive just stops responding. It does work if I don’t login, but after login the page fails to load. There’s not much more I can say about this atm…
BTW: next forgotten thing is the number of lanes is never programmed in the FDI TX part, only in the FX RX part. I was reading up on specs when I saw this (I did wonder already). Anyhow, fiddling with that now. Also: the number of lanes will only be accepted if the FDI ports are shutoff, so that’s something I’m testing with as well…
About the patch, OK, thanks for clarifying. I can more or less forget about it then as far as actually using it is concerned. I do have mods which I’d like to apply later on some way, as you will understand seeing the things I found, but I can imagine that my style is not entirely what you’d like the most, so feel free to modify in that respect. There’s also a number of defines I have added to intel_extreme.h for the M/N programming.
Updates:
the TX FDI lanes are programmed after all, but during training instead of during enabling PLL. Seems not very consistent at least.
the 5uS waiting time for the readback of the ‘training completed’ flag seems to be too short. Training reports a lot of times fail with this time. With 50 or 100uS it always reports success (testing 1 and 2 lanes)
sometimes I regain picture after training, but only sometimes. From the looks of it training is not helping with setting other than startup resolution. So I now more or less expect that there’s still something else that needs to be ‘hit’ for that to work.
Indeed, apparently I was not logged in on my Haiku machine and I didn’t notice. When did this start happening? It’s very annoying if we can’t use our own tools
Training the FDI link is still not stable (have to retest), I’m curious what the problem there turns out to be. So at this moment the modesetting is limited to all modes that fly with the same number of FDI lanes as activated by the cardBIOS during boot. FDI link training will solve that later on.
Please note: I am only testing on analog connected screen (VGA port) upto now, so it’s quite probable that other connections won’t yet work as each type has its own specifics.
Also please note that there are a lot of differences between architecture versions which makes an all-round driver quite a challenging job todo…
The trick to setting resolutions is to know that even on an anlog connected screen the panel fitter is still in use. So that one needs to be programmed with the resolution to use along with CRTC (northbridge) and port (connector) side (south bridge). Aparantly the FDI link does not need to be reprogrammed for each mode as long as the number of lanes does not need to be changed. Apart from the M/N timing on that that is.
Thank you. I will probably have a look at some other connections and also other cards ( I have 3 Intel gfx systems lying around here, but the other two are probably older). No laptop panels to test though.
Update:
Indeed, training the FDI connection for the lanes needed solves the modesetting issue: I now saw modes from 640x480 upto/including 1920x1080 working OK, BUT:
There’s still something not right as only once in maybe some 20 times modesetting works with FDI training (training always reports OK though). So that will once again probably cost me lots of time (i practically live testing and rebooting all days long… I guess I rebooted some 300-500 times already in the past weeks.)
If I have more I’ll post it here. I guess it’s almost time to cleanup as well: the code is a mess currently.
I’ve been poking around more for the FDI training setup, but no more results there yet. Might well be I need to implement manual training as some Ivy’s seem to need that (maybe mine ).
I decided to first cleanup the code and bring it back to minimal changes compared to the current GIT version for the analog port updates I’ve done. Once I got that I’ll post a first testing version, only 32bit for now as my development laptop (with nVidia gfx ) only runs 32bit software. It would be cool if it could be tested to see if it does not ‘break’ anything (I’ll make as sure as I can be that it doesn’t), and hopefully brings analog connected screens to life.
I expect to upload the testing version within a day or two.
I’ll probably stick with a binary version for now since it’s quite easy to put it on a USB stick of 1Gb and boot from that (It’s the way I am working on the driver at least )
Anyway, at some point I guess it’s handy I try to grasp the Gerrit thing as well… But at this point I expect this to take more time for me.
ah. Yes if you don’t have setup Gerrit then it would make more wor and that work are better to put on the driver
Question. are it not slow to boot from a stick? Or you perhaps haven’t Haiku on that computer you are developing on?
Now I don’t know nearly anything about the process of developing drivers. When I was looking in to Web cam addon and HDA driver I just made a link from where it was built to the right place under Home. I thought if the system got to a state where the driver made my system unstable, I could just hit space at startup and not load the driver. Perhaps I’m “kicking in open doors”, but then I know if I’m on the right track or it’s a no no
It’s my dayjob PC, so no, no Haiku on it. And yes, with the stick I use, it’s very slow (maybe some 20 secs or so) but that’s the stick’s fault. It’s the very el cheapo one (1Gb) which our company delivers with our equipment, I guess it costs way below 1 euro
Actually I am very pleased with the way Haiku responds/works booting off that stick: I even browse the web sometimes that way.
You can just create a fresh bootable stick, and have the kerneldriver and accelerant installed in home/config/non packaged there about.
of course instead of the nivdia file names it will be the names of the intel driver, so the files I’ll have in the zip I’ll link to. Oh yes: so there’s a specific Haiku part on that page. The intel driver has no settings file, so you can skip that.
Ah, and if you have a problem, just hit ‘ALT’+‘CTL’+‘DEL’ blindly to enter the dialog where you can kill processes and such. Of course you won’t see it. Wait a few secs, and hit those keys again, this time holding them for 5+ secs: the system will reboot.
Hit spacebar and choose ‘failsave video driver’ to boot with VESA mode. You’ll see the desktop again and you can simply remove the accelerant bin file for the next boot to be normal.
This way surely works, but machines with working ACPI shuts down normally when the power button pressed, an i better prefer normal shutdown than reset.
Reset can results in inconsistent filesystem. Is there a better way for machines with non-working ACPI? Like adding a program to the launch_daemon which will be started after the desktop is ready, and it would check if a specific ke on the keyboard pressed. If not, it would reboot the machine or something similar.
Ah OK, Nice to know.
The reset I advised does not corrupt the filesystem. Haiku nicely saves all open stuff before actually resetting. So it differs from just pressing a hard reset button in the old days
I have done numerous resets in the way I described it in the past month: not once was there corruption. And always I could nicely checkout the previous_syslog file to see what exactly was happening in the system.
Edit: Hmm, maybe for one thing: if I change a display mode that renders my system ‘invisible’, and I hit ‘ENTER’ to make it final (which I often do for testing), the next reboot will not have remembered that for the icons screen startup resolution selection. (if you normally shutdown it -does-).
The system -does- switch to the selected resolution once the desktop comes up though.
Apart from often trouble with modesetting (Haiku often issues -two- set cmd’s instead of one most of the time during my tests) there’s a second problem (apparantly):
Haiku ‘remembers’ the current set mode not in -one-, but in -two- places. app_server_settings and vesa?
Deleting app_server_settings makes the system -still- use the resolution that was last set… With the BeOS this was not the case (and I liked that better in this respect )
) only runs 32bit software. It would be cool if it could be tested to see if it does not ‘break’ anything (I’ll make as sure as I can be that it doesn’t), and hopefully brings analog connected screens to life.