obus Posted October 19, 2022 Share Posted October 19, 2022 (edited) Clean installation to Release Candidate 13.0 (build: 22A379) from USB-stick. Everything works like a charm! Spoiler Edited October 19, 2022 by obus 3 Link to comment Share on other sites More sharing options...
deeveedee Posted October 20, 2022 Share Posted October 20, 2022 (edited) Has anyone noticed a problem with driver Ps2KeyboardDxe.efi when OpenVariableRuntimeDxe.efi is enabled (with load early enabled)? Details below... I am experimenting with OpenVariableRuntimeDxe.efi as I switch my Latitude E6410 from CLOVER to OC. I have noticed that without OpenVariableRuntimeDxe.efi (where OpenRuntime.efi does not load early), my internal PS/2 keyboard up/down cursor keys work fine to navigate the OC boot picker. If I enable OpenVariableRuntimeDxe.efi (load early) with OpenRuntime.efi set to load early, my laptop's internal PS2 keyboard cursor keys do not work (initially). I discovered that if I press <F12> during boot-up to open the BIOS boot menu and then select my boot device, the PS2 keys work for the OC boot picker. If I don't press <F12> and I allow the laptop to boot normally, the internal PS2 keyboard keys do not work for the OC boot picker. Only reliable work-around is to use OpenUsbKbDxe.efi with an external USB keyboard if I want to navigate the OC boot picker. This appears to be a driver timing issue, because I can get the internal PS2 cursor keys to work with the OC boot picker if I boot from USB stick (slower boot). The <F12> work-around is adequate, but I'm curious to know if anyone else has seen this and if so, is there a solution. My UEFI drivers are below: OpenVariableRuntimeDxe.efi (load early) OpenRuntime.efi (load early) HfsPlusLegacy.efi ResetNvramEntry.efi (--preserve-boot) Ps2KeyboardDxe.efi If I use OpenUsbKbDxe.efi instead of Ps2KeyboardDxe.efi (to enable an external USB keyboard), the external USB keyboard works without any work-arounds. Edited October 20, 2022 by deeveedee 1 Link to comment Share on other sites More sharing options...
Stefanalmare Posted October 20, 2022 Share Posted October 20, 2022 43 minutes ago, deeveedee said: Has anyone noticed a problem with driver Ps2KeyboardDxe.efi when OpenVariableRuntimeDxe.efi is enabled (with load early enabled)? Details below... I am experimenting with OpenVariableRuntimeDxe.efi as I switch my Latitude E6410 from CLOVER to OC. I have noticed that without OpenVariableRuntimeDxe.efi (where OpenRuntime.efi does not load early), my internal PS/2 keyboard up/down cursor keys work fine to navigate the OC boot picker. If I enable OpenVariableRuntimeDxe.efi (load early) with OpenRuntime.efi set to load early, my laptop's internal PS2 keyboard cursor keys do not work (initially). I discovered that if I press <F12> during boot-up to open the BIOS boot menu and then select my boot device, the PS2 keys work for the OC boot picker. If I don't press <F12> and I allow the laptop to boot normally, the internal PS2 keyboard keys do not work for the OC boot picker. The <F12> work-around is adequate, but I'm curious to know if anyone else has seen this and if so, is there a solution. My UEFI drivers are below: OpenVariableRuntimeDxe.efi (load early) OpenRuntime.efi (load early) HfsPlusLegacy.efi ResetNvramEntry.efi (--preserve-boot) Ps2KeyboardDxe.efi If I use OpenUsbKbDxe.efi instead of Ps2KeyboardDxe.efi (to enable an external USB keyboard), the external USB keyboard works without any work-arounds. Are you using Duet (LegacyBoot) to boot your computer? If yes, read this: "Recommended configuration settings for this driver: • OpenVariableRuntimeDxe.efi loaded using LoadEarly=true. OpenDuet users should not load this driver, as it is included in OpenDuet. • OpenRuntime.efi specified after OpenVariableRuntimeDxe.efi (when applicable), also loaded using LoadEarly=true" I never used OpenVariableRuntimeDxe.efi in my legacy rig and I had no problems with USB, Ps2 mouse/keyboard in picker. 1 1 Link to comment Share on other sites More sharing options...
deeveedee Posted October 20, 2022 Share Posted October 20, 2022 (edited) @Stefanalmare Thank you. ocvalidate doesn't complain about my configuration, but what you said makes sense. I'll test and report back. EDIT: @Stefanalmare Disabling OpenVariableRuntimeDxe.efi fixed the PS2 keyboard problem. Thank you! I think that this error message in ocvalidate should be changed to mention Duet/LegacyBoot. OpenRuntime.efi at UEFI->Drivers[2] should have its LoadEarly set to FALSE unless OpenVariableRuntimeDxe.efi is in use! CheckUefi returns 1 error! My working config is as follows: LegacyBoot (Duet) installed config.plist: UEFI > Drivers > OpenVariableRuntimeDxe.efi: Disabled config.plist: UEFI > Drivers > OpenRuntime.efi: Enabled, load early config.plist: UEFI > Drivers > Ps2KeyboardDxe.efi: Enabled config.plist: UEFI > Input > KeySupport > YES Edited October 20, 2022 by deeveedee 1 Link to comment Share on other sites More sharing options...
Stefanalmare Posted October 20, 2022 Share Posted October 20, 2022 4 minutes ago, deeveedee said: @Stefanalmare Thank you. ocvalidate doesn't complain about my configuration, but what you said makes sense. I'll test and report back. Octavilate complain in my case (load early OpenRuntime.efi). But I just ignore. 1 Link to comment Share on other sites More sharing options...
miliuco Posted October 20, 2022 Share Posted October 20, 2022 (edited) @deeveedee This could be a good issue for the bug tracker, what do you think? https://github.com/acidanthera/bugtracker/issues Edited October 20, 2022 by miliuco Link to comment Share on other sites More sharing options...
Stefanalmare Posted October 20, 2022 Share Posted October 20, 2022 4 minutes ago, miliuco said: @deeveedee This could be a good issue for the bug tracker, what do you think? https://github.com/acidanthera/bugtracker/issues Bug tracker when all is explained? Maybe, octavilate error when you set load early OpenRuntime.efi and OpenVariable Runtime Dxe.efi isn't physically present (it is in Duet). Link to comment Share on other sites More sharing options...
deeveedee Posted October 20, 2022 Share Posted October 20, 2022 @miliuco and @Stefanalmare - I don't think that the OpenRuntime load early message is a bug, but I think it would be nice if the message mentioned Duet as I indicated here. It's more a feature request than a bug fix. Link to comment Share on other sites More sharing options...
pitrysha Posted October 20, 2022 Share Posted October 20, 2022 53 minutes ago, deeveedee said: @miliuco and @Stefanalmare - I don't think that the OpenRuntime load early message is a bug, but I think it would be nice if the message mentioned Duet as I indicated here. It's more a feature request than a bug fix. Read documentation OpenCore -> Docs -> Configuration.pdf -> page 89-90 Link to comment Share on other sites More sharing options...
miliuco Posted October 20, 2022 Share Posted October 20, 2022 (edited) @Stefanalmare @deeveedee @pitrysha No, I have not explained myself, of course ocvalidate warning isn’t an error, it’s a way to remark to the user the way to set these drivers. OC docs say how to set them, that OpenVariableRuntimeDxe is not needed when using Duet an also that OpenRuntime must have LoadEarly false if OpenVariableRuntimeDxe not used. I was referring to the issue with Ps2KeyboardDxe.efi and the internal keyboard when OpenVariableRuntimeDxe is set, and the fix when OpenVariableRuntimeDxe is removed. Maybe here there is some kind of incompatibility between them. Edited October 20, 2022 by miliuco 1 2 Link to comment Share on other sites More sharing options...
deeveedee Posted October 20, 2022 Share Posted October 20, 2022 With such a great manual, one has to wonder why we have ocvalidate. 😂 1 Link to comment Share on other sites More sharing options...
Tecnicaso Rico Posted October 20, 2022 Share Posted October 20, 2022 (edited) 8 hours ago, deeveedee said: Has anyone noticed a problem with driver Ps2KeyboardDxe.efi when OpenVariableRuntimeDxe.efi is enabled (with load early enabled)? Details below... I am experimenting with OpenVariableRuntimeDxe.efi as I switch my Latitude E6410 from CLOVER to OC. I have noticed that without OpenVariableRuntimeDxe.efi (where OpenRuntime.efi does not load early), my internal PS/2 keyboard up/down cursor keys work fine to navigate the OC boot picker. If I enable OpenVariableRuntimeDxe.efi (load early) with OpenRuntime.efi set to load early, my laptop's internal PS2 keyboard cursor keys do not work (initially). I discovered that if I press <F12> during boot-up to open the BIOS boot menu and then select my boot device, the PS2 keys work for the OC boot picker. If I don't press <F12> and I allow the laptop to boot normally, the internal PS2 keyboard keys do not work for the OC boot picker. Only reliable work-around is to use OpenUsbKbDxe.efi with an external USB keyboard if I want to navigate the OC boot picker. This appears to be a driver timing issue, because I can get the internal PS2 cursor keys to work with the OC boot picker if I boot from USB stick (slower boot). The <F12> work-around is adequate, but I'm curious to know if anyone else has seen this and if so, is there a solution. My UEFI drivers are below: OpenVariableRuntimeDxe.efi (load early) OpenRuntime.efi (load early) HfsPlusLegacy.efi ResetNvramEntry.efi (--preserve-boot) Ps2KeyboardDxe.efi If I use OpenUsbKbDxe.efi instead of Ps2KeyboardDxe.efi (to enable an external USB keyboard), the external USB keyboard works without any work-arounds. Maybe you can experiment with Ps2KeyboardDxe.efi set to load early and see what happens. Edited October 20, 2022 by Tecnicaso Rico Link to comment Share on other sites More sharing options...
Stefanalmare Posted October 20, 2022 Share Posted October 20, 2022 40 minutes ago, Tecnicaso Rico said: Maybe you can experiment with Ps2KeyboardDxe.efi set to load early and see what happens. I have Ps2KeyboardDxe.efi loaded normally, and it is working like should do. 1 Link to comment Share on other sites More sharing options...
deeveedee Posted October 21, 2022 Share Posted October 21, 2022 Sorry for what is probably a remedial question that has been asked before. Where can I find the definitions of the kernel versions that OC uses for Min and Max Kernel in the OC config.plist? Link to comment Share on other sites More sharing options...
1Revenger1 Posted October 21, 2022 Share Posted October 21, 2022 14 minutes ago, deeveedee said: Sorry for what is probably a remedial question that has been asked before. Where can I find the definitions of the kernel versions that OC uses for Min and Max Kernel in the OC config.plist? Darwin/Kernel versions. Wikipedia lists them all but aside from some early versions, the major version is increment by one each time the OS is updated. The major version generally is the macOS version (15, 14, 13 for Catalina, Mojave, High Sierra, etc) + 4. Big Sur is 20, Monterey is 21, and Ventura is 22.https://en.wikipedia.org/wiki/Darwin_(operating_system) 2 1 Link to comment Share on other sites More sharing options...
deeveedee Posted October 21, 2022 Share Posted October 21, 2022 (edited) @1Revenger1 Thanks for the quick reply. Just to confirm, if I want OC to inject a kext for Monterey but not for Big Sur, I would set MinKernel to 21.0.0. Correct? Correction: it seems that OCLP is setting correct Min and Max Kernel for IntelPowerManagement I'm asking, because I used OCLP to generate an OpenCore build for a MacBookPro6,2. Some of the injected kexts (IntelPowerManagement) that I believe are necessary for Monterey have MinKernel set to 22.0.0. If I interpret your post correctly, with MinKernel set to 22.0.0, the kexts would not be loaded for Monterey (only for Ventura). Correct? Note that I need to confirm my suspicion about the IntelPowerManagement kexts, so I'm not asking for that to be diagnosed/debugged in this thread. Thanks. Edited October 22, 2022 by deeveedee Link to comment Share on other sites More sharing options...
miliuco Posted October 23, 2022 Share Posted October 23, 2022 Good night. It's been a long time with no changes in config.plist but, in build c7b1063, three new keys have been added to AppleInput. Mouse dwell-clicking has been implemented by Marvin Häuser. Read this in the bug tracker. config.plist UEFI >> AppleInput: added 3 new keys to implement dwell-clicking: PointerDwellClickTimeout (Number): sets pointer dwell-clicking single left click timeout in milliseconds; 0 indicates the timeout is disabled. PointerDwellDoubleClickTimeout (Number): sets pointer dwell-clicking single left double click timeout in milliseconds; 0 indicates the timeout is disabled. PointerDwellRadius (Number): sets pointer dwell-clicking tolerance radius in pixels; the radius is scaled by UIScale. 0 indicates the radius is disabled. Note about Dwell Mouse Dwell is a solution that allows people with a physical difficulty to use pointing devices without the need to click a button. It has traditionally been useful for head pointers users but can also be useful for people with hand/finger movement difficulties and even outside of this scope when using non-click devices (joysticks, rollerballs). The user does not have to press a button. Simply hold the mouse within a predefined area for a predetermined amount of time to emit a virtual click that has the same effect as clicking the mouse. The time the pointer has to stay held in the area to issue a single click is defined in PointerDwellClickTimeout. The time that the pointer has to stay held in the area to issue a double click is defined in PointerDwellDoubleClickTimeout. The size of the circular area within which the pointer is to remain is defined in PointerDwellRadius. 6 2 Link to comment Share on other sites More sharing options...
Stefanalmare Posted November 7, 2022 Share Posted November 7, 2022 About previous discussion: 4 Link to comment Share on other sites More sharing options...
deeveedee Posted November 8, 2022 Share Posted November 8, 2022 (edited) @Stefanalmare Thanks for posting this. I have experimented with RequestBootVarRouting enabled and disabled in my HackBookPro6,2 (which uses Duet) and I don't see any difference. I'll disable RequestBootVarRouting in my next version of my posted EFI. Edited November 8, 2022 by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted November 11, 2022 Share Posted November 11, 2022 (edited) EDIT: After further research, I have seen multiple recommendations to ignore the Latitude E6410 UEFI boot option and to stay with Legacy booting. I'm still curious to know if anyone has an answer for my question below, but at this point, I'm inclined to stay with OpenCore legacy booting. =============================================== I am currently using OpenCore's LegacyBoot utility with my Dell Latitude E6410. The LegacyBoot works well, but I'd like to try UEFI which is supposed to be supported by the E6410. The Dell Latitude E6410 BIOS does offer a UEFI boot option, but it does not automatically detect OpenCore. What "File Name" would I need to specify in the BIOS configuration screen below in order to try UEFI boot of OpenCore? I don't know what I'm doing, so I tried BOOTx64.efi, BOOT/BOOTx64.efi and EFI/BOOT/BOOTx64.efi. Thank you. Dell Latitude E6410 UEFI Boot configuration Spoiler Edited November 11, 2022 by deeveedee Link to comment Share on other sites More sharing options...
Slice Posted November 11, 2022 Share Posted November 11, 2022 You have to use back slash. 3 Link to comment Share on other sites More sharing options...
deeveedee Posted November 11, 2022 Share Posted November 11, 2022 @Slice Thank you for the quick reply. I tried both of the following File Names without success on my Dell Latitude E6410. Maybe I need to switch to CLOVER? \EFI\OC\OpenCore.efi \EFI\BOOT\BOOTx64.efi Link to comment Share on other sites More sharing options...
Slice Posted November 11, 2022 Share Posted November 11, 2022 I can help you with Clover. 4 Link to comment Share on other sites More sharing options...
deeveedee Posted November 11, 2022 Share Posted November 11, 2022 @Slice I know you can! 😀 1 2 Link to comment Share on other sites More sharing options...
oldman20 Posted December 7, 2022 Share Posted December 7, 2022 From Dortania Document: ResetSystem.efi: Utility to perform system reset. Takes reset type as an argument: cold reset, firmware, shutdown, warm reset. Defaults to cold reset. how can I control it? just use Arguments with cold reset/ firmware/ shutdown/ warm reset?? like this? 1 Link to comment Share on other sites More sharing options...
Recommended Posts