Fwd: dc7900 Mountain Lion instructions

[mosslack]

I'm pressed for time at the moment, can anyone help this person?

Begin forwarded message:

From: Andy Le <andy...@gmail.com>

Subject: dc7900 Mountain Lion instructions

Date: February 5, 2013 5:31:17 PM EST

To: hackin...@zoho.com

Hello!

First, thanks so much for the guide! It was very well done and easy to follow.

My problem however is that after I get ML to install, I followed your MultiBeast steps for the DSDT file. After installing that using MultiBeast 4.6.1 my mouse and keyboard no longer work!

What exactly does the DSDT file do? I seem to have everything working besides the video card (resolution stuck at 1024x768). Any help on this? Mine is a stock dc7900 with GMA 4500 I believe.

Thanks so much!

--
  Andy Le

From the main system of mosslack...

______________________________

Alt-OS <+> GG <+> TBIE <+> Hack List

[pete...@cruzio.com]

>> What exactly does the DSDT file do? I seem to have everything working
>> besides the video card (resolution stuck at 1024x768). Any help on this?
>> Mine is a stock dc7900 with GMA 4500 I believe.

A DSDT is specific to a particular motherboard and its BIOS. When a
product's BIOS "rolls" (i.e., changes version) the DSDT sometimes also
"rolls".

The motherboard, and its chip set, define what devices are physically
possible. Sort of like the "universe".

The BIOS provides gross control over those devices, such as selecting ACHI
over IDE mode, for block devices such as disk drives. In most cases, ACHI
is required (but in some cases, such as a DC7800, ACHI is not an option,
so a kernel extension is required).

The DSDT provides specific control over those devices, often including
device renaming. Sort of like the "Sol planetary system".

The OS itself, is designed for a very wide variety of implementations.

Using a combination of kernel extensions, DSDT device definitions and BIOS
controls, a physical system may be made to appear to the OS as close as
possible to a Mac. Sort of like "Earth", vs. "Mars".

In some cases, the underlying hardware is much more flexible than the OS.
In this case, it is occasionally necessary to add additional code to the
DSDT.

One specific example is the USB 3.0 ports on 7-Series mobos.

Under OS X, a DSDT change is required just to make these ports usable as
USB 3.0 at all.

Additionally, in order to make these same ports usable as USB 2.0/1.1
ports, considerable additional changes are needed as the XHC ports, which
are basically USB 3.0, only, must be "multiplexed" into the EHC ports,
which are basically USB 2.0/1.1. only, so as to use these at the USB
2.0/1.1 rate, for otherwise, the USB 3.0 ports are usable ONLY as USB 3.0
ports and the USB 2.0/1.1 ports are usable ONLY as USB 2.0/1.1.

The DSDT provides this "multiplexing", by identifying cases where a USB
3.0 (or a USB 2.0/1.1) devices are connected, and then "on the fly"
changing which DSDT devices (XCH or EHC) will actually control those
external devices.

This is perhaps the most complicated example which has yet been defined,
and one which is emerging and is, currently, usable only in a restricted
set of cases.

In most cases, the DSDT is simply modified to add certain logical device
properties to a physical device. These logical device properties are
necessary to be added so that OS X will see the devices as its own native
devices.

In some cases, the DSDT has to get down to the very basics, such as
telling OS X precisely how much RAM a system has, although with modern
boot loaders, these basics may be covered by device injection.