Jump to content

bisk

Members
  • Posts

    73
  • Joined

  • Last visited

  • Days Won

    1

bisk last won the day on March 11 2022

bisk had the most liked content!

Recent Profile Visitors

2902 profile views

bisk's Achievements

Sergeant

Sergeant (6/17)

1

Reputation

  1. Sorry, haven't been around for a little bit. OK, as soon as I upgraded to Big Sur and then a little later on, Monterey, AlpsHID is the way to go as the buttons resumed full functionality and the tracking is smoother than AlpsT4USB. But the buttons were definitely non-functional under Catalina on my E7280 unless my finger was in contact with the trackpad using the newer AlpHID. I am using voodooI2CHID v1.0 in all cases. I didn't know of a newer version. I am no longer running Catalina on this E7280 but I do save state info from each of my installs. Enclosed below is both the text and graphical versions of the oreg info from my Catalina-E7280. Hope that it helps Thanks for your hard work ! Dell_Lat7280-10.15.7.zip
  2. Huh, ok thanks for that. I will be probably updating in the next few days. Interestingly enough, I get good, normal trackpad button response by rolling back to the previous AlpsT4USB.kext v1.5. Left button works perfectly w/o the need to be in contact with the trackpad and right button is usually ok too but not 100%. Maybe this kext is not so popular because of limited gestures ? I dunno, and don't care as all that I really use is 2 finger scrolling. I'll go back to the AlpsHID.kext if trackpad button functionality returns with Big Sur and/or AlpsT4USB.kext stops functioning. But, otherwise, dead trackpad buttons is a real deal killer for me so I'll keep cruising with the older version.
  3. Just tried the AlpsHID_PTP_test on my Lat E7280 running Catalina 10.15.7 with latest sec updates, etc. TrackPad buttons are still dead for me unless I am in contact with the trackpad The TrackPad, itself seems nice and smooth, I don't do too many finger acrobatics tho'. I have been trying the 1.2 git version and had no better luck with that so stopped by here for a visit. So the TrackPad buttons are functioning properly, i.e. like a mouse, for some of you ? Is the 1.2 git version more evolved than the test version above ?
  4. No, but seriously, this little card has been working so smoothly for so long and connects so very reliably well at 5GHz. Checked out the link you provided and several other variations on the same theme but all with no luck. I've tried to delete the snapshot in Big Sur both logged in and in recovery mode but keep getting an -69863 "insufficient privileges" error. I can drop the Atheros-modified IO80211Family.kext into /L/E but it will not load into the prelinked kernel cache to replace the stock Mac version. Since I was unable to affect the sealed boot snapshot, I reverted the system back to Catalina, placed the Atheros-modified IO80211Family.kext into /L/E, rebuilt the kernel cache and verified that it was working fine. I then updated to Big Sur only to find that Apple removed this kext from /L/E. It looks like even with SIP disabled, kexts with invalid signatures are no longer accepted. kextunloads of the stock Apple IO80211Family.kext fail with an error message and kextloads of my Atheros-modified IO80211Family.kext quietly fail. It appears that the published methodology of removing and regenerating snapshots no longer works in Big Sur 11.6.x Has anyone been able to delete the boot snapshot under the current version of Big Sur ? Is there any known way to load/replace a stock Apple kext with a hacked one ? Injection definitely causes KP. This is really bumming my trip ! Anyone ???
  5. Guys, thanks so much for your responses but I think that you misunderstand my issue. I completely understand the changes needed to keep Atheros WiFi working after High Sierra. I did my own simple mods years ago. Since I make all of the necessary device specific mods in my DSDT, I just carried the old unmodified IO80211Family/AirportAtheros40 kexts along into Mojave and then Catalina. No Injector kext necessary. First I put them into /L/E and then later as Clover improved was able to do with injection instead. My WiFi has been as fast as is to be expected from 802.11ac. No problems at all. Now, I use a Mojave 10.14.6 IO80211Family.kext with and added 10.13.6 High Sierra AirportAtheros40.kext Plugin. OpenCore injection from OC/Kexts worked just fine under 10.15.7. But now with Big Sur, attempting to inject the Mojave IO80211Family.kext (with faked up version number) invokes a "Refusing new kext" error accompanied by a kernel panic. Looks like Big Sur doesn't want me replacing a stock kext contained in the prelinked kernel on the fly. And is punishing me for trying ! Is this a thing now ? Do I need to go back to dropping this into /L/E again ? Cloning my boot drive before trying ...
  6. Hello all, Been around for a while but new to the OpenCore world. I successfully installed OpenCore 0.7.7 and upgraded from Mojave to Catalina on my Dell XPS2720. This is an old Haswell AIO system. It was a perfect vanilla Mac under Mojave. Under Catalina it was equally perfect so long as my SMBIOS platform was iMac14,2. So, I went ahead and upgraded to Big Sur, changing the platform to iMac14,4. It seems very solid so far aside from one little problem. It will Kernel Panic on boot if I try to inject my old Mojave IO80211Family.kext from OC/kexts. I needed to remove this kext from the config in order to complete the upgrade. I run with an old Atheros AR9462 WiFi card and so use the Mojave IO80211Family.kext with a High Sierra AirportAtheros40.kext Plugin and this has worked just fine under 10.14 & 10.15. I suppose that I could try to move this stuff into LE but would definitely like to avoid that. So, I put this question out there. Is there some config adjustment that I can make to help this kext replacement to happen ? Thanks in advance,
  7. OK. I tried replacing the old style clover KernelAndKextPatches.KextsToPatch version of this FrameBuffer patch and I get a KP with a second display connected just as before. Also, just did an update to 10.14.3 and discovered that the old patch doesn't even work anymore ! Under 10.14.3, I will KP as soon as I connect an HDMI display not just when I wake from sleep with an external display as with 10.14.2. So, I rolled my AppleIntelFramebufferAzul.kext back to the 10.14.2 version and all seems OK again. To sum it up ... 1. New WEG Device.Properties patch does NOT help under either 10.14.2 or 10.14.3. 2. Only the old Clover KernelAndKextPatches.KextsToPatch patch works under 10.14.2. NO ! I was WRONG, WRONG, WRONG on point #2. The old Clover KernelAndKextPatches.KextsToPatch patch DOES still work for 10.14.3. I just needed to completely clear the kextcache by manually deleting the prelinkedkernel. Also, I'm not sure that specifying an alternate config.plist with the Options feature of Clover v2.4k_r4700 works ! So I just need to research WEG style Device.Properties patching to replace my existing old style Clover patch. It'll be a good exercise
  8. I've been going around in circles with this one for a while - trying to get the Bluetooth going on my Dell XPS 2720. It was working OK with the original Atheros combo card but I just swapped that out for a Broadcom combo card to go after AirDrop. The card that I installed is a Dell DW1550. The WiFi works just fine but it seems like I can't quite get the Bluetooth firmware to load. I first tried RehabMan's BrcmPatchRAM solution from both /L/E and CLOVER/kexts/Other but it fails to load the firmware with error(s): EH02@1a000000: AppleUSBHostController::hardwareExceptionThreadCallGated: 0x00000020 BrcmPatchRAM2: [413c:8143]: Failed to write to bulk pipe ("0xe0002eb (UNDEFINED)" 0xe0002eb) BrcmPatchRAM2: [413c:8143]: continuousRead - failed to queue read (0xe00002d8) Later I get 3 busy timeout[#] (60s) 'AppleUSBHostLegacyClient', 'BrcmPatchRAM2', 'IOUSBHostInterface', 'IOUSBHostInterface', 'IOUSBHostInterface', 'IOUSBHostInterface' If I then follow with a warm reboot, I don't even get this far, instead I get a bunch of ... HP24@1a10000: AppleUSB20HubPort::resetAndCreateDevice: failed to start device HP24@1a10000: AppleUSB20HubPort::resetAndCreateDevice: failed to create device (0xe00002e9), disabling port and Broadcom BCM20702A0 device disappears from IORegistry, only HP24@1a140000 appears. [email protected]@1a100000.HP24@1a14000 is where my Broadcom BCM20702A0 device lives. If I shutdown and do a cold boot, I'm back to BrcmPatchRAM2 finding my device and failing to upload firmware to it again. ----- Now, if I try BTFirmwareUploader.kext, things look much more promising but still NO bluetooth ... BTFirmwareUploader) BTFirmwareUploader :: Device is Dell DW1550 4352 combo 2019-02-07 16:11:13.212026-1000 0x155 Default 0x0 0 0 kernel: (BTFirmwareUploader) BTFirmwareUploader :: Using device specific firmware v14 c5545 2019-02-07 16:11:13.212175-1000 0x155 Default 0x0 0 0 kernel: (BTFirmwareUploader) BTFirmwareUploader :: Started the upload of firmware (70099 bytes)... 2019-02-07 16:11:13.235621-1000 0xff Default 0x0 0 0 kernel: (IOUSBFamily) USBMSC Identifier (non-unique): 2GEYH5CX 0xbc2 0x3008 0x132, 2 2019-02-07 16:11:13.515909-1000 0x118 Default 0x0 0 0 kernel: (IOUSBHostFamily) 000002.515902 AppleUSBHostResources@(null): AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 100 sleepUnits 0 2019-02-07 16:11:13.956263-1000 0x155 Default 0x0 0 0 kernel: (BTFirmwareUploader) BTFirmwareUploader :: Successfully patched the firmware. 2019-02-07 16:11:14.026858-1000 0x118 Default 0x0 0 0 kernel: (IOUSBHostFamily) 000003.026851 AppleUSBHostResources@(null): 2019-02-07 16:11:14.065402-1000 0x155 Default 0x0 0 0 kernel: (kernel) <compose failure [UUID]> 2019-02-07 16:11:14.112936-1000 0x155 Default 0x0 0 0 kernel: (IOBluetoothHostControllerUSBTransport) **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x8800 **** 2019-02-07 16:11:14.112946-1000 0x155 Default 0x0 0 0 kernel: (BroadcomBluetoothHostControllerUSBTransport) **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed (matched on Device) -- 0x8800 **** 2019-02-07 16:11:14.113085-1000 0x6f Default 0x0 0 0 kernel: (IOUSBHostFamily) 000003.113081 AppleUSBHostResources@(null): 2019-02-07 16:11:14.163949-1000 0x177 Default 0x0 0 0 kernel: (IOBluetoothHostControllerUSBTransport) **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x8800 **** 2019-02-07 16:11:14.163958-1000 0x177 Default 0x0 0 0 kernel: (BroadcomBluetoothHostControllerUSBTransport) **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed (matched on Device) -- 0x8800 **** . . . 2019-02-07 16:11:39.725469-1000 0x5b6 Default 0x0 0 0 kernel: (IOBluetoothFamily) [IOBluetoothFamily][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x8800 2019-02-07 16:11:39.725473-1000 0x5b6 Default 0x0 0 0 kernel: (IOBluetoothFamily) [IOBluetoothFamily][start] -- completed Oh, and I know the card is good because Windows loads it up just fine and if I do a warm reboot, the bluetooth will be fully functional on the Mac side until a sleep/wake. Anyway, I am just looking for suggestions of what to try next. Thanks in advance debug_24858.zip
  9. Hi. Been gone for a while, sorry. I did just come back and downloaded your modified config, thanks Of course I hacked through it myself before looking here and so ended up doing it all the hard way, I'm sure. Turned out that my pink screen was due to me not undoing the GFX0->IGPU Patch and/or not setting Graphics->Inject=NO. But, either way, now I'm running with WhateverGreen and my integrated display res has improved from 1920x1080 to 2560x1440 AND I don't need to turn my attached HDMI display off/on to get a picture on startups. Cool. But now I have an interesting USB problem on the same box so new topic coming up ... BTW, are those Properies->(PciRoot(0x0)/Pci,,, entries the WhateverGreen way to do the same FrameBuffer patch that you gave me here earlier ? Because I'm still using the old one. Is the old way gonna stop working in the future ? Thanks again !
  10. I removed all the Sensor Keats but same result. KP always right about the time FakePCIID.kext loads. Last kext loaded in stack trace does vary tho. AppleAHCIPort 3x AppleUSBHostPacketFilter 1x and one bus error. That’s a new one. I will modify my patches and try WhateverGreen again. Am I able to lose FakePCIID.kext with WEG ? If not then I suspect problem will persist.
  11. OK ! Finally made it back. Sorry for the delay but life gotta little busy there. So, to address your comments ... No, Sinetek-rtsx.kext does NOT make my sD reader work. The kext loads and attaches to the proper device but that's all. So, it's removed now. I am embarrassed to say that I did not realize that VoodooPS2Controller was not needed for desktops. I guess that I've been working on laptops for so long that most of the desktops that I converted prior had PS2 keyboards and mice. Ooops ! OK, that's out too. AppleShippingDrive and FaceTime kexts are primarily to fix "cosmetics". They simply inject vendor/device ids of known Apple devices in place of the actual. When configured properly, they allow an installed optical drive to show up as an "Apple Shipping Drive" and a webcam to be treated as a "FaceTime HD Camera (Built-in)". In rare cases, they can actually help the devices perform better. In fact, in the case of this XPS2720, the webcam was only showing me an orange blob in PhotoBooth until I added FaceTime.kext, Now it performs perfectly ! Sometimes the FaceTime.kext can have the opposite affect and stop a webcam from working. AppleShippingDrive.kext never seems to hurt anything and IS only 100% cosmetic in my experience. Hmmm, always thought that generating an SSDT for my CPU using the fab scripts first by RevoGirl and later by PikerAlpha was the way to for any system. OK. So I removed SSDT.aml from ACPI->patched and I do still have the same 29 P-States and sleep working fine, Cool ! I did give WhateverGreen a try when I was attempting to figure out the dual display patch for this XPS2720. I removed FakePCIID_Intel_HD_Graphics.kext + FakePCIID.kext and added WhateverGreen.kext only to be greeted by a pink hued desktop. Plus, still some KPs ! So it was more like WhateverPink for me I do a couple of Clover patches in the config, one is GFX0->IGPU, Plus I modify my DSDT fairly extensively. I'm kinda old school. I generated a new debug package and had a glance at the last panic log ... *** Panic Report *** panic(cpu 0 caller 0xffffff7f89225c1d): "DSMOS: SMC returned incorrect key: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/DontStealMacOS/DontStealMacOS-27.200.2/Dont_Steal_MacOS.cpp:221 Backtrace (CPU 0), Frame : Return Address 0xffffff811255b970 : 0xffffff80067aeafd 0xffffff811255b9c0 : 0xffffff80068e85a3 0xffffff811255ba00 : 0xffffff80068d9fca 0xffffff811255ba70 : 0xffffff800675bca0 0xffffff811255ba90 : 0xffffff80067ae517 0xffffff811255bbb0 : 0xffffff80067ae363 0xffffff811255bc20 : 0xffffff7f89225c1d 0xffffff811255bd60 : 0xffffff7f89225a7e 0xffffff811255bd70 : 0xffffff8006e28a7a 0xffffff811255bdc0 : 0xffffff8006e345ab 0xffffff811255bdf0 : 0xffffff8006e34536 0xffffff811255be20 : 0xffffff7f89225a64 0xffffff811255be40 : 0xffffff8006e2c65b 0xffffff811255be80 : 0xffffff8006e2c3a1 0xffffff811255bf00 : 0xffffff8006e2b8f7 0xffffff811255bf50 : 0xffffff8006e2d3c6 0xffffff811255bfa0 : 0xffffff800675b0ce Kernel Extensions in backtrace: com.apple.Dont_Steal_Mac_OS_X(7.0)[E8A46A07-5CA9-3449-AB3C-194D7EDBDEC6]@0xffffff7f89225000->0xffffff7f89229fff dependency: com.apple.kec.corecrypto(1.0)[0F77793D-78A0-3EA4-B2AC-A287F438DE3A]@0xffffff7f872ae000 dependency: com.apple.driver.AppleSMC(3.1.9)[9FAF842D-CCF4-3F6A-893D-DD542139F128]@0xffffff7f87a7e000 Could this be related to FakeSMC.kext ? debug_13797.zip
  12. I have downloaded the script, generated debug file ... I do get the KP pretty regularly still, about 1 out of every 3 start ups but no ill effects that I can notice once I'm up and running. Thanks in advance ! debug_18952.zip
  13. You nailed it ! Added your patch and all is I rebooted and then attached the external HDMI display and it just worked, no panic/restart. I sleep the system with 2 displays and it wakes up perfectly every time. And of course, the external display is recognized just fine without the need to set it a wrong res and then reset it back to a good one. So could you please explain exactly what this patch is changing ? What I think that I understand is that it's applied to Framebuffer@1 (105) and changes the port type from DP(04) to HDMI(08). But Framebuffer@1 is where my internal display attaches while my external HDMI display actually attaches to Framebuffer@0. At least that's what I assumed since that's where the new AppleDisplay appears when I connect the external HDMI display. What does swapping the 2 bytes 09->12 immediately after the 0105 do ? If you wouldn't mind expanding on these points, I would sure love to learn. Thank you so much. This is a really great site. You and Herve particularly have been so consistently amazing over the years ! I do have one last strangeity and I apologize if it's offtopic here but ... This system will KP at middle boot right after FakePCIID.kext loads about every 1 out of 4 times. Seems to be a timing thing. KP trace flies by really quickly but seems to involve AppleSMC.kext. I am running the very latest FakeSMC, FakePCIID, Lilu, etc.
  14. Thanks for your reply ! Please advise how you would like me to generate a 'debug' file. Not much of a trick to get the external display to show, really. Seems as thought it's always active but just not receiving the proper resolution mode initially as the external monitor's green light is on solid but with (backlit) black display at boot up. I simply click "Gather Windows" on SystemPreferences->Displays to get the configuration panel for the external display to show up on my primary internal display. Then I switch it to Scaled and purposely select an unsupported resolution like 720p. Then when I immediately switch back to "Default for Display", the external display works and stays that way. Unfortunately, if I sleep, the system will then reboot on wake. This does not happen if I do not connect the external display. I should also mention that if I connect the external display after boot up, the system promptly reboots. So the external display must be connected prior to boot up to work at all. However, if I disconnect the external display then the primary display does go black for a moment but then bounces right back and all is well. In the meantime, I have tried changing the SMBIOS designation to Macmini7,1 but end up with the exact same result. Interestingly, I got a hold of an ioreg file for a genuine iMac14,1 and the primary display actually shows up as an AppleBacklightDisplay under AppleIntelFramebuffer@2 which I totally did not expect. I figured that it would live under AppleIntelFramebuffer@0 where AGPM lives. So, now I'm just more confused, lol ! I have enclosed 4 ioregs. 1 for the system with just an internal display, one with the external HDMI display connected before my fix and one after my fix and also one from a genuine iMac14,1. Hope this helps to get things rolling I had thought that getting my primary/internal display to land under AppleIntelFramebuffer@0 and my external HDMI display to land under AppleIntelFramebuffer@1 might fix everything but maybe that's a flawed assumption on my part DellXPS2720_ioregs.zip
  15. Hi everybody. I have an unusual problem with my Dell XPS 2720. At least this one is new to me ! This is an All-In-One Haswell desktop and I've got Mojave 10.14.1 running pretty well on it except for one strange issue. The internal display shows up as AppleDisplay under AppleIntelFrameBuffer@1 and if I connect an external display to the HDMI port that shows up as AppleDisplay under AppleIntelFrameBuffer@0. There is a little trick that I need to do to actually get the 2nd display to appear the first time which is not a big deal but the big problem is that if the system sleeps, it will then KP upon wake if and only if an external disply is connected to the HDMI port. I have tried defining this system as both an iMac14,1 and iMac14,2 with the same result. iMac15,1 won't recognize an external display. I assume that this is due to the displays being in the opposite places from where the OS expects them to be. Can I swap the framebuffers with kext patches in Clover ? Or is DSDT/SSDT patching the way to go ? Any guidance much appreciated
×
×
  • Create New...