772 replies to this topic

[OoTLink]

Mmmm Nouveau guys, thanks.

In Linux, when the nvidia driver doesn't support Vaios (as it usually doesn't)... in the dude's own words:
"on the linux nvidia driver you have to tell it that a DFP is actually present, in addition to providing an EDID for it, so you might have both problems too"
"it does. the EDID has to be retrieved via ACPI and it doesnt know how to do that yet. but before it even gets to that it has to be told that DFP-0 is connected."

What the heck do we call a DFP in OS X and how do we tell it that there's one there even if it doesn't detect it?

[First Last]

DFP in the xorg.conf means a digital flat panel. Every TFT display is treatened as an DFP device.

see the definition from the man page:
"The driver usually can autodetect the presence of a digital flat panel.  In the case that this fails, this option can be used to force the driver to  treat the attached device as a digital flat panel.  With this  driver, a digital flat panel will work only if it was POSTed by the BIOS,  that is, the computer must have booted to the panel.  If you have a dual head card you may also need to set the option CrtcNumber described above. Default: autodetected."
Src.: http://www.x.org/arc.../man4/nv.4.html

What is meant with "booted to the panel"?

[OoTLink]

Thanks to a friendly member at macrumors, i was able to get us the 'device-properties' for an i5/i7 MacBook Pro (with the 330m!)

This is great, because we can use it to experiment with EDID injection


I've attached it, the idea is you can try using your own EDID and try a few values, then dump it into your boot.plist (or however you wish to use it) using something like OSX86Tools (which can import a plist file and convert it into the fat "device properties" hex mess at the bottom of boot.plist

I tried this, but my bootloader is pretty goofed up right now and is ignoring my Boot.plist files

Also: If you want to use it with a plist editor change the extension to .plist. There's a few EDID strings in this thread and you can always use SoftMCCS to grab yours.

Attached Files

•  gfxplist.txt   5.24K   31 downloads

[OoTLink]

I think I'm getting somewhere! Using that gfx.plist (with a modified EDID), my LCD *still* doesn't come on, but I get 3 display interfaces in my ioregdump.

LCD, CRT, and HDMI. And they are on PEG3 beyond the NGFX object, bet you didn't see that coming!

I'm beginning to think some DSDT mojo might help, but still!

Look at attachments, ioregdmp is what I had to begin with, and with string modifications I'm at gdump2.txt now

I've also included the boot.plist with my EDID in it (and the gfx.plist which should also have my EDID in it )


BTW, the plist files end in .plist, I just converted them to .txt .. bceause that's the only way to make them uploadable XD
You'll notice that I changed the PCI on the 4th ACPI entry (where EDID is) to PCI(0x3, 0x0) .. this is how Chameleon recognizes my GT330m

Attached Files

•  gdump2.txt   121.21K   13 downloads
•  ioregdmp.txt   567.69K   6 downloads
•  com.apple.CurrentBoot.plist.txt   7.69K   13 downloads
•  gfx.plist.txt   5.24K   17 downloads

[Funky frank]

Maybe a "Notify (PEG3, 0x02)" or "Notify (PEG3.NGFX.LCD, 0x02)" somewhere at the right place could activate the LCD? 0x02 means "activate/unsleep". Please also watch the "GFX0.DD01" to "GFX0.DD08" devices which seem to be virtual display devices or something... DD02 has also brightness functions inside. Don't know if it's important.

offtopic:
kizwan: Do you know why only RP01 and RP02 devices appear in my ioreg, but no RP06... ? RP06 seems to be the internal ethernet device...

[kizwan]

Funky frank, on Nov 21 2010, 10:22 PM, said:

offtopic:
kizwan: Do you know why only RP01 and RP02 devices appear in my ioreg, but no RP06... ? RP06 seems to be the internal ethernet device...

Usually it doesn't appear in IOReg if the PCI-Express port (RPXX) is not available (not implemented electrically). You can trace where the ethernet device is connected to which PCI-Express port in Windows Device Manager. Open the properties, go to Details tab & get the Parent value. It should consist of vendor & device ID. Locate it under System devices. When you found the device, open properties, go to Details tab & get the Address value. Search Name (_ADR, 0xAddress) in DSDT. you will found the correct RPXX.

[Funky frank]

kizwan, thanks a lot!

So here are some places in our F11-ACPI, taken from Win7:

Internal LAN (Marvell Yukon 88e8057):

ven/dev: 11ab/4380
Location in dsdt: RP03.PXSX
Parent device: "chipset PCI Express Root Port 3 - RP03" (8086/3b46), address "0x001c0002"
DSDT-status: Missing mac-like functions and naming
kext to hack: yukon2.kext


WLAN (Intel Centrino Advanced-N 6200 AGN):

ven/dev: 8086/422c
Location in dsdt:  RP01.PXSX
Parent device: "chipset PCI Express Root Port 1 - RP01" (8086/3b42), address "0x001c0000"
DSDT: Missing mac-like functions and naming
kext to hack: None available, maybe iwiDarwin could support it (description says it supports PROSet/Wireless 6x00 devices in svn version), if it will have support for OSX 10.6.


nVidia Geforce GT 330m:

ven/dev: 10de/0a29
Location in dsdt:  PEG3.NGFX
Parent device: "processor PCI Express Root port 1 - PEG3" (8086/D138), address "0x00030000"
DSDT-status: Hierarchy seems to be special, there exist also pseudo-deive "dd01" to "dd08". There is also a not used node "PEGP.NGFX" that is for Vaios with hybrid graphics processors.
kext to hack: NVDAHal50.kext


Realtek High Def Audio ALC275:

ven/dev: 10ec/0275
address: 0x0000000001
Location in dsdt: PCI0.HDEF
Parent device: "High Definition Audio Controller Intel" (8086/3b56), address "0x001b0000"
DSDT-status: Naming is ok, needs _DSM function and other
kext to hack: AppleHDA.kext with proper pin configuration or VoodooHDA.kext with proper dual device configuration (currently only detects the HDMI/Nvidia Audio device)


4 x nVidia Highdef Audio:

ven/dev: 10de/000a
addresses: 0x00000001,0x00000101,0x00000201,0x00000301
Location in dsdt: none
Parent device: "High Definition Audio Controller nVidia" (10de/0be2), "0x00000001", parent is PEG3 (8086/D138)
DSDT-status: devices and parents do not appear at all
kext to hack: AppleHDA (with proper DSDT entries) or VoodooHDA (unstable)


Internal LCD:

id: *PNP09ff
address: 0x0110
Location in dsdt: PEG3.NGFX.LCD
Parent device: "Gefore GT 330m" (10de/0a29)
DSDT-status: Seems to be quite complete, but is not active at login
kext to hack: ? NVDAHal50

[Funky frank]

OoTLink, on Nov 21 2010, 07:44 AM, said:

I've also included the boot.plist with my EDID in it (and the gfx.plist which should also have my EDID in it  )

Just to understand this, do I have to put these ACPI entries into chameleon's com.apple.Boot.plist ? Because I did and there is no change in my ioreg...

Edit: UNder IOACPIPlane I have PEG3.NGFX.LCD and so on without your ACPI patches. Where do they appear in your IOREG?  Under IOService?

[OoTLink]

Frank, I was beginning to worry this morning that what I might've said was in fact caused by the newer NVDA50Hal.kext from the MBP update (which you are probably using), and NOT the gfx-strings lol

I Guess that was the case Oh well.

I still don't think there's much harm to come from screwing around with gfx-strings, but it looks like YET AGAIN we're back at a sorta square 1 situation ><

To me though it seems like OS X is guessing the computer is a 15" high res MacBook Pro. With the bare GPU driver I remote in and get 1680x1050.

That said, I was doing gfx-string tweaking and now I can't remote in at all, although OS X is running. I could really use a VGA monitor right now lol.

[Funky frank]

OoTLink, on Nov 21 2010, 11:18 PM, said:

Frank, I was beginning to worry this morning that what I might've said was in fact caused by the newer NVDA50Hal.kext from the MBP update (which you are probably using), and NOT the gfx-strings lol

Can you tell me whether your LCD appears under the IOService tree or just under the IOACPIPane ?

[OoTLink]

Tell me what command to use to dump the IOService tree and I'll dump it..

Or do you want that one program? the registry explorer? Yea I can do that.. hehe

[Funky frank]

OoTLink, on Nov 22 2010, 04:08 AM, said:

Tell me what command to use to dump the IOService tree and I'll dump it..

Can you just look into the IOService with IORegExplorer and look at the node PEG3.NGFX if there is LCD.

[OoTLink]

Nothing Grr. @#% it. *ebays his Vaio* or something

[Funky frank]

What about focusing on

1. Internal LAN

2. Internal sounddevice

?

I think it is quite presumably that we can make these two work. What do you think?

My OSX is already ok for audio editing (usb device) and programming...

[jlvaio]

http://www.insanelym...p;#entry1591866

[Razorbackeve]

My two cents.

I own a sony vaio CR11z, i´m using right now dong HD driver for the integrated ATI X2300.
Before i tried every injector avaliable with no success, black screen as anyone else.

But several days ago, this thread made some light for me about a possible solution:
Generic brightness
That topic is about a brightness driver wich on the beginning i couldn´t make it work, then ivik (the programmer) released another driver based on a more generic ACPI driver wich reads a customized device on DSDT.
    

Device (BRGT)
				{
					Name (_HID, EisaId ("APP0321"))
					Name (_CID, "brightness")

Well, the point is: picking some code from inside DEVICE (LCD) on dsdt and pasting it on the suggested device code, gave me access to the ACPI brightness control: Brightness on Vaio

These are the GBRT (Get brightness) and SBRT (Setbrightness) wich are inside DEVICE (SNC)

			  Method (GBRT, 0, NotSerialized)
						   {
							   Store (0x00, DID)
							   Store (0x85, BCMD)
							   Store (0x85, SMIF)
							   Store (0x00, TRP0)
							   Store (PAR2, Local1)
							   Return (Local1)
						   }
	   
							  Method (SBRT, 1, NotSerialized)
						   {
							   Store (Arg0, Local0)
							   If (LGreater (Local0, 0x08))
							   {
								   Return (Local0)
							   }
	   
							   Store (0x01, DID)
							   Store (0x85, BCMD)
							   Store (Arg0, PAR2)
							   Store (0x85, SMIF)
							   Store (0x00, TRP0)
							   Return (Zero)
						   }

If brightness controls GET/SET are inside Device(SNC) on DSDT, what else it is?
We can take a deeper look onto SNC and try to extract some code and add it to our graphic device on DSDT, filling the "missing" code and/or getting the ability to tweak it.
I´m very sure after this brightness thingy that all the internal LCD problems come from  hidding code inside Device(snc) , wich Osx doesn´t recognize at all (Not even a single dsdt line inside it) or DEVICE (EC0)

Info about sony  ACPI methods Link (Posted earlier on this thread also).



Another example:
Into Device (EC)
Is this method telling the system wich output from the graphic card is the active one ?

 Method (_QBD, 0, NotSerialized)
					   {
						   If (LEqual (OSYS, 0x07D6))
						   {
							   If (IGDS)
							   {
								   Notify (\_SB.PCI0.GFX0, 0x81)
							   }
							   Else
							   {
								   Notify (\_SB.PCI0.PEGP.EVGA, 0x81)
							   }
						   }
						   Else
						   {
							   Store (\_SB.PCI0.LPCB.SNC.ESR, Local0)
							   Or (0x04, Local0, Local0)
							   Store (Local0, \_SB.PCI0.LPCB.SNC.ESR)
							   If (And (\_SB.PCI0.LPCB.SNC.ENCR, 0x04))
							   {
								   Notify (\_SB.PCI0.LPCB.SNC, 0x92)
							   }
   
							   Sleep (0x01F4)
						   }
					   }

Look also how the method does some callings to Device(SNC):

Store (\_SB.PCI0.LPCB.SNC.ESR, Local0)
Store (Local0, \_SB.PCI0.LPCB.SNC.ESR)


Down this code you can find also this one:

					Method (_Q43, 0, NotSerialized)
					  {
						  Store (0x33, DID)
						  Store (0x85, BCMD)
						  Store (0x02, PAR2)
						  Store (0x85, SMIF)
						  Store (0x00, TRP0)
					  }
  
					  Method (_Q44, 0, NotSerialized)
					  {
						  Store (0x33, DID)
						  Store (0x85, BCMD)
						  Store (0x01, PAR2)
						  Store (0x85, SMIF)
						  Store (0x00, TRP0)
					  }
  
					  Method (_Q45, 0, NotSerialized)
					  {
						  Store (0x33, DID)
						  Store (0x85, BCMD)
						  Store (0x00, PAR2)
						  Store (0x85, SMIF)
						  Store (0x00, TRP0)
					  }

This is clearly setting some values for brightness. (For 3 output devices -----> VGA/S-VIDEO/LCD ?)

Anyway, if we follow Store (Local0, \_SB.PCI0.LPCB.SNC.ESR) we arrive to:

  
					 Name (ENCR, Zero)
					 Name (ESR, Zero)
					 Name (ABCH, Zero)
					 Name (ECR0, Zero)
					 Name (FNUM, Buffer (0x20)
					 {
						 /* 0000 */	0x00, 0x01, 0x01, 0x01, 0x02, 0x01, 0x00, 0x00, 
						 /* 0008 */	0x00, 0x00, 0x05, 0x01, 0x06, 0x01, 0x17, 0x01, 
						 /* 0010 */	0x00, 0x00, 0x19, 0x01, 0x0A, 0x01, 0x13, 0x01, 
						 /* 0018 */	0x14, 0x01, 0x15, 0x01, 0x0E, 0x01, 0x0F, 0x01
					 })

Doesn´t this look like some kind of sony NVCAPS?

Maybe i´m completely wrong, but i think we have to extract ACPI code from sony propietary zones to more friendly devices in order to make them work.

Thanks for reading.

[Mammoth]

Hello everyone,

I have a lot of respect for you all still trying to get this to work. I just found a link which might help you:

http://www.insanelym...p;mode=threaded


Hope it does help,

Mammoth

[ricardoplugins]

has anyone tried Snow leopard in a SONY VAIO i7  ( VPCF13PFX )
I'm pretending to use it for Final Cut Pro (so audio & video must work)

Hardware content (similar):
Processor: i7-740QM  1.73 GHz
VIDEO:     NVIDIA® GeForce® GT 310M / GT 425M
AUDIO:     Realtek ??? Audio HD PCEE

ETHERNET: Marvell® Yukon® 88E8057 PCI-E Gigabit Ethernet
WIRELESS: Marvell® Atheros® AR9287 Wireless Network Adapter
MOTHERBOARD: Intel® 5 Series 6 Port SATA AHCI

Please anything you know will be really helpfull
Thanks
        skydivemail@yahoo.com

[Funky frank]

Razorbackeve: Your investigated stuff looks very interesting. Do you know if it is possible to enable the path /proc/acpi like on linux systems? Is there any way to enable this in OSX? It should, because it's based on linux...

With /proc/acpi you can easily write parameters to acpi devices. I think this would save a lot of time.

I will try to implement your suggestions, Razorbackeve. But where is the right place for it? Where is the place the standard lcd activation happens on other acpi setups? Any ideas?

[ghost3000]

Funky frank, on Nov 29 2010, 09:49 PM, said:

Razorbackeve: Your investigated stuff looks very interesting. Do you know if it is possible to enable the path /proc/acpi like on linux systems? Is there any way to enable this in OSX? It should, because it's based on linux...

With /proc/acpi you can easily write parameters to acpi devices. I think this would save a lot of time.

I will try to implement your suggestions, Razorbackeve. But where is the right place for it? Where is the place the standard lcd activation happens on other acpi setups? Any ideas?

See if this helps to enable the procfs. http://osxbook.com/b...apter11/procfs/