498 replies to this topic

[valv]

jdys_1991, on May 10 2010, 10:35 PM, said:

Is the guide 100% complete yet or is there still bits missing?
And thank you for the great work, Valv!

Take a look at the end of post#4, firewire hack added at the time u've been asking.
Btw, more code to come, don't worry. U'll get all hacks . More complicated ones later on. Too much work on the ACPILoader.

Greetz,

[hdx18]

Hi Valv!

Unfortunately, there's some problem with your last DSDT modification (concerning Firewire).
The compiler found this error:

/Users/MacOSX/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl  1313:         Method (_L1A, 0, NotSerialized)
        {
            Notify (\_SB.PCI0.RP05.FRWR, Zero)
            Notify (\_SB.PWRB, 0x02)
        }
Error    4064 -                                                                                                                                        Object does not exist ^  (\_SB.PCI0.RP05.FRWR)

ASL Input:  /Users/MacOSX/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl - 11453 lines, 412976 bytes, 5584 keywords
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 40 Optimizations

[valv]

Oh, sorry, sorry, this is because I've got confused about device names since I radically changed those, and I don't like to tell do the same 'cause it is not as simple as typing some code. we'll see later if I get more pedagogic way to show u how to do it. In the mean time Code corrected on first place. go edit and everything will turn back to normal.
Again, thank u for waking me up.

[hdx18]

Hi Valv!

I just realized something.

One of the DSDT fixes seems not to work.  It's about UHC5 device.  I injected a device-id (0x39, 0x3A, 0x00, 0x00) to make the system think it's a compatible hardware... But it's still not recognized as a built-in device.  the ID is also different (0x39 0x29 0x00 0x00)...  System info gives me those details (in French, but easy to understand   ) :

Bus USB :

  Emplacement du contrôleur de l’hôte : Emplacement d’extension
  Gestionnaire du contrôleur de l’hôte : AppleUSBUHCI
  Identifiant du périphérique PCI : 0x2939
  Identifiant de révision du PCI : 0x0003
  Identifiant du fournisseur du PCI : 0x8086
  Numéro de bus : 0x7d

Note that all other USB devices (UHCx & EHCx) are recognized as built-in...

And my injection hack:

            Device (UHC5)
            {
                Name (_ADR, 0x001A0002)
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x02)
                        {
                            "device-id",
                            Buffer (0x04)
                            {
                                0x39, 0x3A, 0x00, 0x00
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            }


Do you have any idea about that?

[valv]

Salut hdx18, let's have a closer look into your injection. Pay attention to the Address of your device

hdx18, on May 14 2010, 01:13 AM, said:

Device (UHC5)
            {
                Name (_ADR, 0x001A0002)
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x02)
                        {
                            "device-id",
                            Buffer (0x04)
                            {
                                0x39, 0x3A, 0x00, 0x00
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            }

The device-id we're faking should somehow be compatible with the device address.
What we can do here is replace that address with this one 0x001D0003. Thus the id becomes compatible, and OsX goes to sleep w/o failure (hopefully).
I forgot about this messy trick. thank u for making me remember it.
Greetz,

[rachaf]

thanks you again valv for Firwire and Ethernet hacks and for pulling our attention on realtek (RTLD) because i have it straight above "EXP3" device in my DV5 laptop:
 PCI_Slots.jpg   21.85K   62 downloads
can't wait for the next hacks   
btw the sound work for me with voodoohda (V2.62) but with no MAX/MIN/MUTE, do you have this problem?

thanks and sorry for my english;

[manmal]

Hi rachaf,

i modified voodooHDA 2.6.1 to support volume control on hdx18 (thanks to pcrew : http://www.insanelym...p...183321&st=0 , i just adapted some code to the newest VoodooHDA source, the basic idea is from him).
I compiled it 32/64 bit for Snow Leopard.
Please give it a try and please give me your feedback if it works or not for you.
Here it works but i tried only the 32 bit version. It is still experimental, volume changes are effective after the first half of the cursor . I am working on it for a "smoother" version of volume control.

I attached also an older version of 2.5.6 VoodooHDA with such modifications, but sometimes it gives me kernel panic (it is due to VoodooHDA, not to my modification).

Voodoohda 2.6.2 seems still experimental. If/When you will find a link for a stable version to download, including sources please let me know and i will do the modifications there too and will post the compiled kext here.

If there is a "cleaner" method using latest patched AppleHDA.kext where sleep works and volume control works out of the box instead of using VoodooHDA please let me (us) know.

Mal

Attached Files

•  VoodooHDA_256_HP_HDX18.kext.zip   150.94K   21 downloads
•  VoodooHDA_261_HP_HDX18.kext.zip   153.05K   128 downloads

[rachaf]

Thank you manmal, and yes i tried your modified voodoohda_2.61 and result is:
-Only the first half of volume control work (like you)
-Mute not working.

AppleHDA kext exist (AppleHDA 1.8.4fc3, patched by deviato for IDT  92HD71B7X for Dell Inspiron 1545) but since we have the same ID it works for me too, sorry i don't know for sleep because i have problem with wake up (for now), this is the link:
http://deviato.wordp...-driver-update/

i hope that you success to give us the perfect voodoohda for our IDT;

and sorry for my english;

[manmal]

Hi,
strange... here mute is working (the led is still "gray", not red when muted but it works!).
I am working on the "smoother" volume control. I will post an update here when it will be ready.
Thanks for the link to AppleHDA by deviato. Unfortunately, after sleep audio does not work any more like any other AppleHDA i tried. Has anyone a solution for it ? AppleHDA works nice but if i put my system to sleep and awake it, audio does not work any more and i need to reboot. That's the main reason why i am using VoodooHDA .

About your sleep/wake problem : have you fixed your dsdt using valv's USB trick in the firsts post of this thread ? If yes, have you checked where's the problem using this command : pmset -g log

Mal

rachaf, on May 14 2010, 03:31 PM, said:

Thank you manmal, and yes i tried your modified voodoohda_2.61 and result is:
-Only the first half of volume control work (like you)
-Mute not working.

AppleHDA kext exist (AppleHDA 1.8.4fc3, patched by deviato for IDT  92HD71B7X for Dell Inspiron 1545) but since we have the same ID it works for me too, sorry i don't know for sleep because i have problem with wake up (for now), this is the link:
http://deviato.wordp...-driver-update/

i hope that you success to give us the perfect voodoohda for our IDT;

and sorry for my english;

[jdys_1991]

I get this error when I press compile DSDT:


Intel ACPI Component Architecture
ASL Optimizing Compiler version 20091214 [Dec 16 2009]
Copyright © 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0

/Users/jay/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl 11233: [*** iASL: Read error on source code temp file /Users/jay/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.src ***]
Error    4096 -                                    syntax error, unexpected $end ^

ASL Input:  /Users/jay/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl - 11234 lines, 407302 bytes, 5484 keywords
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 0 Optimizations


I have no idea what I need to do to fix it. I've uploaded my .dsl file. Could you please have a look, valv? MAKE SURE YOU RENAME dsdt.ZIP to dsdt.DSL!! I don't have any program installed to zip it, so please CHANGE THE EXTENSION. It didn't allow me to upload, otherwise.
Thank you!

Attached Files

•  dsdt.zip   397.76K   18 downloads

[hdx18]

Hi jdys_1991!

I compared your DSDT file with mine.  You seem to have extracted it from an older BIOS version (assuming you have an HDX16/HDX18 computer).  The latest version of the BIOS is F.32A (ftp://ftp.hp.com/pub/softpaq/sp46001-46500/sp46073.exe).  You should update it before fixing the DSDT table.  Afterward, extract the updated DSDT table and make the changes as indicated.  You should be ok!

NB: This update is optional, but since you're doing some modifications to the DSDT file, why not making it with a fresh and updated BIOS...  

Greetz!

[manmal]

hi,
talking about hdx18 bios updates ... interesting discussion: do you see many changes from F31A to F32A ? Can anyone please let me have a detailed list of what changed (in dsdt/ssdt/acpi tables) since F31A to F32A ? To my knowledge, nothing changed ... i compared bit to bit the dsl files decompiled from aml files extracted from ubuntu.  But i may be wrong...

Thanks in advance.
Mal

[rachaf]

manmal, on May 14 2010, 03:17 PM, said:

Hi,

About your sleep/wake problem : have you fixed your dsdt using valv's USB trick in the firsts post of this thread ? If yes, have you checked where's the problem using this command : pmset -g log

Mal

Hi Mal

The cause of my problem was related with "RTC fix" (0x08 to 0x02), i thought that this fix wasn't important for me.
thank you for the command, before the fixe this command give me this message "Sleep: Platform Failure - AC 100"

like always; sorry for my english

[valv]

jdys_1991, on May 15 2010, 08:38 PM, said:

I have no idea what I need to do to fix it. I've uploaded my .dsl file. Could you please have a look, valv? MAKE SURE YOU RENAME dsdt.ZIP to dsdt.DSL!! I don't have any program installed to zip it, so please CHANGE THE EXTENSION. It didn't allow me to upload, otherwise.
Thank you!

ok. would mind providing me also with the unedited dsdt ?

[hdx18]

manmal, on May 15 2010, 08:12 PM, said:

hi,
talking about hdx18 bios updates ... interesting discussion: do you see many changes from F31A to F32A ? Can anyone please let me have a detailed list of what changed (in dsdt/ssdt/acpi tables) since F31A to F32A ? To my knowledge, nothing changed ... i compared bit to bit the dsl files decompiled from aml files extracted from ubuntu. But i may be wrong...

Thanks in advance.
Mal

To be honest, you may be right. I assumed jdys_1991 is using a DSDT file extracted from an HDX18/16. All I can tell with certainty is that his DSDT table has some different codes (other than the fixes and hacks from Valv) than those I have in my DSDT (extracted from the latest BIOS from an HDX18 using an Ubuntu OS). Maybe jdys_1991 has a different HP computer, which could also explain the discrepancies...

The only fix/enhancement indicated by HP for the newest BIOS is an update to Computrace Option ROM (version 889). I don't know if the DSDT (and other tables) between F31A and F32A versions are different. Sorry!

[valv]

hdx18, on May 16 2010, 03:06 AM, said:

I don't know if the DSDT (and other tables) between F31A and F32A versions are different. Sorry!

No difference, in my humble thought.
Edit: That dsdt doesn't seem to be from an hdx18 (I could be wrong). But if am wrong, then it was harshly messed. hacks were not literally applied. Please provide me with ur old untouched and freshly extracted one. I'll see what could be done.
But don't use it by now.

[jdys_1991]

hdx18, on May 15 2010, 08:25 PM, said:

Hi jdys_1991!

I compared your DSDT file with mine.  You seem to have extracted it from an older BIOS version (assuming you have an HDX16/HDX18 computer).  The latest version of the BIOS is F.32A (ftp://ftp.hp.com/pub/softpaq/sp46001-46500/sp46073.exe).  You should update it before fixing the DSDT table.  Afterward, extract the updated DSDT table and make the changes as indicated.  You should be ok!

NB: This update is optional, but since you're doing some modifications to the DSDT file, why not making it with a fresh and updated BIOS...  

Greetz!

Oh right, I didn't know. Yeah, I have a HDX18 laptop.. I will update my BIOS now and try again!
Thank you!

[valv]

u still need to provide the old dsdt even with a bios update (I miss the point on that update, since nothing on dsdt would change after that)

[hdx18]

valv, on May 16 2010, 09:18 PM, said:

u still need to provide the old dsdt even with a bios update (I miss the point on that update, since nothing on dsdt would change after that)

Since jdys_1991's HDX18 computer seems to have an older BIOS (probably older than F31A because of the discrepancies noted when comparing with the DSDT table of the latest BIOS), shouldn't he update it?  I understand that the DSDT table from F31A is identical with the one from F32A... but it seems different with older BIOSes.  Only jdys_1991 could clarify that by verifying his computer BIOS version.

I also understand that jdys_1991 could stay with the BIOS he has on his computer and correct its DSDT table consequently.  But again, since this table seems a bit different, some different errors/warnings could arise.  These could obviously be corrected anyway...  But isn't it easier to work on a common ground (i.e. same DSDT)?

Maybe I'm wrong...

[valv]

You are totally right, some errors could arise later (not necessarily DSDT related). This is not a problem by itself, 'cuz we could adapt things and correct 'em accordingly, since rachaf and other people does not even have the same DSDT and those hacks do work for them (if attentively following). The big mess would be that, over time, u'll find out that HP engineers, made some hilarious errors on some models. That is I totally agree with u on the point that we should start with closest conditions possible. This way we can easily understand the reasons for a non working hack, or to be sure if some errors arise on one's notebook (same model & same conditions) that they aren't related to ACPI, but more to Software and versions. There's also the point that even with same model, most of us don't have same devices, as of wifi, bluetooth, Processors...
btw, regarding the wifi whitelist's hack, how we could setup the new (patched) version of the bios if we already use the latest one ? could we downgrade (the bios) before making changes ? I've read something about that, but I can't remember exactly. Some clue ?

Greetz,