772 replies to this topic

[OoTLink]

http://www.insanelym...mp;#entry747500

Funkyfrank, try    MacVidia_1.0.81.pkg.zip ( 151.86K ) Number of downloads: 264

and if that doesn't work, maybe the    MacVidia_NVDriver107.zip ( 49.68K ) Number of downloads: 199

If those work, let me know ^^ thanks. What they SHOULD do (and what I've heard they do) is enable a software framebuffer (eg, no QE/CI) but with 1920x1080 support

[kizwan]

Funky frank, on Nov 15 2010, 06:08 AM, said:

kizwan: What about this idea:

DD02 device seems to me the output device for LCD. The function DD02._DSS sets the state of it. Maybe we could change the calls in a way that the lcd / dd02 is alwas active. What do you think? Btw. why there are also DDXX-devices, it's not mentioned in the acpi docs.

Yeah, I don't see any reason why not. Go ahead. Study the EDID value will be good idea too.

About the DDXX devices, it is manufacturer specific implementation. That is why you can't find it in ACPI docs. I believe it is display configurations.

[OoTLink]

One of the reasons I want to know about macvidia is to see if we can get a better glimpse at the info according to OS X when it works.

[JamesA27]

Hello, I have a VAIO VPCF127FX and luckily I came across this forum.

I don't know too much but I wanted to know more about this problem.  So, I've gotten various errors booting up onto standard mode with both the retail 10.6.3 Retail Snow Leopard DVD and also the installed version.  However, both do work when I boot up in Safe Mode and I do not know why this is...

Anyway, I have tried various drivers and updates from in Safe Mode.  But, I was wondering if this is the same problem as you guys have?  When I boot up in standard mode, the monitor shuts off with no backlight or response, while safe mode boots up fine.  Also, I have booted up in verbose mode and have gotten different errors, yet, unfortunately I do not know when I am making progress.  I can try installing any .kexts or updates tomorrow if you need someone to test them.

Thanks,

James

[Funky frank]

kizwan: But where in the dsdt is the line of code that acually enables the internal LCD? Do you know this? Or is it hardcoded within the nvidia driver without any use of ACPI?  In general is there any code in ACPI that actually enables some hardware?

OoTLink: The provided MacVidia requires i386 kernel and then crashes at boot. I think it has to be recompiled for 10.6 and linked to recent system components. We need the sources of that! Can you get it here in the forum?

Edit: Ok in the meanwhile maybe we should focus on not so difficult patches, like Audio and speed-stepping for the Core i7.

CPU Stepping: Kizwan, do you know how to setup a good cpu stepping by using Chameleon PStates? CStates are for older cpus, right? The CPU is running quite hot here, so I guess the stepping could be better. Is there any tool the shows the current cpu speeds? My "about mac" crashes.

Audio: If the audio device in ACPI is renamed from HDEF to AZAL, voodoohda will load and stay stable here. HDEF is the nvidia hdmi audio device or the internal Realtek one? Anybody?

Bluetooth: Does it work for you? Not for me. With unpatched dsdt it shows up bluetooth devices but does not add it. Maybe bluetooth needs to be activated thru snc device first.

LAN: Any ideas? Is there a similiar driver out there?

[OoTLink]

If you use VoodooHDA, it's possible to get the internal audio working, but I never did get beyond the initial sketchy state of it (it would start up the internal speakers when I manually started the driver, but after trying to configure it to start at boot, it crashed the machine lol).

By default VoodooHDA really likes to work with the HDMI output. Go figure right?

[kizwan]

Funky frank, on Nov 16 2010, 05:07 AM, said:

kizwan: But where in the dsdt is the line of code that acually enables the internal LCD?

When did I said there is one in the DSDT? There is LID control method which is for LID operation (e.g. what to do when LID is close/open).

There are control method in the DSDT to turn ON/OFF the usual stuff like bluetooth & wireless.

Funky frank, on Nov 16 2010, 05:07 AM, said:

CPU Stepping: Kizwan, do you know how to setup a good cpu stepping by using Chameleon PStates? CStates are for older cpus, right? The CPU is running quite hot here, so I guess the stepping could be better. Is there any tool the shows the current cpu speeds? My "about mac" crashes.

Does AppleLPC.kext loaded? You need it loaded because it will help CPU run much cooler. I do not generate the C-State & P-State manually since my notebooks is supported by default by OSX. C-State is CPU power management while P-State is an operational state. Both state related with each other.

[OoTLink]

If Vaio Control Center is any indication, the F series' "lid' sensor only recognizes the laptop being closed, not opened. Just fyi

[Funky frank]

kizwan, on Nov 16 2010, 01:46 AM, said:

Does AppleLPC.kext loaded? You need it loaded because it will help CPU run much cooler. I do not generate the C-State & P-State manually since my notebooks is supported by default by OSX. C-State is CPU power management while P-State is an operational state. Both state related with each other.

No AppleLPC is not loaded. In the dsdt the is a LPCB device on PCI0. In IORegistry there is a LPCB with name "8086,3b03" and compatible "pci104d,9067".

Edit: Added "8086,3b03" to AppleLPC.kext and now it's loaded. But the cpu is still very hot and the cooler runs all the time. How to enable proper power management now?

Edit: Ok, with 1. adding devid to AppleLPC.kext, 2. the option ForeceHPET=Yes, 3. GeneratePStates=yes and 4. GenerateCStates=Yes the cpu is not so hot anymore, but still runs hotter than under win7.

Edit: Hm, sleepmode does not work anymore....

[Funky frank]

kizwan: Do you know what device is the ethernet device in the dsdt? Did you remove it in your DSDT?
Vendor 11ab Devid 4380, Yukon 88e8057, should be loaded by Yukon2.kext if editing pcimatch...

edit: I tried to patch the network device in dsdt like explained here. The strange thing is, in the VaioDST generated in OSX, there is only a P0PF device, in the Vaio DSDT generated in Windows (posted in this thread at beginning and  dsdt_VAIO_windows.dsl.zip   17.62K   6 downloadshere), there is only a P0P9 device. Also strange is Ethernet device is not listed in IOReg at all.

So I tried to patch the device like this:

			/*Device (P0PF)
			{
				Name (_ADR, 0x001E0000)
				Method (_PRW, 0, NotSerialized)
				{
					Return (GPRW (0x0B, 0x04))
				}
			}*/
			// NETWORK patch
			Device (P0P9)
			{
				Name (_ADR, 0x001E0000)
				Method (_PRW, 0, NotSerialized)
				{
					Return (GPRW (0x0B, 0x04))
				}

				Method (_PRT, 0, NotSerialized)
				{
					If (PICM)
					{
						Return (AR09)
					}

					Return (PR09)
				}
				
				Device (GIGE)
				{
					Name (_ADR, Zero)
					OperationRegion (GPIO, SystemIO, 0x0800, 0x06)
					Field (GPIO, ByteAcc, NoLock, Preserve)
					{
						GO01,   8, 
						GO02,   8, 
						GO03,   8, 
						GO04,   8, 
						GO05,   8, 
						GP9,	1
					}

					Name (_PRW, Package (0x02)
					{
						0x09, 
						0x03
					})
					Method (EWOL, 1, NotSerialized)
					{
						If (LEqual (Arg0, One))
						{
							Or (GP9, One, GP9)
						}
						Else
						{
							And (GP9, Zero, GP9)
						}

						If (LEqual (Arg0, GP9))
						{
							Return (Zero)
						}
						Else
						{
							Return (One)
						}
					}
				}
				
			}

The original patch in the thread needs addresses like AR09, GP09 and GP9 that do not exists neither in OSX dsdt nor in Windows dsdt.

And why the dsdts are different? Because I have the recent BIOS update? Maybe there is something useful in the Windows DSDT.

[Funky frank]

This seems to be very interesting stuff:
ACPI Call - tool to call ACPI commands from terminal - Also there is the following comment:

Quote

# turn off discrete graphics card
echo '\_SB.PCI0.PEG1.GFX0.DOFF' > /proc/acpi/call
# turn it back on
echo '\_SB.PCI0.PEG1.GFX0.DON' > /proc/acpi/call

More info about Nvidia GPU poweroff/on
The related DSDT

If you look at the VAIO dsdt, there seem to be 2 gfx devices/cards/whatever, PCI0.PEGP and PCI0.PEG3. The variable PNHM controls whether PEG3 (== 0x000106E0 || 0x000106A0) or PEGP is addressed on many splaces in the DSDT. So maybe it a hybrid architecture inside?

[goila]

Funky frank, on Nov 16 2010, 07:25 PM, said:

No AppleLPC is not loaded. In the dsdt the is a LPCB device on PCI0. In IORegistry there is a LPCB with name "8086,3b03" and compatible "pci104d,9067".

Edit: Added "8086,3b03" to AppleLPC.kext and now it's loaded. But the cpu is still very hot and the cooler runs all the time. How to enable proper power management now?

Edit: Ok, with 1. adding devid to AppleLPC.kext, 2. the option ForeceHPET=Yes, 3. GeneratePStates=yes and 4. GenerateCStates=Yes the cpu is not so hot anymore, but still runs hotter than under win7.

Edit: Hm, sleepmode does not work anymore....

Windows running at 930 MHz

[OoTLink]

The Vaio F uses the PM55 chipset, there is no hybrid GPU option in there.

[kizwan]

Funky frank, on Nov 17 2010, 05:42 AM, said:

kizwan: Do you know what device is the ethernet device in the dsdt? Did you remove it in your DSDT?
Vendor 11ab Devid 4380, Yukon 88e8057, should be loaded by Yukon2.kext if editing pcimatch...

edit: I tried to patch the network device in dsdt like explained here. The strange thing is, in the VaioDST generated in OSX, there is only a P0PF device, in the Vaio DSDT generated in Windows (posted in this thread at beginning and dsdt_VAIO-windows.dsl.ziphere), there is only a P0P9 device. Also strange is Ethernet device is not listed in IOReg at all.

So I tried to patch the device like this:

			Device (P0PF)
			 {
				 Name (_ADR, 0x001E0000)
				 Method (_PRW, 0, NotSerialized)
				 {
					 Return (GPRW (0x0B, 0x04))
				 }
			 }

The original patch in the thread needs addresses like AR09, GP09 and GP9 that do not exists neither in OSX dsdt nor in Windows dsdt.

And why the dsdts are different? Because I have the recent BIOS update? Maybe there is something useful in the Windows DSDT.

You need to adjust the patch according to your DSDT. Patch Device (P0PF) instead of adding new device method.

About the different DSDT, I don't know about it. It should be the same. What application you use to extract DSDT in Windows? And what application you use to extract DSDT in OSX? Please use DSDT Editor to extract DSDT in Windows & OSX. Download & use DSDTEditor_Linux_Mac_Win.zip. You can use it in Windows & OSX because it is Java based application. Compare both DSDT.

Funky frank, on Nov 17 2010, 08:15 AM, said:

This seems to be very interesting stuff:
ACPI Call - tool to call ACPI commands from terminal - Also there is the following comment:

More info about Nvidia GPU poweroff/on
The related DSDT

If you look at the VAIO dsdt, there seem to be 2 gfx devices/cards/whatever, PCI0.PEGP and PCI0.PEG3. The variable PNHM controls whether PEG3 (== 0x000106E0 || 0x000106A0) or PEGP is addressed on many splaces in the DSDT. So maybe it a hybrid architecture inside?

That is to enable & disable the Nvidia GPU, not display or internal LCD. You should already know whether your notebook have hybrid graphics or not. Usually DSDT was wrote for a broad range of notebook specification. It doesn't mean it have hybrid GPU (to be precise Nvidia Optimus technology) just because there is an entry in DSDT.

[teppi210]

I have problem graphic card for vaio F12.

My graphic card Geforce GT 310 with 512MB

THanks

Mammoth, on May 28 2010, 09:28 PM, said:

Hmmm. I have been wondering about NVDANV50Hal.kext because the new MacBook Pro Update 1.3 is supposed to have all the updated files needed to natively support the GT 330M. I'm puzzled because I thought that once I installed 1.3 update, my GPU would just work, but was surprised when that did not happen. If you are saying there are no references to the GT 330M in NVDANV50Hal, then why is OS X insisting on loading it when there SHOULD be appropriate drivers available now from the 1.3 update? Where do you think the disconnect is? Isn't my assumption correct that the correct drivers should be able to be found and used now?

I am going to try changing the ID's and such and let you know the results,

again, I TRULY thank you for your help and appreciate all that you are doing for me. I am killing myself working on this thing solid now for the past two weeks. It is you that provide me hope that we may be able to get this to work.

THANK YOU VERY MUCH KIZWAN!!!!

[Funky frank]

kizwan, on Nov 17 2010, 10:05 AM, said:

You need to adjust the patch according to your DSDT. Patch Device (P0PF) instead of adding new device method.

About the different DSDT, I don't know about it. It should be the same. What application you use to extract DSDT in Windows? And what application you use to extract DSDT in OSX? Please use DSDT Editor to extract DSDT in Windows & OSX. Download & use DSDTEditor_Linux_Mac_Win.zip. You can use it in Windows & OSX because it is Java based application. Compare both DSDT.

Kizwan, sorry for this, I took the Windows DSDT from this post here, and thought it was for the F11 but it's not  

kizwan said:

That is to enable & disable the Nvidia GPU, not display or internal LCD. You should already know whether your notebook have hybrid graphics or not. Usually DSDT was wrote for a broad range of notebook specification. It doesn't mean it have hybrid GPU (to be precise Nvidia Optimus technology) just because there is an entry in DSDT.

Ok I already got this too I was just wondering if this obsolete code could cause an activation problem of the internal lcd since Snow Leopard runs on a lot of mac with dual graphics, so if the DSDT has code for it in it maybe SL thinks to active the second, stronger device... But I understand the nvidia graphics is already activated, it just does not recognize the internal display.

Btw. I looked into the SL 10.6.5 update into yukon2.kext, there is still no change or new support for new Marvel network devices.

Edit: Here seems to be Linux open source drivers for Marvell Yukon 88e8057: driver page marvell

Edit: Jesus Christ, Bluetooth suddenly works and I don't have any clue why... Lol

Edit: {censored}, really don't know why doesn't work anymore. I remove AppleLPC, used pre-SMBUS-patched AML and reinstalled NullCPUManagement.kext - Sleepmode still does not work. But i worked!

Edit: Webcam not works too

Edit: FOr Atheros AR9287 (wifi card) there is this Linux source and info available: linux source atheros ar9287

[OoTLink]

Bluetooth should work all along, it's supported by default, so is DVD burning and USB

[Funky frank]

OoTLink, on Nov 19 2010, 07:20 AM, said:

Bluetooth should work all along, it's supported by default, so is DVD burning and USB

Was not here.

[Funky frank]

				<string>pci168c,2a</string>
				<string>pci106b,0086</string>
				<string>pci168c,1c</string>
				<string>pci168c,23</string>
				<string>pci168c,24</string>

The AirPortAtheros21.kext of OSX 10.6.5 has new PCI matches inside. Maybe it will work now with our Atheros "pci168c,2e"? f11 atheros linux AR9285 fix Maybe interesting

kizwan, Ootlink: Do you know where to find the wlan device in the f11 dsdt? Maybe patching it in this way, and using 10.6.5 IO80211Family.kext would work... IO80211Family.kext 10.6.5 patched for 2b and 2e

Oh I am sorry it seems some F11s have these Atheros devices built-in, but my actually has a Intel 6200AGN card inside, so there seems to be absoluty no support for it. This project looks most promising for me. But it just compiles for OSX 10.5.

[OoTLink]

lol, little backstory for ya really fast:

I don't have OS X on my Vaio at the moment; during the summer I blew at least a half dozen weekends trying to get OS X to behave, several re-installs, and then a hell of a lot of single user mode. With the hardest semester yet of classes in progress, I haven't exactly been enthusiastic about settting aside some hard drive space for a project that has yet to show any progress at all since the last time I touched it.

Please don't take that as a bad thing, it's a really hard process because there's next to zero documentation and everyone else that has tried this (midtown and extraspeed included), messed around with a Vaio for a few days, got fed up, and dumped it on ebay.

I really appreciate your work, especially that of Kizwan who has been trying since the beginning of this project as hard as he can to help us out (without even having a reason to! After all, he doesn't have a Vaio F).


IMHO the biggest, monumental problem is there's nothing like ioreg for Windows to peer into the situation and figure out why it works in Windows but not in OS X. We hardly know how these laptops are wired, other than that it uses an LVDS signal. Nobody knows how or why the backlight turns on, or why OS X detects the video card but never actually seems to detect the monitor.

See that's a problem - Kizwan I remember distinctly that when i had the video card recognized (with the proper NVDA50HAL.kext and NVDAResman.kext), that the ioreg report listed the video card, but no devices at all plugged into it (and that means the LCD wasn't even detected).

That we're going at this with DSDTs is actually a very good idea, I'm curious what bootloader you're using and how though, because when I last used Chameleon the build I had didn't seem to work with DSDTs at all.

Anyway, as a last interesting tidbit - Ubuntu's Nouveau driver recognizes the LCD, albeit at a really strange resolution (2048x1440?). I want to know why nouveau recognizes our LCDs! lol.

When I've gotten that far, I'll put OS X on my Vaio again and it'll be a matter of time before we have 1920x1080 support.