Lenovo V330 - 15ikb

[Sniki]

Probably not, but you could try.



Test your USB-C->USB3 adapter in Windows.

@RehabMan you were correct, the adapter is only 2.0 i guess, same behavior on Windows, everything connected to the USB-C Ports via the USB to USBC adapter works as 2.0 device. (2.0 speeds).
I'll have to find a device that is USB-C port directly, like a USB-C Flash Drive or something in order to detect the Faster Speed ports on SSDT-UIAC.

I also got a bios update which fixed my Volume buttons that sometimes acted like they were stuck as pressed.
Wonder if that update fixed the problem with the EC not loading, as i had to go back and test USB-C Ports on Windows.
I`ll have to check after i install macOS, as i ordered the NVME SSD which i expect to get it in two weeks or three and will be stayed in Windows for some days as i have some stuff to do.

@Sniki Can you upload your Clover folder? I have some performance problem may it can solve it.

I will post the files for you during the week as i don't have my other laptop here, and my files are saved on iCloud Drive for now.

 

[Sniki]

@RehabMan i did reinstall macOS High Sierra 10.13.5 from scratch as i had my USB ready with it.

Like we previously talked i have an issue where APPLEACPIEC is not loading under EC0 but on boot-ec.
I did try to add "Linux" emulation on SSDT-XOSI.dsl but still same result, added SSDT-LPC, added SMBUS just to check if somehow it could be related to that but still won't load. (i can remove LPC & SMBUS SSDTs later if they are unnecessary/cause trouble as i added them just for testing purpose)

What i did though is that i added SSDT-RMDT and installed ACPIDebug.kext and collected logs, there are some errors related to that which hopefully you could help me identify where the issue is that it isn't loading, also if you find another error that needs to be fixed other than the EC0 not loading id like to know.

Also after the bios Update, it seems that the SSDT-12 (PTIDevc) seems to have changed a lot.
can you check if that the code for fan rpm is hopefully added there or it's still unimplemented.

Here i attached my PR files from script (pressed F4/F2 before boot).

 

[RehabMan]

Like we previously talked i have an issue where APPLEACPIEC is not loading under EC0 but on boot-ec.

It is normal.

Also after the bios Update, it seems that the SSDT-12 (PTIDevc) seems to have changed a lot.
can you check if that the code for fan rpm is hopefully added there or it's still unimplemented.

Look at OSDD, you find:

                        Store (\_SB.PCI0.LPCB.H_EC.ECRD (RefOf (\_SB.PCI0.LPCB.H_EC.PENV)), Index (OSD2, Zero))

So maybe H_EC.PENV is interesting... But it is not defined anywhere:

NUC6i7KYK:origin rehabman$ grep PENV *.dsl
SSDT-12-PtidDevc.dsl:    External (_SB_.PCI0.LPCB.H_EC.PENV, UnknownObj)    // (from opcode)
SSDT-12-PtidDevc.dsl:                        Store (\_SB.PCI0.LPCB.H_EC.ECRD (RefOf (\_SB.PCI0.LPCB.H_EC.PENV)), Index (OSD2, Zero))
SSDT-12-PtidDevc.dsl:                    Store (\_SB.PCI0.LPCB.H_EC.ECRD (RefOf (\_SB.PCI0.LPCB.H_EC.PENV)), Index (OSD1, Zero))

I suspect the entire H_EC is defined by the Windows ACPI host, therefore not functional on other systems.

 

[Sniki]

It is normal

Ok so as you say, i should ignore it and continue with the rest as that shouldn't be an issue then, as EC0 is not loaded but AppleACPIEC is loaded on boot-ec instead.

Look at OSDD, you find:
So maybe H_EC.PENV is interesting... But it is not defined anywhere:
I suspect the entire H_EC is defined by the Windows ACPI host, therefore not functional on other systems.

Ok so is it possible to dump that somehow on Windows, the read and write register should be easy to grab on windows with RW-everything and NFC but the point is to get a formula as the read & write registers on my laptops seems to always be 8-bit offsets.

Also about the new method of graphics configuration with config.plist /Devices/Properties changes that vit9696 & headkaze did, do you think we should move into that or we will keep patching as we usually did.

I did install latest WhateverGreen.kext & Lilu.kext after building them from source but i didn't do the Devices/Properties configuration, i still keep the KextstoPatch & AddProperties.

I did modify the HDMI Port patch that is present on your config_620_....plist by analyzing the IntelKBLFramebuffer.kext binary file and now HDMI & VGA Port are working both excellent, im on 10.13.6 and i have no need for EDID Patching:
HDMI works fine, no cursor lag, no panic on unplug, no blurry graphics on internal display in some shadows like login screen.
VGA Port detects the connection automatically, doesnt panic on unplug, no blurry graphics, no issue.

Im wondering if this is due to framebuffer patching that i did or the new WhateverGreen & Lilu.

 

[RehabMan]

Ok so as you say, i should ignore it and continue with the rest as that shouldn't be an issue then, as EC0 is not loaded but AppleACPIEC is loaded on boot-ec instead.

Yes.

Ok so is it possible to dump that somehow on Windows, the read and write register should be easy to grab on windows with RW-everything and NFC but the point is to get a formula as the read & write registers on my laptops seems to always be 8-bit offsets.

You might look at other open source fan control/fan status apps on Windows for clues.

Also about the new method of graphics configuration with config.plist /Devices/Properties changes that vit9696 & headkaze did, do you think we should move into that or we will keep patching as we usually did.

For the new WhateverGreen properties, I would use config.plist/Devices/AddProperties, not Devices/Properties.

 

[Sniki]

@RehabMan
not sure if it has to do with the new WhateverGreen & Lilu changes (i mean about having no need for patched EDID on 10.13.6 Skylake+), but one thing i know for sure, is that with this patch that i made after analyzing AppleIntelKBLGraphics.kext binary file on HexFiend and some information that i gathered on the documentations available on the forums, i have a working HDMI & VGA, without glitches, without panics on cable unplug, without laggy cursor & without black screen on wake.
disabling the patch i have no HDMI output & kernel panic after unplugging the cable (same with VGA).

Previously, from the patches that are present on your config.plist for 620 Graphics, i had working HDMI with 0105 instead of 0204 kextpatch.

But i needed to have patched EDID to have no Laggy Cursor when i connected HDMI cable & to not have kernel panics/instant reboot when detaching the HDMI cable.
VGA did also work with this patch but no matter with EDID patched or not, i had kernel panics & had to press detect display to get output on the screen.

After i modified the patch i have working HDMI & VGA without any issue (even VGA is being detected automatically like HDMI, no need to press detect display), also it doesn't crash on VGA Cable unplug either & i have no patched EDID or custom display override at all.

Here is my modified patch:

Comment: 0x591b0000, HDMI-Audio & VGA by Sniki
Name: com.apple.driver.AppleIntelKBLGraphicsFramebuffer
Find: 02040A00 00080000 87010000 03060A00 00040000 87010000 FF000000 01000000 20000000
Replace: 01050A00 00080000 87010000 02040A00 00080000 87010000 03060A00 00010000 87010000

Again like i said above, im still not sure if the need for patched EDID has been solved on WhateverGreen & Lilu or due to my patch, but one thing is for sure, with this patch i have all working outputs working like charm.

 

[RehabMan]

@RehabMan
not sure if it has to do with the new WhateverGreen & Lilu changes (i mean about having no need for patched EDID on 10.13.6 Skylake+), but one thing i know for sure, is that with this patch that i made after analyzing AppleIntelKBLGraphics.kext binary file on HexFiend and some information that i gathered on the documentations available on the forums, i have a working HDMI & VGA, without glitches, without panics on cable unplug, without laggy cursor & without black screen on wake.
disabling the patch i have no HDMI output & kernel panic after unplugging the cable (same with VGA).

Previously, from the patches that are present on your config.plist for 620 Graphics, i had working HDMI with 0105 instead of 0204 kextpatch.

But i needed to have patched EDID to have no Laggy Cursor when i connected HDMI cable & to not have kernel panics/instant reboot when detaching the HDMI cable.
VGA did also work with this patch but no matter with EDID patched or not, i had kernel panics & had to press detect display to get output on the screen.

After i modified the patch i have working HDMI & VGA without any issue (even VGA is being detected automatically like HDMI, no need to press detect display), also it doesn't crash on VGA Cable unplug either & i have no patched EDID or custom display override at all.

Here is my modified patch:

Comment: 0x591b0000, HDMI-Audio & VGA by Sniki
Name: com.apple.driver.AppleIntelKBLGraphicsFramebuffer
Find: 02040A00 00080000 87010000 03060A00 00040000 87010000 FF000000 01000000 20000000
Replace: 01050A00 00080000 87010000 02040A00 00080000 87010000 03060A00 00010000 87010000

Again like i said above, im still not sure if the need for patched EDID has been solved on WhateverGreen & Lilu or due to my patch, but one thing is for sure, with this patch i have all working outputs working like charm.

The patch you mention adds the 0105 port (as HDMI), and changes 0204 to HDMI, 0306 to VGA.
Best to look into doing the same patch with WhateverGreen.kext mechanisms.

 

[Sniki]

@RehabMan i noticed that Hackintosh scene had some major changes on preparation for macOS Mojave public release,
so i wanted to have some questions/clarifications/suggestions related to this.

VirtualSMC - i see that this kext got a lot of attention recently, although i don't much knowledge of what it's purpose is, i noticed some of it's features after reading the Readme of it's respective Github repo:

• Implements MMIO protocol and interrupt-based responses for compatibility with modern OS
• Properly reports key attributes and r/w protection in the keys
• Allows tuning on per-model basis and allows to use different SMC generations
• Extensible by the plugins for sensor and key addition support
• Enables smcdebug=XX boot argument support on 10.9
• Replaces hardware SMC it finds (to disable SMC entirely you need to flash a dedicated firmware)

So my questions related to this kext are:
Does this mean it will be possible to have a easier time dumping data, code for Battery Status patch (see which offsets are needed to be patched), also will this give us the possibility to dump code for like FanRPM reading & other sensors ?

What will be the other benefits switching to this kext.

WhateverGreen - i noticed you did a decent amount of changes on your beta branch of OSX-Laptop-Clover-Config.
Regarding Audio patching, i was curious to know: do we need SSDT-HDEF to have audio or we can have it with Device/Properties ? (Hda=gfx & LayoutID).

Last attempt which i think was macOS Mojave Public Beta 4-5 and WhateverGreen.kext was on earlier stages of development.
I had issues with output (HDMI,VGA,HDMI-Audio).

Previous versions of macOS High Sierra (10.13.5 and below) we had issues with Black Screen,Laggy Cursor, Flickering & Kernel Panic on HDMI cable Unplug scenario so to avoid it we needed to patch EDID.

On 10.13.6 High Sierra, that issue seems to have been resolved and i had perfect working Video & Audio Outputs with this Framebuffer patch that i created after analyzing the framebuffer on HexFiend.

My perfect patch for High Sierra 10.13.6 was:

Comment: 0x591b0000, HDMI-Audio & VGA by Sniki
Name: com.apple.driver.AppleIntelKBLGraphicsFramebuffer
Find: 02040A00 00080000 87010000 03060A00 00040000 87010000 FF000000 01000000 20000000
Replace: 01050A00 00080000 87010000 02040A00 00080000 87010000 03060A00 00010000 87010000

With this patch i had perfect HDMI & HDMI Audio (no laggy cursor when HDMI tv/display connected, no flickering on Internal Display, no Kernel Panic on HDMI cable Unplug).

Also i had perfect working VGA Port, No lag, no kernel panic, automatic detection like HDMI whenever i connected the VGA cable (no need for sysprefs>displays> detect display.

So im curious to know how do i implement this patch on WhateverGreen.kext, i saw the alldata feature you added to the kext.
But i still didn't have time to study the patching process that much.

Im happy that the hackintosh development is going the way i always prefered, less kexts, less SSDTs, most of the stuff on config.plist.

Also im curious about Discrete GPU, it's said that WhateverGreen.kext can turn it off, but how much effective is that feature compared to the way we previously used to disable GPU via ACPI ?

Aside from these things changes, i have a perfect setup with this laptop (only FingerPrint Reader & DGPU that have no support). everything else works perfect including the Card Reader that works OOB.

 

[RehabMan]

@RehabMan i noticed that Hackintosh scene had some major changes on preparation for macOS Mojave public release,
so i wanted to have some questions/clarifications/suggestions related to this.

VirtualSMC - i see that this kext got a lot of attention recently, although i don't much knowledge of what it's purpose is, i noticed some of it's features after reading the Readme of it's respective Github repo:

• Implements MMIO protocol and interrupt-based responses for compatibility with modern OS
• Properly reports key attributes and r/w protection in the keys
• Allows tuning on per-model basis and allows to use different SMC generations
• Extensible by the plugins for sensor and key addition support
• Enables smcdebug=XX boot argument support on 10.9
• Replaces hardware SMC it finds (to disable SMC entirely you need to flash a dedicated firmware)

So my questions related to this kext are:
Does this mean it will be possible to have a easier time dumping data, code for Battery Status patch (see which offsets are needed to be patched), also will this give us the possibility to dump code for like FanRPM reading & other sensors ?

What will be the other benefits switching to this kext.

WhateverGreen - i noticed you did a decent amount of changes on your beta branch of OSX-Laptop-Clover-Config.
Regarding Audio patching, i was curious to know: do we need SSDT-HDEF to have audio or we can have it with Device/Properties ? (Hda=gfx & LayoutID).

Last attempt which i think was macOS Mojave Public Beta 4-5 and WhateverGreen.kext was on earlier stages of development.
I had issues with output (HDMI,VGA,HDMI-Audio).

Previous versions of macOS High Sierra (10.13.5 and below) we had issues with Black Screen,Laggy Cursor, Flickering & Kernel Panic on HDMI cable Unplug scenario so to avoid it we needed to patch EDID.

On 10.13.6 High Sierra, that issue seems to have been resolved and i had perfect working Video & Audio Outputs with this Framebuffer patch that i created after analyzing the framebuffer on HexFiend.

My perfect patch for High Sierra 10.13.6 was:

Comment: 0x591b0000, HDMI-Audio & VGA by Sniki
Name: com.apple.driver.AppleIntelKBLGraphicsFramebuffer
Find: 02040A00 00080000 87010000 03060A00 00040000 87010000 FF000000 01000000 20000000
Replace: 01050A00 00080000 87010000 02040A00 00080000 87010000 03060A00 00010000 87010000

With this patch i had perfect HDMI & HDMI Audio (no laggy cursor when HDMI tv/display connected, no flickering on Internal Display, no Kernel Panic on HDMI cable Unplug).

Also i had perfect working VGA Port, No lag, no kernel panic, automatic detection like HDMI whenever i connected the VGA cable (no need for sysprefs>displays> detect display.

So im curious to know how do i implement this patch on WhateverGreen.kext, i saw the alldata feature you added to the kext.
But i still didn't have time to study the patching process that much.

Im happy that the hackintosh development is going the way i always prefered, less kexts, less SSDTs, most of the stuff on config.plist.

Also im curious about Discrete GPU, it's said that WhateverGreen.kext can turn it off, but how much effective is that feature compared to the way we previously used to disable GPU via ACPI ?

Aside from these things changes, i have a perfect setup with this laptop (only FingerPrint Reader & DGPU that have no support). everything else works perfect including the Card Reader that works OOB.

VirtualSMC.kext is a replacement for FakeSMC.kext. But it is new, so not a lot of sensor plugins written for it yet (there is one for CPU sensors). You can use SMCBattteryManager.kext with it, and it will enable battery status via AppleSmartBatteryManager.kext by what appears to be simulation of the SMC battery registers via ACPI battery methods. So, you still need to patch ACPI for battery status. I've tried VirtualSMC on a few different machines (including experimenting with SMCBatteryManager.kext) and it seems to work, but I'm not prepared to adjust all the guides to use it.

WhateverGreen.kext replaces IntelGraphicsFixup.kext, CoreDisplayFixup.kext, Shiki.kext, FakePCIID_Intel_HD_Graphics.kext and allows patching of the framebuffer (ig-platform-id data) using injected properties instead of KextsToPatch. And since the SKL/KBL/CFL kexts deal with the ig-platform table data a bit differently, it is the best option (as KextsToPatch cannot really deal with it anymore). And it is a bit easier, as you can specify the patching semantically instead of just binary find/replace.

You can still use SSDT-HDEF/SSDT-HDAU/SSDT-IGPU/etc to inject audio layout, ig-platform-id, etc.
Or you can inject those items with config.plist/Devices/Properties (and in some cases Devices/Arbitrary, or Devices/AddProperties).

For your patch (which appears to just trade the 0306 port for 0105, the 0306 data you have at the end will be ignored due to portcount in that ig-platform-id being only 3, not 4), there are several ways to do it...
1. direct replacement
framebuffer-con1-data <01050A00 00080000 87010000 02040A00 00080000 87010000 03060A00 00010000 87010000>

2. patch just con2 where the 0306 port is
framebuffer-con2-data <01050A00 00080000 87010000>

3. use semantic patching to change the 0306 to 0105/HDMI
framebuffer-con2-index = 1
framebuffer-con2-busid = 5
framebuffer-con2-type = <00080000>

I haven't looked at any facilities WhateverGreen.kext might have to disable a discrete GPU. My guess is that it won't do what you think it might do. I only see a flag related to egpu, which is probably not helpful for the laptop internal discrete/switched GPU.

 

[the-braveknight]

I haven't looked at any facilities WhateverGreen.kext might have to disable a discrete GPU. My guess is that it won't do what you think it might do. I only see a flag related to egpu, which is probably not helpful for the laptop internal discrete/switched GPU.

I tried looking at WhateverGreen.kext code for that option but couldn’t find or understand anything. However, it does seem to be disabling the Nvidia switched graphics card, just like calling the relevant _OFF method.