Lenovo V330 - 15ikb

[Sniki]

Strange that connector-type is not changed to HDMI in either ioreg.
You might try without FakePCIID_Intel_HDMI_Audio.kext and might try patched AppleHDA instead of AppleALC.kext.

That's the weirdest part, even removing the -igfxnohdmi flag and still shows as 04 instead of 08 on ioreg when i look at connector type.

The reason why i added FakePCIID_Intel_HDMI_Audio.kext is because only after i add it, the Intel HDMI Audio device appears on DPCI Manager, without it i only see the conexant Cx20751 codec (which made me assume that i need it).

I had similar result even with my Injector kext that i build from your script & which i always use but wanted to try AppleALC to see if somehow this issue might be related to it.

Will test with my Injector kext and by removing FakePCIID_Intel_HDMI_Audio.kext and see if something changes but i do believe that it should be something more on the WhateverGreen.kext since it keeps using DP instead of HDMI even though patches are ok.

 

[RehabMan]

That's the weirdest part, even removing the -igfxnohdmi flag and still shows as 04 instead of 08 on ioreg when i look at connector type.

Probably the code in the kext is forcing it back to DP.
You could try other ig-platform-id values to see if the behavior is different.

The reason why i added FakePCIID_Intel_HDMI_Audio.kext is because only after i add it, the Intel HDMI Audio device appears on DPCI Manager, without it i only see the conexant Cx20751 codec (which made me assume that i need it).

Are you saying no audio without FakePCIID_Intel_HDMI_Audio.kext? (because I don't know why you'd care about DPCIManager).

I had similar result even with my Injector kext that i build from your script & which i always use but wanted to try AppleALC to see if somehow this issue might be related to it.

Yeah, my suggest was just to try both ways to implement audio, just to see...

Will test with my Injector kext and by removing FakePCIID_Intel_HDMI_Audio.kext and see if something changes but i do believe that it should be something more on the WhateverGreen.kext since it keeps using DP instead of HDMI even though patches are ok.

Make sure you test without changing the other data too (eg. no changes to -flags or -busid).

 

[Sniki]

@RehabMan - I did make a new config.plist & some cleanup on hotpatch & fresh kext re-installation.

1. HDMI-Audio is working now, i only added these Device/Properties settings as shown on the picture:

Will give a try to my Injector kext and see if it works too.

I think i need FakePCIID_Intel_HDMI_Audio.kext because normally on my other laptops, both the Audio Codec & HDMI Audio Codec appear to the Audio Devices tab as seen on the picture below, this picture is from this laptop and i have the Intel HDMI Codec listed on the picture, without FakePCIID_Intel_HDMI_Audio.kext, the Intel HDMI Codec won't show up there, only the Conexant shows up without the FakePCIID_Intel_HDMI_Audio.kext, if i install the FakePCIID_Intel_HDMI_Audio.kext, it will appear, so from this i assume that i need the kext right ?

VirtualSMC.kext: it seems that now i can't boot the laptop without the flag -vsmccomp , im not really familiar with the kext, should i make a dump or something and send a pull data to their github as i see new commit of more dump data like every two days or so ?

WhateverGreen.kext: there is definitely a bug with the reporting on IOREG, i have HDMI Audio working using my TV, but when i open IOREG the connector-type is < 00 04 00 00 > while it should be < 00 08 00 00 >, i assume that HDMI Audio wouldn't have worked if it wasn't < 00 08 00 00 > as HDMI right ?.
Should i send a bug report to Headkaze ?

Also i have a question with the framebuffer patching on WhateverGreen.kext.

Im still not sure how the con0, con1, con2 ..., count ?

Is con0 supposed to be the @Framebuffer0 and con1 the @Framebuffer1, con2 the @Framebuffer2 ?
or the counting starts from the first external port ?

Also is there any benefit if i increase VRAM to 2048 ?, i saw that there was a patch for it on FBPatcher for WhateverGreen.kext Device/Properties.

 

[RehabMan]

@RehabMan - I did make a new config.plist & some cleanup on hotpatch & fresh kext re-installation.

1. HDMI-Audio is working now, i only added these Device/Properties settings as shown on the picture:

View attachment 352376

You don't need the framebuffer-con1-type since you already set the type for 0105 to HDMI in the framebuffer-con1-data.

I think i need FakePCIID_Intel_HDMI_Audio.kext because normally on my other laptops, both the Audio Codec & HDMI Audio Codec appear to the Audio Devices tab as seen on the picture below,

No picture "below" but yeah some computers need spoofed HDA (with FakePCIID_Intel_HDMI_Audio), some don't.

VirtualSMC.kext: it seems that now i can't boot the laptop without the flag -vsmccomp

With my tests here, I didn't need that flag.

WhateverGreen.kext: there is definitely a bug with the reporting on IOREG, i have HDMI Audio working using my TV, but when i open IOREG the connector-type is < 00 04 00 00 > while it should be < 00 08 00 00 >, i assume that HDMI Audio wouldn't have worked if it wasn't < 00 08 00 00 > as HDMI right ?.
Should i send a bug report to Headkaze ?

That is just the graphics kext doing that. We don't know why. Nothing to do with WhateverGreen though.

Also i have a question with the framebuffer patching on WhateverGreen.kext.

Im still not sure how the con0, con1, con2 ..., count ?

The X in framebuffer-conX-* refers to the position within the connector table (it is always a number 0-3).

Is con0 supposed to be the @Framebuffer0 and con1 the @Framebuffer1, con2 the @Framebuffer2 ?

Yes.

or the counting starts from the first external port ?

Starts at first connector, zero-based.

Also is there any benefit if i increase VRAM to 2048 ?, i saw that there was a patch for it on FBPatcher for WhateverGreen.kext Device/Properties.

Never tested it.

 

[Sniki]

You don't need the framebuffer-con1-type since you already set the type for 0105 to HDMI in the framebuffer-con1-data.

Fixed that.

With my tests here, I didn't need that flag.

Cannot boot without the flag, I wanted to ask you, do we install it on L/E as well or we only keep it on EFI/Clover/kexts/other ?
I can attach verbose boot screenshot on where it gets stuck.

VGA Port works perfect, automatic detection, no screen flickering, no black screen or kernel panic on VGA cable unplug.

HDMI - When I connect the cable to HDMI TV/Ex Display: Internal Screen sort of flickers like its 40Hz or so, cursor is laggy and if I unplug the HDMI cable the laptop internal screen will turn black and stay black, I try to connect vga or HDMI port just to see if screen shows up on the external displays, it will stay black on externals as well.

I assume we will need to patch EDID again, these symptoms do look familiar, i wonder if EDID patching works on Mojave & on this clover version ?

 

[RehabMan]

do we install it on L/E as well or we only keep it on EFI/Clover/kexts/other ?

As always, I install all kexts I need to /L/E.
My version of Clover has specific support for VirtualSMC.kext with InjectKexts=Detect (not in official Clover yet).
Make sure your drivers64UEFI is correct for VirtualSMC!

HDMI - When I connect the cable to HDMI TV/Ex Display: Internal Screen sort of flickers like its 40Hz or so, cursor is laggy and if I unplug the HDMI cable the laptop internal screen will turn black and stay black, I try to connect vga or HDMI port just to see if screen shows up on the external displays, it will stay black on externals as well.

You're using CFL kext?
Did you patch for brightness correctly.

I assume we will need to patch EDID again, these symptoms do look familiar, i wonder if EDID patching works on Mojave & on this clover version ?

You could always try.
You will need to inject EDID via config.plist/Devices/Properties.

 

[Sniki]

As always, I install all kexts I need to /L/E.
My version of Clover has specific support for VirtualSMC.kext with InjectKexts=Detect (not in official Clover yet).
Make sure your drivers64UEFI is correct for VirtualSMC!

Is supposed to be like this ?, I did add the VirtualSmc.efi

You're using CFL kext?
Did you patch for brightness correctly.

Sorry for stupid question but what is exactly CFL kext ?, I haven't ever tested it, I have Brightness working correctly, however I will attach Problem reporting files so you can land an eye to it.

You could always try.
You will need to inject EDID via config.plist/Devices/Properties.

How is the patch supposed to be via config.plist/Devices/Properties, as it isn't documented correctly on Headkaze guide.

 

[RehabMan]

Is supposed to be like this ?, I did add the VirtualSmc.efi
View attachment 352704

As per VirtualSMC.kext README, SMCHelper-64.efi should be removed.

Sorry for stupid question but what is exactly CFL kext ?, I haven't ever tested it, I have Brightness working correctly, however I will attach Problem reporting files so you can land an eye to it.

Looks ok. You can't use CFL native, as there is not believed to be any support for your device (0x5917). So you're spoofing as 0x5916 (KabyLake), which is fine.

How is the patch supposed to be via config.plist/Devices/Properties, as it isn't documented correctly on Headkaze guide.

Search my guide plists for no-edid.

 

[Sniki]

As per VirtualSMC.kext README, SMCHelper-64.efi should be removed.

Removed the SMCHelper-64.efi from EFI/Clover/Drivers64UEFI but still same result, cannot boot without adding "-vsmccomp", here is a verbose screenshot:

Looks ok. You can't use CFL native, as there is not believed to be any support for your device (0x5917). So you're spoofing as 0x5916 (KabyLake), which is fine.

I think I should be spoofing 0x591B currently but I will give 0x5916 a try as well and see if there is a difference.

Search my guide plists for no-edid.

Couldn't find any related information to this, some hints would be appreciated.

 

[RehabMan]

Removed the SMCHelper-64.efi from EFI/Clover/Drivers64UEFI but still same result, cannot boot without adding "-vsmccomp", here is a verbose screenshot:
View attachment 352776

Reading the VirtualSMC docs, doesn't seem like a flag you need to avoid anyway.

I think I should be spoofing 0x591B currently but I will give 0x5916 a try as well and see if there is a difference.

It really doesn't matter which device-id you inject.
What matters more is the ig-platform-id you choose.

Couldn't find any related information to this, some hints would be appreciated.

Open the guide project in xcode, and search for no-edid. It will put you right at the Devices/Property entry, which gives you all you need to know (the name of the property to inject). Obviously, the data needs to be filled with your (patched) EDID.