Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

Ok for that will be done. But I'm saying that I want Clover to be able to checkout the VirtualSMC repository and then compile it.
sorry for my english level. maybe can? do you consider only VirtualSMC.efi?. maybe you take idea from lilu and friends? https://github.com/corpnewt/Lilu-and-Friends

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites

Just now, Sherlocks said:

sorry for my english level. maybe can? do you consider only VirtualSMC.efi?. maybe you take idea from lilu and friends?

Since I've already added other achidanthera EFI stuff to Clover... I'll try to add that driver as well. Only I don't think that Lilu is a business for Clover.

Link to comment
Share on other sites

Since I've already added other achidanthera EFI stuff to Clover... I'll try to add that driver as well. Only I don't think that Lilu is a business for Clover.
in lilu and friend script, there is build for VirtualSMC kext and driver(efi) and etc(extra kext). just inform info to you for idea.

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 1
Link to comment
Share on other sites

@Sherlocks (or anyone intrested), I succeded building the VirtualSMC among Clover stuff. Can you kindly test it for me if it is good?

 

VirtualSmc-x64_XCODE5.efi.zip

VirtualSmc-x64_XCODE8.efi.zip

 

In order to build the driver with XCODE8 toolchain (XCODE5 is already good) I had to made a tiny change to the source code (VirtualSMC.c at line 594):

Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_NOTIFY, (VOID*)EraseAuthenticationKey, (VOID*)NULL, &mAuthenticationKeyEraseEvent);

instead of:

Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_NOTIFY, EraseAuthenticationKey, NULL, &mAuthenticationKeyEraseEvent);

..going to ask to the mantainer if want to made this change...

Edited by vector sigma
typo
  • Like 1
Link to comment
Share on other sites

@SherlocksClover can now checkout and build VirtualSMC with the --ext-co argument (at the moment using only the XCODE5 toolchain since for XCODE8 require a small correction). Implemented your changes and corrected the po files.

Anyway all the translations needs to be syncronized with the new en Localizable.strings. Maybe I'm missing something...

  • Like 1
Link to comment
Share on other sites

[mention=980913]Sherlocks[/mention] (or anyone intrested), I succeded building the VirtualSMC among Clover stuff. Can you kindly test it for me if it is good?

 

VirtualSmc-x64_XCODE5.efi.zip

VirtualSmc-x64_XCODE8.efi.zip

 

In order to build the driver with XCODE8 toolchain (XCODE5 is already good) I had to made a tiny change to the source code (VirtualSMC.c at line 594):

Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_NOTIFY, (VOID*)EraseAuthenticationKey, (VOID*)NULL, &mAuthenticationKeyEraseEvent);

instead of:

Status = gBS->CreateEvent (EVT_SIGNAL_EXIT_BOOT_SERVICES, TPL_NOTIFY, EraseAuthenticationKey, NULL, &mAuthenticationKeyEraseEvent);

..going to ask to the mantainer if want to made this change...

 

good. i will test it after leave work at job. 

 

[mention=980913]Sherlocks[/mention], Clover can now checkout and build VirtualSMC with the --ext-co argument (at the moment using only the XCODE5 toolchain since for XCODE8 require a small correction). Implemented your changes and corrected the po files.

Anyway all the translations needs to be syncronized with the new en Localizable.strings. Maybe I'm missing something...

 

po were corrected. maybe seems all the translations needs. r4692 is good(XCODE10). i tested it in the morning today. thank you for your effort

 

 

  • Like 1
Link to comment
Share on other sites

Hi [mention=980913]Sherlocks[/mention], can you explain me the difference between commit r4695 and r4693? I cannot see that the po Editor insert you as the last translator... any chance that you edit those file manually? Otherwise there is a problem somewhere else
hi vector. i didn't use editor. i just found wrong parts in po files from users report. and edited it manually.

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites

1 hour ago, Sherlocks said:

i just found wrong parts in po files from users report. and edited it manually.

In my last commit I found this:

-"X-Generator: Pootle 2.5.0-rc1\n"
+"X-Generator: Poedit 2.1.1\n"

v2.1.1 vs v.2.5.0-rc1 used by ErmaC, see below:

-"PO-Revision-Date: 2015-09-24 19:50+0000\n"
-"Last-Translator: ErmaC <ErmaC@insanelymac.com>\n"
+"PO-Revision-Date: 2018-10-02 11:36+0200\n"
+"Last-Translator: vector sigma\n"

but what the Hell! ErmaC had 2.5.0 in 2015, and my version is old????? ...it is a fresh download from the main page as I never used it before .

Now I'm guessing what I have to do to have the latest version:

1576340798_Schermata2018-10-03alle18_11_53.png.b1bbfbd7f66f41c843dc94dce91489da.png

(1999-2018 :hysterical:). .. it says me that is the latest version available.

 

EDIT

 

ok, now I used my glass:cold:.... ErmaC used Pootle and me Poedit. Maybe this is the cause.

Edited by vector sigma
  • Like 2
Link to comment
Share on other sites

On 10/1/2018 at 7:41 AM, RehabMan said:

Now would be a good time to commit my suggested change (previous post in this thread) to kext_patcher.c to handle InjectKexts="Detect" properly when VirtualSMC.kext is used.

 


VOID CheckForFakeSMC(CHAR8 *InfoPlist, LOADER_ENTRY *Entry)
{
  if (OSFLAG_ISSET(Entry->Flags, OSFLAG_CHECKFAKESMC) &&
      OSFLAG_ISSET(Entry->Flags, OSFLAG_WITHKEXTS)) {
    if (AsciiStrStr(InfoPlist, "<string>org.netkas.driver.FakeSMC</string>") != NULL
        || AsciiStrStr(InfoPlist, "<string>org.netkas.FakeSMC</string>") != NULL
        || AsciiStrStr(InfoPlist, "<string>as.vit9696.VirtualSMC</string>") != NULL)
    {
      Entry->Flags = OSFLAG_UNSET(Entry->Flags, OSFLAG_WITHKEXTS);
      if (Entry->KernelAndKextPatches->KPDebug) {
        DBG_RT(Entry, "\nFakeSMC or VirtualSMC found, UNSET WITHKEXTS\n");
        gBS->Stall(5000000);
      }
    }
  }
}

 

@Sherlocks

Thanks for commit r4694!

  • Like 5
Link to comment
Share on other sites

With the move to WhateverGreen.kext and doing most injections manually (graphics, and usually audio) via config.plist/Devices/Properties, it is unfortunate that the settings in config.plist/Graphics/EDID no longer apply.

 

This commit fixes this problem, similar to how the workaround for AAPL,ig-platform-id and AAPL,snb-platform-id work:

https://github.com/RehabMan/Clover/commit/093095541f28e6ff0a4c420a274b58a88b004c26

 

Basically, it fixes up any properties with "override-no-edid" or "override-no-connect" with the custom EDID if specified with Graphics/EDID/Inject=true (and other applicable EDID settings from that section).

 

Note: There is no need to actually specify any EDID in your Devices/Properties/PciRoot(0)/Pci(0x02,0), but the property must be there.  Eg.
AAPL00,overrride-no-connect=<>

 

As it looks in Xcode:

1203985148_EDIDdevicespropertiesexample.png.5ee068d61f304f8a4f42b91f789043bb.png

Edited by RehabMan
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Slice said:

Good idea! Committed to 4703

Bug found.  Actually thought of the bug on my daily run.

Case of full edid specified in Devices/Properties with with Graphics/EDID/Inject=false, no injection happens.

 

Change is this:


NUC6i7KYK:Clover rehabman$ git diff
diff --git a/rEFIt_UEFI/Platform/Settings.c b/rEFIt_UEFI/Platform/Settings.c
index 8c66fd2b..820d5960 100644
--- a/rEFIt_UEFI/Platform/Settings.c
+++ b/rEFIt_UEFI/Platform/Settings.c
@@ -6988,12 +6988,11 @@ SetDevices (LOADER_ENTRY *Entry)
           }
           devprop_add_value(device, Prop2->Key, (UINT8*)&gSettings.IgPlatform, 4);
           DBG("   Add key=%a valuelen=%d\n", Prop2->Key, Prop2->ValueLen);
-        } else if (AsciiStrStr(Prop2->Key, "override-no-edid") || AsciiStrStr(Prop2->Key, "override-no-connect")) {
+        } else if ((AsciiStrStr(Prop2->Key, "override-no-edid") || AsciiStrStr(Prop2->Key, "override-no-connect"))
+                   && gSettings.InjectEDID && gSettings.CustomEDID) {
           // special case for EDID properties
-          if (gSettings.InjectEDID && gSettings.CustomEDID) {
-            devprop_add_value(device, Prop2->Key, gSettings.CustomEDID, 128);
-            DBG("   Add key=%a from custom EDID\n", Prop2->Key);
-          }
+          devprop_add_value(device, Prop2->Key, gSettings.CustomEDID, 128);
+          DBG("   Add key=%a from custom EDID\n", Prop2->Key);
         } else {
           // normal properties, ...
           devprop_add_value(device, Prop2->Key, (UINT8*)Prop2->Value, Prop2->ValueLen);

  • Like 1
Link to comment
Share on other sites

1 hour ago, Sherlocks said:

in my case for WEG

AddProperties + EDID injection + intel injection. no problem.

 

should we consider AddProperties case+EDID injection without intel injection?

 

 

Any of the methods for injecting properties can be mixed provided they are not injecting onto the same device.

 

So, you can use AddProperties to inject on Nvidia + AMD, Devices/Audio/Inject to inject audio, Devices/Properties to inject USB, and then Graphics/Inject/Intel=true to inject IGPU properties.  As long as each is separate, it works (note that there is hard-coded conflicts/priority between AddProperties and Arbitrary).

 

But if you try to inject on a given device two or more different ways, only the first way wins (this is especially true if you inject to multiple devices via Devices/Properties... there are exceptions to my rules when you only inject to a single device, and probably even an exception if you end on the device that you plan further injections down the line) because of the quirky way devprop_addvalue works. 

 

It is a complete mess.

 

I have it in mind to fix devprop_add_device_pci/devprop_addvalue such that it is a bit smarter, which would allow a much more sensible/less complex result (eg. inject via any method, on any device, and it works).  But haven't really looked into it to see how much work it would be nor the backward compatibility issues that might arise.

Edited by RehabMan
  • Like 2
Link to comment
Share on other sites

 
Any of the methods for injecting properties can be mixed provided they are not injecting onto the same device.
 
So, you can use AddProperties to inject on Nvidia + AMD, Devices/Audio/Inject to inject audio, Devices/Properties to inject USB, and then Graphics/Inject/Intel=true to inject IGPU properties.  As long as each is separate, it works (note that there is hard-coded conflicts/priority between AddProperties and Arbitrary).
 
But if you try to inject on a given device two or more different ways, only the first way wins (this is especially true if you inject to multiple devices via Devices/Properties... there are exceptions to my rules when you only inject to a single device, and probably even an exception if you end on the device that you plan further injections down the line) because of the quirky way devprop_addvalue works. 
 
It is a complete mess.
 
I have it in mind to fix devprop_addvalue such that it is a bit smarter, which would allow a much more sensible/less complex result (eg. inject via any method, on any device, and it works).  But haven't really looked into it to see how much work it would be nor the backward compatibility issues that might arise.
yes. i'm using Addproperties for only igpu and using other device from SSDT. seems there are number of cases to be consider. thanks.


나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites

6 hours ago, Sherlocks said:

in my case for WEG

AddProperties + EDID injection + intel injection. no problem.

 

should we consider AddProperties case+EDID injection without intel injection?

 

Yes, we consider EDID injection without Intel injection.

All injections in my laptop moved to Device Properties. But they are static. There should be a way to add dynamically calculated properties such as EDID.

  • Like 1
Link to comment
Share on other sites

Seems there is a problem with current sourceforge Clover build.

For example, you have ApfsDriverLoader,-64 but no AppleImageLoader-64.

My understanding is that ApfsDriverLoader requires AppleImageLoader.

Link to comment
Share on other sites

2 hours ago, RehabMan said:

Seems there is a problem with current sourceforge Clover build.

For example, you have ApfsDriverLoader,-64 but no AppleImageLoader-64.

My understanding is that ApfsDriverLoader requires AppleImageLoader.

No. AppleImageLoader installs ImageLoaderProtocol that we already have but with two additional features:

1. Load 32/64 bit EFI modules for systems pre10.8.

2. Check digital signature. I think if you will trust OSX Installer downloaded from Apple site then you don't need to check its signature.

Anyway everybody is able to download fresh release drivers from acidantera site.

 

PS. AFAIK latest ApfsDriverLoader contains AppleImageLoader features inside and AppleImageLoader is obsolete.

  • Like 1
Link to comment
Share on other sites

7 hours ago, Slice said:

No. AppleImageLoader installs ImageLoaderProtocol that we already have but with two additional features:

1. Load 32/64 bit EFI modules for systems pre10.8.

2. Check digital signature. I think if you will trust OSX Installer downloaded from Apple site then you don't need to check its signature.

Anyway everybody is able to download fresh release drivers from acidantera site.

 

PS. AFAIK latest ApfsDriverLoader contains AppleImageLoader features inside and AppleImageLoader is obsolete.

 

Hmm... When I build AppleSupportPkg from acidanthera current sources (on github), I still end up with ApfsDriverLoad.efi and AppleImageLoader.efi in UDK/Build/RELEASE_XCODE5 (and AppleUiSupport.efi... UsbKbDxe.efi too)

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

Working on SVG support I encounter strange behavior. In debug log I see

8:349  0:007  ShapeID=C
8:359  0:009  shape xform:  0.007812  0.000000  0.000000 -0.007812  2147483647.2147483647  -2147483648.2147483647

What are the digits? Is it clang compiler mistake working with float?

Can someone give me latest Clover compiled by gcc to check the same line? DEBUG_SVG should be set to 1.

  • Like 1
  • Confused 1
Link to comment
Share on other sites

  • 5 weeks later...

To draw images Clover uses UEFI GOP driver. Something here is out of our control

Same image with same Clover output:

Virtual machine QEMU

Снимок экрана 2018-11-25 в 14.19.27.png

 

Real machine with nvidia graphics

screenshot1.png

 

Real machine with Intel graphics...

Crash. :bye:

 

There is an error in Clover codes, no doubt, but why such difference on different hardware?

 

Sample.svg.zip

Link to comment
Share on other sites

To make a quick appearance, I see an error in your SVG:

      <rect id="shadow_6_" x="52" y="-22.79" class="st32" width="128" height="128"/> -->

There is no opening comment token but there is an extraneous closing comment token. Also, the floating points should be handled by the CPU's built in instructions for floating points, there should not be errors in the actual math. I somehow suspect that the loading (or printing) of these floating points may possibly not be correct though, unsure without really going through and looking but I don't have time to do that. Though simply removing that extra comment token may resolve the issue. The reason why you are getting different results on different GOP interfaces is because some of them probably check the bounds of the outcome and that clearly goes over any bounds of a screen given your bounding box and those numbers, if the screen is bigger/smaller than the box that will affect the way it is drawn as well. It looks as though there is a corruption of the video memory because it's being drawn over where it's not supposed to be (remember that there are two different numbers that represent the horizontal pixel count in GOP, they do not need to be the same), this is pretty obvious that the numbers you are getting are being used to draw, so my guess is the loading of the numbers is incorrect. Most likely do to the reading of the file not knowing how to handle that extra ending comment token.

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...