Contribute
Register

Native DSDT/AML IDE & Compiler: MaciASL Open Beta

Status
Not open for further replies.
Not sure what you mean by "royal mix of solutions." I used each SSDT tool separately and tested each time for P-States. I didn’t change anything else.

In any case, just changing my SMBios to Mac3,1 seemed to do the trick. Without using a customized SSDT I get P-States of 12,13,14,15,16,21. I have a feeling that MacMan's DSDT (from DSDT downloads here) has native power management built in. If I use MaciASL to create a customized SSDT I get P-States of 16,17,18,19,20.

And I do put .aml files in /Extra. That was a typo. The only thing in E/E is FakeSMC.

BTW do I need to use "EnableC2State" and C3, C4? The bios of the Gigabyte baoard looks to have C3. C5. C7?
 
Build 1
Z390 AORUS PRO WIFI |  i9 9900K |  Radeon Other
Thank you! Seems like common sense to at least have a link to the project site on the post.
 
@SJ

One thing I've noticed is that recent versions of MaciASL are sorting the .maciasl patches. It would be nice if this sorting was removed or there was a way for a patch repo author to disable it.

The code responsible is in -beginSheet in patch.m. I have disabled it in my fork:
Code: 
    //REVIEW_REHABMAN: this screws up various .maciasl repos where the order has already been pre-determined
    // and customized.  Let's just not sort for now...
    //if (!sourceView.sortDescriptors.count)
    //    sourceView.sortDescriptors = @[[NSSortDescriptor sortDescriptorWithKey:@"name" ascending:true selector:@selector(localizedStandardCompare:)]];

It causes problems for most of my patch repos where I group patches into categories or sections.

Laptop patches:
Code: 
=> Various Syntax Error Fixes	NullPatch.txt
Fix _PLD Buffer/Package Error	fix_PLD.txt
Fix TNOT Error	fix_TNOT.txt
Fix FPED Parse Error	fix_FPED.txt
=> Intel Graphics Patches (HD3000/HD4000)	NullPatch.txt
HD3000 Low Resolution	graphics_HD3K_low.txt
HD3000 High Resolution	graphics_HD3K_high.txt
HD4000 Low Resolution	graphics_HD4K_low.txt
HD4000 High Resolution	graphics_HD4K_high.txt
HD3000 on 7-series	graphics_MEI_sandy.txt
Generic with EDID	graphics_EDID.txt
Brightness fix	graphics_PNLF.txt
Rename GFX0 to IGPU	graphics_Rename-GFX0.txt
=> USB (ECHI) Patches	NullPatch.txt
6-series USB	usb_6-series.txt
7-series USB	usb_7-series.txt
=> Battery Patches	NullPatch.txt
Acer Aspire 4830T	battery_Acer-Aspire-4830T.txt
Acer Aspire 5750g	battery_Acer-Aspire-5750g.txt
ASUS N55SL	battery_ASUS-N55SL.txt
Compaq CQ60	battery_Compaq-CQ60.txt
Dell XPS 13	battery_Dell-XPS-13.txt
HP Envy DV6	battery_HP-Envy-DV6.txt
HP G6 2221ss	battery_HP-G6-2221ss.txt
Lenovo Twist	battery_Lenovo-Twist.txt
Lenovo Ux10-Z580	battery_Lenovo-UX10-Z580.txt
Lenovo X220	battery_Lenovo-X220.txt
Lenovo y580	battery_Lenovo-y580.txt
Samsung RF411	battery_Samsung-RF411.txt
Samsung Series3	battery_Samsung-Series3-NP300.txt
Sony VAIO S	battery_Sony-VAIO-S.txt
Sony VAIO SVE	battery_Sony-VAIO-SVE1511.txt
=> Atheros WiFi Patches	NullPatch.txt
AR9285 WiFi RP02-PXSX	wifi_AR9285-RP02-PXSX.txt
AR9285 WiFi RP02-WLAN	wifi_AR9285-RP02-WLAN.txt
AR9285 WiFi RP02-WNIC	wifi_AR9285-RP02-WNIC.txt
AR9285 WiFi RP03-PXSX	wifi_AR9285-RP03-PXSX.txt

Or in my 4530s repo, it is a series of steps:
Code: 
=> First, choose one of the following:	NullPatch.txt
ProBook 4x30s	4x30s.txt
ProBook 4x40s Ivy Bridge	4x40s_IvyBridge.txt
ProBook 4x40s Sandy Bridge	4x40s_SandyBridge.txt
=> Next, choose your screen type:	NullPatch.txt
IGPU/LVDS Single-Link	03a_HDMI.txt
IGPU/LVDS Dual-Link	03b_1080p+HDMI.txt
=> Finally, choose your desired fan behavior:	NullPatch.txt
Fan and Temps (original fan patch)	04a_FanPatch.txt
Fan and Temps (quiet fan)	04b_FanQuiet.txt
Fan and Temps (readings only)	04c_FanSpeed.txt
Fan and Temps (quiet fan mod)	04b_FanQuietMod.txt
=> Optionally, ARPT patch for AR9285 Atheros WiFi	NullPatch.txt
Atheros 9285 WiFi AirPort Patch	08_AR9285.txt

Of course, the sorting really messes with the presentation.

If you wanted to implement some sort of "folder/grouping" natively that would be great too...
 
The sorting was a request I implemented to keep display order stable for repositories and their patches. Though the process of loading the repositories is asynchronous, they should still keep to a particular order for ease of use. Alphabetizing them makes it simpler for users to find what they're looking for.
You're trying to add separators using "null" patches which I think is inappropriate; the tree isn't a menu as you're using it, it's a simple sorted list with two levels. If there are instructions they should be in the patch's header; if there are patches to be completed in sequence they should be in the same patch. All grouping should be implemented at the repository level, that was provided since the beginning.
A few times I considered more markup/grouping, but simplicity is key here; it's not a profile page looking for more glitz =>*★⭑. Simple is readable, and grouping by repository keeps things usage-based: users shouldn't see patches which don't relate to their concerns.
The only feature I foresee implementing at some point is a kind of directory or P2P method for discovering more repositories. The repositories themselves are just abstract collections of patches, but finding them could be made easier, even if the discovery method isn't hard-coded to Sourceforge.
 
SJ_UnderWater said:
The sorting was a request I implemented to keep display order stable for repositories and their patches. Though the process of loading the repositories is asynchronous, they should still keep to a particular order for ease of use. Alphabetizing them makes it simpler for users to find what they're looking for.
You're trying to add separators using "null" patches which I think is inappropriate; the tree isn't a menu as you're using it, it's a simple sorted list with two levels. If there are instructions they should be in the patch's header; if there are patches to be completed in sequence they should be in the same patch. All grouping should be implemented at the repository level, that was provided since the beginning.
A few times I considered more markup/grouping, but simplicity is key here; it's not a profile page looking for more glitz =>*★⭑. Simple is readable, and grouping by repository keeps things usage-based: users shouldn't see patches which don't relate to their concerns.
The only feature I foresee implementing at some point is a kind of directory or P2P method for discovering more repositories. The repositories themselves are just abstract collections of patches, but finding them could be made easier, even if the discovery method isn't hard-coded to Sourceforge.
Click to expand...

For the ProBook, it would be quite unwieldy to have a all patches for each configuration in a single patch file. There would be 90 different combinations! I'm clearly not looking for any glitz, just trying to make my repo(s) easier to use. You have probably seen my posts, which tend to be low on glitz. As an example, I use old school smileys.

But no worries, I will work around it... something like:

Code: 
[1.0] == First, choose one of the following ==	NullPatch.txt
[1.1]  ProBook 4x30s	4x30s.txt
[1.2]  ProBook 4x40s Ivy Bridge	4x40s_IvyBridge.txt
[1.3]  ProBook 4x40s Sandy Bridge	4x40s_SandyBridge.txt
[2.0] == Next, choose your screen type ==	NullPatch.txt
[2.1]  IGPU/LVDS Single-Link	03a_HDMI.txt
[2.2]  IGPU/LVDS Dual-Link	03b_1080p+HDMI.txt
[3.0] == Finally, choose your desired fan behavior ==	NullPatch.txt
[3.1]  Fan and Temps (original fan patch)	04a_FanPatch.txt
[3.2]  Fan and Temps (quiet fan)	04b_FanQuiet.txt
[3.3]  Fan and Temps (readings only)	04c_FanSpeed.txt
[3.4]  Fan and Temps (quiet fan mod)	04b_FanQuietMod.txt
[4.0] == Optionally, ARPT patch for AR9285 Atheros WiFi ==	NullPatch.txt
[4.1]  Atheros 9285 WiFi AirPort Patch	08_AR9285.txt

:)
 
Added a device properties panel to the repository, powered by the IORegistry. For those interested in keeping track of what their DSDT and/or bootloader is doing, this is invaluable. Since IOACPIPlane entries rarely align with those in IOService or IODeviceTree, the entries are identified by device name, which should keep things simple. Keep in mind the panel's data is only updated by rebooting, but keeping it open while making edits can be very useful. Also try rebooting without closing MaciASL for a faster feedback loop.
0MmouZJ.png
 
Pushed an update which allows IOJones files to be read by MaciASL, producing a temporary tableset file from which any or all ACPI tables could be opened. This also means only one file (.iojones) is required from a real mac to provide information for both apps.
 
Added a few features, including new table definitions, a top-level exception handler, true asynchronous and concurrent network access, and a network reachability test for those with spotty internet access. Instead of failing outright, network requests will be queued until internet access is restored.
Also rewrote the Spotlight importer in CoreFoundation for those on Snow Leopard, and for reduced memory footprint.
 
1. The latest binary on sourceforge.net is from 2013-08-01. I got the source and compiled it.

There is a warning:
Fix.m:16:13: 161 enumeration values not handled in switch: 'ASL_MSG_RESERVED', 'ASL_MSG_ALIGNMENT', 'ASL_MSG_ALPHANUMERIC_STRING'...

I don't have expirience with OSX programming yet.
Can I ignore this warning and use version 1.3 build 251 ?

2. How to create a .acpi file for all tables, so I don't get errors from external definitions in DSDT ?

Thanks
 
All that warning says is I haven't finished the fix-it feature. Choose "Export Tableset" to save a .acpi (tableset) file
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top