OSX on DELL Vostro 3450 / Inspiron N4110 / XPS L702x UEFI Clover

[Zprood]

 

Have you deleted IOWMIFamily and removed the patch to override AMW0? Because I'm not seeing any of "double" brightness changes here no matter how I adjust the backlight level. In case you still have WMIFamily installed it would generate secondary NX_BRIGHTNESS event into the system.

 

Zeroing out the string is a junkie move, the assertion is still there and you need to find the cause of it.

The assertion is produced by AppleHDAWidget::pinDefaultDeviceType() so it's something caused by the changes you made to the pinConfig (ConfigData). With my pinConfig I don't get any sound assertions. 

Sorry to miss this attention about deleting IOWMIFamily and remove the patch AMW0, now it turns out works. For the pinConfig i do modify it when update 10.9.1, revert it back from your, logs have gone.

THX again. 

[TimeWalker75a]

Yes... I see...

 

One "sanity check" you might do is extract each of your DSDT/SSDT tables from ioreg:

- run IORegistryExplorer, search for AppleACPIPlatformExpert, open "ACPI Tables" property

....

- in that directory (with only the dsdt.aml, ssdt*.aml), in Terminal: 'iasl -da *'

 

... If you get a successful load and disassembly of all the binaries, then there is no issue, but if you get errors and failure to disassemble them, you might want to look into why...

Why resort to stone age when I can just run DarwinDumper and get all of the acpi tables in a matter of 3 second (and it will decompile the tables in a common folder too, so same thing as -da happens). I'm quite aware of the IOReg technique (hence I've mentioned it as an option in my previous post). I'm more then positive the tables are ok and there won't be any issues, because if manually coded supplemental tables would have had errors then parts of the _DSM or devices wouldn't inject into the system as no External references would be met.

 

I see no reason for people trying to edit amls since I've posted both dsl tables on my git (just need to upload a separate table to add pieces of code for AMD models to disable SG and remove _DSM from IGPU). If any modifications needs to be done on these tables then dsl are freely available with no extra steps to make them compile properly.

 

 

Sorry to miss this attention about deleting IOWMIFamily and remove the patch AMW0, now it turns out works. For the pinConfig i do modify it when update 10.9.1, revert it back from your, logs have gone.

THX again. 

Good. 

 

 

codec commander is not working in lion 10.7.5

not show sound popup 

 

14. 2. 27. 오전 2:21:10.000 kernel: kxld[org.tw.CodecCommander]: The following symbols are unresolved for this kext:

14. 2. 27. 오전 2:21:10.000 kernel: kxld[org.tw.CodecCommander]: __ZN9IOService12updateReportEP19IOReportChannelListjPvS2_

14. 2. 27. 오전 2:21:10.000 kernel: kxld[org.tw.CodecCommander]: __ZN9IOService15configureReportEP19IOReportChannelListjPvS2_

14. 2. 27. 오전 2:21:10.000 kernel: Can't load kext org.tw.CodecCommander - link failed.

 

If you are trying to use any of the pre-compiled kexts - they are compiled with 10.9 SDK, so they won't work in 10.7.5. Compile from source setting appropriate SDK in Build settings. 

[RehabMan]

Why resort to stone age when I can just run DarwinDumper and get all of the acpi tables in a matter of 3 second. I'm quite aware of the IOReg technique (hence I've mentioned it as an option in my previous post). I'm more then positive the tables are ok and there won't be any issues, because if manually coded supplemental tables would have had errors then parts of the _DSM or devices wouldn't inject into the system as no External references would be met.

The purpose is not to obtain disassembly of the tables. The purpose is to see if they all load into ACPI namespace as you intend. I realize you believe there is no issues, thus why I call this a "sanity check." It is a process by which you verify your assumption. I have tried this in a number of troubleshooting scenarios, and it is very effective.

 

If you don't want to spend the time double-checking your work, that's fine. I'm just sharing a valued technique that you might have been unaware of.

[TimeWalker75a]

The purpose is not to obtain disassembly of the tables. The purpose is to see if they all load into ACPI namespace as you intend. I realize you believe there is no issues, thus why I call this a "sanity check." It is a process by which you verify your assumption. I have tried this in a number of troubleshooting scenarios, and it is very effective.

 

If you don't want to spend the time double-checking your work, that's fine. I'm just sharing a valued technique that you might have been unaware of.

I've edited my message saying that DarwinDumper will do the same thing for you - it will decompile all the tables it has obtained from IOReg in a common folder, essentially performing iasl -da operation on the amls it has obtained. So you can the open them one by one and check if the integrity is ok. Opening up both custom tables with either DSDT Editor and Patcher (java based) or MacIASL results in acpi table being properly loaded into the editor, with the exception of External references being out of order so MethodObj and IntObj declarations end up above DeviceObj declarations and compile will say there's no way to access these references. 

[RehabMan]

I've edited my message saying that DarwinDumper will do the same thing for you - it will decompile all the tables it has obtained from IOReg in a common folder, essentially performing iasl -da operation on the amls it has obtained. So you can the open them one by one and check if the integrity is ok. Opening up both custom tables with either DSDT Editor and Patcher (java based) or MacIASL results in acpi table being properly loaded into the editor, with the exception of External references being out of order so MethodObj and IntObj declarations end up above DeviceObj declarations and compile will say there's no way to access these references.

I don't think DarwingDumper uses 'iasl -da'. It is not the same to disassemble them individually as they are never all loaded into one namespace. The type of checking you get from "iasl -da" only happens because they are all loaded into the same namespace.

 

It can find things like:

- duplicate definitions of common hack utility methods (DTGP, B1B2, etc)

- duplicate definitions of devices (eg. PNLF defined in both DSDT and an SSDT)

- renames that were done in one binary, but not another (eg. GFX0 renamed in DSDT, but not in all SSDTs)

- etc

 

It is a useful "error checking" tool.

[TimeWalker75a]

Ok, indeed DD just performs individual decompilation of each table ("$iasl" -d "$gAMLDir"/$tbl_name.aml &> /dev/null)

I've done as suggested and result is the following (and I can't use fields from EmdebbdedController memory space without having it as external reference)

 

Loading Acpi table from file DSDT.aml
Acpi table [DSDT] successfully installed and loaded
Loading Acpi table from file SSDT-3.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-2.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-1.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Pass 1 parse of [DSDT]
ACPI Error: [ECRM] Namespace lookup failure, AE_ALREADY_EXISTS (20130823/dswload-436)
ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20130823/psobject-304)

[RehabMan]

Ok, indeed DD just performs individual decompilation of each table ("$iasl"[/size] -d [/size]"$gAMLDir"[/size]/$tbl_name.aml &> /dev/null)[/size]

I've done as suggested and result is the following (and I can't use fields from EmdebbdedController memory space without having it as external reference)

 

Loading Acpi table from file DSDT.aml
Acpi table [DSDT] successfully installed and loaded
Loading Acpi table from file SSDT-3.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-2.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-1.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Pass 1 parse of [DSDT]
ACPI Error: [ECRM] Namespace lookup failure, AE_ALREADY_EXISTS (20130823/dswload-436)
ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20130823/psobject-304)

 

You should be using External(FOO, FieldUnitObj) to refer to Fields defined in an EC region in another compilation unit.

 

If you are defining new fields (eg. fields at offsets not defined elsewhere), use another declaration of the EmbeddedControl OperationRegion plus a new Field definition, both with unique names. Note that any EmbeddedControl OperationRegion must be declared in the associated EC scope.

 

Hopefully that makes sense.

[RehabMan]

You should be using External(FOO, FieldUnitObj) to refer to Fields defined in an EC region in another compilation unit.

 

If you are defining new fields (eg. fields at offsets not defined elsewhere), use another declaration of the EmbeddedControl OperationRegion plus a new Field definition, both with unique names. Note that any EmbeddedControl OperationRegion must be declared in the associated EC scope.

 

Hopefully that makes sense.

Basically, constructs like this:

   External (_SB_.PCI0.LPCB.EC0_.ECRM) // EC 0x100 byte Memory Space
...
        // read memory ambient temperature          
        Field (ECRM, ByteAcc, Lock, Preserve)
        {
            Offset (0x5C), 
            MCPT,   8, 
        }

Should be written:

        OperationRegion (ECX1, EmbeddedControl, Zero, 0xFF)
        Field (ECX1, ByteAcc, Lock, Preserve)
        {
            Offset (0x5C), 
            MCPT,   8, 
        }

Same in the other SSDT:

            OperationRegion (ECX2, EmbeddedControl, Zero, 0xFF)
            // allow to get and set touchpad LED status from EC RAM 0x45 bit 7           
            Field (ECX2, ByteAcc, Lock, Preserve)
            {
                Offset (0x45), 
                    ,   7, 
                TLED,   1, 
            }

Note how in each case, unique names are used for the OperationRegion/Field declarations. ECX1/ECX2 are not likely used by the DSDT (you should verify).

[TimeWalker75a]

You should be using External(FOO, FieldUnitObj) to refer to Fields defined in an EC region in another compilation unit.

 

If you are defining new fields (eg. fields at offsets not defined elsewhere), use another declaration of the EmbeddedControl OperationRegion plus a new Field definition, both with unique names. Note that any EmbeddedControl OperationRegion must be declared in the associated EC scope.

 

Hopefully that makes sense.

A lot, actually. I was trying to supplement already defined field, I guess it goes against the spec. So I defined a new region and matching filed one with a unique name. 

 

Thing is, there are bound to be errors when simulating ACPI interpreter's work because DSDT is the same for both types of these machines, regardless of their configuration (AMD or Intel only laptops)... so External definitions in stock DELL DSDT will likely fail because there's no AmdRef or SgRef ACPI tables coming from BIOS, so arbitrary things like External (_SB_.PCI0.PEG0.PEGP.DD02) won't exist for some but will be there for the others...

SSDT-2:
        Scope (\_SB.PCI0.LPCB.EC0)
        {
            // allow to get and set touchpad LED status from EC RAM 0x45 bit 7
		   OperationRegion (ECSP, EmbeddedControl, 0x45, 0x005D)           
            Field (ECSP, ByteAcc, Lock, Preserve)
            { 
                    ,   7, 
                TLED,   1, 
            	Offset (0x5C), 
            	MCPT,   8, 
            }
        }
SSDT-1:
    External (_SB_.PCI0.LPCB.EC0_.MCPT, IntObj) // Memory Compartment Temperature

[RehabMan]

A lot, actually. I was trying to supplement already defined field, I guess it goes against the spec. So I defined a new region and matching filed one with a unique name. 

 

Thing is, there are bound to be errors when simulating ACPI interpreter's work because DSDT is the same for both types of these machines, regardless of their configuration (AMD or Intel only laptops)... so External definitions in stock DELL DSDT will likely fail because there's no AmdRef or SgRef ACPI tables coming from BIOS, so arbitrary things like External (_SB_.PCI0.PEG0.PEGP.DD02) won't exist for some but will be there for the others...

SSDT-2:
        Scope (\_SB.PCI0.LPCB.EC0)
        {
            // allow to get and set touchpad LED status from EC RAM 0x45 bit 7
		   OperationRegion (ECSP, EmbeddedControl, 0x45, 0x005D)           
            Field (ECSP, ByteAcc, Lock, Preserve)
            { 
                    ,   7, 
                TLED,   1, 
            	Offset (0x5C), 
            	MCPT,   8, 
            }
        }
SSDT-1:
    External (_SB_.PCI0.LPCB.EC0_.MCPT, IntObj) // Memory Compartment Temperature

 

I see we had the same idea (see my post above)... In the External for MCPT, it should be FieldUnitObj, but probably both work.

 

One day, I would like to try this for the Probook or some of my other hacks, but I'm not sure how I would handle some of the patches we do. For example, to get battery status working is very invasive and does not lend towards using an SSDT or Clover patches. I'm assuming your battery code does not access any multi-byte EC registers, such that a DSDT patch is not necessary?

[TimeWalker75a]

I realized that I have to offset by different number .. because Offsetting 5C from 45 is not the place I want to end up

My battery code accessed EC registers (not SMI direct access as on most Asus for example) and I have them split into 8 bit registers down from 16 joining back with B1B2 by means of Clover patches. I basically replace ECRM with patched ECRM in DSDT and override battery device..

[RehabMan]

I realized that I have to offset by different number .. because Offsetting 5C from 45 is not the place I want to end up

Yup. I figured you'd discover that when it didn't compile.

 

My battery code accessed EC registers (not SMI direct access as on most Asus for example) and I have them split into 8 bit registers down from 16 joining back with B1B2 by means of Clover patches. I basically replace ECRM with patched ECRM in DSDT and override battery device..

Curious... What kind of process do you use to create such an extensive Clover DSDT patch.

[TimeWalker75a]

Yup. I figured you'd discover that when it didn't compile.

 

 

Curious... What kind of process do you use to create such an extensive Clover DSDT patch.

Why wouldn't it compile? Right after I posted I realized I'd end up at 0x45+0x5C instead of *just* 0x5C.. so I changed it offset by 17 bytes and adjusted the field length accordingly. 

 

1. obtain DSDT from BIOS the way it comes bundled (no dsl-aml-dsl conversions).. get it from AIDA or any flavor of linux. make a copy for future reference 

2. using MacIASL open up the binary file and make the changes you desire one step at a time (like add certain method or change certain device), preferably

3. open up original table using any hex editor of your preferences and locate the scope you were altering .. (search by text for faster results) 

4. select the scope (a method, device or region .. altering Name entries should be done with higher range .. like if you need to change a Name or Mutex, then you'd select a method that is near by that Name entry and the entry itself), first 2 bytes before the name are usually CRC of that scope..

5. open up the binary you have edited and select same scope from there.. try replacing the scope in (3) with the scope you got here.. save the binary and see if it can be properly decompiled retaining the structure.. it's likely that it won't, because checksums won't be correct.. so you have to calculate new CRC by comparing the size of bytes (easy when you edit config with PlistEditPro.. it tells you size of Data entries) you are replacing the scope with. 

4. clover is good at adjusting CRCs when parenthesis structures are not complex, but more often then ever it fails to do so properly, so you will end up with kernel panic in regards to APCIPlatformExpert.. which is easily fixable by going to \patched from Shell and mv non_working_conig then cp working config as config.plist 

[RehabMan]

Why wouldn't it compile? Right after I posted I realized I'd end up at 0x45+0x5C instead of *just* 0x5C.. so I changed it offset by 17 bytes and adjusted the field length accordingly.

It would not have compiled error free as the offset is beyond the bounds as specified in the OperationRegion.

0x45+0x5C is not less than 0x5d.

 

1. obtain DSDT from BIOS the way it comes bundled (no dsl-aml-dsl conversions).. get it from AIDA or any flavor of linux. make a copy for future reference 

2. using MacIASL open up the binary file and make the changes you desire one step at a time (like add certain method or change certain device), preferably

3. open up original table using any hex editor of your preferences and locate the scope you were altering .. (search by text for faster results) 

4. select the scope (a method, device or region .. altering Name entries should be done with higher range .. like if you need to change a Name or Mutex, then you'd select a method that is near by that Name entry), first 2 bytes before the name are usually CRC of that scope..

5. open up the binary you have edited and select same scope from there.. try replacing the scope in (3) with the scope you got here.. save the binary and see if it can be properly decompiled retaining the structure.. it's likely that it won't, because checksums won't be correct.. so you have to calculate new CRC by comparing the size of bytes (easy when you edit config with PlistEditPro.. it tells you size of Data entries) you are replacing the scope with. 

4. clover is good at adjusting CRCs when parenthesis structures are not complex, but more often then ever it fails to do so properly, so you will end up with kernel panic in regards to APCIPlatformExpert.. which is easily fixable by going to \patched from Shell and mv non_working_conig then cp working config as config.plist

That's what I thought you might say. Way way way too much work! If I was to do it, I think I'd write some code to automate it (give it native binary + patched binary, and have it spit out Clover patches). Also, it seems to me if something changes within the patched area in a new version of BIOS, the patch will completely break and have to be re-created again. At least source code-based patches can be applied across BIOS versions.

 

I think I'll stick with my current methods... Thanks for the detailed explanation though.

[TimeWalker75a]

It would not have compiled error free as the offset is beyond the bounds as specified in the OperationRegion.

0x45+0x5C is not less than 0x5d.

 

 

That's what I thought you might say. Way way way too much work! If I was to do it, I think I'd write some code to automate it (give it native binary + patched binary, and have it spit out Clover patches). Also, it seems to me if something changes within the patched area in a new version of BIOS, the patch will completely break and have to be re-created again. At least source code-based patches can be applied across BIOS versions.

 

I think I'll stick with my current methods... Thanks for the detailed explanation though.

Just tried it out of curiosity and it in fact has compiled, since 5C is not out of bound for 5D length. (it treats 0x45 as 0)

 

It's not too much work when all you need really is 5 to 6 patches.. the rest belongs in SSDTs. 

Here we need:

1. IRQs removed from TIMR and RTC reserving them for HPET, otherwise it steals from EHCI

2. Override for battery device to make registers split and join for ACP Platform to parse them

3. EC RAM 16 bit to 8 bit conversion

4. SLPE fix + added PMBase+30 region and B1B2  method all in the same patch

5. We need to wipe FOWM method clean to prevent hangs due to UEFI boot mode

6. Darwin patch patching the _INI method

7. A bunch of simple rename patches (like GFX0 to IGPU etc)

 

The rest is done externally.. 

[RehabMan]

Just tried it out of curiosity and it in fact has compiled, since 5C is not out of bound for 5D length. (it treats 0x45 as 0)

OK. Makes sense. Brain fart for me.

 

It's not too much work when all you need really is 5 to 6 patches.. the rest belongs in SSDTs. 

Here we need:

1. IRQs removed from TIMR and RTC reserving them for HPET, otherwise it steals from EHCI

2. Override for battery device to make registers split and join for ACP Platform to parse them

3. EC RAM 16 bit to 8 bit conversion

4. SLPE fix + added PMBase+30 region and B1B2  method all in the same patch

5. We need to wipe FOWM method clean to prevent hangs due to UEFI boot mode

6. Darwin patch patching the _INI method

7. A bunch of simple rename patches (like GFX0 to IGPU etc)

 

The rest is done externally..

I just can't imagine doing it for each BIOS release and each model (which may be slightly different).

 

Just wow! No friggin' way.

[TimeWalker75a]

OK. Makes sense. Brain fart for me.

 

 

I just can't imagine doing it for each BIOS release and each model (which may be slightly different).

 

Just wow! No friggin' way.

No BIOS releases for well over a year now here .. and not expecting one in the distant future, so we are *safe by the bell* 

Considering majority of BIOS releases do not include changes to ACPI I wouldn't be really stressed about this .. model range is completely different story though.. but as far as ProBooks go they generally all use InsydeH20 lately, so there shouldn't be any dramatic differences in their ACPI code.. HP has payed for the platform code once, so they are interested in reusing it more than once and the more the better.. I'm speaking out of my ass now, because I haven't been around the ProBook scene so I can't really know whether it's the case, but at least that what a normal person would assume ..

 

DELL works on the cheap side of things and the entire range of Sandy Bridge laptops from different price ranges based on SecureCore Tiano generally have same ACPI tables (with the exception of Root Ports being slightly shuffled, but it's handled via SSDTs) ... so majority of the patches apply to Vostro 3450, 3750, Inspiron N4110, XPS L502, L702x, L511z and a 13" model which number I can't remember.. 

[RehabMan]

No BIOS releases for well over a year now here .. and not expecting one in the distant future, so we are *safe by the bell* 

Considering majority of BIOS releases do not include changes to ACPI I wouldn't be really stressed about this .. model range is completely different story though.. but as far as ProBooks go they generally all use InsydeH20 lately, so there shouldn't be any dramatic differences in their ACPI code.. HP has payed for the platform code once, so they are interested in reusing it more than once and the more the better.. I'm speaking out of my ass now, because I haven't been around the ProBook scene so I can't really know whether it's the case, but at least that what a normal person would assume ..

 

DELL works on the cheap side of things and the entire range of Sandy Bridge laptops from different price ranges based on SecureCore Tiano generally have same ACPI tables (with the exception of Root Ports being slightly shuffled, but it's handled via SSDTs) ... so majority of the patches apply to Vostro 3450, 3750, Inspiron N4110, XPS L502, L702x, L511z and a 13" model which number I can't remember..

A few more BIOS updates on the ProBook side -- and the changes do often carry into ACPI. And subtle differences between models. Obviously, the older the computer gets, the time between BIOS updates increases.

 

I think maybe I purchase new computers too often to effectively implement this technique without automated tools.

[TimeWalker75a]

Updated first post with up-to-date files for both Vostro and Inspiron. Also pushed AMD specific SSDT-2 to git.

UPD: here we go, i updated to 9.2 and now usb3 doesn't work.

Try these patches (just trim the ones you have according to this picture): http://puu.sh/7bEzO.png

[Sherlocks]

Timewalker can you make codec commander to use 10.7-10.9.x? I'm rookie about compile in xcode. I need your codec commander. Very good job workable. Thanks

[TimeWalker75a]

The earliest SDK I currently have is for 10.8 .. Its almost 2AM here, so its something I'll probably leave for today ..

[Sherlocks]

Thanks Timewalker i'm waiting .
I have mac 3 version except snow leopard. I'm ready to test codec commander.

 

# i builded codec commander SDK 10.8

kext loaded. but after sleep, Generate Stream is not working. so i cant use headphone

 

here is log

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> awake

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> hda codec power restored

14. 2. 27. 오전 9:47:36.000 kernel: Previous Sleep Cause: 5

14. 2. 27. 오전 9:47:36.000 kernel: The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 1470c02

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: PIO operation #1

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 2170c02

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: PIO operation #2

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> workloop started

14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 425

14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 1419

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> simulate mute-unmute event

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: scancode 20 in

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: adb keycode 74 out

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: scancode 20 in

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: adb keycode 74 out

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> simulate headphone jack event

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 707c0

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 70700

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands

[Inter95]

Try these patches (just trim the ones you have according to this picture): http://puu.sh/7bEzO.png

 

you are a genius! That did the trick, also i was having problem with the headphone jack, didn't matter if i did the trick to send it to sleep and interrupt it after 5s, most of the time didn't work. after this fix, it's seen that now is working great so far.

 

 

 

UPD: USB3 and speaking are working perfect. but headphone doesn't work at all. it was working fine after i applied the patch for USB3 but now doesnt.

[Sherlocks]

Codec Commander sometimes can't recognize headphone.

 

simulate headphone is not working as default setting

So i changed value like blow.

[TimeWalker75a]

UPD: USB3 and speaking are working perfect. but headphone doesn't work at all. it was working fine after i applied the patch for USB3 but now doesnt.

If you rebooted from windows the headphone port will be able to detect the jack, but audio won't pass through ... also, make sure you still have HDA Hardware Config in CustomPeripheral kext.

 

 

i builded codec commander SDK 10.8

kext loaded. but after sleep, Generate Stream is not working. so i cant use headphone

 

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> workloop started

14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 425

14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 1419

 

Have you built it with 10.8 SDK and trying to use it with 10.7.5? While this somewhat works, certain functions DSP functions may be different in 10.7.5, so kext will not work properly. 

Codec Commander sometimes can't recognize headphone.

 

simulate headphone is not working as default setting

So i changed value like blow.

Just read the readme on git .. if no audio stream is generated headphones won't work in any OSX version after 25 seconds after wake. In 10.9.2 headphones won't be detected after 2nd PIO is sent.