RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,058
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
You can see all the updates to the repo by looking at the commits on github.
Native Brightness working without 'blinkscreen' using patched AppleBacklight.kext
- Thread starter RehabMan
- Start date
- Status
You can see all the updates to the repo by looking at the commits on github.
- Joined
- May 16, 2012
- Messages
- 40
- Motherboard
- hp 6197
- CPU
- INTEL I7
- Graphics
- HD3000 AMD6770
- Mac
- Classic Mac
- Mobile Phone
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,058
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
Thanks, i saw that there are not update patch for vanilla method, all good
Well, it was updated two days ago...
But you should realize that the 'ACPI' method patches are a superset of the 'vanilla' patch. You can actually use the 'ACPI' patches, but implement the vanilla method. Or switch between them simply by adding or removing ACPIBacklight.kext. You will note that for the generic laptop repo, I didn't even bother including separate 'native' patches because the ACPI ones will work just fine for that purpose.
- Joined
- May 16, 2012
- Messages
- 40
- Motherboard
- hp 6197
- CPU
- INTEL I7
- Graphics
- HD3000 AMD6770
- Mac
- Classic Mac
- Mobile Phone
Ok, i used this the first time that i used this vanilla method you remember, https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/blob/master/13_Brightness.txt
Now this patch has been updated right? So i must patch dsdt with this new patch..
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,058
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
If you click on History, you can see the commits that affect that file: https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/commits/master/13_Brightness.txt
I would not say "must." The change made probably doesn't affect you. More like "may, if you like."
- Joined
- May 16, 2012
- Messages
- 40
- Motherboard
- hp 6197
- CPU
- INTEL I7
- Graphics
- HD3000 AMD6770
- Mac
- Classic Mac
- Mobile Phone
Understood, thanks, like always.
- Joined
- Jan 11, 2014
- Messages
- 103
- Motherboard
- Samsung NP530U3B
- CPU
- i5-2467M
- Graphics
- Intel HD 3000
- Mac
- Classic Mac
- Mobile Phone
RehabMan, if you prefer I can talk about this in a new topic.
I've continued to do some tests with the patch I applied yesterday that gave me full backlight to understand which specific part of it was the responsible. Also, I noticed that actually I do have QE/CI after the patch (translucent menu bar, shaking icons in Launchpad, ...) but my FPS in OpenGL Extensions Viewer decreased to 60 (used to be 535 with correct snb-platform-id). The graphical experience as a whole is fluid, at least.
My previous situation: display correctly detected as Built-in Display, brightness slider working, HDMI out, low backlight in built-in display.
Inside IGPU, the Method (_DSM) was:
Code:
Method (_DSM, 4, NotSerialized)
Code:
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Store (Package (0x02)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] "AAPL00,override-no-edid", [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Buffer (0x80)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0000 */ 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0008 */ 0x4C, 0xA3, 0x00, 0x02, 0xFF, 0xFF, 0xFF, 0xFF, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0010 */ 0x00, 0x15, 0x01, 0x03, 0x80, 0x1D, 0x10, 0xFF, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0018 */ 0x2F, 0x00, 0x00, 0xA0, 0x57, 0x49, 0x9B, 0x26, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0020 */ 0x10, 0x48, 0x4F, 0x00, 0x00, 0x00, 0x01, 0x01, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0028 */ 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0030 */ 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x9E, 0x1B, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0038 */ 0x56, 0x78, 0x50, 0x00, 0x18, 0x30, 0x30, 0x20, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0040 */ 0x25, 0x00, 0x25, 0xA5, 0x10, 0x00, 0x00, 0x19, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0048 */ 0x00, 0x00, 0x00, 0xFD, 0x00, 0x00, 0x3C, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0050 */ 0xD9, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0058 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0060 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0068 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0070 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] /* 0078 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xCC[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }, Local0)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Return (Local0)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }[/FONT][/COLOR]Then I ignorantly applied this patch and suddenly I had full backlight. After some reboots, I could isolate which lines were the real reason for it, so now I have two new situations.
New situation 1: display not correctly detected (spdisplays_display), no brightness slider, no HDMI out, full backlight on the display - but ONLY if HDMI cable is connected to the laptop. The image doesn't load in the HDMI device, but without the cable, the boot seems freeze at last verbose message before graphics. The moment I plug the cable, image appears.
For this, I made a mix between the code above and the linked patch, resulting this:
Code:
Method (_DSM, 4, NotSerialized)
Code:
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Store (Package (0x04)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] "AAPL,snb-platform-id", [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Buffer (0x04)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] 0x10, 0x00, 0x03, 0x00[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }, [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana]
[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] "AAPL00,override-no-edid", [/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Buffer (0x80)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] {[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] (here goes the EDID, just avoiding useless repetition)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }, Local0)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] Return (Local0)[/FONT][/COLOR]
[COLOR=#232323][FONT=Verdana] }[/FONT][/COLOR]New situation 2: it occurs when I remove the EDID part of the code. Then the display is not detected at all and the video works in the HDMI device (only).
Observations: if I remove the snb-platform-id from the DSDT, then I go back to the "previous situation" (HDMI + low backlight display). The same occurs if I replace it with the “default” one (the one I saw in every patch so far for Intel HD 3000 and laptops…): 0x00, 0x00, 0x01, 0x00
So, it seems I found a (temporary?) solution for the max brightness, but I can't stay with an useless HDMI cable connected to a portable computer forever. Any thoughts..?
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,058
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
For that case you must be injecting snb-platform-id some other way (boot loader/device-properties), I assume.
What is your native device-id? If it is 0x116, then injecting it via DSDT (or other method) is having no effect and is not necessary (helpful because you can remove it from your matrix of variables). So, in this case, perhaps the only real change is the different snb-platform-id. I think it is the standard one for a desktop (although on my desktop, I get away without injecting it at all).
What is missing from here is whether or not you're defining PNLF, which determines whether the display is treated as AppleDisplay or AppleBacklightDisplay. Obviously a display that is only AppleDisplay is not subject to changes to the backlight level (and therefore you keep your "boot" level backlight).
OK. So your screen requires EDID injection.
I think that "mistake" is inconsequential. I've run my laptop (native device-id is 0x116) on 10.9 with vanilla AppleIntelSNBGraphicsFB.kext. So... I think the lack of 0x is an anomaly but has no effect on whether iokit loads the driver or not.
When you are removing these items, are you adjusting the package size as appropriate? If not, unpredictable results occur (I think OS X may ignore the result from the _DSM entirely).
I agree that changing the snb-platform-id to a desktop one is a bad idea and not helpful for a laptop...
It would be interesting to know if your laptop display is using eDP...
Also, I think you should spend some time with ACPIBacklight, there is a lot of experimentation you could do there with the backlight controls (using 'ioio') not possible with AppleBacklight.
- Joined
- Jan 11, 2014
- Messages
- 103
- Motherboard
- Samsung NP530U3B
- CPU
- i5-2467M
- Graphics
- Intel HD 3000
- Mac
- Classic Mac
- Mobile Phone
There might be an injection coming from any of the Clover fixes, but I can't be sure about it. The only string injection I make is for App Store/iCloud fix (Ethernet). I'm attaching in this post my Clover config.plist and the system extracted DSDT in case you have any extra doubts. Currently I'm doing as suggested by a Clover developer: I've picked up the pure DSDT, applied some manual fixes to it, and then applied some extra fixes using Clover (taking care not to apply it twice).
True. During my tests I must have taken off device-id together with snb-platform-id. Now I tried only removing device-id and indeed it still works. Actually I could also put a wrong id like 0126, it has no changes.
I do have PNLF in my DSDT, you can verify in the attachments. It is also shown in ioreg (just extra verifying...)
You're probably right, now I remember that not injecting 0116 didn't cause a non-load of AppleIntelSNBGraphicsFB, but I've got a black screen anyway. I believe the real solution that time was using DualLink 0 in Clover.
Sure, I always compile before saving to see if I've left something behind. Anyway I found it's just faster to leave Package() and let MaciASL calculate the number for me.
It shouldn't be helpful but so far I don't feel it any worse and the benchmarks confirm it...
It's LVDS, already checked in Linux.
This is the hardest part as that topic is really broad and it's not easy to collect the pieces. I've done some testing with it a couple of days ago without success so in the moment I'm more motivated on trying to discover how to keep my current configuration, with the wrong snb-platform-id, without needing to connect a useless HDMI cable.
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,058
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
0126 is not wrong. It is the "other" HD3000 mobile device-id.
It could be that PNLF is ignored when you use a desktop snb-platform-id...
You should definitely never use dual-link, as your screen is 1366x768 (correct?). Dual-link is to be used only for higher resolution displays, as those displays use a different cable from the motherboard to the LVDS display (a dual-link cable).
Compiling will not check that the package size is too large. It is not an error. For example, this is valid code although not acceptable for _DSM return.
In the returned package there are 4 total entries, the last two uninitialized. OS X won't like that and the compiler will not complain. It is valid code, but not valid for _DSM.
It is just taking the "mobileness" out of the equation, so no backlight adjustment/manipulation...
Good to know.
I'm suggesting you try it and start experimenting with the different values. There is much more control with ACPIBacklight as you can use a different range of values (you don't have to stick with the 0-0x710 range as you do with AppleBacklight).
- Status