517 replies to this topic

[GAOO]

Thank you very much for your informative post, HannibalX. I was worried you may have abandoned us

I was looking at your list of kexts, and there's two I'm not familiar with:
- IntelCPUPMDisabler.kext
- OSvKernDSPLib.kext

The other kexts doesn't seem like they will affect the Graphcis at all. But I'm not so sure about these two. I'll be looking into them and trying them out with Natit.

I also inspected your Boot.plist, and nothing seems out of the ordinary, except for:
<key>Graphics Mode</key>
<string>1600x900x32</string>

What happens when you don't have the Graphics Mode key? Also, do you have Quartz Extreme and Core Image working? I would like to assume you do since you said Natit works, but it would be nice to confirm it.


BTW, I am also using GPT and retail disk, but I do not think it is necessary to get the Graphics working. A near vanilla install (such as with iATKOS) should be compatible as well in my opinion.

Hey all -

Sorry, I've been out of town - and haven't had a chance to really check in here.

I'm still using the natit.kext that bcc9 posted, I haven't had a chance to test his DSDT method yet.

Here is the output in the system.log from when the natit.kext loads:

Aug 12 16:42:12 localhost kernel[0]: Natit: Setting @0,name=NVDA,Display-AAug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,compatible=NVDA,NVMacAug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,device_type=displayAug 12 16:42:12 localhost kernel[0]: Natit: Setting @1,name=NVDA,Display-BAug 12 16:42:12 localhost kernel[0]: Natit: Setting NVCAP=<data not shown>Aug 12 16:42:12 localhost kernel[0]: Natit: Setting device_type=NVDA,ParentAug 12 16:42:12 localhost kernel[0]: Natit: Setting model=NVIDIA Geforce 9400M

I'm not certain if that is helpful or not.

Also, here is the lspci data for my video card:

04:00.0 VGA compatible controller: nVidia Corporation Device 0866 (rev b1) (prog-if 00 [VGA controller])	Subsystem: Dell Device 02ba	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-	Latency: 0	Interrupt: pin A routed to IRQ 23	Region 0: Memory at cc000000 (32-bit, non-prefetchable)	Region 1: Memory at d0000000 (64-bit, prefetchable)	Region 3: Memory at ce000000 (64-bit, prefetchable)	Region 5: I/O ports at 4000	Capabilities: [60] Power Management version 2		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)		Status: D0 PME-Enable- DSel=0 DScale=0 PME-	Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+		Address: 00000000fee00000  Data: 4094

As I mentioned to GA00, I'm running a vanilla install. I copied the retail OSX 10.5.6 DVD to a 8GB USB stick (see this thread). I'm also using the latest Chameleon RC2 installed using the munky method (see this thread but use the Chameleon files instead).

Here is a list of the kexts that I have in my EFI partition:

drwxr-xr-x   3 root  wheel   102B Jul 25 14:16 IO80211Family.kextdrwxr-xr-x   3 root  wheel   102B Aug  3 21:12 IOAudioFamily.kextdrwxr-xr-x   3 root  wheel   102B Jul 25 14:16 IONetworkingFamily.kextdrwxr-xr-x   3 root  wheel   102B Jul 24 14:19 IntelCPUPMDisabler.kextdrwxr-xr-x   3 root  wheel   102B Aug  3 13:16 Natit.kextdrwxr-xr-x   3 root  wheel   102B Aug  4 16:52 OSvKernDSPLib.kextdrwxr-xr-x   3 root  wheel   102B Apr  6 20:25 VoodooBattery.kextdrwxr-xr-x   3 root  wheel   102B Aug  3 21:11 VoodooHDA.kextdrwxr-xr-x   3 root  wheel   102B May  8 23:51 VoodooPS2Controller.kextdrwxr-xr-x   3 root  wheel   102B Aug  4 22:38 VoodooPower.kextdrwxr-xr-x   3 root  wheel   102B Jul 24 14:19 dsmos.kext

VoodooHDA is *NOT* working, I get sound and everything - but I have the horrible static. The IO80211Family.kext was editted to add my device id for my wireless card. (IONetworkFamily is added because it's a dependency). I want to try the DSDT method instead, so I don't have to edit the kext. My onboard ethernet is not working, I get this error:

ug 12 16:42:12 localhost kernel[0]: AppleRTL8169Ethernet: Unknown hardware version ID (28000000)Aug 12 16:42:12 localhost kernel[0]: AppleRTL8169Ethernet: probeHardware() failed

I know it will work, I had it working when I originally used the netbookinstaller to prepare my USB stick (this was prior to using the above linked method with Chameleon). I think it might be something that can be tweaked via DSDT as well.

I hope that helps some, I haven't had a chance to do much with it lately. As a side comment, I am using a GPT disk -- and dual booting Windows 7 and OSX with Chameleon as the bootloader.

It doesn't contain much, but here is my com.apple.Boot.plist:

?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict>	<key>Kernel</key>	<string>mach_kernel</string>	<key>Kernel Flags</key>	<string></string>	<key>Default Partition</key>	<string>hd(0,3)</string>	<key>Timeout</key>	<string>5</string>	<key>Graphics Mode</key>	<string>1600x900x32</string>	<key>Legacy Logo</key>	<string>yes</string>	<key>device-properties</key>	<string></string></dict></plist>

[GAOO]

Found that IntelCPUPMDisabler.kext works just like Disabler.kext, and OSvKernDSPLib.kext is needed for one of the other Audio drivers. So other than Natit.kext, nothing else affects graphics.

So far, other than HannibalX, everyone else seems to have the 720p LCD, which has the resolution of 1366x768. HannibalX got Natit.kext working with his 900p LCD, while everyone else with 720p didn't, so could it be that the Natit.kext or its NVCAP requires some tweaking to work with the 720p screen?

Well this is also assuming that Natit.kext works perfectly fine for HannibalX (QE&CIworks & doesn't rely on Graphics Mode). Otherwise it may not have to with 720p or 900p...

Thank you very much for your informative post, HannibalX. I was worried you may have abandoned us

I was looking at your list of kexts, and there's two I'm not familiar with:
- IntelCPUPMDisabler.kext
- OSvKernDSPLib.kext

The other kexts doesn't seem like they will affect the Graphcis at all. But I'm not so sure about these two. I'll be looking into them and trying them out with Natit.

I also inspected your Boot.plist, and nothing seems out of the ordinary, except for:
<key>Graphics Mode</key>
<string>1600x900x32</string>

What happens when you don't have the Graphics Mode key? Also, do you have Quartz Extreme and Core Image working? I would like to assume you do since you said Natit works, but it would be nice to confirm it.


BTW, I am also using GPT and retail disk, but I do not think it is necessary to get the Graphics working. A near vanilla install (such as with iATKOS) should be compatible as well in my opinion.

[HannibalX]

Found that IntelCPUPMDisabler.kext works just like Disabler.kext, and OSvKernDSPLib.kext is needed for one of the other Audio drivers. So other than Natit.kext, nothing else affects graphics.

So far, other than HannibalX, everyone else seems to have the 720p LCD, which has the resolution of 1366x768. HannibalX got Natit.kext working with his 900p LCD, while everyone else with 720p didn't, so could it be that the Natit.kext or its NVCAP requires some tweaking to work with the 720p screen?

Well this is also assuming that Natit.kext works perfectly fine for HannibalX (QE&CIworks & doesn't rely on Graphics Mode). Otherwise it may not have to with 720p or 900p...

Yes, IntelCPUPMDisabler.kext is similar to Disabler.kext. OSvKernDSPLib.kext and IOAudioFamily.kext are stock, but they are pre-requisites for getting VoodooHDA.kext to load out of the EFI partition.

QE & CI are fully working, and the Graphics Mode string only affects the graphics mode that Chameleon uses -- it has no effect on OSX.

Have you tried generating an EFI String for your graphics card? Obviously, it won't get QE/CI working -- but it would at least display native resolution -- and it might lead you further down the road to getting it fully working.

Also, using the word vanilla and iATKOS v7 together is a bit of a misnomer... iATKOS is prepatched. A vanilla install refers to using the retail DVD with no alterations at all. All of my modified kexts don't reside within the OSX install at all -- they are all in the EFI partition.

[GAOO]

I wasn't quite saying that iATKOS is vanilla. But iATKOS is close to it, and I think that if I can get the graphics driver working for the Boot132+retail disk+Chameleon, then iATKOS may work as well.

In any case, if Natit.kext required no changes on your end to get it working, then I think it is most likely something with the LCD screen.. which is extremely odd. Are you sure you didn't touch any of the other drivers, like NVDAResman or the NV50HAL?

Not quite sure how to proceed at this point anymore.. BTW, does Natit still work in 10.5.7 or 8 for you HannibalX?

Yes, IntelCPUPMDisabler.kext is similar to Disabler.kext. OSvKernDSPLib.kext and IOAudioFamily.kext are stock, but they are pre-requisites for getting VoodooHDA.kext to load out of the EFI partition.

QE & CI are fully working, and the Graphics Mode string only affects the graphics mode that Chameleon uses -- it has no effect on OSX.

Have you tried generating an EFI String for your graphics card? Obviously, it won't get QE/CI working -- but it would at least display native resolution -- and it might lead you further down the road to getting it fully working.

Also, using the word vanilla and iATKOS v7 together is a bit of a misnomer... iATKOS is prepatched. A vanilla install refers to using the retail DVD with no alterations at all. All of my modified kexts don't reside within the OSX install at all -- they are all in the EFI partition.

[bcc9]

QE & CI are fully working, and the Graphics Mode string only affects the graphics mode that Chameleon uses -- it has no effect on OSX.

By having chameleon switch graphics mode on you a few times before the nvidia drivers try to load you may have put your card into a different state than everyone else that's having trouble with 10.5.x on the built-in display. The built-in may simply be in the wrong mode for everyone else. I'd certainly try your different mode (with my original nvcap) if I was the one having problems.

Also, using the word vanilla and iATKOS v7 together is a bit of a misnomer... iATKOS is prepatched. A vanilla install refers to using the retail DVD with no alterations at all. All of my modified kexts don't reside within the OSX install at all -- they are all in the EFI partition.

And you guys might want to compare versions of the nvidia kexts that you have (among others). There were multiple versions of the nvidia kexts floating around in the 10.5.6 timeframe.

[HannibalX]

And you guys might want to compare versions of the nvidia kexts that you have (among others). There were multiple versions of the nvidia kexts floating around in the 10.5.6 timeframe.

NVDANV50Hal.kext & NVDAResman are both v1.5.44 with a last modified of 12/4/08 @ 9:49PM.

I'll try your DSDT that you posted to this thread, and report back my results.

Also, I am running 10.5.7, haven't gone to 10.5.8 yet because of all the reported issues with sleep.

[HannibalX]

NVidia GeForce 9400M G:



  Chipset Model:	NVidia GeForce 9400M G

  Type:	Display

  Bus:	PCI

  VRAM (Total):	256 MB

  Vendor:	NVIDIA (0x10de)

  Device ID:	0x0866

  Revision ID:	0x00b1

  Displays:

Display:

  Resolution:	1600 x 900

  Depth:	32-Bit Color

  Core Image:	Hardware Accelerated

  Main Display:	Yes

  Mirror:	Off

  Online:	Yes

  Quartz Extreme:	Supported

  Rotation:	Supported

Display Connector:

  Status:	No Display Connected

That's using the DSDT.aml posted by bcc9 in this thread, no NATIT.kext -- everything looking good.

Just need to tweak it for my wireless and ethernet now ;-)

Also, here is my ioreg output:

sh-3.2# ioreg -l -t -x -w100 | grep NVCAP

    | |   |     |   "NVCAP" = <05010000000001000e0000000000010b00000000>

sh-3.2# 

[bcc9]

That's using the DSDT.aml posted by bcc9 in this thread, no NATIT.kext -- everything looking good.

Great. I can tell you used the dsdt version as I put the extra G detail on the model name

Just need to tweak it for my wireless and ethernet now ;-)

You're not gonna get dell 1515 wireless working under 10.5.x, you need 10.6 for that.

| | | | "NVCAP" = <05010000000001000e0000000000010b00000000>

If you're bored you could also try the 3 video port version:
05010000 00000100 06000000 0000010b 00000000 (ie change the e to a 6)
That should be a more precise match for your hardware.

Also, I am running 10.5.7, haven't gone to 10.5.8 yet because of all the reported issues with sleep.

YMMV, but if you just make sure to be running AppleIntelCPUPowermanagement without having it disabled by disabler.kext or nullcpupowermanagement, then sleep should work.

[HannibalX]

You're not gonna get dell 1515 wireless working under 10.5.x, you need 10.6 for that.

I don't have the Dell 1515 wireless. I chose wisely when I ordered :-)

430-2929 Dell Wireless 1397 802.11g Half Mini Card

It is working, but I had to edit AppleAirPortBrcm4311.kext to add pci14e4,4315.

If I could change it to mask itself as 4313 in the DSDT, it'd run with no edits.

[GAOO]

I don't have the Dell 1515 wireless. I chose wisely when I ordered :-)

430-2929 Dell Wireless 1397 802.11g Half Mini Card

It is working, but I had to edit AppleAirPortBrcm4311.kext to add pci14e4,4315.

If I could change it to mask itself as 4313 in the DSDT, it'd run with no edits.

Did about the same thing. Took the AppleAirPortBrcm4311.kext and ran a script that someone on this forum provided to get the wireless 4320 working. Looking for Broadcom 43xx on google will lead you to it. Some people has the Dell 1515 here, but I have no solution for that at the moment...

Also, bluetooth 365 works as well. bcc9 provided a solution to it sometime ago, also on this forum.

Not so concerned with sound at the moment since I have an external USB sound card. Would really like to get video working first before I focus on internal sound...

I tried bcc9's DSDT as well a while back, and no success. I am really thinking this has to do with the LCD screen now... unless the NVCAP values also tells the GPU how to detect the LCD?

[GAOO]

In response to the versions of the NVidia drivers:

GeForce.kext ,NVDAResman.kext, NVDANV50Hal.kext are all v1.5.48.


It's interesting to note that they have a modified date of 12/4/08 as well.

HannibalX, do you mind uploading your GeForce, NVDAResman, and NVDANV50Hal kexts as a zip file on here? It would be much appreciated.

Honestly don't know if a version difference of 0.04 would make a difference..

NVDANV50Hal.kext & NVDAResman are both v1.5.44 with a last modified of 12/4/08 @ 9:49PM.

I'll try your DSDT that you posted to this thread, and report back my results.

Also, I am running 10.5.7, haven't gone to 10.5.8 yet because of all the reported issues with sleep.

[bcc9]

I tried bcc9's DSDT as well a while back, and no success. I am really thinking this has to do with the LCD screen now... unless the NVCAP values also tells the GPU how to detect the LCD?

Time to hook up an external monitor and see if those nvidia kexts are loading ok with qe/ci or what. If not then I'd suspect a config problem with your distro. While using the external monitor, would be good to try system preferences->display->detect displays to see if it accomplishes anything. I'd also look at whether the distro screwed with the pci matching (vanilla values should work), and whether you're running unibody macbook versions of those kexts. There are unibody macbook nvidia kexts posted in the 1340 thread.

There is plenty of troubleshooting you could do really.

[GAOO]

Thanks, I'll be running more tests with the external monitor tonight.

There is one interesting thing that I found with NVEnabler kext. NVEnabler includes a @0,display-cfg key. With its default value of 0301000 or other values such as 00000000, 01000000, 03000000, a blue screen does popup, but nothing else besides that. But by removing the key, nothing shows on screen! A black, empty output. It seems like this @0,display-cfg could be a potential fix, but like the NVEnabler developers, I don't know too much about what the @0,display-cfg is actually doing.

The other thing to note is that by changing the @0,display-cfg value, NVEnabler detects different rom signatures. It seems like it's affecting NVEnabler as to where to look for the ROM signature? Dunno how important this is to us, maybe helpful in debugging what it does.

Time to hook up an external monitor and see if those nvidia kexts are loading ok with qe/ci or what. If not then I'd suspect a config problem with your distro. While using the external monitor, would be good to try system preferences->display->detect displays to see if it accomplishes anything. I'd also look at whether the distro screwed with the pci matching (vanilla values should work), and whether you're running unibody macbook versions of those kexts. There are unibody macbook nvidia kexts posted in the 1340 thread.

There is plenty of troubleshooting you could do really.

[bcc9]

Thanks, I'll be running more tests with the external monitor tonight.

There is one interesting thing that I found with NVEnabler kext. NVEnabler includes a @0,display-cfg key. With its default value of 0301000 or other values such as 00000000, 01000000, 03000000, a blue screen does popup, but nothing else besides that. But by removing the key, nothing shows on screen! A black, empty output. It seems like this @0,display-cfg could be a potential fix, but like the NVEnabler developers, I don't know too much about what the @0,display-cfg is actually doing.

Ok, but what nvcap is nvenabler using? I think it's using the wrong nvcap for a 9400m. So try adding that @0,display value that seems to be helping to my original natit (which has the working nvcap). Such as

<key>@0,display-cfg</key>
	 <data>
	  AwEDAA==
	  </data>

The other thing to note is that by changing the @0,display-cfg value, NVEnabler detects different rom signatures. It seems like it's affecting NVEnabler as to where to look for the ROM signature? Dunno how important this is to us, maybe helpful in debugging what it does.

nvenabler also prints a bunch of errors as it stumbles around trying to find the video rom, so I wouldn't conclude much unless you can get the nvenabler folks to explain their diagnostic messages fully.

[GAOO]

I have no idea what NVCAP NVEnabler is using, but I think we can safely assume it is wrong since their detection algorithm doesn't seem to be successful. Anyhow, I added the @0,display value to your modified Natit, but besides the blue screen, nothing else shows.

I'm trying to pinpoint the problem to a specific source, but it is quite difficult. I'm currently looking at an IOReg of a genuine Macbook with the 9400M to see if I can find any other info. HannibalX and bcc9, do you mind saving your IOReg files and putting them up here as well? A "ioreg -lw0 > ioreg.txt" and then uploading the ioreg.txt would be great...

I'm also having a suspicion that the EDID from these 720p internal LCDs may be problematic.. if you guys, HannibalX and bcc9, have a dual boot system with Windows (and if you guys don't mind of course), can you install this monitor inspector http://www.entechtai...les/moninfo.exe and copy its Asset Information and paste it into a text file and upload it here?

BTW, can I also have a copy of your GeForce.kext, NVDANV50HAL.kext, and NVDAResman.kext, HannibalX?

I greatly appreciate your guys help, thanks a lot.


And also thanks for sticking with me for this long bcc9, greatly appreciate your help and input.

Ok, but what nvcap is nvenabler using? I think it's using the wrong nvcap for a 9400m. So try adding that @0,display value that seems to be helping to my original natit (which has the working nvcap). Such as

<key>@0,display-cfg</key>
	  <data>
	   AwEDAA==
	   </data>

nvenabler also prints a bunch of errors as it stumbles around trying to find the video rom, so I wouldn't conclude much unless you can get the nvenabler folks to explain their diagnostic messages fully.

[bcc9]

I have no idea what NVCAP NVEnabler is using

You could boot into single user mode and make sure their kext is loaded and then get it with ioreg. Or use an external monitor and boot fully.

, but I think we can safely assume it is wrong since their detection algorithm doesn't seem to be successful. Anyhow, I added the @0,display value to your modified Natit, but besides the blue screen, nothing else shows.

Did you add the value I recommended or the one from nvenabler? The value I recommended is from a genuine macbook with 9400m and so stands the best chance of working for you I think. You may also want to add the second entry:

<key>@1,display-cfg</key>
   <data>//8IAQ==</data

Neither of these were needed for the xps1340 but both are present in the unibody macbook ioregistry.

I'm trying to pinpoint the problem to a specific source, but it is quite difficult. I'm currently looking at an IOReg of a genuine Macbook with the 9400M to see if I can find any other info. HannibalX and bcc9, do you mind saving your IOReg files and putting them up here as well? A "ioreg -lw0 > ioreg.txt" and then uploading the ioreg.txt would be great...

I'll see. I'd have to edit out personal info first...

I'm also having a suspicion that the EDID from these 720p internal LCDs may be problematic.. if you guys, HannibalX and bcc9, have a dual boot system with Windows (and if you guys don't mind of course), can you install this monitor inspector http://www.entechtai...les/moninfo.exe and copy its Asset Information and paste it into a text file and upload it here?

NVDAResman should be getting the EDID automatically. I think trying to manually input the EDID is going to steer you off track. Thirdly, the EDID is already in the ioregistry no need to run moninfo.exe to get a copy.
Have you yet tried to attach a second monitor and verify that that is working for you? If not then you have more fundamental problems than anyone else with a 14z.

BTW, can I also have a copy of your GeForce.kext, NVDANV50HAL.kext, and NVDAResman.kext, HannibalX?

Those were posted over in the 1340 thread. I only have 10.5.[7,8] and 10.6 versions at this point. Are you still only on 10.5.6? Maybe you should try a known-working distro... Basically you just want to make sure that your versions aren't pre-unibody macbook and that your distro hasn't screwed up the match clauses in the Info.plists.

And also thanks for sticking with me for this long bcc9, greatly appreciate your help and input.

Thanks; I'd like to see you get to the bottom of this.

[GAOO]

I didn't know you could do ioreg in single user mode, lol. That would be most helpful, thanks for pointing it out.

I added the value that you've gave, and I previously also gotten it from a genuine macbook. But you did remind me that I probably do need @1,display-cfg.. I vaguely remember something about if I specify one of them, I need to specify the other as well.

Forgot that the EDID is in the ioreg as well. I've just been testing with an external monitor using your modified Natit.kext, and here's what I found:

With your recommended NVCAP of 05010000 00000100 06000000 etc etc, nothing gets displayed on HDMI or internal LCD. This is funny, since it's supposed to be the appropriate one.. The other thing is, on this Macbook that I am using on the side, although it only has one external display port, it also has the 06 in the NVCAP.

With the original NVCAP of 05010000 00000100 0E000000 etc etc, only the background shows on the HDMI, nothing else. On certain restarts, it will flash to the console, and report a crash. Sometimes, it would even say that there's too many crashes at a given instant and it can't write a crash report. Sounds pretty awful..

I installed using a 10.5.6 retail disk and upgraded to 10.5.8. This is post unibody macbook right? I also couldn't find the Nvidia kexts in the 1340 thread, was it attached there or was there a link in there? I flipped through the pages rather quickly and I didn't find any attachments related, but if it was a link, I may have missed it...

On the other hand, if westep23 got it to work perfectly fine on his external HDMI, then perhaps I do have a faulty install? westep23, if you're still around, can you tell me which distro you're using and what your install steps were?

[GAOO]

Argh, god help me, now external HDMI is completely working, with QE and CI and all. Was playing around with bits for NVCAP in bcc9's modified Natit.kext. Channel 2 has a value of 0A, lol. Channel 1 has value of 04. What in the world is going on?? This goes completely against the explanations that people more knowledgeable than me gave..

Details:
Was focused on getting external working, since internal LCD wasn't working whatsoever. So I was playing with Channel 2 bits:
0E - HDMI outputs, but only background. Console reports numerous crashes
06 - No output on HDMI.
0C - Corrupted HDMI, like 0E
0A - Corrupted HDMI, like 0E

So then I left channel 2 at 0A, thinking well, 06 was supposed to be the right value for channel 2, but since it doesn't display anything, that means the upper most bit must be a 1 for HDMI to work (since E, C, A all have the upper bit set). Then I was like hell, bcc9 did mention that the bits could get shifted, so let me try see if I can get lucky with the internal LCD. Bit shifting channel 1 bits...
01 - Nothing.
02 - Nothing
04 - WTF, external LCD works? Nothing on internal though.

This can't be real right? So i thought maybe the channel 2 bits were finally working correctly for some reason, let me try reset the channel 1 bit back to 01. Restart...

Corrupted HDMI and more crash output on console.

Wow, so channel 1 with 04 and channel 2 with 0A works well. Can someone please explain to me what the hell I just did???


EDIT:
More tests, here's what I found:
If I try to bit shift Channel 1 to 08, HDMI corrupts, console reports crashes. So it seems like Channel 1 must have 04, or at least bits 00000100.

Tried playing around with Channel 2, changed to 0C, everything for HDMI still works. Changed to 06, no output on HDMI again. I don't see any difference between 0C and 0A, so kind of troubled by that.


Now I am very happy that I am half way into getting this damned thing to work. It seems like its just the bit encoding is a lot different than usual. Well TOO different that I can't even find any help on it :/ But it seems like I just need set one more bit to get the internal LCD working.. lets hope that's the case!

[bcc9]

Wow, so channel 1 with 04 and channel 2 with 0A works well. Can someone please explain to me what the hell I just did???

By cycling thru the bit positions for channel one you've found by trial&error which bit is for HDMI on your system. You can make sure that it's really channel 1 by looking at your ioreg and making sure that your display is display-a not display-b. For reference, the bit mappings for the 1340 are:

1 0 0 0 - dvi/hdmi 
	  1 0 0 - display port
	  0 1 0 - vga
	  0 0 1 - built-in (LVDS)

The 14z is probably simply

1 0 0 - dvi/hdmi
	 0 1 0 - vga
	 0 0 1 - built-in (LVDS)

Seems like you should have been able to get HDMI working on channel2 with my original nvcap like it worked for westep23.

Still haven't heard from you what NVCAP nvenabler picks.

Have you tried 'detect displays' yet?

With your recommended NVCAP of 05010000 00000100 06000000 etc etc, nothing gets displayed on HDMI or internal LCD. This is funny, since it's supposed to be the appropriate one.. The other thing is, on this Macbook that I am using on the side, although it only has one external display port, it also has the 06 in the NVCAP.

Which makes sense as the macbook has 2 external video ports (dvi/hdmi&vga) just like the 14z. The mini-dvi onthe macbook is dvi-i.

I installed using a 10.5.6 retail disk and upgraded to 10.5.8. This is post unibody macbook right?

Yes, you'd certainly have full support after upgrading.

[westep23]

Ok I got NVEnabler to work. Im pretty sure that im using the stock 10.5.8 kexts. But I've be {censored} with this install so Im sure. My kexts versions are

GeForce 1.5.48.6 (17.5.7f10) <<--all NVDA kext same version
IOGraphicsFamily 1.7.3
And I might have the patched IOPCIFamily from bcc9 shows version 2.6
The working nvcap

<04000000000001000e0000000000000a00000000>

I'm going to do a clean retail install so I can make sure what installed. Also I didn't try HDMI.
And I also added my device id to Geforce.kext,NVDAResman,NVDANV50Hal, and NVEnabler. Like this

<key>IOPCIMatch</key>
<string>0x086610de</string>

But I dont know if it's needed. Post back after I do a clean install.