adjustor 3.3.0__tar.gz → 3.4.0__tar.gz

{adjustor-3.3.0/src/adjustor.egg-info → adjustor-3.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: adjustor
-Version: 3.3.0
+Version: 3.4.0
 Summary: Adjustor, a userspace program for managing the TDP of handheld devices.
 Author-email: Kapenekakis Antheas <pypi@antheas.dev>
 Project-URL: Homepage, https://github.com/hhd-dev/adjustor
@@ -38,7 +38,7 @@ except intel handhelds and older prior to 6XXX AMD handhelds.
 ## TDP Control
 For the ROG Ally, Ally X and Legion Go that have an ACPI/EC implementation for 
 bios and fan curves,
-Adjustor uses the manufactuer functions for setting TDP.
+Adjustor uses the manufacturer functions for setting TDP.
 For the Allys, the asus-wmi kernel driver is used to set the tdp and manage the
 fan curves.
 For the Go, Lenovo's WMI methods are called through `acpi_call`, which will hopefully
@@ -53,14 +53,14 @@ For more, see [AMD TDP Control Details](#amd-tdp).
 In all cases, there are checks to ensure that the TDP is within the safe range
 of the processors.
 
-## Energy Management
-Adjustor can also manage the energy profile of the processor, by setting EPP
+## Energy Management in Handhelds
+Adjustor can also manage the energy profile of the processor in handhelds, by setting EPP
 and proper frequency values.
 After we transitioned people away from Decky plugins (which had some governor controls)
 to using Handheld Daemon for TDP, we found that Power Profiles Daemon (PPD) 
 would use aggressive CPU values.
 These values are optimized for devices that have a dedicated power budget for the CPU
-(e.g., laptops, desktops), which caused issues with handhelds.
+(e.g., laptops, desktops), which causes undesirable behavior handhelds.
 
 For example, the balanced PPD profile would set EPP to balance_performance and
 enable CPU boost, which would increase the draw of the CPU during gaming by 2W
@@ -91,6 +91,48 @@ TDP range instead of CPU values (which is the user's expectation).
 Of course, depending on TDP and user preference, the CPU governor values will be set
 accordingly.
 
+## Energy Management in other computers
+As we design Handheld Daemon to be enabled in more Deck style devices (e.g., HTPCs), 
+these devices have different power requirements and processors (e.g., Intel), which 
+are better managed with Power Profiles Daemon.
+It is the aim of the Handheld Daemon project to become a general Deck style session 
+manager for anything gamescope related, with useful features for all devices.
+
+In these cases, starting with 3.4, for devices that are not in the CPU/device
+whitelist (includes only AMD U series APUs and handhelds), Adjustor contains a 
+general energy management plugin that allows for switching the PPD power profile 
+from game mode.
+In addition, it supports [sched_ext schedulers](#sched_ext).
+
+This means that for general devices, Handheld Daemon uses PPD, and for handhelds,
+Handheld Daemon becomes PPD.
+This can be confusing for distribution maintainers and users, as they can and 
+should install both (e.g., Adjustor uses the Power Profile Daemon polkits).
+
+In any case, Adjustor will never break/conflict with PPD and contains helpful 
+messages about disabling PPD in case the optimized handheld plugin is loaded.
+For distribution maintainers that ship both and want Handheld Daemon to work
+without user intervention, the environment variable `HHD_PPD_MASK` is provided.
+If and only if it is set e.g., by using a systemd service extension, Handheld Daemon
+will mask and disable PPD if optimized energy management is supported and enabled (e.g., for handhelds).
+If the general plugin is loaded, it will unmask PPD during startup.
+This means that Power Management will work properly for all devices without manual
+intervention or whitelisting by distribution maintainers.
+
+## Sched_ext<a name="sched-ext"></a>
+Starting with version 3.3, Adjustor can attach sched_ext schedulers to the
+kernel if those are supported and installed.
+Adjustor manages the lifetime of the scheduler, including launching and attaching
+it, without using a systemd service, and is fully responsive to quirk scheduler
+switches.
+
+Schedulers are whitelisted in a case by case basis, with LAVD, rusty, and bpfland
+being supported in the current version (the `scx_` namespace is crowded with e.g.,
+test schedulers).
+Of course, only installed schedulers are shown if and only if the kernel supports
+them.
+Get in touch to add your favorite scheduler, as it is a single line change.
+
 ## AMD TDP Control Details<a name="amd-tdp"></a>
 Adjustor controls TDP through the Dynamic Power and Thermal Configuration Interface
 of AMD, which exposes a superset of the parameters that can be currently found in 
@@ -99,7 +141,7 @@ This vendor interface is part of the ACPI ASL library, and provided through the
 ALIB method 0x0C.
 The underlying implementation of the interface is SMU calls.
 This means that as long as the kernel module `acpi_call` is loaded, Adjustor
-can control TDP in an equivalent way to [RyzenAdj](https://github.dev/FlyGoat/RyzenAdj/).
+can control TDP in a similar way to [RyzenAdj](https://github.dev/FlyGoat/RyzenAdj/).
 
 The ABI of this vendor function (as it is provided to manufacturers) can be 
 considered mostly stable, so little work is needed between subsequent 
@@ -109,8 +151,9 @@ Of course, support for processors is only added after the ACPI bindings have
 been reviewed, to avoid surprises.
 Both the Ally and Legion Go use this function, in the exact same way, so setting
 TDP with it is very stable, and we have had no reported crashes.
-It should not be used (and is not used) with those devices, however, as the 
-manufacturer functions will interfere.
+It can not be used and is not used with those devices, however, as the 
+manufacturer functions would interfere and provide a better user experience,
+such as setting appropriate fan curves and changing the power light color on the Legion Go.
 
 Unfortunately for devices that do have an ACPI/EC implementation for TDP, there
 is no official way of setting TDP on demand, either on Linux or Windows, with

{adjustor-3.3.0 → adjustor-3.4.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "adjustor"
-version = "3.3.0"
+version = "3.4.0"
 authors = [
   { name="Kapenekakis Antheas", email="pypi@antheas.dev" },
 ]

{adjustor-3.3.0 → adjustor-3.4.0}/readme.md

@@ -17,7 +17,7 @@ except intel handhelds and older prior to 6XXX AMD handhelds.
 ## TDP Control
 For the ROG Ally, Ally X and Legion Go that have an ACPI/EC implementation for 
 bios and fan curves,
-Adjustor uses the manufactuer functions for setting TDP.
+Adjustor uses the manufacturer functions for setting TDP.
 For the Allys, the asus-wmi kernel driver is used to set the tdp and manage the
 fan curves.
 For the Go, Lenovo's WMI methods are called through `acpi_call`, which will hopefully
@@ -32,14 +32,14 @@ For more, see [AMD TDP Control Details](#amd-tdp).
 In all cases, there are checks to ensure that the TDP is within the safe range
 of the processors.
 
-## Energy Management
-Adjustor can also manage the energy profile of the processor, by setting EPP
+## Energy Management in Handhelds
+Adjustor can also manage the energy profile of the processor in handhelds, by setting EPP
 and proper frequency values.
 After we transitioned people away from Decky plugins (which had some governor controls)
 to using Handheld Daemon for TDP, we found that Power Profiles Daemon (PPD) 
 would use aggressive CPU values.
 These values are optimized for devices that have a dedicated power budget for the CPU
-(e.g., laptops, desktops), which caused issues with handhelds.
+(e.g., laptops, desktops), which causes undesirable behavior handhelds.
 
 For example, the balanced PPD profile would set EPP to balance_performance and
 enable CPU boost, which would increase the draw of the CPU during gaming by 2W
@@ -70,6 +70,48 @@ TDP range instead of CPU values (which is the user's expectation).
 Of course, depending on TDP and user preference, the CPU governor values will be set
 accordingly.
 
+## Energy Management in other computers
+As we design Handheld Daemon to be enabled in more Deck style devices (e.g., HTPCs), 
+these devices have different power requirements and processors (e.g., Intel), which 
+are better managed with Power Profiles Daemon.
+It is the aim of the Handheld Daemon project to become a general Deck style session 
+manager for anything gamescope related, with useful features for all devices.
+
+In these cases, starting with 3.4, for devices that are not in the CPU/device
+whitelist (includes only AMD U series APUs and handhelds), Adjustor contains a 
+general energy management plugin that allows for switching the PPD power profile 
+from game mode.
+In addition, it supports [sched_ext schedulers](#sched_ext).
+
+This means that for general devices, Handheld Daemon uses PPD, and for handhelds,
+Handheld Daemon becomes PPD.
+This can be confusing for distribution maintainers and users, as they can and 
+should install both (e.g., Adjustor uses the Power Profile Daemon polkits).
+
+In any case, Adjustor will never break/conflict with PPD and contains helpful 
+messages about disabling PPD in case the optimized handheld plugin is loaded.
+For distribution maintainers that ship both and want Handheld Daemon to work
+without user intervention, the environment variable `HHD_PPD_MASK` is provided.
+If and only if it is set e.g., by using a systemd service extension, Handheld Daemon
+will mask and disable PPD if optimized energy management is supported and enabled (e.g., for handhelds).
+If the general plugin is loaded, it will unmask PPD during startup.
+This means that Power Management will work properly for all devices without manual
+intervention or whitelisting by distribution maintainers.
+
+## Sched_ext<a name="sched-ext"></a>
+Starting with version 3.3, Adjustor can attach sched_ext schedulers to the
+kernel if those are supported and installed.
+Adjustor manages the lifetime of the scheduler, including launching and attaching
+it, without using a systemd service, and is fully responsive to quirk scheduler
+switches.
+
+Schedulers are whitelisted in a case by case basis, with LAVD, rusty, and bpfland
+being supported in the current version (the `scx_` namespace is crowded with e.g.,
+test schedulers).
+Of course, only installed schedulers are shown if and only if the kernel supports
+them.
+Get in touch to add your favorite scheduler, as it is a single line change.
+
 ## AMD TDP Control Details<a name="amd-tdp"></a>
 Adjustor controls TDP through the Dynamic Power and Thermal Configuration Interface
 of AMD, which exposes a superset of the parameters that can be currently found in 
@@ -78,7 +120,7 @@ This vendor interface is part of the ACPI ASL library, and provided through the
 ALIB method 0x0C.
 The underlying implementation of the interface is SMU calls.
 This means that as long as the kernel module `acpi_call` is loaded, Adjustor
-can control TDP in an equivalent way to [RyzenAdj](https://github.dev/FlyGoat/RyzenAdj/).
+can control TDP in a similar way to [RyzenAdj](https://github.dev/FlyGoat/RyzenAdj/).
 
 The ABI of this vendor function (as it is provided to manufacturers) can be 
 considered mostly stable, so little work is needed between subsequent 
@@ -88,8 +130,9 @@ Of course, support for processors is only added after the ACPI bindings have
 been reviewed, to avoid surprises.
 Both the Ally and Legion Go use this function, in the exact same way, so setting
 TDP with it is very stable, and we have had no reported crashes.
-It should not be used (and is not used) with those devices, however, as the 
-manufacturer functions will interfere.
+It can not be used and is not used with those devices, however, as the 
+manufacturer functions would interfere and provide a better user experience,
+such as setting appropriate fan curves and changing the power light color on the Legion Go.
 
 Unfortunately for devices that do have an ACPI/EC implementation for TDP, there
 is no official way of setting TDP on demand, either on Linux or Windows, with

{adjustor-3.3.0 → adjustor-3.4.0}/src/adjustor/core/const.py

@@ -41,7 +41,7 @@ DEV_PARAMS_7040: dict[str, DeviceParams] = {
     "temp_target": D(60, 70, 85, 90, 100),
 }
 
-DEV_PARAMS_NEO: dict[str, DeviceParams] = {
+DEV_PARAMS_28W: dict[str, DeviceParams] = {
     "stapm_limit": D(0, 4, 15, 28, 35),
     "skin_limit": D(0, 4, 15, 28, 35),
     "slow_limit": D(0, 4, 20, 32, 37),
@@ -58,7 +58,8 @@ DEV_PARAMS_8040: dict[str, DeviceParams] = DEV_PARAMS_7040
 DEV_PARAMS_LEGO = DEV_PARAMS_7040
 
 DEV_DATA: dict[str, tuple[dict[str, DeviceParams], dict[str, AlibParams], bool]] = {
-    "NEO-01": (DEV_PARAMS_NEO, ALIB_PARAMS_7040, False),
+    "NEO-01": (DEV_PARAMS_28W, ALIB_PARAMS_7040, False),
+    "V3": (DEV_PARAMS_28W, ALIB_PARAMS_8040, False),
     "83E1": (DEV_PARAMS_LEGO, ALIB_PARAMS_7040, False),
 }
 

{adjustor-3.3.0 → adjustor-3.4.0}/src/adjustor/core/lenovo.py

@@ -104,12 +104,12 @@ def set_fan_curve(arr: Sequence[int], lim: Sequence[int] | None = None):
     )
 
 
-def set_power_light(enabled: bool):
+def set_power_light_v1(enabled: bool):
     logger.debug(f"Setting power light status.")
     return call(r"\_SB.GZFD.WMAF", [0, 0x02, bytes([0x03, int(enabled), 0x00])])
 
 
-def get_power_light():
+def get_power_light_v1():
     logger.debug(f"Getting power light status.")
     if not call(r"\_SB.GZFD.WMAF", [0, 0x01, 0x03], risky=False):
         return None
@@ -119,6 +119,42 @@ def get_power_light():
     return None
 
 
+def set_power_light(enabled: bool, suspend: bool = False):
+    logger.debug(f"Setting power light status.")
+    if enabled:
+        if suspend:
+            cb = 0x03
+        else:
+            cb = 0x02
+    else:
+        cb = 0x01
+    return call(
+        r"\_SB.GZFD.WMAF",
+        [0, 0x02, bytes([0x024 if suspend else 0x04, 0x00, cb])],
+    )
+
+
+def get_power_light(suspend: bool = False):
+    logger.debug(f"Getting power light status.")
+    if not call(r"\_SB.GZFD.WMAF", [0, 0x01, 0x024 if suspend else 0x04], risky=False):
+        return None
+    o = read()
+    if isinstance(o, bytes) and len(o) == 2:
+        return o[1] == (0x03 if suspend else 0x02)
+    return None
+
+
+def get_bios_version():
+    raw = None
+    try:
+        with open("/sys/class/dmi/id/bios_version") as f:
+            raw = f.read()
+        return int(raw.replace("N3CN", "").split("WW")[0].strip())
+    except Exception as e:
+        logger.error(f"Failed to get BIOS version from '{raw}' with error:\n{e}")
+        return 1
+
+
 def get_feature(id: int):
     if not call(
         r"\_SB.GZFD.WMAE",

{adjustor-3.3.0 → adjustor-3.4.0}/src/adjustor/drivers/amd/__init__.py

@@ -24,7 +24,7 @@ from adjustor.fuse.gpu import (
 
 logger = logging.getLogger(__name__)
 
-APPLY_DELAY = 0.5
+APPLY_DELAY = 0.2
 
 
 def _ppd_client(emit, proc):
@@ -126,14 +126,29 @@ class AmdGPUPlugin(HHDPlugin):
                 ]
             )
             for line in out.decode().splitlines():
-                if "not-found" in line.lower():
+                line = line.lower()
+                if "masked" in line:
                     continue
-                if "power-profiles-daemon" in line or "tuned" in line.lower():
+                if "not-found" in line:
+                    continue
+                if "inactive" in line:
+                    continue
+                if "power-profiles-daemon" in line or "tuned" in line:
                     self.ppd_conflict = True
                     break
         except Exception as e:
             logger.error(f"Failed to check for PPD conflict:\n{e}")
 
+        if self.ppd_conflict and os.environ.get("HHD_PPD_MASK", None):
+            logger.warning(
+                "PPD conflict detected but HHD_PPD_MASK is set. Masking PPD."
+            )
+            # Mask and disable
+            os.system("systemctl mask power-profiles-daemon.service")
+            os.system("systemctl disable --now power-profiles-daemon.service")
+            # Keep going without check to avoid obscure errors
+            self.ppd_conflict = False
+
         if self.ppd_conflict:
             self.initialized = False
             return {

{adjustor-3.3.0 → adjustor-3.4.0}/src/adjustor/drivers/amd/settings.yml

@@ -46,6 +46,11 @@ enabled:
               options:
                 min: 400MHz
                 nonlinear: 1GHz
+              hint: >-
+                Sets the minimum frequency for the CPU.
+                Using 400MHz will save battery in light games.
+                However, the delay of increasing the frequency
+                may cause minor stutters, especially in VRR displays.
             cpu_boost:
               type: multiple
               title: CPU Boost
@@ -92,8 +97,7 @@ enabled:
               title: Custom Scheduler
               hint: >-
                 Allows attaching a scheduler to the kernel sched_ext.
-                Schedulers need to be installed.
-                "Kernel" .
+                Schedulers need to be installed and kernel needs to support sched_ext.
               options:
                 disabled: Disabled
                 scx_lavd: LAVD