Jump to content

Dell XPS 1340 under OSX 10.6, including boot-132 install cd

bcc9

By bcc9,
in Installation Guides

 Share
1,149 posts in this topic

Recommended Posts

olegpronin
olegpronin
Posted
Posted
Can you explain? I haven't noticed any startup time differences between using VoodooBattery vs not using anything.

I'm not attached to Voodoobattery, can you point me to the source code for appleacpibattery & the current release, so that I can compare? I couldn't find the source last I checked.

It would be nice if there was a fully working replacement for voodoobattery as I don't like depending upon abandon-ware.

I have no explanation.. When I used AppleACPIBattery, it started very quickly. When VooodooBattery - before launching the interface it freezes a little (no hdd led), after 4-5 seconds it starts and works normal.

 

I decided to delete AC Adapter inject from VooodooBattery and added it to DSDT using Method _PRW. I don't know if it's better or not, start up still the same.

Sources of latest AppleACPIBattery was attached.

 

Thanks, figuring out that the battery status update methods needed to be rewritten to do 8 bit I/O to avoid the "Method parse/execution failed" errors was a key part...

yes, I figured it out in your DSDT. Very good research!

 

hdmi audio won't actually work however, as av-signal-type is failing to be set to 0x8 as required. If someone could figure this final piece out they'd be my hero smile.gif

Can't help with HDMI since I have no device with HDMI at all here ;)

 

Hmm, I hadn't noticed volume problems with AppleHDA. Sure enough, looks a little buggy. I always just adjust the volume using the dell hotkeys on this laptop which works OK.

Did you try to do the same thing like in the video?

One more thing - when laptop is just turned up, I don't know why, but at first start of changing volumes, it jumps always to maximum position.

 

UPDATE. Incredible! I searched a little in internet and found AppleACPIBattery kext for lion. yes, I know it doesn't show the information in profile, but the startup is more quickly.

 

Attached kext.

 

UPDATE2. I think it was my bad about AppleACPIBattery - I believe the previous kext was compiled in the old SDK. That's why it had KP.

 

UPDATE3. bcc9, but if you can look on the sources and check out why error when collecting system information about battery and fix it, will be superb!

AppleACPIBatteryManager.source.zip

1498_AppleACPIBatteryManager.kext.zip

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Did you try to do the same thing like in the video?
Yes, I can see that the menu bar volume slider doesn't match the one in system preferences->audio. But I said I don't use the menu bar slider, I use the dell volume hotkeys. Those hotkeys (and the OSD for the volume) DO track the system preferences->audio slider properly.

 

So your problem seems to be rather cosmetic, or at least there is a good workaround, and I wouldn't ditch AppleHDA just for that.

VoodooHDA is a problem since slice stated long ago that he has stopped supporting it (and there have been no updates since). When possible, I'd rather use a kext that is supported by apple than one that was hacked from freebsd and isn't support by anyone.

Link to comment
Share on other sites
olegpronin
olegpronin
Posted
Posted

This is not a cosmetic. I don't want to discuss much about it, we use what we want to use ;) just one thing - slice still uses voodoohda and doesn't plan to move back.

 

I use sometimes different audio software and this glitch kills me, because yes I use the Sensor keyboard and programs use system pref changing volume. Each time after I used volume in pref, first time pressing on sensor board gives me maximum volume and doesn't matter that volume was before.

Link to comment
Share on other sites
Cyrus the Great
Cyrus the Great
Posted
Posted
Here is a patched DSDT for lion.

This version fixes the UPBI and UPBS methods for dynamic battery status.

(VoodooBattery now works with this DSDT). There should no longer be any temptation to use a rolled-back version of AppleACPIPlatform.

hi bbc9 thanks for your genuine discovery

my laptop is hp dv6-1125 and i am try to replace my bat0 section with one from your dsdt but not work for me .i can not understand with section of my bat0 must be changed plz can look in my dsdt.

thanks for your help.

DSDT.aml.zip

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
hi bbc9 thanks for your genuine discovery

my laptop is hp dv6-1125 and i am try to replace my bat0 section with one from your dsdt but not work for me .i can not understand with section of my bat0 must be changed plz can look in my dsdt.

thanks for your help.

In your DSDT, look at for example, in the UPBI method, the Store operations. In these operations:

Store (^^PCI0.LPC.EC0.BTDC, Index (PBIF, One))

Store (^^PCI0.LPC.EC0.BATV, Index (PBIF, 0x04))

you're referencing the field definitions:

BTDC, 16,

BATV, 16,

which are 16 bit. Per the ACPI spec, the EmbeddedControl region must use byte access. So you rewrite those fields as pairs of 8 bit fields and do the access byte at a time. Take a look at the differences in my dsdt for the BTDC, BTFC, BTCT, BTRC, BTPV fields for examples on how to do this. I don't have time to do these edits for other platforms myself.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
thanks for your help.

i am do it but it seems the solutions not work with hp.

Since it's clear from your DSDT that your system is attempting 16bit I/O for the battery status, it seems like you have exactly the same problem.
Link to comment
Share on other sites
juanerson
juanerson
Posted
Posted
In your DSDT, look at for example, in the UPBI method, the Store operations. In these operations:

Store (^^PCI0.LPC.EC0.BTDC, Index (PBIF, One))

Store (^^PCI0.LPC.EC0.BATV, Index (PBIF, 0x04))

you're referencing the field definitions:

BTDC, 16,

BATV, 16,

which are 16 bit. Per the ACPI spec, the EmbeddedControl region must use byte access. So you rewrite those fields as pairs of 8 bit fields and do the access byte at a time. Take a look at the differences in my dsdt for the BTDC, BTFC, BTCT, BTRC, BTPV fields for examples on how to do this. I don't have time to do these edits for other platforms myself.

THANK YOU SO MUCH... it worked perfect in my dsdt, now I have battery support in Lion & Snow, so this is certainly "the real fix" as you said my friend. Also I want to say, THANK YOU AGAIN for all your contributions, Legend. God bless you.

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
THANK YOU SO MUCH... it worked perfect in my dsdt, now I have battery support in Lion & Snow, so this is certainly "the real fix" as you said my friend. Also I want to say, THANK YOU AGAIN for all your contributions, Legend. God bless you.
Awesome. It's good to hear back on some success (when all one hears about is failures it makes you wonder if you're missing something).
Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
In your DSDT, look at for example, in the UPBI method, the Store operations. In these operations:

Store (^^PCI0.LPC.EC0.BTDC, Index (PBIF, One))

Store (^^PCI0.LPC.EC0.BATV, Index (PBIF, 0x04))

you're referencing the field definitions:

BTDC, 16,

BATV, 16,

which are 16 bit. Per the ACPI spec, the EmbeddedControl region must use byte access. So you rewrite those fields as pairs of 8 bit fields and do the access byte at a time. Take a look at the differences in my dsdt for the BTDC, BTFC, BTCT, BTRC, BTPV fields for examples on how to do this. I don't have time to do these edits for other platforms myself.

When I look at the methods used under Device (BAT0), I can see the followings:

 

In the UPBI method:

 

Store (^^PCI0.LPC.EC0.BCLB, Local0)
Store (^^PCI0.LPC.EC0.BCHB, Local1)
***
Store (^^PCI0.LPC.EC0.BVLB, Local0)
Store (^^PCI0.LPC.EC0.BVHB, Local1)

 

When I check BCLB, BCHB, BVLB and BVHB in Device (EC0), they already have 8 as the value:

 

BCLB,   8, 
	 BCHB,   8, 
				  Offset (0x74), 
	 BVLB,   8, 
	 BVHB,   8, 
				 Offset (0x7E),

 

This is the UPBS method:

 

Method (UPBS, 0, NotSerialized)
		{
			Store (^^PCI0.LPC.EC0.MBST, Index (PBST, Zero))
			^^PCI0.LPC.EC0.SMRD (0x09, 0x16, 0x0A, RefOf (Local0))
			Store (Local0, Index (PBST, One))
			^^PCI0.LPC.EC0.SMRD (0x09, 0x16, 0x0F, RefOf (Local1))
			Store (Local1, Index (PBST, 0x02))
			^^PCI0.LPC.EC0.SMRD (0x09, 0x16, 0x09, RefOf (Local2))
			Store (Local2, Index (PBST, 0x03))
		}

Am I doing something wrong? May be my problem is related to something else?

 

Thanks,

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Am I doing something wrong? May be my problem is related to something else?
There's no way for anyone to tell for sure from those limited fragments.... Make sure none of the fields accessed from the embedded controller are > 8 bits, not just under the UPBI method.
Link to comment
Share on other sites
Cyrus the Great
Cyrus the Great
Posted
Posted

hi bcc9

i find that this value refer to 16 bit also but how can i split it to 8 bit:MBRM

				Store (^^PCI0.LPC.EC0.MBRM, Local5)
			If (LNot (And (Local5, 0x8000)))
			{

and also when changing MBRM this is refer to it how can i fix it:

							If (LLessEqual (^^PCI0.LPC.EC0.MBRM, 0x96))
						{
							Store (Zero, Local0)
						}

thanks for your help

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
bcc9, clean your inbox.

I have a bit. But too many people are PMing me for personal support. I don't have time to keep up and my profile already asks folks to not PM me for tech support. Most messages I'm getting are not personal and could just as well go to the public threads.

Link to comment
Share on other sites
olegpronin
olegpronin
Posted
Posted
I have a bit. But too many people are PMing me for personal support. I don't have time to keep up and my profile already asks folks to not PM me for tech support. Most messages I'm getting are not personal and could just as well go to the public threads.

 

Ok, then I will answer here better since I'm not about personal support :(

 

I tried to compare SVN builds for checking out problem of facetime. 755 and 760 - looks like there I can't find a problem that stops facetime working..

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted
Ok, then I will answer here better since I'm not about personal support ;)

 

I tried to compare SVN builds for checking out problem of facetime. 755 and 760 - looks like there I can't find a problem that stops facetime working..

If facetime is working in 755 and not in 760, you could further narrow it down to the exact change that made the difference. Since r756,757 are in branches, it's a matter of figuring out whether it is the 758, 759 or 760 patch that caused facetime to no longer work.

Once you figure out which patch made the difference, we can take a look at the details of the patch.

I suspect the difference is with the system's UUID generation code.

I tried changing the ethernet device name in the DSDT to match genuine mac dsdt (s/MAC0/GIGE/), but that made no difference.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...