Hi Lekensteyn,
These are great developments, great effort. I wonder, not knowing much
about the internals of this, how generic are these calls to _DSM
methods? Could someone write the correct _DSM calls for each any
hybrid laptop with a _DSM method? Or is there any way to test the
different parameters and see which one does something to the graphics
card?
Cheers
On Sun, Oct 23, 2011 at 12:30 PM, Lekensteyn <lekenst...@gmail.com> wrote:
> Hi Eric,
>
> I'm attaching my notes for digging in my own tables as well as the
> disassembled tables you sent me before.
> The TableID of SSDT5.dsl is OptTabl (OptimusTable?) and the methods and
> devices in it suggests that it is relevant.
>
> A quick overview on that views revealed some interesting methods:
>
> - \_SB.PCI0.PEG0.PEGP._DSM calls \_SB.PCI0.GFX0.HDSM (Arg0, Arg1, Arg2,
> Arg3) and returns the return value from that method
> - \_SB.PCI0.GFX0.HDSM
> If arg 0 equals to the buffer
> 0xF8, 0xD8, 0x86, 0xA4, 0xDA, 0x0B, 0x1B, 0x47, 0xA7, 0x2B, 0x60, 0x42,
> 0xA6, 0xB5, 0xBE, 0xE0
> then OPCI becomes One.
>
> If OPCI is One OR if SGCI or NBCI are One (which is never the case), the
> next continues:
>
> If arg1 (the revision number) does not equal 0x100 0x80000002 is returned
> (which is btw the value returned on errors).
>
> Arg 2 is the function, func 0 returns a 4-byte buffer depending on some
> register values
> func 1 returns a buffer with four 0x0 (in this case)
> ... there are other methods but I'm not going to analyse all of them for
> now..
> func 0x03 is what we're looking for.
>
> Arg3 is converted to an integer, taking the first 8 bytes of the buffer as
> an integer (forming a 64-bit one). On that integer, the least two bits are
> significant.
> if it's 0, \_SB.PCI0.PEG0.PEGP.SGST is called (status?),
> if it's 1, \_SB.PCI0.PEG0.PEGP.SGON is called (turn something on?),
> if it's 2, \_SB.PCI0.PEG0.PEGP.SGOFF is called (turn sth. off?)
>
> After that, if the result of \_SB.PCI0.PEG0.PEGP.SGST equals 0x0F, a buffer
> of 0x0, 0x2, 0x0, 0x0 is returned. Otherwise, a buffer of 4 zeros is
> returned.
>
> The method becomes:
> \_SB.PCI0.PEG0.PEGP._DSM
> {0xF8,0xD8,0x86,0xA4,0xDA,0x0B,0x1B,0x47,0xA7,0x2B,0x60,0x42,0xA6,0xB5,0xBE,0xE0}
> 0x100 0x3 {0x00,0x00,0x0,0x1}
> The above is for turning it n, replace the last 0x1 by 0x2 for turning it
> off (theoretically)
>
> Some methods may return a Package as result ("Object type 0x4"). If you
> encounter that, use acpi_call from
> https://github.com/Bumblebee-Project/acpi_call. I'll soon make it available
> in the bumblebee/testing PPA.
>
> I wish there was a register/ method documentation somewhere, that would help
> a lot with analysing.
>
> Regards,
> Lekensteyn
>
> On Sun, Oct 23, 2011 at 5:56 AM, Eric Appleman <erapple...@gmail.com> wrote:
>>
>> Consult the following for background and logs:
>> https://github.com/Bumblebee-Project/Bumblebee/issues/133
>>
>> Is there anyone here who is well-versed in ACPI who'd be willing to look
>> at my tables as well as those of similarly arranged machines?
>>
>> Thanks in advance.
>>
>> - Eric Appleman, Bumblebee Project
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~hybrid-graphics-linux
>> Post to : hybrid-graphics-linux@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~hybrid-graphics-linux
>> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~hybrid-graphics-linux
> Post to : hybrid-graphics-linux@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~hybrid-graphics-linux
> More help : https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list: https://launchpad.net/~hybrid-graphics-linux
Post to : hybrid-graphics-linux@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hybrid-graphics-linux
More help : https://help.launchpad.net/ListHelp
