Jump to content
vit9696

VirtualSMC — SMC Emulator

459 posts in this topic

Recommended Posts

1 hour ago, TurbineSeaplane said:

 

Are you using only that Radeon VII now?

Everything working totally natively with the beta version?

yes, I have only Radeon VII, both iMac18,3 and iMac19,1 works, natively support but only for 10.14.5 beta.

Share this post


Link to post
Share on other sites
Advertisement
36 minutes ago, steve3d said:

yes, I have only Radeon VII, both iMac18,3 and iMac19,1 works, natively support but only for 10.14.5 beta.

 

Thank you!

This may be my future GPU…

 

Anything you don’t care for about it?

Share this post


Link to post
Share on other sites
19 minutes ago, TurbineSeaplane said:

 

Thank you!

This may be my future GPU…

 

Anything you don’t care for about it?

Please move this conversation to the GPU section or in PMs, this has nothing to do with VirtualSMC

Share this post


Link to post
Share on other sites
43 minutes ago, Pavo said:

Please move this conversation to the GPU section or in PMs, this has nothing to do with VirtualSMC

 

Agreed. My fault totally sorry. 

Just sort of happened. 

Share this post


Link to post
Share on other sites
On 3/27/2019 at 5:06 PM, Emanuele-1998 said:

why doesn't it charge me sometimes the charging time and the battery? and why when I connect the charger tells me he is not in charge? when will the new release be released? PLEASE @vit9696 @chris1111 @Dr. Hurt

Schermata 2019-03-27 alle 22.02.49.png

Schermata 2019-03-27 alle 22.03.01.png

Did you do the proper patches to your DSDT? Because if you haven't then that's your problem. All laptops require a certain number of specific patches to the DSDT in order to achieve proper functionality and the battery is the most common example of why its necessary. Apple switched up their method for accessing embedded controller data and made it so that the write bits need to be in 8 bit portions in order for the read bits to return proper information when the battery manager attempts to access the info. So you have to make sure that you've gotten that all straightened out along with a few other common patches which are needed as well. 

Share this post


Link to post
Share on other sites
Posted (edited)
On 10/30/2018 at 2:36 PM, Andres ZeroCross said:

Because hot patching requires that you abandon the concept of editing the DSDT directly in favor of making all of you adjustments via clover patches and SSDT with all of the changes you want to make. This method allows for the DSDT to be edited on the fly and has the benefit of surviving updates to your bios without having to patch all over again. Its also able to be used across similar devices unlike static patching where you're required to make your own edits to to your computers DSDT thus making the process of installing Mac 100x easier if you happen to just find some build with comparable hardware. The process is very complicated and it requires there to be no conflicts between devices listed in the DSDT and the HotPatched SSDTs that you use. The way you avoid those errors is by renaming the devices or the portions of the code which signal some function by using clover configurator to make the changes on the fly as well and this ensures that the SSDT will be able to load and won't conflict with the actual functions present in the real DSDT file. Thats why he renamed it, to avoid any possible conflicts which may be in the DSDT because you have to have only SSDTs in the ACPI/patched folder, there can't be a DSDT in there because the system loads the stock DSDT at boot and patches it on the fly and this is what allows for much better compatibility and with less risk of problems.
if you 

 

 

 

I know,,

But for me it's strange. It's like kill old ones, and make new ones with same device. You make clover to patch your DSDT, then load your SSDT. How about just "LOAD" your DSDT + SSDT configuration with less use of clover patch / hot patch. 

But, as long as your device has good perfomance then good luck :thumbsup_anim:

 

Edited by sass86oh

Share this post


Link to post
Share on other sites

Hi everyone, I wanted to ask the more experienced here, what information is needed to properly support a new chipset.

 

@modmike was kind enough to add my chipset and ID in the code and provide a built kext, but it did not show any FAN values.

 

My Intel NUC8i7BEH2 is set up as Macmini8,1 and using the ITE IT8987E-VG chipset with ID 0x8987.

 

What information for proper I/O detection would be needed? How can I find the keys that would be useful? Is it via smcread that's included? If this is the case, I am attaching them here...

 

Can you point to a guide, please? Or at least the Terminal command and output that would be useful to you? Thanks in advance.

nuc8i7beh-smc-keys-macmini8,1.txt

Share this post


Link to post
Share on other sites
Posted (edited)
On 4/13/2019 at 11:03 AM, sass86oh said:

Did you do the proper patches to your DSDT? Because if you haven't then that's your problem. All laptops require a certain number of specific patches to the DSDT in order to achieve proper functionality and the battery is the most common example of why its necessary. Apple switched up their method for accessing embedded controller data and made it so that the write bits need to be in 8 bit portions in order for the read bits to return proper information when the battery manager attempts to access the info. So you have to make sure that you've gotten that all straightened out along with a few other common patches which are needed as well. 

Yes but many times it appears and at others it disappears no longer appearing from one day to another but i hope,  soon in a virtualsmc update

Edited by Emanuele-1998

Share this post


Link to post
Share on other sites
7 hours ago, Emanuele-1998 said:

Yes but many times it appears and at others it disappears no longer appearing from one day to another but i hope,  soon in a virtualsmc update

Send me your DSDT and Ill patch it for you.

Share this post


Link to post
Share on other sites

Hi again everyone, what is the procedure please to add support for a new controller, per my post above?

I refer to the Intel NUC8i7BEH2 set up as Macmini8,1 that is using the ITE IT8987E-VG chipset with ID 0x8987.

 

Obviously adding the model to the code/repo is not enough, can anyone kindly provide more information?

It would be appreciated for more models (perhaps) popping out soon... Thanks!

Share this post


Link to post
Share on other sites
Posted (edited)

Hi, thank you all again for this kernel extension.

 

My device has no light sensor device(ACPI0008), so I know the SMCLightSensor wouldn't work for me. 

I need a SSDT-ALS0 to fake an ambient light sensor so that the brightness can be preserved perfectly after I shut down the device; otherwise, the brightness value would change after every boot.

 

However, I got this error log which shows VirtualSMC wants to implement my fake sensor. Could developers write a boot argument which can disable the light sensor attaching since I really need that SSDT, and I don't want VirtualSMC keep trying to attach a fake sensor.

 

(AppleSMCLMU) <AppleSMCLMU`AppleLMUController::smcGetKeyInfo(unsigned int, SMCKeyInfoData*)> AppleLMUController::smcGetKeyInfo Error: received error 0x84 when getting key info for 'ALRV'
(AppleSMCLMU) <AppleSMCLMU`AppleLMUController::smcReadKey(unsigned int, unsigned long long, void*)> AppleLMUController::smcReadKey Error: received error 0x84 when reading key 'MSLD'

 

Edited by zhengshiqi

Share this post


Link to post
Share on other sites
10 hours ago, displhehynehym said:

Is there a reason for SMCLightSensor.kext to not have OSBundleCompatibleVersion?

Not really, it is supposed to have one in my opinion.

Now that we have OpenCore for a better approach of kext injection, there is no more reason to use LiluFriend and put everything inside /L/E, though.

Share this post


Link to post
Share on other sites

I encountered a problem with the latest release of VirtualSMC 1.0.4: the machine lost sleep.

When trying to put the machine to sleep, In the system log I can see an entry repeat itself a couple of times: 

localhost kernel[0]: (AppleACPIPlatform) System sleep prevented by THSS

What can I do to fix this without going back to the previous release?  With the previous releases of VSMC I had no problems whatsoever.

Share this post


Link to post
Share on other sites
4 hours ago, PMheart said:

Not really, it is supposed to have one in my opinion.

Now that we have OpenCore for a better approach of kext injection, there is no more reason to use LiluFriend and put everything inside /L/E, though.

That's great, although I really don't know how to configure OpenCore at this moment.

I've tested it with two Clover-based laptops, and the kext should have OSBundleCompatibleVersion for LiluFriend to load. I just added that in info.plist and LiluFriend loads.

Share this post


Link to post
Share on other sites

Power Nap won't work with gen 3 emulation on the lattest Virtual SMC, if I use gen 2, powernap works flawlesly, with gen 3 it does normal wake with reason "EC RTC"/HID ACTIVITY. I'm using iMacPro,1.1 smbios. 

Share this post


Link to post
Share on other sites
On 5/3/2019 at 11:00 AM, MacKonsti said:

Hi again everyone, what is the procedure please to add support for a new controller, per my post above?

I refer to the Intel NUC8i7BEH2 set up as Macmini8,1 that is using the ITE IT8987E-VG chipset with ID 0x8987.

 

Obviously adding the model to the code/repo is not enough, can anyone kindly provide more information?

It would be appreciated for more models (perhaps) popping out soon... Thanks!

 

Hi everyone, can please someone point to the right direction in order to add support for this I/O controller?

@vit9696 @Pavo and @PMheart your help is appreciated. I have been searching but without success.

Is there a method of creating custom SSDT and redefine or remap the expected SMC keys, for example? Will that work?

Thanks again

Share this post


Link to post
Share on other sites
On 5/27/2019 at 3:19 PM, J1mmyS said:

I encountered a problem with the latest release of VirtualSMC 1.0.4: the machine lost sleep.

When trying to put the machine to sleep, In the system log I can see an entry repeat itself a couple of times: 


localhost kernel[0]: (AppleACPIPlatform) System sleep prevented by THSS

What can I do to fix this without going back to the previous release?  With the previous releases of VSMC I had no problems whatsoever.

Just FYI if anyone else is having a similar problem with sleep: it seems that this was caused by combination of OpenCore 0.0.2 + VirtualSMC 1.0.4.

With Clover r4934 + VirtualSMC 1.0.4 sleep is working normally again.

Share this post


Link to post
Share on other sites

@baohiep, this is a legacy project, which did not make its way forward due to FakeSMC plugins having different driver model and being impossible to effectively glue. In addition to that most of the code in FakeSMC is unfortunately quite messed up, so the whole idea was considered a failure soon afterwards. Thanks for reminding, I removed the branch.

Share this post


Link to post
Share on other sites
Posted (edited)

HI @vit9696

 

I don't find how to set SMC plugins in VirtualSMC/Content and create Ressources folder. And how to update plugins newest version ?

 

Please

 

Sorry for my bad English

Edited by Matgen84

Share this post


Link to post
Share on other sites
On 6/3/2019 at 7:25 PM, J1mmyS said:

Just FYI if anyone else is having a similar problem with sleep: it seems that this was caused by combination of OpenCore 0.0.2 + VirtualSMC 1.0.4.

With Clover r4934 + VirtualSMC 1.0.4 sleep is working normally again.

 

I have figured out what breaks the sleep in my case.

 

If I configure platformdata manually, I can set SmcRevision to any arbitrary value which allows the machine to sleep.

If I set SmcRevision manually to zero, or if I enable autoconfigure according to generic information (in my case iMacPro1,1) the machine will not enter sleep.

 

Please, what should I do - what is the best practice?

Share this post


Link to post
Share on other sites
Posted (edited)
18 hours ago, J1mmyS said:

I have figured out what breaks the sleep in my case.

 

If I configure platformdata manually, I can set SmcRevision to any arbitrary value which allows the machine to sleep.

If I set SmcRevision manually to zero, or if I enable autoconfigure according to generic information (in my case iMacPro1,1) the machine will not enter sleep.


I'd like to second this. My sleep has not been working for the past week or two (I'm guessing when I updated to OpenCore 0.0.2 and VirtualSMC 1.0.4). 

 

Setting up the SMC-related options under PlatformInfo/DataHub in my OpenCore configuration has fixed sleep for my X299 system.

Edited by Tony Arnold
Typographic fixes.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×