Driver compatibility for Dell Studio 14z (Successful OSX install!)

[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.entechtaiwan.com/files/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.entechtaiwan.com/files/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 screwing 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.

[GAOO]

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?

 

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.

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

 

The explanation about the bit mapping is a bit unclear. Are you saying that the bit mapping for channel 1 and channel 2 are the same and inter-exchangeable? I'll check the channel tonight. But I was pretty sure ioreg said something about @1 display, meaning channel 2 right? Anyhow, let me just double check everything again tonight.

 

I tried Detect Displays, but it detects nothing. About the NVCAP for NVEnabler, I am not sure, I haven't gotten a chance to check it. But since it uses 3 different methods to detect the NVCAP and other values, I don't think there's a way to find out the NVCAP that has been detected successfully right?

 

 

Ok I got NVEnabler to work. Im pretty sure that im using the stock 10.5.8 kexts. But I've be screwing 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.

 

I tried that NVCAP before but with no success.. but I think that may have been with a 10.5.6 install. And I don't know if using bcc9's Natit or NVEnabler would make a difference, since they're both injecting those values (NVCAP) in. NVEnabler does try to inspect the ROM for more values, but it doesn't seem successful at all (the @0,display-cfg is what causes the internal LCD blue screen to pop up... maybe that is needed for bcc9's Natit to make the internal LCD work). Anyhow, if you do try a clean retail install and it was successful, please let me know and I can try it out and also with an external HDMI monitor.

 

 

Will report back more results tonight, look forward to yours too westep23

[GAOO]

Ok, so I was checking my ioreg, and I see both display-A@0 and display-B@1. I am pretty sure display-B@1 is my external HDMI, because there's a width and height value for display-A@0 and they are both 00000000. The display-B@1 does not have a width and height value, and some of the values also contains strings that are much longer than that of display-A@0.

 

I tried using westep23's NVCAP with Natit and NVEnabler, but no success. NVEnabler always shows a blue screen on the internal LCD, and just a black screen on the external. I also tried adding @0,display-cfg and @1,display-cfg to my working NVCAP with bcc9's modified Natit, no success. Whether your clean install is success or not, westep23, can you let me know? Would be very interested in hearing about what you've tried so far.

 

Will try to continue to figure out the NVCAP bits on my side. The bits are still very strange to me, and doesn't make much sense. The channel 2 bits and the channel 1 bits seems to depend on each other to make the external HDMI work. Right now, Ch1=04 and Ch2=0C will make HDMI work. If I change Ch1 to 02, 01, or 08, HDMI displays a corrupted blue screen with tons of crashes reporting on the console. If I change Ch2 to anything without the MSB(most significant bit) set on the second digit, then nothing on the HDMI shows (For ex, 06 does not output anything on HDMI). It just baffles me why does channel 1 and channel 2 bits seem to depend on each other??

 

EDIT:

BTW, ran NVEnabler on its own, without any NVCAP inject, and it reports a NVCAP of a value that is the same as westep23's NVCAP.

 

... ??? This NVCAP is based on NVEnabler's first detection method, can't find out the other 2 methods since single user mode only occurs right after the 1st detection method.

[bcc9]

The explanation about the bit mapping is a bit unclear. Are you saying that the bit mapping for channel 1 and channel 2 are the same and inter-exchangeable? I'll check the channel tonight. But I was pretty sure ioreg said something about @1 display, meaning channel 2 right? Anyhow, let me just double check everything again tonight.

So my understanding (which may be imperfect as NVCAP is not fully documented anywhere AFAIK) is that the channel1 & channel2 bytes of NVCAP are bit fields. You set the bits to indicate which video output ports are assigned to which display. Channel1 represents the primary display (aka the @0 display), channel2 the secondary (aka the @1 display).

 

So ordinarily you'd have just 1 bit set for the primary display, the bit representing your main video port, and the other bits set for the secondary display. You can swap the bytes for testing purposes I should think. Setting the same bit in both bytes would be "illegal" I believe.

 

So it still looks like I gave you the right NVCAP possibilities back in post #10, and that even the original one would be OK, and your problem with the built-in display is something else.

 

Now that you've finally tested with an external monitor, I'd revisit the EDID possibility.

What exactly is the resolution of your "720p" display? 1280x800 like the 1340? If it's 1280x768 the 10.5.x nvidia driver may be deeming it an invalid resolution. You could hack your edid to use a standard resolution if it's 1280x768. I assume the nvidia driver isn't logging any errors when you boot with -v?

 

Will try to continue to figure out the NVCAP bits on my side. The bits are still very strange to me, and doesn't make much sense. The channel 2 bits and the channel 1 bits seems to depend on each other to make the external HDMI work. Right now, Ch1=04 and Ch2=0C will make HDMI work. If I change Ch1 to 02, 01, or 08, HDMI displays a corrupted blue screen with tons of crashes reporting on the console. If I change Ch2 to anything without the MSB(most significant bit) set on the second digit, then nothing on the HDMI shows (For ex, 06 does not output anything on HDMI). It just baffles me why does channel 1 and channel 2 bits seem to depend on each other??

When you set ch1=4,ch2=c, you are disabling the LVDS port and so things work with the other ports. When you have the LVDS port enabled the nvidia driver has problems with your config (EDID? Lack of use of built-in keyword anywhere in your EFI string?), and so it doesn't initialize things right.

 

... ??? This NVCAP is based on NVEnabler's first detection method, can't find out the other 2 methods since single user mode only occurs right after the 1st detection method.

Seems to me it's just using a static NVCAP string, just like the algorithm in chameleon, and the only thing it's trying to do dynamically is set the two channel bytes. And it looks like it's doing that wrong too as it's set 4 bits as if your hardware had 4 display ports.

I think by detection methods you're just seeing its redundant failure messages as it looks for the vga rom in the wrong places.

 

The working nvcap

 

<04000000000001000e0000000000000a00000000>

Funny it's picked 4 display ports for your system instead of 3; it doesn't seem to be properly detecting the # of ports dynamically. That is basically the same as the chameleon value I posted in post #10 (other than the 4 vs 3 ports).

<key>IOPCIMatch</key>

<string>0x086610de</string>

If you have vanilla kexts you should see that the 9400m would be matched anyways; no need for a 0866 specific entry.

[GAOO]

My 720p resolution is 1366x768, kind of an odd resolution. I think we should wait and see what results westep23 has for his new installation. If he does have the same LCD screen, then perhaps it has to do with the install..??

 

The other thing about 720p LCDs are that Dell had two manufacturers make them, mine is by AUO, and I read that LG (or another company starting with L..) makes them as well. The LG ones had graininess problems reported by users. Anyhow, if westep23's LCD is from LG, then another attributable problem could be tied to my AUO 720p display... which would really suck.

 

Anyhow, I sent westep23 a message, and I hope I can talk to him on an instant messenger or something. Thanks a lot for your help bcc9.

[bcc9]

My 720p resolution is 1366x768, kind of an odd resolution. I think we should wait and see what results westep23 has for his new installation. If he does have the same LCD screen, then perhaps it has to do with the install..??

1366?! Oh {censored}, why didn't you say so. 1366 is not evenly divisible by 8 and so is not normally considered a valid resolution. I had to go thru hoops and eventually hack my EDID manually on my plasma to get an nvidia card to work at that resolution.

[GAOO]

I thought I mentioned it several times before, but anyhow, its nice to know that it is a problem with the resolution. Do you have any idea how to force it down to a lower one?

 

Seems like you hacked the EDID on your plasma, so I'm guessing it's not possible to hack it on the internal LCD? :/

 

I still have a week before the return period is up, so I can still return it and get a 900p screen.. LOL...

 

1366?! Oh {censored}, why didn't you say so. 1366 is not evenly divisible by 8 and so is not normally considered a valid resolution. I had to go thru hoops and eventually hack my EDID manually on my plasma to get an nvidia card to work at that resolution.

 

 

EDIT: Still looking forward to hear what westep23 did, and his progress so far.

[bcc9]

I thought I mentioned it several times before, but anyhow, its nice to know that it is a problem with the resolution. Do you have any idea how to force it down to a lower one?

Oops, you did. Well, I'm just thinking it's a problem, I don't know for sure under OSX. And apparently 10.6 is more lenient so you could always just upgrade to the beta (or wait).

Seems like you hacked the EDID on your plasma, so I'm guessing it's not possible to hack it on the internal LCD? :/

Should be easier. I had to snip a wire to un-write protect the flash memory and actually flash update the display device. You should be able to just add the edid to natit and away you go. Try changing the 1366 to 1280 for starters. (I'm assuming your lcd can scale from 1280x768). Does windows use the 1366x768 or is it rounding it to 1360 or 1368? Might want to figure out what the next best resolution is that windows allows.

 

EDIT:

Hmm, I just double checked and my 1340 connected to the plasma via hdmi worked at 1366x768, under osx 10.5.6 &10.5.7. So I may be full of it. On the other hand nvidia drivers have fought me over that resolution a lot in the past.

 

EDIT2: Actually the plasma shows about 2 pixels of wraparound so I think the nvidia card is outputting 1368x768 when claiming 1366x768. Your LCD may not handle that...

[GAOO]

Hm... well I am planning to upgrade to Snow Leopard when it is out and when we know that it is installable without much of a problem. I don't mind waiting it out, though getting OSX to work now would be very ideal. How stable is SL beta? And why aren't people using it as much (like westep23 backed out of it)?

 

Regarding the resolution, it seems like most people had trouble with 1366 x 768 resolution with OSX around 2006-2007. Not so much recently since I don't see much people complaining about it when I do a google search on it.

 

What I failed to test tonight was set ch1 to 00 and left Ch2 alone, and see if HDMI still works. Based on your explanation, it still should. And if it still does work, then OSX is definitely having problems with the internal LCD, which could explain why there's a corrupted HDMI output on Ch2 when Ch1 is set to detect the internal LCD.

 

I usually use the external HDMI whenever I have access to it, and use the internal LCD on the go. Is there a way to tell Chameleon v2 to use a specific extension cache in the extra folder on boot? I don't mind using the VESA mode on the go... as opposed to having no display on the go for OSX.

[westep23]

No I still use it. I have too for wireless. It's pretty stable. I actually like it better because after I (bcc9) patched the dsdt. Everything works perfectly in 32bit mode.

 

#1 Reason: My videocard always worked.

[GAOO]

I see, for some reason I was under the impression that you went back to regular Leopard, I guess I'm wrong. I may go the SL route maybe sometime later, which may be when SL is actually out.

 

It is very nice to hear that with the patched DSDT the graphics works without any problems. That's actually a huge plus!

 

Which build of SL do you have?