Jump to content
Slice

Different sensors projects

51 posts in this topic

Recommended Posts

Guys,

Don't mix 6.18 and 3.41.

 

There are three different projects for monitoring temperatures, voltages, fans speed and other hardware parameters:

Initially it was FakeSMC with plugins for producing SMC keys for hardware parameters for different hardware. But sometimes ago Kozlek separated own version of FakeSMC and producing new set of plugins while I stay with good working version 3. So..

1. FakeSMC v3 with Hardware Sensors3  which I still supported.

2. FakeSMC v6 (rev1800) by Kozlek and supported by Rehabman. AFAIK both are abandoned and the project is not supported. Or may be maintained by coauthors.

3. New VirtualSMC by vit9696 with own set of sensors kexts. It depends on Lilu.kext. The project is in active development.

All three project have incompatible interfaces sensors<->SMC so they are incompatible with each other.

 

There are applications for monitoring hardware parameters and they commonly depends on these projects.

1. iStat, iStatMenu, iStatPro compatible with real Macs because they use SMC keys just like those presents in real Macs.

2. HWMonitorSMC by Navi (initial codes from Kozlek)  used in my HWSensors3.

3. HWMonitor by Kozlek with graphics like in IntelPowerGadget used in his HWSensors version.

4. HWMonitorSMC2 by Vector_Sigma tends to be universal supporting all project. It also may use sensors information produces by Apple graphics and by IntelPowerGadget.

 

Let us discuss here differences and common ideas for this projects.

 

Share this post


Link to post
Share on other sites
Advertisement

Hi
By reading through the thread here, not sure if the current Sensors work.... is this card supported?

 

vclist v1.0.2 (vector sigma 2018-2019), found 1 graphics card!
----------------------------------------------------
Model               = Radeon RX Vega 56
vendor ID           = <02100000>
vendor ID           = <7f680000>
revision ID         = <c3000000>
subsystem ID        = <88230000>
sub system VendorID = <8c140000>


Device Utilization  = 0%
Total Power         = 15 Watts
Temperature         = 47°
Fan Speed           = 0 RPM
Fan Speed           = 28%
vram Used           = 126513152 bytes
vram Free           = 3500003264 bytes


Metal properties:
Max Threads Per Thread group = width 1024, height 1024, depth 1024
Max Thread group Memory Length = 65536
Recommended Max Working Set Size = 0xFF000000
Depth 24 Stencil 8 Pixel Format = true
Programmable Sample Positions = true
Read-Write Texture  = 2
Headless            = false
Is Low Power        = false
Removable           = false

I would like to Monitor Power, Temp and Fan-Speed.

 

Thanks, Mike

Share this post


Link to post
Share on other sites
7 hours ago, jinbingmao said:

 

Added fan and voltage reporting in SMCSuperIO through I/O Registry (requires client updates) by @joedmru

 

https://github.com/acidanthera/VirtualSMC/commit/ab5e40d02a4079bc35ecffec51fb601fd21cf738

If someone will provide a ioreg...

9 minutes ago, Mike Ranger said:

Hi
By reading through the thread here, not sure if the current Sensors work.... is this card supported?

 


vclist v1.0.2 (vector sigma 2018-2019), found 1 graphics card!
----------------------------------------------------
Model               = Radeon RX Vega 56
vendor ID           = <02100000>
vendor ID           = <7f680000>
revision ID         = <c3000000>
subsystem ID        = <88230000>
sub system VendorID = <8c140000>


Device Utilization  = 0%
Total Power         = 15 Watts
Temperature         = 47°
Fan Speed           = 0 RPM
Fan Speed           = 28%
vram Used           = 126513152 bytes
vram Free           = 3500003264 bytes


Metal properties:
Max Threads Per Thread group = width 1024, height 1024, depth 1024
Max Thread group Memory Length = 65536
Recommended Max Working Set Size = 0xFF000000
Depth 24 Stencil 8 Pixel Format = true
Programmable Sample Positions = true
Read-Write Texture  = 2
Headless            = false
Is Low Power        = false
Removable           = false

I would like to Monitor Power, Temp and Fan-Speed.

 

Thanks, Mike

Looks like you already know what the app will show..

Share this post


Link to post
Share on other sites

Not sure I understand... I am using a older version FakeSMC with specially tuned GPUSensors from KGP.

My boodloader is OpenCore.

I would like to switch to either VirtualSMC or your fork of FakeSMC with HWSensors, the question is if my card (Vega56) would work.

Since I use OpenCore, just switching kexts is not quite so easy, so ideally you could give me an indication.

Thanks, Mike

Share this post


Link to post
Share on other sites
Posted (edited)
20小时前,vector sigma说:

如果有人提供碘酒...

看来您已经知道该应用程序将显示什么。

Looking forward to joining soon

 

Edited by jinbingmao

Share this post


Link to post
Share on other sites

Looks great.... all temps recorded correctly in the HW-Sensors App.

Sorry if I ask this... but why would this not fully support Istat?

Everything shown in HWMonitorSMC2, really not much in Istat.

Regards, Mike

Share this post


Link to post
Share on other sites
18 minutes ago, Mike Ranger said:

Looks great.... all temps recorded correctly in the HW-Sensors App.

Sorry if I ask this... but why would this not fully support Istat?

Everything shown in HWMonitorSMC2, really not much in Istat.

Regards, Mike

 

I'm not using iStat, but Sensei shows temps and fans. 

 

scrns-bega-56-comp-00001.thumb.jpg.9af9e92b8d8b93508049ce7c6b8e967c.jpg

scrns-bega-56-comp-00002.thumb.jpg.630749c6bc71c55e2ea1a15e414b05fd.jpg

scrns-bega-56-comp-00003.thumb.jpg.a84ca29bc2410e06d61f101844efeba3.jpg

Share this post


Link to post
Share on other sites

Wow... really cool...gotta try Sensei

Well.... now I am stuck.... I don't know how to write some DSDT code for the LCP sensors.

Most of the stuff looks good.

CPU multipliers dont work.... some temps are off.

 

Share this post


Link to post
Share on other sites

So I can confirm that everything works.... 

In order to get more functionality, I would have to create a DSDT for the LCP  sensors. The problem I have however is, that looking through my DSDT, I have no good idea how to translate this info correctly.

I will try to better understand.

 

Share this post


Link to post
Share on other sites

Same context, different question.

Is there a way to tweak / discover the sensors for VirtualSMC in a similar way, in particular the LPC sensors.

Thanks, Mike

Share this post


Link to post
Share on other sites

I really dont understand.... Sensor-Reading and VirtualSMC / FakeSMC should be one unit, why separate it?

I also dont understand, why with VirtualSMC, only HWMonitorSMC2 show the majority of the Sensor Data and all standard Mac Software (like Istat) basically shows nothing.

Should not the goal be that standard Mac software can utilise / work with the sensor data provided?

 

 

 

Share this post


Link to post
Share on other sites
9 hours ago, Mike Ranger said:

I really dont understand.... Sensor-Reading and VirtualSMC / FakeSMC should be one unit, why separate it?

I also dont understand, why with VirtualSMC, only HWMonitorSMC2 show the majority of the Sensor Data and all standard Mac Software (like Istat) basically shows nothing.

Should not the goal be that standard Mac software can utilise / work with the sensor data provided?

 

 

 

FakeSMC with sensors is different from VirtualSMC with sensors. They provide different info for system. It is not my affair why VirtualSMC shows nothing.

Share this post


Link to post
Share on other sites

it is funny... i posted the same question in VirtualSMC Thread and was told i should post here.

Not that it matters, I agree with you that VirtualSMC should provide the values so that any Mac-App can utilize.

Who is the responsible programmer for VirtualSMC....

This all sounds a bit "political" to me.

Share this post


Link to post
Share on other sites
18 hours ago, Mike Ranger said:

I really dont understand.... Sensor-Reading and VirtualSMC / FakeSMC should be one unit, why separate it?

I also dont understand, why with VirtualSMC, only HWMonitorSMC2 show the majority of the Sensor Data and all standard Mac Software (like Istat) basically shows nothing.

Should not the goal be that standard Mac software can utilise / work with the sensor data provided?

 

 

 

VSMC sensors do not create SMC keys so they arent compatible with other software, voltages must be read from IOReg, not from SMC Keys

there is no "standard" software for Mac, and there is no "standard" software for Hackintosh, each developer uses his own keys

some of them are from real Mac, some of them are different

 

PS even FakeSMC plugins by Slice and FakeSMC by Kozlek use partially incompatible keys

Edited by Rodion2010

Share this post


Link to post
Share on other sites
On 1/7/2020 at 5:08 PM, Mike Ranger said:

Wow... really cool...gotta try Sensei

Well.... now I am stuck.... I don't know how to write some DSDT code for the LCP sensors.

Most of the stuff looks good.

CPU multipliers dont work.... some temps are off.

 

Oh man! Sensei looks cool but doesn't work with Mojave :cry:

Share this post


Link to post
Share on other sites

Hello, from our point of view there are serious terminology and organisation issues.

 

— There exists a SMC emulator: FakeSMC or VirtualSMC.

— There exists a driver providing sensor information: Intel Power Gadget kernel extension, macOS GPU kexts, Acidanthera Sensors or HWSensors. The driver does not necessary relate to the SMC emulator, as it can report sensor data with multiple methods.

— There exists an application interpreting sensor information data: HWMonitor, HWMonitorSMC2, iStat Menus, etc.

 

We believe it does not make sense to discuss sensor drivers and sensor applications in SMC emulator threads, they simply do not relate close enough to each other. The only case where we could imagine it be discussed is some API interaction with the emulator during driver development.

 

From the presence of HWMonitorSMC2 in the first message we believe this is a joint thread for HWSensors (drivers) and HWMonitorSMC2 (sensor apps). So for us it makes good sense to request features for the latter here.

 

If this thread is considered exclusive to HWSensors drivers, then it would be great if you create a dedicated thread for HWMonitorSMC2 for us to interact altogether. Moving messages to VirtualSMC thread is inadequare as VirtualSMC thread has nothing to do to sensors, and in fact it is even outside of the hardware sensors forum.

 

Regarding our new sensors format, as we said previously, we added Super I/O data reporting through I/O Registry in raw format, and need application authors to interpret the data. The formats, modulators and demodulators differ a little, so we created a thread with datasheets here: https://applelife.ru/threads/datasheets-k-chipam-superio.2944734/.

 

Cheers and thanks for understanding =)

Share this post


Link to post
Share on other sites

Thanks all for clarifying. I can confirm that the new Super I/O is really working great. All is missing is the link to the well known Apps like Istat for example.

The question is really if I understood you correctly:

 

How to close that bridge from the raw data Super I/O to, for example IStat, which most Mac/Hack users have installed and using. I think the main reason that not more users have switched to VirtualSMC is exactly that reason.... and sorry for stating that in this thread....hope it is not off-topic.

 

If I officially submit that as a request, where would that go.... into the VirtualSMC one?

 

Thanks again, Mike

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.

  • Similar Content

    • By kevin_1351
      tl;dr: VirtualSMC causes me a flood of log messages and correlated cpu spikes. FakeSMC doesn't.
       
      Hi, I have almost finalized my Huawei Matebook X Pro Opencore setup and everything is working very well besides wifi/bt ofc (which is about to change).
       
      However, I noticed how the cpu usage sometimes went up a little and when looking at the Console I could see a never-ending flood of:
      default 14:05:05.983292+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:05.982975+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:05.982996+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985932+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985949+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.986134+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426574+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:39.426729+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426585+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431085+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431097+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431246+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433068+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:42.433227+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433078+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434453+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434465+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434622+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:44.436155+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:44.436166+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0  
      As you can see, multiple of these per second. Another guy with the same computer is also having this issue and posted a dsdt change to fix it. This fix didn't solve anything though
      He tried to limit the Notify call by implementing a state change requirement before calling Notify.
       
      Here is the original acpi:
      Scope (_SB) { Device (LID) { Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } ^^PCI0.GFX0.CLID = Local0 Return (Local0) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } Notify (LID, 0x80) // Status Change } } Which he changed to: 
      Scope (_SB) { Device (LID) { Name (_OLD, One) // assuming everything else.. the lid should start open? Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } Return (Local0) } } Device (PNLF) { Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } If ((^^^^LID._OLD != Local0)) { Notify (LID, 0x80) // Status Change ^^^^LID._OLD = Local0 } } } Besides me not seeing any reason to declare _OLD in LID. The idea itself shouldn't be too bad right? Well, as I said, his fix didn't work.
       
      In fact, to prove that Method _Q81 doesn't have anything to do with the issue at all, I created a Clover/Opencore patch to change _Q81 to XQ81. This resulted in my lid not working at all of course, but the log flooding still persisted!
      So _Q81 doesn't have anything to do with the issue afaik.
       
      Now, further Google searches led me to a chinese post where he tied the issue to VirtualSMC. And indeed, by migrating to FakeSMC the issue is no more.
       
      Unfortunately, I'm very fond of VirtualSMC for various reasons. So I would very much like to keep it. If not I'd have to implement the old way of doing Battery monitoring etcetc. Which isn't very elegant and update proof as it requires DSDT patching.
       
      So, I do believe that the issue may very well be in the DSDT code, perhaps in the ambient light part. I'm not very skilled at this and just started studying the ACPI spec 3 days ago.
       
      Could someone please help me out? Thanks a lot in advance
       
       
      origin.zip
      OC.zip
    • By Slice
      This thread devoted to share information about different SMC keys found or investigated anywhere.
       
      What are they?
      SMC keys is a somehow language to speak between macOS and hardware microcontroller presented in real Mac and absent in Hackintosh.
      They inform macOS about Hardware ID and current status. Moreover macOS can write something through SMC protocol to control hardware.
      FakeSMC ( ©Netkas) is the driver to emulate this microcontroller on PC having no such device which is necessary to boot macOS here.
      But FakeSMC contain only ~20 keys while real Mac answers ~200 keys.
      Some keys we added by HWSensors project reporting temperatures, FAN speeds, voltages etc.
      Some keys are model dependent was added by Clover to be sure if user changed model in GUI then corresponding keys will be changed automatically.
      Clover sets
      LogDataHub(&gEfiMiscSubClassGuid, L"RPlt", &gSettings.RPlt, 8);
      LogDataHub(&gEfiMiscSubClassGuid, L"RBr", &gSettings.RBr, 8);
      LogDataHub(&gEfiMiscSubClassGuid, L"EPCI", &gSettings.EPCI, 4);
      LogDataHub(&gEfiMiscSubClassGuid, L"REV", &gSettings.REV, 6);
      LogDataHub(&gEfiMiscSubClassGuid, L"BEMB", &gSettings.Mobile, 1);
      BEMB - is a mobility sign. =0 -desktop, =1 - mobile.
      REV - SMC hardware revision, changes sometimes with Apple updates.
      RPlt, RBr and EPCI is hardware capabilities, noticed used in Intel HD drivers.
       
      Structure.
      All SMC keys consists of name 4 ascii chars as 32bit integer, type and value.
      Types:
       "flag", len 1
       "ui8 ", len 1
       "ui16", len 2
       "sp78", len 2
       "ui32", len 4
      "fp2e", len 2
      "fpe2", len 2
      "{rev", and others...
       
      List of known keys
      SMC_list.plist.zip
      More keys will be discussed in the thread
       
       
      Feel free to share you knowledge and ask about noticed keys.
    • By Slice
      Hi all,
       
      I created an installer for my version of FakeSMC with plugins and applications latest revision.
       
      Compatibility from 10.6 up to 10.15.
      Test, please.

      Download here: HWSensors.pkg.zip
      See my signature
       
      02.11.2019
      New project home
      https://github.com/CloverHackyColor/FakeSMC3_with_plugins
      FakeSMC v3.5.3 and plugins
       
      HWMonitorSMC2 at
      https://github.com/CloverHackyColor/HWMonitorSMC2
       
       
      FakeSMC 3.4.0 revision 751
      HWSensors.pkg-751.zip
       
      New project home is
      https://sourceforge.net/projects/hwsensors3.hwsensors.p/
      where you can download most recent versions.
      Now it is FakeSMC 3.4.1
       
      Explanations about the difference between versions 3 and 6
        #137 
       
      20.05.2016
      Revision 32 with explanation at    #220 
       
      10.10.2017
      FakeSMC is 3.5.0 compatible with High Sierra.
      New plugin VoodooBatterySMC created on the base of VoodooBattery by Superhai but with SMC keys generating to show Battery voltage and amperage. As well it created key BATP needed for right speedstep and FileVault2.
      Other kexts revised.
×