Jump to content

2,087 posts in this topic

Recommended Posts

@vector sigma

Look please

HWMonitorSMC/Interface/HWOulineView.swift:82:49: error: cannot convert value of type 'String' to expected argument type 'NSImage.Name'
        self.graphButton.image = NSImage(named: "freq_small")
                                                ^~~~~~~~~~~~
                                                NSImage.Name(rawValue:  )

rev 240

Share this post


Link to post
Share on other sites
Advertisement
21 hours ago, Slice said:

@vector sigma

Look please


HWMonitorSMC/Interface/HWOulineView.swift:82:49: error: cannot convert value of type 'String' to expected argument type 'NSImage.Name'
        self.graphButton.image = NSImage(named: "freq_small")
                                                ^~~~~~~~~~~~
                                                NSImage.Name(rawValue:  )

rev 240

Hi, the "named" initializer was introduced in swift 4.2, and unless Apple reverted some happy changes I'm not aware of, looks like are you using an old Xcode.

 

If you want build pkg/dmg installers with kexts built with old Xcode among the monitor 2 with full ability, if that is the case, there's a warkaround I made:

  1. build extensions in a older OS
  2. reboot to latest OS and copy pre built kexts inside a sub directory of the root of the project called "kexts_prebuilt"
  3. make pkg.... but with pre built extensions and with latest sdk available for the apps (Xcode 11 adviced). Using latest sdk will activate some new functionalities for the newer OS, otherwise unavailable (like for example the ability to follow the dark/light appearance of the OS and the line color for the graphs based on that)

 

Share this post


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

Hi, the "named" initializer was introduced in swift 4.2, and unless Apple reverted some happy changes I'm not aware of, looks like are you using an old Xcode.

 

If you want build pkg/dmg installers with kexts built with old Xcode among the monitor 2 with full ability, if that is the case, there's a warkaround I made:

  1. build extensions in a older OS
  2. reboot to latest OS and copy pre built kexts inside a sub directory of the root of the project called "kexts_prebuilt"
  3. make pkg.... but with pre built extensions and with latest sdk available for the apps (Xcode 11 adviced). Using latest sdk will activate some new functionalities for the newer OS, otherwise unavailable (like for example the ability to follow the dark/light appearance of the OS and the line color for the graphs based on that)

 

OK, but

Dell:hwsensors3 sergey$ make pkg
** Using HWSensor trunk **
** Using HWSensor's pre built extensions **

ACPIMonitor.kext (1.0.3)
AmdCPUMonitor.kext (1.0.2)
F718x.kext (1.0.1)
FakeSMC.kext (3.5.2)
GeforceSensor.kext (1.2.4)
ITEIT87x.kext (1.0.7)
IntelCPUMonitor.kext (1.2.3)
NVClockX.kext (1.0.2)
PC8739x.kext (1.0.1)
RadeonMonitor.kext (1.3.4)
SMIMonitor.kext (1.1.0)
VoodooBatterySMC.kext (1.6.1)
W836x.kext (1.3.4)
X3100.kext (1.0.1)

** Building HWMonitorSMC.app v1 **
** Building HWMonitorSMC.app v2 **
swift 5.0.1 will be used..
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/Interface/PopoverWindowController.swift:34:8: warning: instance method 'windowDidResize' took 101ms to type-check (limit: 100ms)
  func windowDidResize(_ notification: Notification) {
       ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/Interface/Preferences/PreferencesVC.swift:288:8: warning: instance method 'getPreferences()' took 100ms to type-check (limit: 100ms)
  func getPreferences() {
       ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/SystemKit/Display.swift:206:27: warning: static method 'getDisplayInfo(screen:displayLocations:)' took 499ms to type-check (limit: 100ms)
  fileprivate static func getDisplayInfo(screen: NSScreen, displayLocations: inout [String]) -> String {
                          ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/SMC.swift:83:12: warning: expression took 470ms to type-check (limit: 100ms)
    return (UInt8(self >> 6), UInt8((self << 2) ^ ((self >> 6) << 8)))
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/SMC.swift:82:8: warning: instance method 'toFPE2()' took 471ms to type-check (limit: 100ms)
  func toFPE2() -> FPE2 {
       ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/SMC.swift:122:12: warning: expression took 105ms to type-check (limit: 100ms)
    return "\(String(describing: UnicodeScalar(self >> 24 & 0xff)!))\(String(describing: UnicodeScalar(self >> 16 & 0xff)!))\(String(describing: UnicodeScalar(self >> 8  & 0xff)!))\(String(describing: UnicodeScalar(self       & 0xff)!))"
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/SMC.swift:121:8: warning: instance method 'toString()' took 105ms to type-check (limit: 100ms)
  func toString() -> String {
       ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/AppDelegate.swift:92:7: error: use of unresolved identifier 'IntelEnergyLibShutdown'
      IntelEnergyLibShutdown()
      ^~~~~~~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/AppDelegate.swift:89:8: warning: instance method 'applicationWillTerminate' took 4179ms to type-check (limit: 100ms)
  func applicationWillTerminate(_ aNotification: Notification) {
       ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:21:6: error: 'Int32' is not convertible to 'Bool'
  if IsGTAvailable() {
     ^~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:40:8: error: 'Int32' is not convertible to 'Bool'
    if GetGTFrequency(&gtFreq) {
       ^~~~~~~~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:57:8: error: use of unresolved identifier 'GetGpuMaxFrequency'
    if GetGpuMaxFrequency(&gtMaxFreq) {
       ^~~~~~~~~~~~~~~~~~
__ObjC.GetGTFrequency:1:13: note: did you mean 'GetGTFrequency'?
public func GetGTFrequency(_ freq: UnsafeMutablePointer<Int32>!) -> Int32
            ^
__ObjC.GetBaseFrequency:1:13: note: did you mean 'GetBaseFrequency'?
public func GetBaseFrequency(_ iNode: Int32, _ pBaseFrequency: UnsafeMutablePointer<Double>!) -> Int32
            ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:18:6: warning: global function 'getIntelPowerGadgetGPUSensors()' took 1391ms to type-check (limit: 100ms)
func getIntelPowerGadgetGPUSensors() -> [HWMonitorSensor] {
     ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:205:3: error: use of unresolved identifier 'GetThresholds'
  GetThresholds(0, &degree1C, &degree2C)
  ^~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:211:3: error: use of unresolved identifier 'GetCpuUtilization'
  GetCpuUtilization(0, &cpuutil)
  ^~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/IntelPowerGadget.swift:125:6: warning: global function 'getIntelPowerGadgetCPUSensors()' took 152ms to type-check (limit: 100ms)
func getIntelPowerGadgetCPUSensors() -> [HWMonitorSensor] {
     ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/Interface/PopoverViewController.swift:185:40: error: cannot assign value of type 'Int32' to type 'Bool'
            self.useIntelPowerGadget = IntelEnergyLibInitialize()
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/Interface/PopoverViewController.swift:307:8: warning: instance method 'initialize()' took 120ms to type-check (limit: 100ms)
  func initialize() {
       ^
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/HWSensorScanner.swift:26:10: warning: expression took 107ms to type-check (limit: 100ms)
  return UInt(((Int(value) & 0xff00) >> 8) | ((Int(value) & 0xff) << 8))
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/sergey/Documents/Projects/hwsensors3/trunk/hwmonitor2/HWMonitorSMC/HWMonitorSensors/HWSensorScanner.swift:25:18: warning: global function 'swapBytes' took 108ms to type-check (limit: 100ms)
fileprivate func swapBytes(_ value: UInt) -> UInt {
                 ^
note: Using new build systemnote: Planning buildnote: Constructing build description
** BUILD FAILED **

 

Share this post


Link to post
Share on other sites
On 8/29/2019 at 10:20 AM, Slice said:

It appears IPG must be installed for compilation the project. Now I have success and released revision 240.

Good, as soon as I have time I'll make the build script aware of the dependency.

Edited by vector sigma

Share this post


Link to post
Share on other sites
12 hours ago, STLVNUB said:

its FREE

 

IMG_2225.jpeg

 

Just tried, but It gives me a lot of readings in less, considering HWMonitorSMC2 has also some more stuff I need to scroll to be shown:

239288864_Schermata2019-08-30alle13_09_01.thumb.png.14d6b71ae202776b4bfda023203aac1d.png

...and without any FakeSMC plugins installed, just IPG. 

P.S. I guess none of your components reach 129 C°, I hope

Edited by vector sigma

Share this post


Link to post
Share on other sites

Well I suspect that nobody has tried on real HW let alone earlier OSX/Mac Os

My Plan is to make HWMonitor compatible with SnowLeopard onward and iron out any bugs

As you can see, it shows heaps more info on REAL Apple hardware

Just need to fix some obvious bugs.

Share this post


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

Well I suspect that nobody has tried on real HW let alone earlier OSX/Mac Os

My Plan is to make HWMonitor compatible with SnowLeopard onward and iron out any bugs

As you can see, it shows heaps more info on REAL Apple hardware

Just need to fix some obvious bugs.

I afraid Kozlek made it for 10.7+ systems. You may try also HWMonitorSMC version 1 which should work in 10.6 with minimum changes. May be just recompile it with SDK10.6.

Share this post


Link to post
Share on other sites
2 hours ago, STLVNUB said:

My Plan is to make HWMonitor compatible with SnowLeopard onward and iron out any bugs

you need to downgrade the code turning off ARC and use manual retain/release of memory of each object in the project. IMHO you should forget 10.6.

To add s.m.a.r.t. for NVMe in latest macs you can port my code if you want, otherwise will be no disk to show in HWMonitor in real macs.

Good luck

Share this post


Link to post
Share on other sites
On 7/29/2019 at 10:39 AM, Slice said:

I see you have "ITE8708" so usual plugin ITE87X should work on your hardware but there is no such id. There are:


  IT8705F = 0x8705,
  IT8712F = 0x8712,

I will add here 8708 a little later.

 

Hi @Slice thanks again for your help! I am not so sure my Intel NUC8i7BEH is using 8708 ITE chipset, the official PDF (see page 2 and page 19) mentions ITE IT8987E-VG (most likely chipset ID 0x8987). I am curious as to what my DSDT that you've analysed shows... can you share the lines/device so I can see? Perhaps it's just unused code inside?

 

On 7/29/2019 at 9:50 PM, Slice said:

@MacKonsti  Test, please

ITEIT87x.kext.zip

Meanwhile make kernel.log (or dmesg) to see messages from IT87x kexts.

 

The kext seems to loaded OK but a) no fans shown at all, b) the dmesg or kernel logs do not have any trace of "ite" at all :( I am using your HWSensors v3 r240.

I got to read both dmesg from Hackintool and Terminal... but nothing. Please advise?

 

Terminal output of looking for the kext:

org.mozodojo.ITEIT87x (1.0.4) BB1BAC42-7713-34FD-B5ED-574867853FC6 <16 8 6 5 3>

 

Edited by MacKonsti

Share this post


Link to post
Share on other sites
2 hours ago, Slice said:

Looks like this chip has other operational logic. We need a datasheet for it. But I can't download because they require money

https://vinafix.com/threads/it8987e-datasheet.26578/

I am not sure it's the datasheet you ask. Remember I posted the only PDF that I could find in my previous post here:

 

Source = http://www.datasheetcafe.com/it8987e-datasheet-pdf-controller/
Datasheet = http://datasheetcafe.databank.netdna-cdn.com/wp-content/uploads/2019/04/IT8987E.pdf

 

That PDF is 197KB and judging from the size, I can assume it's the same as the one posted in your found thread (vinafix.com)

What do you think? I can pay 1,50 EUR for 1 day of access (30 downloads max.) but they talk also of "schematic" not "datasheet"...

 

Thanks

Edited by MacKonsti

Share this post


Link to post
Share on other sites
2 hours ago, MacKonsti said:

I am not sure it's the datasheet you ask. Remember I posted the only PDF that I could find in my previous post here:

 

Source = http://www.datasheetcafe.com/it8987e-datasheet-pdf-controller/
Datasheet = http://datasheetcafe.databank.netdna-cdn.com/wp-content/uploads/2019/04/IT8987E.pdf

 

That PDF is 197KB and judging from the size, I can assume it's the same as the one posted in your found thread (vinafix.com)

What do you think? I can pay 1,50 EUR for 1 day of access (30 downloads max.) but they talk also of "schematic" not "datasheet"...

 

Thanks

There are schematic only. I need operational description: how to program access to the chip.

Share this post


Link to post
Share on other sites

ITE 8987 is already included in the latest kext. If you install it correctly then I may propose it works differently from other chips, which I have datasheets.

  IT8987E = 0x8987

 

Share this post


Link to post
Share on other sites

Hi @Slice I believe that I installed is as it should. Downloaded the latest r240 built binaries and installed your test kext. What I understand is that it's not loaded at all. The smc key Fn shows zero as in "no fans reported" hence my request for you to have a look in the DSDT.

 

Is the test ITE kext you offered enable with debug logs or should I do something extra? I am installing FakeSMC.kext and ITEIT87x.kext from /Library/Extensions/ like all other acidanthera's kexts (Lilu, Whatevergreen, AppleALC etc.). Do you recommend Clover instead? I prefer /L/E/ due to ease of management of updates.

 

All other kexts load, except no trace of ITEIT87x.kext... could it be that IT8987 and IT8987E are slightly different?

 

Thank you.

Share this post


Link to post
Share on other sites

1. I know how to debug with Clover. I am not famous with OC.

2. Are you installed FakeSMC 3.5.2? The kext will work ONLY with this version.

3. /L/E is good enough place.

4. IT8987E is a name inside the kext. It doesn't matter how it named. Does matter his ID=0x8987.

Share this post


Link to post
Share on other sites
3 hours ago, Slice said:

1. I know how to debug with Clover. I am not famous with OC.

2. Are you installed FakeSMC 3.5.2? The kext will work ONLY with this version.

3. /L/E is good enough place.

4. IT8987E is a name inside the kext. It doesn't matter how it named. Does matter his ID=0x8987.

 

1. Sorry I did not understand your point #1 :)

 

2. Yes I have installed it from your r240 prebuilt binaries:

org.netkas.FakeSMC (3.5.2) 6278FBFB-B844-3B87-AB22-082386772375 <12 8 6 5 3>

org.slice.IntelCPUMonitor (1.2.3) 836978E0-72AC-3E63-B4F1-E9845CAD238E <16 8 6 5 3>

 

However, interestingly enough, ACPIMonitor.kext does not load, doesn't appear anywhere. Perhaps no ACPI on this generation of NUC?

Nor did the test ITEIT87x.kext load at all :(. No trace of either kext.

 

3. Great /L/E/ is where I have FakeSMC and your plugins.

 

4. Yes understood :) I meant if the ID=0x8987 covers both types of chipset IT8987 and IT8987E as my NUC's datasheet from Intel mentions ITE IT8987E-VG which I hope is not custom! (hence the total lack of proper PDF you would need)

 

9 hours ago, Slice said:

There are schematic only. I need operational description: how to program access to the chip.

 

I totally understand... but the schematic is all I could find. I will consider spending 1,50 EUR via PayPal to access your posted URL (vinafix.com) with the hope it's not the same PDF.

 

In any case, no dmesg or other system logs show any trace of ITE or IT87xx kext. Let me know if I can provide something else... Force-loading them via sudo kextload -v IT87x.kext doesn't help either.

 

P.S. I am also using HWMonitorSMC2 v2.4.9, please consider adding a space character in the MHz that are shown on the menu bar, if the user double clicks e.g. on the CPU frequency. It's easier for the eyes. Now I have e.g. 2200MHz while the dropdown list has 2200 MHz with a space. Thanks!

Share this post


Link to post
Share on other sites

1. If you will boot with Clover then I can propose you to make preboot.log by pressing F2.

 

Other then that set boot-arg msgbuf=1048576. In this case your dmesg will contain more information.

Moreover you can install https://github.com/SergeySlice/IOAudioFamily/releases/download/v206.5/IOAudioFamily.kext-206.5.zip

to make dmesg log much more informative by excluding audio spam.

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
      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.
       
×