hybrid-graphics-linux team mailing list archive

[Alex Williamson <alex.l.williamson@xxxxxxxxx>]

On Mon, May 16, 2011 at 4:03 AM, Diego <diegosolor@xxxxxxxxx> wrote:
> you were right:
> [    2.415947] [drm] nouveau 0000:01:00.0: Unsupported chipset 0xffffffff
> this is why the screen freezes when I try a switch to the nvidia card?

Not necessarily, it might mean you've switched the graphics, but not
the mux.  Do you get anything out the hdmi port when you do this?

> also, when you have some time, could you explain us how to play witch
> acpi_call to figure out how to switch the mux?

I'm not sure how much advice I have to offer, acpi is pretty difficult
to reverse engineer and I'm far from understanding exactly how things
work on my system.  The ASL in your DSDT is a simple programming
language that gets interpreted by the OS.  You can reference the ACPI
spec to understand what each function does, but putting the pieces
together to understand what it's doing as a whole is often more like
reverse engineering assembly than just uncommented code.

Method names that begin with an underscore are from the reserved
namespace, and you can find definitions of what they do in the ACPI
spec.  All variable and method names are limited to 4 characters,
which makes guessing their purpose difficult.  The Asus DSDT is at
least not obfuscated beyond that required by ASL, so that helps a
little.  You'll also find bugs everywhere in the DSDT, because as many
have said, BIOS writers are crack smoking monkeys.  Methods are
defined as "Method (NAME, <#param>, ...), so you know how many
parameters to pass in, even though the code often ignores them anyway.

Another thing to be aware of is that the DSDT can query the
capabilities of the OS and may do things differently for different
OSes.  You can see the setup for this when the DSDT makes _OSI calls.
Linux ACPI has decided that the only capabilities that make sense to
expose are those for various version of Windows and specifically not
Linux.  This means Linux will by default respond true to _OSI("Windows
2000"), but false to _OSI("Linux").  The theory is that vendors really
only test Windows and it's better to follow the known tested path and
make things work than follow the potentially completely broken and
untested other paths in the code.  The trouble is that many on these
systems support a splashtop, instant on OS, which is linux under the
covers.  We don't really know how they boot these and they very well
might have working code for _OSI("Linux").  I actually find that
booting my UL30VT with acpi_osi="Linux" acpi_osi="!Windows 2009" makes
the backlight brightness keys work.

For this work specifically, it also helps to use a monitor connected
to the hdmi port so you can tell if you've actually done something and
the mux hasn't switched.  For me, the _DSM in the switchto_dis script
switches over to nouveau as the console, but by itself, it lets the
lcd go haywire, like an unsynced monitor (which I suspect is actually
somewhat accurate to what's actually happening).  MXDS will turn off
the lcd backlight ("Display Switch" perhaps) and MXMX ("MuX" maybe)
apparently modifies the mux settings.  These are probably from the MXM
specification, but nobody seems to have a recent copy of the spec.

I was hoping more Asus laptops would work similar to mine, but I can
see in your DSDT that things like the _DSM function 2 listing are
missing things compared to mine.  I also feel obligated to mention
that poking at your system via ACPI is at your own risk, and I assume
no responsibility if you break something.  In my experience, I've
never caused any harm that a cold power cycle couldn't fix, YMMV.
Good luck,

Alex