TimeWalker75a

Gave Sierra a quick whirl jumping from my Yosemite install. Besides the card reader not appearing as an internal device (but working nonetheless) and USB property merging not showing up due to USBMergeNub changes I had no issues, at all. Oh, the XHCI ports for FL chipset worked, but would be finicky after sleep. The reason all this is in past tense is because the SSD I had cloned the system died after a dozen restarts (HWMonitor was reporting 45% health) and wouldn't even get scanned via fsck, system just halts right away .. so I've wasted a couple hours and suffered some pain along the way. Will rinse and repeat when I've recovered ... Sent from my SM-G920F using Tapatalk

I have a busted clavicle guys, going through rehab so was not in the loop at all and still guilty of not having uploaded new files for the guide ... Sent from my SM-G920F using Tapatalk

I'm actually in the middle of mapping the keyboard the same way as above. Pretty successful with the exception of Fn+F4 as it expects an immediate sleep trigger, so repeated press of the combo does not call the ec query. Sent from my SM-G920F using Tapatalk

I am not sure if XOPT is even relevant now for the new kext, but I realize why you mention it. I was on about some other brightness however .. the one laptop boots up with on every reboot. It appears that Lenovo are doing something utterly dumb here where they boot with the backlight on the panel set to 100% brightness... and I am inclined to think this is because they evaluate _BCL at BIOS level and using _BCM to set the panel to whatever elements 0 and 1 return from the BRTW package at \_SB.PCI0.LPC.EC. Here 0 being default level when on AC power and 1 being the default for DC power. And these just happen to be 0x64. You get my drift... On DELL, the level is written to SystemIO by EC queries and is then used by BIOS on every boot. So once you can translate the IGD PWM values to match exactly with levels used by the BIOS you get a consistent backligt during cold/soft boots. What this means is that regardless of the level IntelBacklight (or ACPIBacklight) has stored in nvram, BIOS would have the equivalent value and you won't have any dimming or sudden brightness jumps once either of the aforementioned kexts loads. Reading around, it seems like Lenovo never implemented something similar and just default to 100% on every boot, which just burns your retinas when you need to enter BIOS or snoop around the boot manager in the middle of the night.

I'm trying to comment the code as I go tracing things. Will make sure to post everything once I have something sensible out of it. Plenty of quirk so far compared to the DELL I'm used to.

So here's the gist. 
 Having started executing _WAK upon wake it determines waking from S3. 
 If Intel IGD graphics are in use, as determined by \VIGD, it then signals IGD that all LID devices have awoken by calling GLIS and passing the evaluation of _LID as an arg to it. Which _LID returns the value of a EC register HPLD (H = H8 = EC, P = Probe, LD = LID). This value happens to be 1 on wake, meaning internal (LFP) LID is open. GLIS notifies IGPU with 0, but it does not notify the LID device itself, an extra notification has to be issued. If you look at _Q2B, which is responsible for preparing the system for sleep when LID is closed, it calls GLIS followed by a status change notification to LID. Never happens in _WAK tough ... So add that an voila, no darwake nor HID tickle is required to wake display when you open the LID. If (LEqual (Arg0, 0x03)) { ... If (\VIGD) { \_SB.PCI0.IGPU.GLIS (\_SB.LID._LID ()) If (\WVIS) { \VBTD () } } Else { If (\WVIS) { \_SB.PCI0.IGPU.GLIS (\_SB.LID._LID ()) \VBTD () } } Notify (\_SB.LID, 0x80) // Having called IGD GLIS, signal the LID to wake \VCMS (0x01, \_SB.LID._LID ()) \AWON (0x00) For some reason for \_OS “Vista”, IGPU has to be aware LID is wake regardless… think it’s just that the Vista driver is retarded like that and does not report \VIGD to ACPI properly. Also, something tells me that _Q2A was meant to be called during wake from LID, but it's not as the firmware is rubbish and instead a cr@pton of things are done in _WAK. Next challenge, understand how in the world this thing signals EC to update brightness level for soft/cold boot as it’s clearly not doing it at present.


Thanks. While that worked, I still wonder why that flag is needed as I don't have it on my DELL and yet the LID wake works wonders. It's more like there's a notification to IGPU missing somewhere when waking up using the LID, as SLPB gets notified by LID to wake the machine up, but display driver is sitting there doing nothing until you HID tickle. Will try to debug ACPI calls to see the difference ...

Hi folks, quick question. On T420, does the screen come alive normally when you had the laptop sleeping with a LID closed and you open the LID, having no external displays connected? Here the laptop resumes from sleep when opening the LID, but the screen stays dark until you hit something on the keyboard or touchpad/trackpoint (HID tickle). Just curious if I need to hunt this down it being a common issue or this has been addressed for T420 ?

I've managed to make a typo in the flash_custom.bat .. it should be '/sa' not '/ca', as in .. skip all (checks). Should be same command set as in the Readme.

It's HERE if you feel adventurous.

Ok, here I go with my shenanigans - picked up a T420s, pretty basic config - i5-2520M, HD3000, 4Gb DDR3, Toshiba 128Gb SSD. The machine didn't have any OS on-board, so to do some basic testing I tossed original Win 7 Professional on there from recovery media. That didn't go well - laptop idled at 98C so needed a clean up, desperately. After de-dusting and re-pasting things got better, but it still easily reaches 80C with average load, while my Dell will barely climb to mid-70s. And an added bonus is that fan controller from EC tends to lock up the fan at 4K RPM, even though the temps be sitting at 44C.. Besides the fan (which I have ordered a Toshiba make replacement), so far there are only two things I dislike about this machine compared to my (also business class) Vostro - no keyboard backlight (but Thinklight is surprisingly good) and the fact that the speakers sound so darn tiny I fail to see how this can be classified as audio system at all. Moving on, having half a dozen WLAN cards around I quickly realized that none of them is compatible due to the infamous whitelist. A couple google searches and a 3 hours spent with BIOS 1.41 this morning and I have myself the latest BIOS with: - MSR_PMG_CST_CONFIG_CONTROL 0xE2 unlocked for native PM - AES-NI instruction set lock removed - RAM Speed Lock at 1333 MHz removed - Whitelist for WWAN and WLAN cards removed - Date/Time tab swapped with Advanced Setup tab - Intel VBIOS updated from 2089 to 2170 with UEFI GOP support and native res (1600x900) in Clover and boot.efi I'll post the BIOS, including details over at bios-mods with proper credits as there's still someone out there who is charging a substantial amount for each of these mods for this series of laptops. OK, that said and done, I have swapped my disk and knowing that Yosemite is less of a hassle to start with, I've settled on installing 10.10.5 first. That went nicely with the files from the pack, thanks @tluck. I'm certainly liking the high-res display and the ability to use a docking station, but there are some things I'd improve personally.

Eh, won't call it luck .. and I've been on that forum board quite frequent too if you recall. All the posts for this gen of laptops over there seems to have been taken over by some Ukrainian guy who's got himself banned due to deliberately charging for "his" work, while none of that work was his to begin with. It was rinse and repeat on a solid ground. Just had a look in the BIOS using UEFITool and it's the same kind of routine to lock down the write to 0xE2 in the same module - PowerManagement2.efi, heck even having the same GUID as on the Vostro. Reckon the other stuff won't be any different, or perhaps not that drastically different anyway. And now two worlds collide .. Perhaps diving into the off-topic, but hey .. I don't think 1.46 is something available for the slim model, it's 1.39 followed by 1.41. Any particular reason to stay on 1.46 for regular T420 besides the fact that nobody has come up with a patched 1.48? I know it says you can't go back once you upgrade, but that's only applicable to the EC firmware which you won't be messing with if you decide to go back or flash something custom.

You might as well be using some earlier version that was posted and doesn't have the latest ACPI fixed that I've included in A12C4 (Custom rev.4). I'm not like those people who put flashy text on their custom stuff, so the only way for you to tell would be to look at the ACPI method _INI in _SB.PCI0 scope. If Darwin is listed there, you have C4, otherwise you don't .. duh. Also, Media Button device should appear like this: Device (MBT) { Name (_HID, EisaId ("PNP0C32")) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { If ((OSYS >= 0x07D6)) { Return (0x0F) } Else { Return (Zero) } } Method (GHID, 0, NotSerialized) { Return (Buffer (One) { 0x02 /* . */ }) } } The easiest way is to copy your working Clover setup from ESP onto a USB flash drive formatted as FAT32, have a directory EFI/BOOT on there with CLOVERX64.EFI named as BOOTX64.EFI so you can boot any time via that option if hell breaks loose. Then once you have installed the SCT package, you can mount your ESP and check the contents of patched tables, config, drivers etc.. to have an idea of what has been installed. The platform issue you were having clearly comes from the SMBIOS being butchered up by something .. my best guess is merging your old config with the one SCT puts on ESP. Also while at it, weren't you saying that you've got one of those Fast Ethernet daughterboards, then why are you using the Gigabit option in the 'Customize' of SCT? What you are saying about the items being posted and having to rename folders concerned PRE-installation only and I think you are waaaay past that stage, so shouldn't be looking at any of these things at all. Believe it or not, ACPI is actually a language that you code things with, so tables have been fixed/adapted/created anew. The information was taken from my own experience, plenty of Intel register deciphering (i.e. for proper shutdown), also EC behavior reverse-engineering using RWE you mention. Some of it from requirements set by kext devs, like RehabMan - huge kudos. So to know how brightness is stored in EC or how the machine knows that you've plugged in the charger involved both reading the ACPI code if registers are published in ACPI, but could be I had to sit there plugging and unplugging or toggling things to see changes in the EC register map and document them .. like touchpad LED or keyboard backlight controls. A lot of the custom ACPI code is the basic necessity for OSX compatibility and then there's plenty more for workarounds on this idi0tic UEFI implementation.. I don't think I can give any kind of explanation on why things have been done they way they have as there's always a room for improvement, even at the stage these laptops are now, running Yosemite. The patches for DSDT in config are largely just patched ACPI tables that have been compared in HEX before and after tailoring the patches manually, but then extracting said differences with correct checksums to comprise the Find / Replace patterns. A lot of that involved the 'trial and error' approach. Allo, yeah long time indeed! What is that yourself have been up to lately? Not much here, been buried in work stuff due to some large projects, so had to skimp for about a year now not touching things that aren't broken .. you get me drift Picked up a Lenovo T420s about a week ago dirt cheap (shipping stuck in the border country though .. arrrgh!) as a new victim, which also has a Tiano firmware and therefore plenty of flaws. Will have to get a refresher on exercising the dark arts of BIOS modding, as the damn things comes with a WLAN whitelist, locked down AES-NI, locked MSR 0xE2, DDR speed locked at 1333 and virtually no Setup options ... bound to be fun. Coincidentally, it also has a single NEC/Renesas USB3 port which I have looked into getting support for it beyond Yosemite and though it seems like there's a way to re-brand the chip via DFU to appear as a third party device, allowing to load 3rd party vendor drivers natively, the result is far from what I would consider ideal.. so I might be just disabling XHCI altogether.

The SCT Support pack will backup all the kexts in a pre-defined list from SLE and if it finds one it will also backup config.plist and also the ACPI/patched on the ESP. It will backup your serial and RTVar data from config and will insert it's own config, preconfigured for platform selected in 'Customize' when installing the package. It will then use your serial data to put back in the config it has copied across to the ESP. If you don't have a config.plist or nothing at all on the ESP, it will generate the serial data for platform or your choice, but it won't come up with anything for RtVars... The machine you have is a typical setup that at least a dozen other people in this thread have and they had no issues following the guide from A to Z. The only kind of quirk I can see in your setup is presence of the intel card (which has semi-functional BT sitting on the USB bus) and a USB dongle for Wi-Fi. Which is not a setup supported, so getting Wi-Fi to work is up to you.

If you'd flashed the BIOS posted in the OP and used everything packaged into the SCT Support pack, you'd have all of that on Yosemite, frustration-free. No DSDT patching, no messing with kexts... nada. And you having those two kexts in your SLE just indicates that you haven't done any of that, because I have never switched to IntelBacklight prior to last weekend.