517 replies to this topic

[GAOO]

bcc9, on Aug 16 2009, 05:44 PM, said:

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?

westep23, on Aug 17 2009, 02:37 AM, said:

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]

GAOO, on Aug 16 2009, 08:19 PM, said:

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?

GAOO, on Aug 16 2009, 09:46 PM, said:

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.

GAOO, on Aug 16 2009, 09:46 PM, said:

... ???  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.

westep23, on Aug 16 2009, 07:37 PM, said:

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).
  

westep23, on Aug 16 2009, 07:37 PM, said:

<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]

GAOO, on Aug 16 2009, 10:20 PM, said:

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 crap, 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...

bcc9, on Aug 17 2009, 05:24 AM, said:

1366?!  Oh crap, 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]

GAOO, on Aug 16 2009, 10:34 PM, said:

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).
  

GAOO, on Aug 16 2009, 10:34 PM, said:

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?

[westep23]

Put this in /System/Library/Display/Overrides

Attached Files

•  DisplayVendorID_4ca3.zip   1.38K   35 downloads

[GAOO]

Seems like you got a lot done in the 10 min time frame, lol.  I didn't even get a chance to reply back to your PM.

But based on your PM's info, it seems like the resolution has been slightly clipped to 1360x768, which is fine by me.

I have to sleep to go to work tomorrow, but I'll give it a try tomorrow.  Thanks a lot for your help, westep23!

westep23, on Aug 17 2009, 11:29 AM, said:

Put this in /System/Library/Display/Overrides

[GAOO]

So incase other people are reading and couldn't follow what was going on in the last 2 messages, basically westep23 was experimenting with /System/Library/Display/Overrides files.  He created an override file using np_'s display utility, and then got the internal LCD to display at 1360x768 in regular Leo (in SL, native res 1366x768 is supported he says).

After westep23 brought my attention to display overriding, I was looking at np_'s progress on his LCD tests.  Looking at some posts on there, I realized that we can easily see if OSX is reading the EDID or not by checking the Windows Server Log.  And look what I found (this is with the modified DSDT or Natit):

Aug 17 06:18:01  [115]   Display 0x2bc40f00: MappedDisplay Unit 0; Vendor 0x6af Model 0x103c S/N 0; online enabled (0,0)[-1073750400 x -1073750400], base addr 0x21c6000

Vendor 0x6af and Model 0x103c corresponds to my internal AUO LCD, so OSX is definitely reading the EDID correct.  And if you look further down the line, that huge neg number multiply by another neg number indicates some kind of arithmetic overflow for the resolution, which could mean that 1366x768 is not a valid resolution under regular Leo.

If I use my NVCAP value in the Natit, we see:

Aug 17 06:23:20  [67]   Display 0x2b103855: MappedDisplay Unit 1; Vendor 0x10ac Model 0x403c S/N 926168917; online enabled (0,0)[1680 x 1050], base addr 0x1800000

And that corresponds to my external HDMI display, and the resolution is correct.

Unfortunately, westep23 has the SEC (sorry the other LCD model is not LG, but SEC) internal LCD, so the display override file he provided above does not work for me.  To create the override display file, I need np_'s DisplayUtility.  But it seems like np_'s DisplayUtility attachment is no longer on this forum, and I have no idea where I can get a copy of it...

[westep23]

Try this one. Just clarify I didn't use np_'s utility. I used Switchresx in SL then copied the override file to the Leo install. I found out tonight that you can use switchrex to create a override  for a unattached display.

Attached Files

•  DisplayVendorID_6af.zip   1.25K   16 downloads

[GAOO]

Thanks westep23, I've been really busy and haven't had a chance to test it out...

Snow Leopard is supposedly coming out on Aug. 28, so I think I'll wait one week to test that instead

[GAOO]

westep23, on Aug 18 2009, 10:38 AM, said:

Try this one. Just clarify I didn't use np_'s utility. I used Switchresx in SL then copied the override file to the Leo install. I found out tonight that you can use switchrex to create a override  for a unattached display.

Actually had some free time tonight, so I tested out this Display Override.  

I just want to THANK YOU VERY MUCH westep23.  The internal LCD works, with the resolution of 1360x768 and QE/CI.  6 pixels missing from the right, but it's okay

So for other users, here's what you need:
- bcc9's modified Natit.kext (NVCAP with Ch1 as 01, and Ch2 as 0E,0C,or 0A), put into wherever you place your extensions.  In my case, the EFI partition.  
- westep23's customized Display Override Folder/File, put in /System/Library/Displays/Overrides

Restart and you're set

EDIT: Attached below for people to find easily.  Give credits to the people mentioned above, not me.  They're the geniuses

BTW, if you have the AUO internal LCD, use the DisplayVendorID_6af.  If you have the SEC internal LCD, use the DisplayVendorID_4ca3.


EDIT2:  You can actually put both DisplayVendorID into the Displays/Overrides folder.  OSX will be able to choose accordingly.

Attached Files

•  Natit.kext.zip   25.36K   50 downloads
•  DisplayVendorID_6af.zip   1.25K   29 downloads
•  DisplayVendorID_4ca3.zip   1.38K   28 downloads

[GAOO]

I am currently trying to figure out how to get sound working.  VoodooHDA does not work too well, has anyone else had any luck with this?

[MrFuzzemz]

GAOO, on Aug 23 2009, 02:28 AM, said:

Actually had some free time tonight, so I tested out this Display Override.  

I just want to THANK YOU VERY MUCH westep23.  The internal LCD works, with the resolution of 1360x768 and QE/CI.  6 pixels missing from the right, but it's okay

So for other users, here's what you need:
- bcc9's modified Natit.kext (NVCAP with Ch1 as 01, and Ch2 as 0E,0C,or 0A), put into wherever you place your extensions.  In my case, the EFI partition.  
- westep23's customized Display Override Folder/File, put in /System/Library/Displays/Overrides

Restart and you're set

EDIT: Attached below for people to find easily.  Give credits to the people mentioned above, not me.  They're the geniuses

BTW, if you have the AUO internal LCD, use the DisplayVendorID_6af.  If you have the SEC internal LCD, use the DisplayVendorID_4ca3.


EDIT2:  You can actually put both DisplayVendorID into the Displays/Overrides folder.  OSX will be able to choose accordingly.

Is what you've listed everything that needs to be done to get graphics working properly? I added the attached Display overides folders and installed the attached Natit.kext, repairs permissions and I get a panic when I restart.  Removing the Natit.kext manually allows me to boot again.  I have a 1600x900 screen by the way. Anything I forgot or should try? Thanks.

I should also let people know that with the Dell 1397 wireless card airport works perfectly with the Broadcom drivers.

[GAOO]

For the 1600x900, HannibalX didn't need any of the display overrides, only the Natit.kext to get his display working.

Can you tell me which distribution you're using?  And what version of OSX?  BTW, try just the Natit.kext alone.

If Natit.kext doesn't work, I don't think bcc9's DSDT would work... but you can give it a try.

MrFuzzemz, on Aug 28 2009, 12:46 PM, said:

Is what you've listed everything that needs to be done to get graphics working properly? I added the attached Display overides folders and installed the attached Natit.kext, repairs permissions and I get a panic when I restart.  Removing the Natit.kext manually allows me to boot again.  I have a 1600x900 screen by the way. Anything I forgot or should try? Thanks.

I should also let people know that with the Dell 1397 wireless card airport works perfectly with the Broadcom drivers.

[MrFuzzemz]

GAOO, on Aug 28 2009, 12:46 PM, said:

For the 1600x900, HannibalX didn't need any of the display overrides, only the Natit.kext to get his display working.

Can you tell me which distribution you're using?  And what version of OSX?  BTW, try just the Natit.kext alone.

If Natit.kext doesn't work, I don't think bcc9's DSDT would work... but you can give it a try.

I installed iDeneb 10.5.7.1 (OSX 10.5.7) with the Broadcom wireless drivers as the only addition. Installing the Natit.kext on this thread with or without the display overides gives me a panic on boot. I would try the DSDT, but I don't know how to install that. Any other suggestions?
Thanks,
MrFuzzemz