All Activity

@kaoskinkae, my friend! 🤗 I would suggest collecting proposals for additional drive icons, such as FAT, FAT32, Network, etc., which could be considered for inclusion in a future release of the drive icon package. However, an exFAT network drive would be far too user-specific for a general release. If someone really needs such an icon, it could easily be created using one of the included master templates. Since the overall impact of the package has been rather limited so far, I would only expand it further if there is clearly enough demand from the community. Cheers, KGP

@miliuco perfect

Perfect in OLD2: AppleHDA.kext + Wifi Intel OCLP (OpenCore Legacy Patcher) 😄 The blue exFAT drive is a network drive on another computer; it's a mechanical hard drive formatted as xFAT, but it only shows xFAT, not xFAT Network. I don't know if it would be possible to tell the difference.

You are very welcome.

@miliuco I was injecting the layout id in Device Properties in hexadecimal format.

@jlrycm Thanks. How do you inject the layout-id? alcid=69 in boot args or layout-id=45 in DeviceProperties? Your codec admits layouts 11, 12, 13, 21, 22, 23, 31, 66, 69, 77, 98 and 99, so 69 is okay. In the pics that you uploaded, I see the possible issue. You have this key: HDAUniversalEffectiveLayoutID = 0x45 0x45 hexadecimal is 69 in decimal, it's as it should, but it must be converted from hex to decimal. The app was looking for the layout-id in the places where AppleALC usually looks for them: layout-id and alc-layout-id. But HDAUniversalEffectiveLayoutID is the key included in the HDAUniversal block, so I'll change the layout-id source to this. And I'll add the conversion. I'll send it to you when done, to test it.

Looks amazing, thanks

@miliuco please see in the screenshots the requested information

I needed to perform some testing in macOS Catalina and made an interesting discovery: use of a Comet Lake graphics device-id (e.g., 0x9BC8) breaks the Chess and PhotoBooth apps in macOS Catalina. The crash report points to a framebuffer problem. Fortunately, simply replacing the device-id with 0x3E9B (a Coffee Lake device-id) fixes the problem without changing the frame buffer patching required for working HDMI. I am now using device-id 0x3E9B, AAPL-ig-platform-id 3ea60005 (Intel Iris Plus Graphics 645 frame buffer) and framebuffer-con0-flags 0x98 for fully working internal display and HDMI port in Catalina, Sequoia and Tahoe (the only macOS versions I've tested on this hack). The working patches that I described previously in this thread also work with device-id 0x3E9B. EDIT: With the frame buffer patching that I have described in this thread, the internal display and HDMI port work as well as or better than they do in Windows 11 (the native OS for this laptop). in macOS, the HDMI port works when the display is connected at boot and also when the display is hot-plugged after boot. I did notice that, while making frame buffer patch changes during my experiments, there were times when I needed a second reboot for patches to become fully effective. This is consistent with what I have observed in my iGPU frame buffer patching with other PCs. EDIT2: I turned to AI, because after my experiments determined the need for changing the device-id, I didn't understand why changing the device-id would "fix" Catalina. Here's an AI explanation for why changing the device-id fixes this.

@LockDown @luxinhaus getcodecid-Release.zip Source getcodecid-master-command-xcodebuild-fallback-fix.zip

This is going to be awesome, 11th gen is such a leap in performance & efficiency on notebook and 12th gen on desktop is great. I see movement on the DRM github i hope it will result in something to test for normal users https://github.com/macintelk/drm

@MaLd0n Manufacturer seems to be well identified. Feedback is very welcome. Now it's time to fix the layout-id, since it doesn't work for @jlrycm

@MaLd0n Thanks. I'll review the database. I've found where is the manufacturer in the output of the command ioreg -p IOService -r -w 0 -l -n HDAUniversalDevice It's the property "HDAUniversalEffectiveCodecID" = 283906592 283906592 is a decimal number for the hexadecimal 0x10EC1220, where 10EC corresponds to Realtek, as defined in the HCAudio.swift file of the project. So, I can extract the codec manufacturer from there. @jlrycm Please tell me the values you have in these 4 places in IOReg: /AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/HDEF@1F,3/HDAUniversalDevice IOAudioDeviceCanBeDefaults HDAUniversalEffectiveLayoutID IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/HDEF@1F,3 layout-id alc-layout-id To see if all keys have the same value or, if they are different, the keys that have your right layout-id.

18 years of life, a sad age to die

@miliucofor easy thing i created one full database audio codec audio-codecs-Release.zip Make the app always check against that database and filter the way you want. I create this for tool GlassFetch. A good idea is create one for lan too and check these databases everytime. Linux is always a good resource to consult.

Where can I find this CloverEditor?

AppleHDA RIP

AI recommended hamstring exercises

perfecto NEW: AppleHDA.kext MyKextInstaller

Well for me the installation process is now becoming the same every time I update. Everything seems to go ok and I get to my desktop and am able to move around fine. Rebooting I get that same old screen "you have been updated to Tahoe" and that's it. I'm now in the process of reinstalling via Recovery and eventually will use a Time Machine backup to restore my profile. Sigh.... Cheers(I think), Howard

@schrup21 thanks for sharing your experience. I will verify again. I usually do the same as you: disabling the kext to get the OTA updates done and enabling the kext after the OTA update is done. However, this time it did not load and after playing with the kext enabling/disabling, I came to the conclusion that something changed with this 26.5.2 update that is not allowing macOS to boot with the kext enabled. I will verify whether the firmware is still saved where it’s supposed to be. I haven’t touched the boot args or device properties defined for this kext / wifi card.

@jlrycm Anotado. I’ll check this issue.

pefecto NEW: AppleHDA + wifi

+1

@jlrycm there's no issue with BCMC on 26.5.2, it's working as it should I enabled BCMC in macOS 26.5.1. Then I initiated the update to 26.5.2. BCMC or the Wi-Fi module has to be disabled during the update process, so I disabled BCMC in the `config.plist` before the first reboot (i.e., while the macOS update was downloading). After the update was complete, I re-enabled BCMC and rebooted, and everything is working as intended.