Jump to content

Studio XPS 13


digital8
 Share

222 posts in this topic

Recommended Posts

Can you share your com.apple.Boot.plist file? I used x86tools to add the Nvidia config and it resulted in a non booting computer. I had to comment out the efi string via terminal in the install disk to get to boot again, what I did was:

 

1. use x86tools to add a custom Nvidia Gforce card (named nVidia GeForce 9400M GS) efi string to my boot.plist

2. use kExthelper to install IOPCIFamily.kext

 

did I miss something?

 

thanks,

 

Ann

Link to comment
Share on other sites

Tests kexts for IDT audio on studio XPS 13, it is based on Age-Sabre18's

 

If it is loaded without the error message and still no sound try to add the PinConfig in ConfigData

:D

 

IDT_audio_Studio_XPS_13.zip

Ah yes, the older 10.5.3 version of AppleHDA patched for this codec. I tried the exact same thing yesterday :hysterical: It doesn't print out the assertion error like the 10.5.5 version, but the results are the same - no audio input/output device or sound. I did try it both with&without my hand coded ConfigData; no difference. Will try modifying the PinConfigurations in HDAEnabler.kext as well, if that's what you mean.

Currently the pinconfiguration I see when I look at the ioregistry appears wrong to me. Also the acpi-path for the audio controller shows AZA in it not HDEF, but I guess that's normal with HDAEnabler?

		  +-o HDEF@8  <class IOPCIDevice, registered, matched, active, busy 0, r
etain 8>
		   {
			 "IOPCIResourced" = Yes
			 "IOInterruptControllers" = ("io-apic-0")
			 "IOName" = "pci10de,ac0"
			 "subsystem-id" = <71020000>
			 "IODeviceMemory" = (({"address"=0xfffffffff0880000,"length"=0x40
00}))
			 "layout-id" = <0c000000>
			 "class-code" = <00030400>
			 "IOPowerManagement" = {"ChildrenPowerState"=0x2,"CurrentPowerSta
te"=0x2}
			 "revision-id" = <b1000000>
			 "IOInterruptSpecifiers" = (<1100000007000000>)
			 "assigned-addresses" = <1040008200000000000088f00000000000400000
>
			 "built-in" = <00>
			 "acpi-device" = "IOACPIPlatformDevice is not serializable"
			 "device-id" = <c00a0000>
			 "vendor-id" = <de100000>
			 "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/AZA@80000"
			 "subsystem-vendor-id" = <28100000>
			 "name" = "pci10de,ac0"
			 "reg" = <0040000000000000000000000000000000000000104000020000000
0000000000000000000400000>
			 "compatible" = <706369313032382c32373100706369313064652c61633000
706369636c6173732c30343033303000>
			 "Credits" = "2008 (c) Kabyl/Taruga"
			 "PinConfigurations" = <f01111412009a399100113991f402101f01111413
098a101f0111141f0111141f01111412d820540f0111141>
		   }

 

Update: Even when I change the pinconfigurations entry in HDAEnabler, the entry in the ioregistry still says f01111412009a399100113991f402101f01111413098a101f0111141f0111141f01111412d820540

0111141

I've tried both:

				<key>PinConfigurations</key>
			<data>
			HxAhAw8AAE/wAABPEAEXkCAQoQMfECED8AAAT/AAAE/w
			AABPYAGmkPAAAE/wAABPDwAATw8AAE8=
			</data>

and

				<key>PinConfigurations</key>
			<data>
			HxAhAw8AAE/wAABPEAEXkCAQoQMfECED8AAAT/AAAE/w
			AABPYAGmkPAAAE/wAABP8AAATw8AAE8=
			</data>

Under HDAEnabler's HDAProperties without any apparent affect. Why isn't this reflected in the ioregistry, am I coding pinconfigurations wrong?

 

I've tried it two different ways because the linux codec dump for the IDT codec gives me different results under 2.6.27 vs 2.6.29 (differs in what is reported for node 0x23). Here is the diff I'm talking about from 2.6.27 to 2.6.29:

 Node 0x23 [Pin Complex] wcaps 0x400301: Stereo Digital
  Pincap 0x00000010: OUT
-  Pin Default 0x4f00000f: [N/A] Line Out at Ext UNKNOWN
+  Pin Default 0x4f0000f0: [N/A] Line Out at Ext UNKNOWN
 Conn = Unknown, Color = Unknown
-	DefAssociation = 0x0, Sequence = 0xf
+	DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Connection: 3
  0x26* 0x20 0x21

Link to comment
Share on other sites

About PinConfig, I was talking about ConfigData String in HDAControler, according to this post :

http://www.insanelymac.com/forum/index.php...st&p=970844

Ok, just the ConfigData string. I had tried that. I've been using:

00a71c10 00a71d10 00a71e21 00a71f03
00b71c00 00b71d00 00b71e00 00b71f4f
00c71cf0 00c71d00 00c71e00 00c71f4f
00d71c10 00d71d01 00d71e17 00d71f90
00e71c20 00e71d10 00e71ea1 00e71f03
00f71c10 00f71d10 00f71e21 00f71f03
01071cf0 01071d00 01071e00 01071f4f
01171cf0 01171d00 01171e00 01171f4f
01271cf0 01271d00 01271e00 01271f4f
01371c60 01371d01 01371ea6 01371f90
01471cf0 01471d00 01471e00 01471f4f
02271cf0 02271d00 02271e00 02271f4f
02371cf0 02371d00 02371e00 02371f4f
02471c00 02471d00 02471e00 02471f4f

 

Can you share your com.apple.Boot.plist file? I used x86tools to add the Nvidia config and it resulted in a non booting computer. I had to comment out the efi string via terminal in the install disk to get to boot again, what I did was:

 

1. use x86tools to add a custom Nvidia Gforce card (named nVidia GeForce 9400M GS) efi string to my boot.plist

2. use kExthelper to install IOPCIFamily.kext

 

did I miss something?

Sounds right. My boot.plist currently looks like the attached.

com.apple.Boot.plist.txt

Link to comment
Share on other sites

I finally got audio to work on my xps 13 with the 10.5.3 version of AppleHDA!

I had to do two extra things besides populating ConfigData in AppleHDAController's Info.plist.

1) Add PathMaps config changes into the 10.5.3 version of AppleHDA.kext/Contents/Info.plist for the IDT nodes

2) Fix the byte order for the pinconfiguration data in HDAEnabler

(The PinConfigurations plist entry I posted above is in the wrong byte order.)

 

Background for #2:

On my second look at the HDA spec http://download.intel.com/standards/hdaudi.../HDAudio_03.pdf I found the section that shows the pinconfig (p. 149) and realized that I should be configuring PinConfigurations in HDAEnabler *without* byteswapping the values from the linux output.

 

I don't understand why all this isn't necessary for other systems with IDT audio; will keep playing to figure out if there's an easier config than what I'm using.

Link to comment
Share on other sites

Im getting a Studio 13 XPS shortly..well i just bought it but it seems it will take some time to arrive. But would be cool if you post like a package with all the kexts/installers working atm.

 

^^Just my opinion =P

Link to comment
Share on other sites

Im getting a Studio 13 XPS shortly..well i just bought it but it seems it will take some time to arrive. But would be cool if you post like a package with all the kexts/installers working atm.
Yes it'd be nice to have an installer package like what ridgeline did once things are straightened out. At this point, I'm not sure what the right config is that'll work for everyone. I've only seen 1 other person report back that my QE/CI fix worked for them, for example, and a couple doesn't work posts (with no troubleshooting information of course).

 

The audio seems a bit flakey, I swear I had to setup HDAEnabler without any AppleHDA and then manually add a working AppleHDA kext before the AppleHDA kext changes would take. This is even though I religiously rm -rf /System/Library/{Caches,Extensions.mkext} with each change.

 

So here's the modified AppleHDA.kext that currently works for me. The HDAEnabler kext is included as well, though it's just the standard version everyone passes around. HDAEnabler has a PinConfiguration defined in it which doesn't match this codec (the one that starts with f0111141). This gets dynamically replaced with the correct PinConfiguration when AppleHDA.kext loads correctly. So if you see the old f0111141... value in your ioregistry as shown in my previous post, you know the AppleHDA kext is not loading correctly.

 

With this, speaker output works, volume/mute hotkeys work, and the headphone jacks work but do not mute the speaker. The mics do not work; I don't know why.

 

Thanks to boombeng for steering me back to the old 10.5.3 version of AppleHDA.kext

xps1340_audio.zip

Link to comment
Share on other sites

I swear I had to setup HDAEnabler without any AppleHDA and then manually add a working AppleHDA kext before the AppleHDA kext changes would take. This is even though I religiously rm -rf /System/Library/{Caches,Extensions.mkext} with each change.
I figured out what I was doing wrong. The above rm commands aren't sufficient when you're just modifying an Info.plist. If you modify an Info.plist you have to touch /System/Library/Extensions to get the cache rebuilt. When I manually added AppleHDA.kext, that would update the modification time on /System/Library/Extensions for me, so it'd trigger the cache rebuild.

 

Damn I had things configured right two days ago and didn't know it because of my flawed procedure.

Link to comment
Share on other sites

bcc9

i h've tried your xps1340_audio.zip but no sound here. I got a error message that i must reinstall HDAEnabler.

Then you didn't install it right with root:wheel ownership and 755 protection. A manual kextload should tell you as much.
Link to comment
Share on other sites

Good to see you have sound now :)
Yes, thank you. I still don't understand why the ConfigData entries are required on the xps1340 but apparently you guys aren't entering it for the other IDT based dell laptops.

Also it'd be nice to get the 10.5 version working; I assume the "0 == fInterruptSource" error is key here. You don't get that in your /var/log/system.log when using the 10.5 version do you?

I do notice that under 10.5, HDAEnabler tries to load 3 times in a row. I'm wondering if maybe it's loading repeatedly due to the multiple codecs. If so, perhaps it's stomping on the working PinConfigurations when attempting to probe the codec for the HDMI audio. Wish I had the source code to hdaenabler to troubleshoot this. May try to roll my own...

Link to comment
Share on other sites

No we don't have this error
Do you have the final+best version of the pathmaps&layouts for 10.5.3 that has working headphone plugin detection? I tried adding the changes you described to Layouts for this but it didn't work for me. It seems like ridgeline's attachment with the latest 10.5.3 version was deleted once you guys switched to 10.5.5.

 

Another thought about 10.5.5 audio - Anybody have EFI audio strings working with HDEF audio? I see that EFIStudio has an option for it, but the resulting EFI strings seem to only populate the AZA node in the ioregistry, failing to rename the node to HDEF. I think EFI audio strings may stand a better chance of working than HDAEnabler when there are two codecs involved.

Link to comment
Share on other sites

Do you have the final+best version of the pathmaps&layouts for 10.5.3 that has working headphone plugin detection? I tried adding the changes you described to Layouts for this but it didn't work for me. It seems like ridgeline's attachment with the latest 10.5.3 version was deleted once you guys switched to 10.5.5.

Here is the one I edited for Headphone detection

Another thought about 10.5.5 audio - Anybody have EFI audio strings working with HDEF audio? I see that EFIStudio has an option for it, but the resulting EFI strings seem to only populate the AZA node in the ioregistry, failing to rename the node to HDEF. I think EFI audio strings may stand a better chance of working than HDAEnabler when there are two codecs involved.

 

I really don't know...

Link to comment
Share on other sites

Here is the one I edited for Headphone detection
That's the 10.5.5 version. I did already backport that to the 10.5.3 version but the result has been no working mics or headphone mute detection.

 

I really don't know...
Fair enough. I know, ask in the madtux thread. But I've only found questions not answers on this topic over there.
Link to comment
Share on other sites

Hi all, 

 

I have a Studio XPS and I have installed fedora 10 on it, and kept space for Hackintosh :) 

 

I initially had this same problem with speakers not muting when headphones are plugged in and the mic too wasnt working. So I installed the latest CVS/GIT version of alsa-driver and the sound card works perfect with the internal mic and headphone detection to mute speakers. 

 

So I am attaching the codec dump using the latest working working drivers from linux. Hope it helps. 

codec0.txt

Link to comment
Share on other sites

So I am attaching the codec dump using the latest working working drivers from linux. Hope it helps.
Hmm, it's interesting that that yours has a different pin default for node 0x0b than the codec#0 dump I previously posted from Fedora 10 with 2.6.29.

Yours:

- Pin Default 0x90a70170: [Fixed] Mic at Int N/A

mine:

+ Pin Default 0x4f00000f: [N/A] Line Out at Ext UNKNOWN

 

I'll try your value and see if it makes a difference.

 

Hey wait, I know you from the xps 13 threads over at notebookreview. :)

Link to comment
Share on other sites

Yes the values are different as the new driver knows the hardware better afaik! Also the way I see it, all this depends on version of alsa-driver you use, and not the kernel. The stock fedora kernel has older alsa-driver 1.0.17.

while I have compiled 1.0.19+

 

 

And oh yes.. I am on the other forum too :)

Link to comment
Share on other sites

Yes the values are different as the new driver knows the hardware better afaik! Also the way I see it, all this depends on version of alsa-driver you use, and not the kernel. The stock fedora kernel has older alsa-driver 1.0.17.

while I have compiled 1.0.19+

The alsa driver is an lkm which is part of the kernel package and I was running the latest possible pre-compiled version, 2.6.29.rc8, but that only got me alsa 1.0.18a. Didn't think there were newer alsa changes since then. Hmm, it does look like the mic is not working for me under fedora.

Time to try your pinconfig.

Link to comment
Share on other sites

Anybody have EFI audio strings working with HDEF audio? I see that EFIStudio has an option for it, but the resulting EFI strings seem to only populate the AZA node in the ioregistry, failing to rename the node to HDEF. I think EFI audio strings may stand a better chance of working than HDAEnabler when there are two codecs involved.
Ok, I have been able to get audio to work using an EFI string instead of HDAEnabler. Apparently it's OK for the device tree entry to be named AZA under 10.5.3 AppleHDA. Under 10.5.5, AppleHDAController no longer produces an "0 == fInterruptSource" failed error but it still doesn't seem to work. It looks like the 10.5.5 version matches on HDEF specifically.
Link to comment
Share on other sites

I tried the latest alsa git, the daily snapshot, and the 1.0.19 build and none of them gave me this new pinconfig entry or a working mike under linux. In fact, they worked worse than the fedora build as these newer versions don't mute the speakers when the left headphone jack is used, and the system bell is now an obnoxiously loud beep (like a smoke alarm test). I wonder what's different about your setup.

 

The 0x0b node is not in the pathmap used for the existing mike config so I'd really like to see it work before trying to build a new pathmap for it.

Link to comment
Share on other sites

I have a question.......Still dont recieved my laptop like 15 more days QQ anyway....about the graphic cards..how does the dual graphic (when you choose 9500m) work?....Do you just install kexts for the 9200GS....or..how does hybrid sli works?

 

thanks!

Link to comment
Share on other sites

 Share

×
×
  • Create New...