DSDT Brightness methods - Intel 3000

http://www.tonymacx86.com/lion-laptop-support/57066-dsdt-brightness-methods-intel-3000-a.html

I'm currently trying to get brightness running properly on LVDS. For OS X to pick up the display correctly, the only addition I needed in GFX0 was the EDID. Adding PNLF gives me the brightness slider as expected. Now here's where it gets weird. On maximum, the backlight's only running at about 50% what it's capable of. 

Putting the machine to sleep and waking it up again pushes the maximum value up a touch, maybe 10%, although there is no numerical change in IODisplayParameters -> Brightness/linear-brightness. Both remain, before and after sleep, on a maximum of 0x400 and 0x710 (Arbitrary values from what I can tell).

I tried the obvious things like placing AAPL,backlight-control etc in GFX0 to no avail, so I went onto messing around with the SNBFB. Now things got interesting. The vanilla connector table is as follows:

0102 0400 1007 0000 1007 0000 
0503 0000 0200 0000 3000 0000 
0205 0000 0004 0000 0700 0000 
0304 0000 0004 0000 0900 0000
0406 0000 0004 0000 0900 0000 

Changing the 0503 (LVDS) in row 2 (Connector 1) to 0406 (HDMI I believe), allowed the backlight to run at full capacity. Great! But then things got ****ty. I lost the ability to control brightness as well as bringing the display back from sleep (machine woke fine, just not the display). I did however gain rotation support, meaning the frame buffer was interacting with the DSDT correctly and treating it as an external monitor. So I gave up looking for answers here, in one way a good thing since it's one less patched kext I have to deal with.

I went on to experimenting with the brightness methods where the display is supposedly connected (DD02). I spent a few hours tinkering with them, mainly BCM since that's where the problem should lie, but it didn't seem like anything I did was changing anything. So I did something drastic and set all brightness levels to 0. If these methods were indeed interacting with the display correctly, after boot I should have lost backlighting altogether. Surprise surprise, jack all happened. In fact, deleting these methods completely had no effect on the original problem whatsoever. Maximum brightness was still only about 50% in reality and the slider's rate of change was still perfectly linear, despite all the increments being set to 0x00.

So here's my question to you. Where the hell is OS X getting its level values from and why doesn't messing around with BCM, BQC and BCL change a single thing?

Hmmmm... OS X also doesn't seem to be reading the panel address correctly, or at all for that matter. Windows says it's at 0x00000400 but OS X has no record of anything being connected there.

http://www.tonymacx86.com/lion-laptop-support/35084-samsung-series-7-slate-tablet-75-complete-10-7-4-a-51.html#post365647

Ok, so I've found the portion which makes the framebuffer in MAD's original post achieve maximum brightness. After decompiling the vanilla AISNBGFB.kext and comparing it to the one in the package in the first post, this is what I found. The differences are highlighted in red:

The vanilla connector table:

0102 0400 1007 0000 1007 0000 
0503 0000 0200 0000 3000 0000 
0205 0000 0004 0000 0700 0000 
0304 0000 0004 0000 0900 0000
0406 0000 0004 0000 0900 0000 

The modified connector table:

0102 0300 1007 0000 1007 0000 
0406 0000 0004 0000 0900 0000 
0205 0000 0004 0000 0700 0000 
0304 0000 0004 0000 0900 0000
0000 0000 0000 0000 0000 0000

As you can see, row 5 (or the 4th connector) has be prioritised in the modified FB and the number of connections have been reduced to 3 (given by the 0300). I tested each possible combination that would logically be the culprit in an attempt to find exactly which value triggered the response we were after. Injecting the table below into the vanilla frame buffer achieved the desired effect.

0102 0400 1007 0000 1007 0000 
0406 0000 0200 0000 3000 0000 
0205 0000 0004 0000 0700 0000 
0304 0000 0004 0000 0900 0000
0406 0000 0004 0000 0900 0000

As you can see, the third and first table are identical aside from the value '0406.' Changing what I think is the LVDS identifier (0503) to HDMI (0406) resulted in maximum brightness with rotation support, no dimming control and no wake from sleep. I believe what this value is doing is making OS X treat the internal display as an external connected over HDMI, since "built-in" goes missing in system profiler.

So what's the verdict? Well if my assumptions are right, it means the frame buffer is working and it won't need to be modified every update. The bad news is, I still have no idea how to get it working.