Jump to content
3338 posts in this topic

Recommended Posts

For me releases of OC 0.8.* Big Sur and Monterey iterations have always worked extremely well when used in conjunction with recent Intel platforms for which Apple has not dropped support, ie Haswell, Skylake as well as Comet Lake based platforms.

 

Older hardware is not in use in my environment therefore I am not qualified to pass judgment on that.

 

At this stage Ventura is however a completely different kettle of fish. I treat Ventura as I would treat a newly born infant in a maternity ward, placing all my trust into the qualified staff of that institution to do everything possible to ensure that that infant will eventually grow and mature into a healthy human being.

 

Without any qualification, I also afford that same trust to the developers of OC knowing, that with time and dedication, as well  as patience on our part, success will finally be achieved for the benefit of all OC users, also knowing that the "baby" called "Ventura" may or may not still undergo considerable "personality changes" whilst growing and maturing. 

 

Just my 2 cents worth.

 

Greetings Henties

 

 

 

Edited by Henties
  • Like 3
  • Thanks 1
  • Haha 1

Thank you for your wonderful development.

 

The kernel prelink problem seems to be difficult.


I waited a bit and then felt like applying DB3.


My Fliseserver has an SSD image of DB2 so it's easy to write it back.


I would like to test it if I get any notice.

 

I look forward to working with you.

 

Thank you.

2 hours ago, PMheart said:

Green screen is indeed a problem which I heard from users, while I have no idea...

 

But now thanks! Where may I find your patch?


Not exactly the implementation I was aiming for code-wise. Exhausted all possible attempts to try and drop just the relevant value from the array object without having to drop the entire property, even tried referencing and applying other patching approaches implemented across WEG but all workflows failed. For someone with limited proficiency in C++ this is expected, hence did not bother submitting a PR as well; to Acidanthera my attempts will probably look laughable 😅

Edited by aben
Guest ricoc90
2 hours ago, 5T33Z0 said:

@eSaF How did you make the GPU appear to be "Internal"? Side-note:  framebuffer-patch-enable is only required when driving a display, not when using an empty framebuffer.


Remove AAPL,slot-name from both the iGPU and dGPU.
iGPU properties:
DP.png.21a45def62a6ba37a560840476151f3b.png

device-id is just cosmetic (to have it show up as uhd 630 rather than "KBL Unknown" and platform-id is a non-headless framebuffer to allow GPU history to actually monitor the iGPU usage (both thanks to @FirstTimeCustomac)

dGPU properties:
image.png.2a382223859304e2ff9c58ad1577e432.png

Edited by ricoc90
19 minutes ago, aben said:


Here you go: https://github.com/abenraj/WhateverGreen/tree/SKL-HEVC-test

 

Not exactly the implementation I was aiming for code-wise. Exhausted all possible attempts to try and drop just the relevant value from the array object without having to drop the entire property, even tried referencing and applying other patching approaches implemented across WEG but all workflows failed. For someone with limited proficiency in C++ this is expected, hence did not bother submitting a PR as well; to Acidanthera my attempts will probably look laughable 😅

I saw it myself hours ago, thanks anyway. :) 

 

Do we need to remove IOGVAHEVCDecodeCapabilities? Is it confirmed to work?

 

And I saw another branch where it failed, but you removed it I guess? What were you attempting to do there? I could help write the correct code.

EDIT - Found it in my browser history: https://github.com/abenraj/WhateverGreen/commit/6388b5750f99887598f868493f00c0cb3fde9531

What I guessed was that you wanted to remove `VTSupportedProfileArray` under `IOGVAHEVCDecodeCapabilities`, while keeping the array `IOGVAHEVCDecodeCapabilities` itself; but you failed to write the correct code for that. Did I get it correctly?

 

15 minutes ago, antuneddu said:

Done !!! 

1242753808_Screenshot2022-07-07alle14_03

If necessary, download the update again ... thanks Devs 💪

Lilu-1.6.1-RELEASE.zip 772.47 kB · 6 downloads OpenCore-0.8.3-RELEASE.zip 5.57 MB · 5 downloads

While I do not like the idea of redistribution (again), please at least state from which commits the files are...

Edited by PMheart
15 minutes ago, PMheart said:

I saw it myself hours ago, thanks anyway. :) 

 

Do we need to remove IOGVAHEVCDecodeCapabilities? Is it confirmed to work?

 

And I saw another branch where it failed, but you removed it I guess? What were you attempting to do there? I could help write the correct code.

EDIT - Found it in my browser history: https://github.com/abenraj/WhateverGreen/commit/6388b5750f99887598f868493f00c0cb3fde9531

What I guessed was that you wanted to remove `VTSupportedProfileArray` under `IOGVAHEVCDecodeCapabilities`, while keeping the array `IOGVAHEVCDecodeCapabilities` itself; but you failed to write the correct code for that. Did I get it correctly?

 

While I do not like the idea of redistribution (again), please at least state from which commits the files are...

I'm sorry if it's not so I thought I was doing a good thing by redistributing, I wanted to facilitate others

 

https://github.com/acidanthera/OpenCorePkg/commit/f3cd35a957bb9c73aa0b1807fb2fde553296389f OC 

 

https://github.com/acidanthera/Lilu/commit/9008be3761602282a542a32b68716b2b86bdb1a1  Lilu

 

  • Like 8
13 minutes ago, PMheart said:

EDIT - Found it in my browser history: https://github.com/abenraj/WhateverGreen/commit/6388b5750f99887598f868493f00c0cb3fde9531

What I guessed was that you wanted to remove `VTSupportedProfileArray` under `IOGVAHEVCDecodeCapabilities`, while keeping the array `IOGVAHEVCDecodeCapabilities` itself; but you failed to write the correct code for that. Did I get it correctly? 


You are indeed correct :) More specifically I was aiming to drop the value "2" under "VTSupportedProfileArray" (most likely a reference to profile 2 that's not present on SKL kexts). Just dropping this value fixes the playback issue.

33 minutes ago, antuneddu said:

Done !!! 

1242753808_Screenshot2022-07-07alle14_03

If necessary, download the update again ... thanks Devs 💪

Lilu-1.6.1-RELEASE.zip 772.47 kB · 16 downloads OpenCore-0.8.3-RELEASE.zip 5.57 MB · 15 downloads

 

Nice, thanks! It's now finally installing Beta 3.. 8 mins left :D

  • Like 3
10 minutes ago, aben said:


You are indeed correct :) More specifically I was aiming to drop the value "2" under "VTSupportedProfileArray" (most likely a reference to profile 2 that's not present on SKL kexts). Just dropping this value fixes the playback issue.

Thanks for letting me know; I will handle it.

  • Like 5

Finally!!! installed on my little Alder Lake 

 

705405461_Capturadepantalla2022-07-07alas14_48_03.thumb.png.c701109cf8bd8db6879d6e96431693eb.png

 

:drool:

 

Now I have it installed on Lenovo 520s, it seems that everything is going well at the moment

 

Thank you very much to all of you who make this possible 🙇‍♂️

 

 

  • Like 6
2 hours ago, Download-Fritz said:

KernelCollections have no spec, so it was always not easy to guess what their intentions are. It looked like some container format (that had the kernel and in separate segments), but it really is much more of a composite format. When they started doing now was referencing segments that precede the Mach-O header of the inner kernel (i.e., inside a KC segment) in said inner kernel. As we treated the inner Mach-O files as separate, this causes issues (basically a negative offset from the header to reach the preceding segment). Though it's now clear, they are not separate, it is one (weird) composite image.

 

I also found the issue with Lilu. It used a deprecated marker segment over the actual segment for the inner kernel. Supposedly for backwards-compatibility of tools, Apple preserved segments that were used by the old prelinkedkernel to still somewhat work with KernelCollections. This specific marker (__PRELINK_TEXT) now broke. Fixes are queued but untested.

Excellent points, thank you for the insight and analysis.  And yes, macOS isn't documented, especially at the start of kernel loading.  So kudos to the OC developers for documenting the undocumented and beginning development on a fix. 

 

Also, Apple added a new lockdown mode to Ventura, I wonder how or if that affects things?  Thank you so much for responding to me.

Edited by dehjomz
  • Like 2
  • Thanks 1

@eSaF

I wold change in your config.plist:

  • AAPL,ig-platform-id from 0300983E to 0300913E
  • device-id ok (device_type and model not needed, included in device-id)
  • framebuffer-patch-enable removed (not needed on headless mode)
  • enable-metal and igfxfw ok
  • added igfxonln=01000000
  • RX580 code not needed, only if you like to see it in System Profiler >> PCI devices list.

 

  • Like 4
1 hour ago, antuneddu said:

Done !!! 

1242753808_Screenshot2022-07-07alle14_03

If necessary, download the update again ... thanks Devs 💪

Lilu-1.6.1-RELEASE.zip 772.47 kB · 49 downloads OpenCore-0.8.3-RELEASE.zip 5.57 MB · 43 downloads

Superb!!
339063530__2022-07-07_22_43_23.thumb.jpg.d77a971677cf91b3592f8037a1554de3.jpg

 

Of course, both Big Sur and Monterey were able to boot!

Edited by MifJpnAlphaPlus
  • Like 6

For the first time, my iHack has decided to give me grief. Ventura B3 install fails with the following message: "No port micro restart (we don't support SMC on this platform)". Then it gracefully shuts down all processes and restarts the system. Using OC 0.8.3, Lilu, VirtualSMC and SMCProcessor (unrelated: AppleALC, IntelMausi, WhateverGreen) kexts, all loaded from yesterday's (July 6 2022) build. Monterey boots just fine. Ventura B1 install boots just fine (using it to type this).

 

Guess I'll wait a little longer before I attempt to recover my iHackPro Skylake based...

 

Also, page 69. Noice! 🤣

Edited by Alex HQuest
  • Thanks 1
  • Haha 1

Welcome to the waiting club, this time I'm in my corner waiting for a solution to our collective problem named macOS Ventura... LOL

But I think the wait ended, the success story of @antuneddu, and others gives me hope...

Long time no see @Alex HQuest, I hope you are well and kicking, LOL

 

  • Like 2
  • Thanks 1
  • Haha 1
Guest 5T33Z0

Installed 13.0 Beta (22A5295h) successfully.

 

OpenCore build used: https://github.com/acidanthera/OpenCorePkg/actions/runs/2629783019

Lilu Version used: https://github.com/acidanthera/Lilu/actions/runs/2629842954

 

Pre-Requisites:  disable SecurebootModel for Installation. Otherwise the installer crashes

 

1280742158_Bildschirmfoto2022-07-07um16_37_04.png.e57d7abf0dccce6d563b2ca9e8b2637f.png

 

Programs Folder is working fine in Dock now. "Utilities" Folder is shown as well.

Edited by 5T33Z0
5 hours ago, aben said:

SKL users on Ventura may choose to test below attached WEG 1.6.1 SOLELY for testing HEVC related issues or as a temporary solution while waiting for official support from Acidanthera members. CC

thanks for developing

does that fix also issues visible in AppStore/Arcade 

Bildschirmfoto 2022-07-07 um 16.59.17.png

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