ATI and possibly nVIDIA resolution patch (based on prasys' 915resolution port)

[lebidou]

I just read your posts and still looking for bugs.

@The King, I don't think the 16/9 aspect ratio is such a big problem, it has been detect as such before, there is no reason for it to be detected as 4/3 now. I'll just revert some changes back to have it detected again. I have been able to set 16/9 modes on my 16/10 panel with no big trouble, maybe nVidia bioses are more restrictives.

@CEOS, the reboot bug is probably due to CVT calculation, I will post a corrected version soon. I'm wondering if they are really necessary anyway.

@Azimutz, could you send me an ioreg when you boot with your GMA but without the patch (when it works)? I know it's weird but I have an entry for GMA in my DSDT even though I don't I have GMA, could be of some help. I'll have look at the bugs you reported.


EDIT: Just updated with planned changes: Removed some debug output that would have caused hanging with debug or inapropriate "Press Any Key..." messages (although I'm wondering if it happens with the precompiled or the ones you compile, because it never happens here).
NVIDIA: Removed the need for CVT computation, not sure about the result, at least it shouldn't crash. Reverted the way it gets resolution back to what it was. The resolution and aspect ratio will be printed in the output, so photos are much appreciated.

[CEOS]

It's working again

GUI is there and Resolution is correct.
exept the graphic bottom bug it rocks solid so far

debug output: http://rapidshare.com/files/369195386/Archiv.zip.html

btw, there in no ram auto detection.
i was quite sure they will add this feature to rc5...

edit: sorry, one picture is blurry, can upload it again if it's importand

[Azimutz]

@CEOS, ram detection is there but disabled. Still needs a lot of work and it will be done out of the trunk. You can check it out here: http://www.insanelymac.com/forum/index.php?showtopic=201902  ... last pages...
When i have time i'll post a rev with ram detection working... already had it done but had to restructure and cleaned it. I also found the solution for the Extra extensions load problem i was messing with
bbl.. taking care of lebidou's request and doing some more tests...

Edit: RAM autodetection can be enabled with UseMemDetect=y, on current trunk (rev 136).

[CEOS]

@CEOS, ram detection is there but disabled. Still needs a lot of work and it will be done out of the trunk.

Thank you for clarification
a version with ram detection would be nice 
it's admittedly just a cosmetic thing, but i get used to it (aseres booter had this for a long time...)

@ lebidou
i think i found out a bit more about the graphic bug.
seems like it's content based.
if i use an other theme, it has a different color.
with DTypes theme it's blue: http://img682.imageshack.us/img682/4581/bluebug.jpg

[lebidou]

Glad to hear good news again! pfew!

I have no clue about the graphic bug, unfortunately. As I said before it could be because it sets a 1920x1200 resolution despite the patching, or the buffer is too small or too big, I don't know.

EDIT:
I attached an internal test version. This is NVidia only. You will experience two different things :
    -when entering GUI the bootloader will setup a 16/10 buffer if your resolution is 16/9 (1920x1200 instead of 1920x1080.) I'm expecting the bug to be there with a more stretched display, but I want photos to see it by myself.
    -after the GUI (grey apple and spinning wheel), the buffer will be set to your resolution minus one (from 1920x1080 to 1919x1079). I don't know what to expect from that one, photos are mandatory.
DO NOT try to change mode while in GUI on NVIDIA, behaviour is unknown.

I have no clue for that bug. It seems to come from the second VESA table. When oldnapalm tested the booter, only the first VESA table was patched, and it work fine for him, without any bug. I think the first table could be for Analog displays (VGA port) and the second is for Digital (DVI, HDMI and maybe LVDS.) Is there a way you can test VGA, CEOS ?

[CEOS]

no visible changes
here is the output: http://rapidshare.com/files/369282840/Archiv.zip.html
(sorry, one picture is really blurry again, will post a better one tomorrow)

i don't know if i'm able to test VGA.
my video card just has 2 DVI ports, no VGA.

there is a DVI=>VGA adapter, but i think it's not the same like a real VGA port...

[Azimutz]

@lebidou, yeah.. nice to read good news CEOS maybe has a point about the "content". I just bumped on some graphics garbage, when trying to type at the GUI using Maclogin theme. Using Chameleon default all fine. I insisted on typing and trying to boot and got the screen full of garbage. First the typed characters didn't show, then a small square showed up at the upper left corner of the screen, then garbage all over

Ok, ioregs+dsdt and a readme: http://www.mediafire.com/file/1ommzanmfzl/GMA_ioreg_dsdt.zip

brb with some more comments...

[lebidou]

I just had look at you photos CEOS, they are instructing: the value I thought was vertical blank in second table doesn't seem to be so... it could be that, or not...

[Azimutz]

@lebidou, about those annoyances i mentioned, they are gone now in the normal booter. Now, on the debug build it doesn't stop the second time before getting to the GUI (the #ifdef AUTORES_DEBUG, etc... you removed from gui.c #635+-). This stuff is a bit tricky, at least to me.. i tried to play with it one of these days and gave up

The "big annoyance" on the debug build, the one that made me hang like when i use "Wait=y", it's not your fault!
This only happens because i have to use USBBusFix. In fact the problem is with UHCIacquire, that's included on USBBusFix. I have to use this fix or i start to get USB problems. It seems if the booter pauses at that point, the usb bus were the keyboard is connected, stays disconnected!?

Atm my builds are absolutely similar to yours, same behavior. I just don't usually build with "make embedtheme". I'm working with latest trunk.

[lebidou]

Azimutz, I'm looking at your dumps and DSDT, I think there is something we can do about that.
One Problem I see is the following :
In my DSDT, the GMA related code (which shouldn't exist) uses some variables it gets from bios in the GNVS Operation REgion. I can't find the same thing in your DSDT. These variables are used to know which port is activated with what kind of device. But, since GMA is integrated, there little chances for this change, so I think we can hardcode it without too much problem (after all, it is hardcoded for my real graphics card, has been replaced, no pb).

What I need from you is to know what kind of outputs are driven by the GMA : how many ports, VGA, DVI (w/ or w/o Dual-Link) , HDMI...
I have the GMA _ADR value all right, what I need is the same for each connectors. That is all.

@CEOS, I looked again. My asumption was right, vertical blanking is vertical blanking. But it has been recalculated automatically, it seems (cvt calculation is really not necessary for the second table.) Those in the first table aren't, I'm wondering what is the relation between the two...

EDIT: did some testing to reproduce the bug, but didn't succeed. All I got is plain black band, not exactly what guys have. CEOS, when you're in the boot menu and type something (like -v or -s) do you see the text appearing above the band ?

[Azimutz]

@lebidou, i'm not sure if i understand everything, but if you say so! GMA drives only one VGA port, connected to VGA on the monitor side with VGA cable. The machine came with the ATI already installed, the GMA had the connector covered... "do not remove" it says.

Played a bit with the code, kept the #ifdef AUTORES_DEBUG you removed and commented out the next one. Works fine like that on debug build. Pauses after reporting chipset, press key, pauses again on edid, press key->GUI. On normal build doesn't show nothing as should. The other stuff that kept me from booting, it's fine this way without getc(), best compromise. Here is a diff of what i have atm:
Remove, outdated.

Managed to fix what i wanted in drivers.c so, those changes i'm gonna keep. Works fine here, does what it's told to just need to be sure that's all fine.. Can you take a look at it? i used code and inspiration from the "ACPI Table search algo" on dsdt_patcher.c. Just to check if there's no bomb hidden in there don't think so.

See ya later..

[lebidou]

Thanks Azimutz. Although I just realized that addind the entry in the DSDT won't help for resolution in chameleon because DSDT is patched after that. But it can help to get the Framebuffer loaded in MacOS. Since you don't use it I don't know if it's really worth it.

I'll have a look at your modifications later.

[Azimutz]

yeah.. that's a thing that i thought and wanted to confirm with you. No need now, you already answered
It was just my noob insecurity working! I'm talking about this patch having nothing to do with getting the graphics card to work. If it works, it can set the correct display resolution even if the framebuffer doesn't load.. i tested that with the ATI successfully.

About my private mods to the code, no hurry.. when you can!

About the GMA, that's up to you. I mean, if you have time to mess with that i'm glad to test it. This card it's just a fallback in case the ATI doesn't work and that's not gonna happen so soon. I can even make the ATI work with Leo framebuffer that's how i used it on Snow, until i found what was missing on the dsdt and later found that Chameleon can replace the dsdt. But some people might still use it on desktops!?
Atm i'm using Graphics Enabler to inject the ATI if i could do the same with the GMA, it would be sweet, but yeah, not that relevant.

Anyway, let me say that, it's been a pleasure to collaborate with you
been learning some stuff. Thanks for that!

[lebidou]

If it works, it can set the correct display resolution even if the framebuffer doesn't load.. i tested that with the ATI successfully.

That's the point actually, and I was thinking about all those ATI mobility users who have trouble getting native resolution. You say you get it working with Leo drivers ? I'm using Tiger's driver in Snow Leopard... See what I mean?

[BuildSmart]

Regarding nVidia ram detection, there are several issue which prevent it from working or from working properly with certain cards.

First: (why it doesn't work properly)

• NV_03, NV_04, NV_10 to NV_30, NV_40 and NV_50 all do it differently.
• when used with multiple cards only the primary card will return the amount of memory based on the current implementation.
  REG32(0x10020c) = old PRAMIN bar0 method and only works with primary card.

Second: (should always be accurate)

• you can extract the number of ram positions on the card.
• you can extract the number of populated ram positions.
• you can extract the size of the chip in the populated ram position.
• you can calculate the amount of memory by the obtained info.

Third: (will always be accurate)

• turn the primary card off.
• assign memory and IO resources to current card.
• turn the current card on. (check the status register to ensure it initialized)
• obtain the amount of memory.
• turn the current card off.
• clear the resources.
• turn the primary card back on.

From examining the ATI registers it appears that the second method will work for it and you could probably use the third method if you figure out the register maps but both will require better register read/write routines (I can provide them) since the current ones are 8bit restrictive.