Jump to content

[pre-release] macOS Ventura


3,556 posts in this topic

Recommended Posts

4 hours ago, Hervé said:

A no brainer update on my Skylake/HD520 Latitude E7270 laptop. No change to the Clover r5148 setup, same as for beta #3. Totally kosher for me. 1.5xGB size for me, not 745MB!

 

In my case it marked 1.52Gb but it is because it also marked xcode update... when I downloaded that, it went to 754.5Mb of system update

 

2099745543_Capturadepantalla2022-07-27alas23_30_03.png.0337342ee62c69a218eac050052e2972.png

  • Like 2
Link to comment
Share on other sites

Thank you for al your support in helping me finding a solution to this ancient lcd big panel, it is working properly with full qc, the trick which did it is @aben suggestion to add these lines,  

 

framebuffer-patch-enable   DATA    01000000
framebuffer-con0-enable    DATA    01000000
framebuffer-con0-alldata   DATA    00000800 02000000 90000000


Thanks to Herv'e who found the internal display on (con0), As Aben mentioned that the sequence basically drops LVDS connector flag CNConnectorAlwaysConnected, which forces built-in displays as external. Known to have fixed certain problematic eDP connectors in the past

When added these lines, the display worked, i changed the display flag from 90000000 to 98000000 and it worked perfectly in both Monterey and Ventura.

 

Thanks to @deeveedee for raising my issue properly

I am still having problems:

1: Airplay not working at all, i have apple tv and using AirportItlwm kext, airplay is working perfectly on Monterey

2:Display never wake after sleep esp if closing the lid, it keep dimmed-black.

3:Mac os installer and recovery work just in vesa mode.

4:Can we make a small ssdt containing these display flags to for kbl spoofing that it may help other who are having troubles to solve the problem?

I want to thank you for all your support to me that solved my problem which last for about 2 months without successful booting, i was on Montery and using Ventura on vesa mode.

i will post my working efi for this model so it may help others solve their problems without changing the display to a new fhd one. i need a small ssdt for this display including the flags if that is possible,

I updated the system to beta 4 and it is working with only the above mentioned problems, wishing we will be able to find any solutions asap

 

Attached is my EFI forlder to help others in this issue.

 

Thank you so much   

SKYLAKE EFI.zip

  • Like 5
Link to comment
Share on other sites

4 hours ago, PC IT said:

Thank you for al your support in helping me finding a solution to this ancient lcd big panel, it is working properly with full qc, the trick which did it is @aben suggestion to add these lines,  

 

framebuffer-patch-enable   DATA    01000000
framebuffer-con0-enable    DATA    01000000
framebuffer-con0-alldata   DATA    00000800 02000000 90000000


As Aben mentioned that the sequence basically drops LVDS connector flag CNConnectorAlwaysConnected, which forces built-in displays as external. Known to have fixed certain problematic eDP connectors in the past

When added these lines, the display worked, i changed the display flag from 90000000 to 98000000 and it worked perfectly in both Monterey and Ventura.


Awesome! Good to know the above suggestion to patch LVDS connector flags helped solve your display issue finally. Congrats and enjoy :) 

Please note that this approach is a mere workaround to this incompatibility situation with your panel when using KBL framebuffers, and as such should not be considered a native solution for a built-in display, until a proper/more meaningful patch that addresses this issue has been implemented. It's still best recommended to upgrade panel to FHD, if possible, to achieve full proper/native functionality of LVDS panels when using macOS framebuffers untouched, otherwise you'll be forced to compromise on native LVDS features such as backlight control, lid wake/Sleep etc.

 

Also, display specifications are not defined at UEFI/ACPI level, only EDID which is accessed from EEPROM and thus not possible to deploy SSDTs for such patches, only via kernel space.

  • Like 2
Link to comment
Share on other sites

3 hours ago, SavageAUS said:

Update not showing for me on my laptop here in Australia.


Sent from my iPhone using Tapatalk

Clover?

SIP?

Other information?

  • Like 1
Link to comment
Share on other sites

Update to Beta 4 completed successfully on Skylake machine here.

 

Oh and BTW, x86PlatformPlugin continues to load natively, by default, without having to inject plugin-type=1 flag to ACPI (SSDT-PLUG), for those interested. Also, Metal 3 support is still present on Kaby Lake iGPUs as of Beta 4.

.image.png.2406c972a176d6f21149b06d471b2396.png

Edited by aben
  • Like 5
Link to comment
Share on other sites

5 minutes ago, aben said:

Update to Beta 4 completed successfully on Skylake machine here.

 

Oh and BTW, x86PlatformPlugin continues to load natively, by default, without having to inject plugin-type=1 flag to ACPI (SSDT-PLUG), for those interested. Also, Metal 3 support is still present on Kaby Lake iGPUs as of Beta 4.

.image.png.2406c972a176d6f21149b06d471b2396.png

meaning that is it ok to remove the SSDT-Plug.aml?

Link to comment
Share on other sites

Guest ricoc90
4 hours ago, SavageAUS said:

Update not showing for me on my laptop here in Australia.


Sent from my iPhone using Tapatalk


Re-enroll into the beta program

Link to comment
Share on other sites

Yesterday after trying several previous commits of OC 0.8.3, Clover, OC-Debug, with and without Fakesmc, OC- Mod ... nothing the error persisted

Spoiler

image.png.a04f98acdccc34e1ea8fa75e612c2b

 

I came up with posts about Beta3 ... I think @ricoc90  ( thx )

 

Well disabled BlueToolFixup.kext

 

... boom ! taken and updated quietly I do not know if this is the solution valid for everyone, I also notice several problems, but still to be taken into consideration

 

Spoiler

1811652667_Screenshot2022-07-28alle02_50

 

  • Like 2
Link to comment
Share on other sites

Guest ricoc90

@antuneddu Yep, BluetoolFixup alters /usr/sbin/BlueTool which makes that macOS wants to do a full replacement rather than doing an incremental patch. Booting without BlueToolFixup indeed works around that, or you can download the full installer instead.
 

 

Link to comment
Share on other sites

48 minutes ago, antuneddu said:

Strange anyway because up to DP3 it hadn't given me any problems
Thanks anyway ... solved by disabling it

I had problems with BlueToolFixup before Ventura.

Link to comment
Share on other sites

@Slice

I'm using this rig as a test bench for Ventura and I have an old R9 270X in the system which is only active on Monterey and below so yeah MacPro is a suitable SMBIOS (in regard of using the same PlatformInfo) for my tests if I use iMac18,3 the colors are messed up and only working SMBIOSes are iMac18,1, macMini8,1 and MacPro7,1 other than these settings the display settings are not working properly.

  • Like 5
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...