yes, the first implementation of acpi_call has no parameter passing... it would be great to have that implemented and allow for more testing.
On Sat, Jul 24, 2010 at 12:31 PM, Durango. <durango8...@yahoo.com.au> wrote: > Thanks Albert > > This is true ,but beware the DSDT may be buggy ,you can compare it with the > windows one ( different compiler) > or do the dsdt dump and recompile to see any errors ,on my N61 i have some > errors and warnings . > > We need the acpi_call module to accept parameters as this will further > testing on the optimus systems ,as there > are calls to the DSM ( eg 0x86 or 0x89 ) which can be passed to the > acpi_call module for ease ,this would enable > us to also try to trigger the MUX with the arguments,ie and possibly grab > the LCDD,this is from my files on the N61. > > If (LEqual (\_SB.PCI0.GFX0.HGAP, 0x02)) > { > Notify (\_SB.PCI0.GFX0.LCDD, 0x86) > Notify (LCDD, 0x86) > > Currently this module is parameter-less ,see file comments ,for example if > you could have acpi_call accept > parameters for your K52 you could parse the Store values in the line instead > of typing something like > echo $(($arg0x00)) > /proc/acpi/call ,which doesnt work even after normal > GFX call . > > Asus.K52Jc.DSDT.dsl:11035: Store (0x00, > \_SB.PCI0.GFX0.DSM2) > > > If i get time to finsh this and some dsdt fixes ,hopefully to enable the > nvidia card to post and be the primary > card via a modified dsdt . > > I will let you know and post any hard progress ,as this is possible . > > # Snip of Windoze Information - > > Windows has the intel card using the nvidia drivers and the intel drivers > are loaded by the nvidia card also, > for the optimus operation ,they both utilise a common IGDM*** intel windows > module with a dumx screen > ,similiar to a screen function in nix or a headless X . > > Cheers > > > > > On 07/24/2010 01:23 AM, Albert Vilella wrote: > > Just to let people know, it seems like some of the optimus-enabled > laptops also have a _DSM method, linked to a DSM2 stub: > > grep DSM *.dsl -Rin | grep -e K52 -e U30 > Asus.K52Jc.DSDT.dsl:10549: Name (DSM2, 0x00) > Asus.K52Jc.DSDT.dsl:10550: Name (DSM5, 0x00) > Asus.K52Jc.DSDT.dsl:10593: Method (_DSM, 4, NotSerialized) > Asus.K52Jc.DSDT.dsl:10635: Or > (DSM2, 0x10, DSM2) > Asus.K52Jc.DSDT.dsl:10636: Return (DSM2) > Asus.K52Jc.DSDT.dsl:10750: > Store (DSM5, Local0) > Asus.K52Jc.DSDT.dsl:11019: Store (Local0, > \_SB.PCI0.GFX0.DSM2) > Asus.K52Jc.DSDT.dsl:11035: Store (0x00, > \_SB.PCI0.GFX0.DSM2) > Asus.K52Jc.DSDT.dsl:21106: Method (_DSM, 4, NotSerialized) > Asus.K52Jc.DSDT.dsl:21108: Return (\_SB.PCI0.GFX0._DSM > (Arg0, Arg1, Arg2, Arg3)) > Asus.K52Jc.DSDT.dsl:21600: > Return (\_SB.PCI0.GFX0._DSM (MUID, REVI, SFNC, SARG)) > DSDT_Asus_U30JC.dsl:10669: Name (DSM2, 0x00) > DSDT_Asus_U30JC.dsl:10670: Name (DSM5, 0x00) > DSDT_Asus_U30JC.dsl:10713: Method (_DSM, 4, NotSerialized) > DSDT_Asus_U30JC.dsl:10755: Or > (DSM2, 0x10, DSM2) > DSDT_Asus_U30JC.dsl:10756: Return (DSM2) > DSDT_Asus_U30JC.dsl:10870: > Store (DSM5, Local0) > DSDT_Asus_U30JC.dsl:11139: Store (Local0, > \_SB.PCI0.GFX0.DSM2) > DSDT_Asus_U30JC.dsl:11155: Store (0x00, > \_SB.PCI0.GFX0.DSM2) > DSDT_Asus_U30JC.dsl:21433: Method (_DSM, 4, NotSerialized) > DSDT_Asus_U30JC.dsl:21435: Return (\_SB.PCI0.GFX0._DSM > (Arg0, Arg1, Arg2, Arg3)) > DSDT_Asus_U30JC.dsl:21932: > Return (\_SB.PCI0.GFX0._DSM (MUID, REVI, SFNC, SARG)) > > Not sure if the patch is supposed to do anything for them, though. > > On Fri, Jul 23, 2010 at 8:25 AM, octagonhead <octagonh...@gmail.com> wrote: > > > Forgot to mention that this is running on a UL30VT, > and there is not so much as a flicker from the screen when manipulating the > switch file > > On 10-07-23 12:14 AM, octagonhead wrote: > > Here is the result of my running this kernel with this patch applied > Note that I used the ubuntu-provided linux-source package of 2.6.35-rc5 > rather > than the vanilla kernel, > So please let me know if this is expected to not work, > > the switcheroo interface is created: > > /sys/kernel/debug/vgaswitcheroo# cat switch > 0:+:Pwr:0000:00:02.0 > 1: :Pwr:0000:01:00.0 > > Here are the results of the switching commands I tried: > > /sys/kernel/debug/vgaswitcheroo# echo DIGD > switch > vga_switcheroo: client 0 refused switch > vga_switcheroo: setting delayed switch to client 0 > > /sys/kernel/debug/vgaswitcheroo# echo DDIS > switch > vga_switcheroo: client 0 refused switch > vga_switcheroo: setting delayed switch to client 1 > > /sys/kernel/debug/vgaswitcheroo# echo OFF > switch > > ^^^this seems to work, causing the nouveau driver to unload > (but not removing the nvidia PCI device nor reducing power consumption > according > to powertop), > but usually causes a kernel freeze after about a minute > > dmesg is attached, with kernel trace at the end > > ... > Anyone wishing to make use of my kernel image may find an Ubuntu package at > one > of these urls: > (sub-arch is Core-Duo/Xeon, all other config options are based of a stock > Ubuntu > kernel) > > http://rapidshare.com/files/408536337/linux-image-2.6.35-rc5_CustomDebugNV.01_amd64.deb > or > http://hotfile.com/dl/56924631/1202d13/linux-image-2.6.35-rc5_CustomDebugNV.01_amd64.deb.html > > Please run this command post installing or this kernel will fail to boot! : > # mkinitramfs -k 2.6.35-rc5 -o /boot/initrd.img-2.6.35-rc5 > > (sorry, im too lazy to properly include the initrd or create a PPA at this > point :) > > > On 10-07-19 04:11 PM, Dave Airlie wrote: > > > Okay first attempt at a patch is > > > http://people.freedesktop.org/~airlied/scratch/0001-nouveau-mux-switching-test-patch-1.patch > > Applies on top of current Linus tree, a dmesg from a pre-optimus > machine with hybrid enabled should let me see the current state of the > toggle, > and if you are feeling brave you shuold be able to toggle the mux, so > it might flip from intel to nothing, and flip back or it might do > nothing. > > stuff should be logged in dmesg. > > Dave. > > On Sat, Jul 17, 2010 at 6:45 PM, Dave Airlie<airl...@gmail.com> wrote: > > > So I'd really like to finish the _DSM support in nouveau so we can > actually switch the GPU over on the non-optimus systems. > > There are two things left to do: > > a) figure out what values to pass the DSM method to trigger the MUX, > It looks like method 0x5 is the one to trigger the mux switch but I've > no idea yet what values to pass it to trigger the mux switch. > > b) figure out how to get the LVDS DDC lines and make nouveau find the > panel, at the moment it fails to find the panel when booted and intel > is in control. > > looking at (a) I expect we could pass a bunch of values to the ACPI > method possibly using acpi_call to switch the mux and switch it back, > > It looks like passing 0 will return the current toggle status, then > its a matter of working out which of the top bits are doing what, > > From reading one DSDT I can see, > > if bit 31 set, then bit 30 is some sort of notify, then bits 25,26,27 > are used to work out some values stored in a TOGF > > otherwise bit 24 is used for something, then bits 12,13,14, and 3,2,1, > and it stores some values for CRT/LCD/TVout, which may again be > toggles. > > If someone with the hardware and can use acpi_call it would be nice to > try and map out some of these things, at least initially a value that > will turn the Intel LCD off and back on. > > The DSDT I'm using at the moment is attached to bug 16403. > > Dave. > > > > _______________________________________________ > 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 > > > _______________________________________________ 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