Jump to content

DFI LP X38 - Vanilla ALC885 sound support

lucaferr

By lucaferr,
in Archive

 Share
23 posts in this topic

Recommended Posts

lucaferr
lucaferr
Posted
Posted

Courtesy of BuildSmart we can now enjoy vanilla audio.

 

Here is the DSDT code that makes it all happen:

			Device (HDEF)
		 {
			 Name (_ADR, 0x001B0000)
			 Method (_PRW, 0, NotSerialized)
			 {
				 Return (Package (0x02)
				 {
					 0x0D, 
					 0x05
				 })
			 }

			 Method (_DSM, 4, NotSerialized)
			 {
				 Store (Package (0x0C)
					 {
						 "built-in", 
						 Buffer (One)
						 {
							 0x00
						 }, 

						 "codec-id", 
						 Buffer (0x04)
						 {
							 0x85, 0x08, 0xEC, 0x10
						 }, 

						 "ConfigData", 
						 Buffer (0xA0)
						 {
							 /* 0000 */	0x01, 0x47, 0x1c, 0x10, 0x01, 0x47, 0x1d, 0x40,
							 /* 0008 */	0x01, 0x47, 0x1e, 0x01, 0x01, 0x47, 0x1f, 0x01,
							 /* 0010 */	0x01, 0x57, 0x1c, 0x12, 0x01, 0x57, 0x1d, 0x10,
							 /* 0018 */	0x01, 0x57, 0x1e, 0x01, 0x01, 0x57, 0x1f, 0x01,
							 /* 0020 */	0x01, 0x67, 0x1c, 0x11, 0x01, 0x67, 0x1d, 0x60,
							 /* 0028 */	0x01, 0x67, 0x1e, 0x01, 0x01, 0x67, 0x1f, 0x01,
							 /* 0030 */	0x01, 0x77, 0x1c, 0x14, 0x01, 0x77, 0x1d, 0x20,
							 /* 0038 */	0x01, 0x77, 0x1e, 0x01, 0x01, 0x77, 0x1f, 0x01,
							 /* 0040 */	0x01, 0x87, 0x1c, 0x40, 0x01, 0x87, 0x1d, 0x98,
							 /* 0048 */	0x01, 0x87, 0x1e, 0xa1, 0x01, 0x87, 0x1f, 0x01,
							 /* 0050 */	0x01, 0x97, 0x1c, 0x50, 0x01, 0x97, 0x1d, 0x9c,
							 /* 0058 */	0x01, 0x97, 0x1e, 0xa1, 0x01, 0x97, 0x1f, 0x02,
							 /* 0060 */	0x01, 0xa7, 0x1c, 0x4f, 0x01, 0xa7, 0x1d, 0x30,
							 /* 0068 */	0x01, 0xa7, 0x1e, 0x81, 0x01, 0xa7, 0x1f, 0x01,
							 /* 0070 */	0x01, 0xb7, 0x1c, 0x20, 0x01, 0xb7, 0x1d, 0x4c,
							 /* 0078 */	0x01, 0xb7, 0x1e, 0x21, 0x01, 0xb7, 0x1f, 0x02,
							 /* 0080 */	0x01, 0xe7, 0x1c, 0x70, 0x01, 0xe7, 0x1d, 0x71,
							 /* 0088 */	0x01, 0xe7, 0x1e, 0x44, 0x01, 0xe7, 0x1f, 0x01,
							 /* 0090 */	0x01, 0xf7, 0x1c, 0x80, 0x01, 0xf7, 0x1d, 0x51,
							 /* 0098 */	0x01, 0xf7, 0x1e, 0xc4, 0x01, 0xf7, 0x1f, 0x01
						 }, 

						 "layout-id", 
						 Buffer (0x04)
						 {
							 0x3f, 0x00, 0x00, 0x00
						 }, 

						 "device-type", 
						 Buffer (0x10)
						 {
							 "Realtek ALC885"
						 }, 

						 "PinConfigurations", 
						 Buffer (One)
						 {
							 0x00
						 }
					 }, Local0)
				 DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				 Return (Local0)
			 }
		 }

 

In DSDT the section is named AZAL or HDEF depending on if and how it was patched.

 

Since I was given a DSDT that has been properly patched and has added features I am attaching both the source and compiled version to this post.

 

The code above will work for many similar DFI boards with ALC885 and a Bernstein module. However, the included DSDT and source file are specific to the DFI LanParty LT X38 - D2R.

DSDT.zip

Link to comment
Share on other sites
R3van
R3van
Posted
Posted

So this works for me (almost) :P with Stock AppleHDA and without any further kexts for sound, thank you very much.

 

Analog out works, can`t test if digital works to.

5.1 doesn`t work as it shows only two speaker.

Can`t test if mic is working.

System Profiler shows a little bit but not complete.

 

screen-capturejwtf.pngscreen-capture-1wsz5.pngscreen-capture-2htnl.pngscreen-capture-3oqbo.png

 

 

However, the most important things works for me so thanks again to BuildSmart and lucaferr.

Link to comment
Share on other sites
lucaferr
lucaferr
Posted
  • Author
Posted

I have the same limitations as you point out. However, I only use analog out, too.

 

Do you have S3 Sleep working at all?

 

lt's all BuildSmart's work! I merely passed it along.

Link to comment
Share on other sites
lucaferr
lucaferr
Posted
  • Author
Posted

Have a good look through your BIOS. I am not sure what it is called but if setup properly, you should see an extra screen in the BIOS/POST bootup. It's probably the case that calls are made to that controller in the wakeup code and if it is disabled, the system would freeze.

 

You do not need to enable any drivers for it in OS X or use it at all. It only needs to be enabled in BIOS.

 

 

Right, maybe the P45 is different enough then.

Link to comment
Share on other sites
stellarola
stellarola
Posted
Posted
System doesn`t wake up

 

A little bit off-topic but who cares :)

 

@lucaferr: Is that anywhere documented? I don`t find such a menu in my BIOS

 

 

It'll wake from sleep, you just don't have the correct bios settings.

Link to comment
Share on other sites
R3van
R3van
Posted
Posted

yes probably, but when it is so i don`t know which is the right one (S3 is on and wake from usb too)

 

Anyway, i don`t use sleep so this is interesting indeed but not essential for me.

 

More important to know would be how Buildsmart have found the right Pinconfigurations and if we can optimize the code to get full information in System Profiler and/or full functionality (as i said before i can`t test digital out, mic and surround so i don`t know if it works right now)

 

Hello

can you attach your ioreg output?

 

Who do you mean? And which section or do you mean the whole ioreg?

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted

Hi lucaferr,

 

Is this mean you can remove legacy kext (audio) completely? As far as I know it only replaced HDAEnabler.kext & still need legacy/patched AppleHDA.kext. I noticed that under "PinConfigurations", you did not put your pin configuration. That is the only different between our (HDEF) code.

 

kizwan

Link to comment
Share on other sites
R3van
R3van
Posted
Posted

So,

 

i have compared the Configdata from Buildsmart with my PinConfigOverrideVerbs from Windows and found some differences:

 

							"ConfigData", 
						Buffer (0xC0)
						{
							/* 0000 */	0x01, 0x47, 0x1c, 0x10, 0x01, 0x47, 0x1d, 0x40,
							/* 0008 */	0x01, 0x47, 0x1e, 0x01, 0x01, 0x47, 0x1f, 0x01,
							/* 0010 */	0x01, 0x57, 0x1c, 0x12, 0x01, 0x57, 0x1d, 0x10,
							/* 0018 */	0x01, 0x57, 0x1e, 0x01, 0x01, 0x57, 0x1f, 0x01,
							/* 0020 */	0x01, 0x67, 0x1c, 0x11, 0x01, 0x67, 0x1d, 0x60,
							/* 0028 */	0x01, 0x67, 0x1e, 0x01, 0x01, 0x67, 0x1f, 0x01,
							/* 0030 */	0x01, 0x77, 0x1c, 0x14, 0x01, 0x77, 0x1d, 0x20,
							/* 0038 */	0x01, 0x77, 0x1e, 0x01, 0x01, 0x77, 0x1f, 0x01,
							/* 0040 */	0x01, 0x87, 0x1c, 0x40, 0x01, 0x87, 0x1d, 0x98,
							/* 0048 */	0x01, 0x87, 0x1e, 0xa1, 0x01, 0x87, 0x1f, 0x01,
							/* 0050 */	0x01, 0x97, 0x1c, 0x50, 0x01, 0x97, 0x1d, 0x9c,
							/* 0058 */	0x01, 0x97, 0x1e, 0xa1, 0x01, 0x97, 0x1f, 0x02,
							/* 0060 */	0x01, 0xa7, 0x1c, 0x4f, 0x01, 0xa7, 0x1d, 0x30,
							/* 0068 */	0x01, 0xa7, 0x1e, 0x81, 0x01, 0xa7, 0x1f, 0x01,
							/* 0070 */	0x01, 0xb7, 0x1c, 0x20, 0x01, 0xb7, 0x1d, 0x4c,
							/* 0078 */	0x01, 0xb7, 0x1e, 0x21, 0x01, 0xb7, 0x1f, 0x02,
									  /* 0080 */	0x01, 0xc7, 0x1c, 0xf0, 0x01, 0xc7, 0x1d, 0x01,
									  /* 0088 */	0x01, 0xc7, 0x1e, 0x33, 0x01, 0xc7, 0x1f, 0x59,
									  /* 0090 */	0x01, 0xd7, 0x1c, 0x03, 0x01, 0xd7, 0x1d, 0xe6,
									  /* 0098 */	0x01, 0xd7, 0x1e, 0x06, 0x01, 0xd7, 0x1f, 0x40,
							/* 00A0 */	0x01, 0xe7, 0x1c, 0x70, 0x01, 0xe7, 0x1d, 0x71,
							/* 00A8 */	0x01, 0xe7, 0x1e, 0x44, 0x01, 0xe7, 0x1f, 0x01,
							/* 00B0 */	0x01, 0xf7, 0x1c, 0x80, 0x01, 0xf7, 0x1d, 0x51,
							/* 00B8 */	0x01, 0xf7, 0x1e, 0xc4, 0x01, 0xf7, 0x1f, 0x01
						},

 

I have tried to put it in my dsdt and it works equal (what i see) to the Configdata from BuildSmart.

 

screen-capturejg5y.pngscreen-capture-13jx5.pngscreen-capture-36g7x.pngscreen-capture-2jekq.png

 

Since this Method is different than the others i have seen in the forums i don`t understand why in this case i have to put the complete Pinconfigoverrideverbs in the dsdt and in the other cases it works different.

 

I think this is more accurate to my case so i use this further even if i don`t know if it works better as before.

 

It would be great if anyone can test other things than analog output :thumbsdown_anim:

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted

It is make sense where you need to change the "ConfigData" contents with your PinConfigOverrideVerbs from Windows.

 

............................

 

Since this Method is different than the others i have seen in the forums i don`t understand why in this case i have to put the complete Pinconfigoverrideverbs in the dsdt and in the other cases it works different.

..................

Can you explain a little bit more what happen in "the other cases"? What cases? :huh:

 

I think I need to use legacy kext because I did some changes to MuteGPIO value (under layouts). What do you think? My DSDT code almost similar with the one posted here (of course with my "ConfigData") except I add values to "PinConfigurations" section. I also have my input & output devices displayed correctly in System Profiler, with or without legacy kext.

            Device (HDEF)
           {
               Name (_ADR, 0x001B0000)
               Name (HDWA, Zero)
               Name (_PRW, Package (0x02)
               {
                   0x05, 
                   0x03
               })
               Method (_PS0, 0, Serialized)
               {
                   If (LEqual (HDWA, Zero))
                   {
                       Store (One, HDWA)
                       HKEY (0x8F)
                   }
               }

               Method (_PS3, 0, Serialized)
               {
                   Store (Zero, HDWA)
               }

               [b]Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x0C)
                   {
                       "built-in",
                       Buffer (One)
                       {
                           0x00
                       },

                       "codec-id",
                       Buffer (0x04)
                       {
                           0x83, 0x08, 0xEC, 0x10
                       },

                       "ConfigData",
                       Buffer (0x40)
                       {
                           /* 0000 */    0x01, 0x47, 0x1C, 0x30, 0x01, 0x47, 0x1D, 0x11,
                           /* 0008 */    0x01, 0x47, 0x1E, 0x0B, 0x01, 0x47, 0x1F, 0x01,
                           /* 0010 */    0x01, 0x87, 0x1C, 0x10, 0x01, 0x87, 0x1D, 0x91,
                           /* 0018 */    0x01, 0x87, 0x1E, 0xAB, 0x01, 0x87, 0x1F, 0x01,
                           /* 0020 */    0x01, 0xA7, 0x1C, 0x20, 0x01, 0xA7, 0x1D, 0x31,
                           /* 0028 */    0x01, 0xA7, 0x1E, 0x81, 0x01, 0xA7, 0x1F, 0x01,
                           /* 0030 */    0x01, 0xE7, 0x1C, 0x40, 0x01, 0xE7, 0x1D, 0xE1,
                           /* 0038 */    0x01, 0xE7, 0x1E, 0x45, 0x01, 0xE7, 0x1F, 0x01
                       },

                       "layout-id",
                       Buffer (0x04)
                       {
                           0x0C, 0x00, 0x00, 0x00
                       },

                       "device-type",
                       Buffer (0x11)
                       {
                           "Mobile ALC883 S/T"
                       },

                       "PinConfigurations",
                       Buffer (0x10)
                       {
                           /* 0000 */    0x30, 0x11, 0x0B, 0x01, 0x10, 0x91, 0xAB, 0x01,
                           /* 0008 */    0x20, 0x31, 0x81, 0x01, 0x40, 0xE1, 0x45, 0x01
                       }
                   }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }[/b]
           }

I bolded the code I add. Please refer to this post what error I got without the legacy kext.

 

I noticed that I need to add DTGP method in dsdt.dsl. Does the value inside DTGP method is hardcoded or need to change it to reflect our setup?

 

kizwan

Link to comment
Share on other sites
R3van
R3van
Posted
Posted

In this Thread ac3bcn uses not the complete codecverbs but for every Value only the last digits.

 

Here and in the other Thread was also no ConfigData used, just Pinconfigurations

 

Sorry, i can`t answer your other questions, i`m a beginnner with that too :)

 

So after a bit trying i got displayed something more in System Profiler, i take every last two digits from my codecverbs and put it under PinConfigurations:

 

screen-captureqtf5.png

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
In this Thread ac3bcn uses not the complete codecverbs but for every Value only the last digits.

ac3bcn only inject PinConfigurations using DSDT & still use HDAController kext to inject ConfigData.

 

Here and in the other Thread was also no ConfigData used, just Pinconfigurations

It still need legacy/patched kext to get audio working.

 

Sorry, i can`t answer your other questions, i`m a beginnner with that too :)

It is ok. I'm beginner too. :(

 

In my case, I was right about layouts. I just removed legacy kext except legacy kext for HDAPlatformDriver.kext (where layouts located) & my audio still working. From my conversation with other people, I think I need to use layout-id from the first post of this thread. I will try that later.

 

kizwan

Link to comment
Share on other sites
R3van
R3van
Posted
Posted

In my Windows registry are two Pinconfigoverrideverbs and i ignored the first (shorter) one till now.

 

Inscribing these values makes no difference for me, so do you know what is this for?

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
In my Windows registry are two Pinconfigoverrideverbs and i ignored the first (shorter) one till now.

Yeah....me too. I believe the first one (shorter) exist when we use driver from microsoft (generic driver) while the second one is when we use driver from realtek. It is true for me base on the date & other information on the registry. But I much prefer codec verbs taken from linux codec dump. :) BTW, it should identical.

 

Inscribing these values makes no difference for me, so do you know what is this for?

I don't have proper answer but I do think it is for properly initialized input & output devices. It maybe makes no difference for you but maybe it is for anybody else with different audio codec. Taruga's patched AppleHDA.kext also don't have ConfigData, but that is old kext.

 

Well, I'm a bit confused here. I thought "ConfigData" was the one that responsible for displaying correct input & output devices in System Profiler. It does with legacy/patched kext. But since "PinConfigurations" values derived from "ConfigData", that maybe still true. Look....I answered my own question. ;)

 

kizwan

Link to comment
Share on other sites
R3van
R3van
Posted
Posted
Yeah....me too. I believe the first one (shorter) exist when we use driver from microsoft (generic driver) while the second one is when we use driver from realtek.

 

kizwan

 

This would mean that get full functional jackets we need only the two lines hexvalues from generic driver and the others are additions in functionality.

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