How to Create or Add New Hardware Variant Definitions to OCLP-Mod: A Complete Developer's Guide
Adding a new hardware variant to OCLP-Mod requires creating a Python class that inherits from BaseHardware in the oclp_mod/sys_patch/patchsets/hardware/ directory, implementing six required methods including name(), present(), and patches(), and placing the file in the appropriate category subdirectory to enable automatic discovery.
OCLP-Mod uses a plugin-based architecture to support diverse hardware configurations on macOS. Creating or adding new hardware variant definitions to OCLP-Mod involves extending the BaseHardware abstract base class to define detection logic and patch sets for unsupported GPUs, network cards, or audio devices. This guide walks through the exact file locations, method signatures, and implementation patterns used in the laobamac/oclp-mod repository.
Create a New Subclass File in the Hardware Patchsets Directory
Place your new hardware definition in the appropriate subdirectory under oclp_mod/sys_patch/patchsets/hardware/. The repository organizes variants by category:
graphics/— For GPU architectures (Intel, AMD, NVIDIA)networking/— For Wi-Fi and Ethernet controllersaudio/— For sound cards and audio codecsmisc/— For other hardware types
Name the file descriptively, such as my_new_gpu.py or broadcom_wifi.py. As a reference implementation, examine intel_skylake.py located at oclp_mod/sys_patch/patchsets/hardware/graphics/intel_skylake.py, which demonstrates the standard structure for graphics variants.
Inherit from BaseHardware and Import Required Modules
Every hardware variant must subclass BaseHardware and import the core dependencies used for detection and patching. The standard import pattern mirrors existing variants in the repository.
from ..base import BaseHardware, HardwareVariant, HardwareVariantGraphicsSubclass
from ...base import PatchType
from .....constants import Constants
from .....detections import device_probe
from .....datasets.os_data import os_data
These imports provide access to the abstract base class, hardware category enumerations, patch type definitions, system constants, device detection utilities, and macOS version data.
Implement the Required Abstract Interface
The BaseHardware class in oclp_mod/sys_patch/patchsets/hardware/base.py defines six abstract methods that every subclass must implement. These methods enable OCLP-Mod to detect hardware presence, determine compatibility, and apply appropriate patches.
-
name(self) -> str— Returns a human-readable identifier displayed in the UI. Typical implementation:return f"{self.hardware_variant()}: MyNew GPU". -
present(self) -> bool— Detects whether the hardware exists on the current machine usingdevice_probehelpers. For GPUs, useself._is_gpu_architecture_present([device_probe.Intel.Archs.YourArch]). -
native_os(self) -> bool— Determines if macOS natively supports this hardware on the current version by comparingself._xnu_majoragainst values inos_data. -
hardware_variant(self) -> HardwareVariant— Returns the high-level category:HardwareVariant.GRAPHICS,HardwareVariant.NETWORKING,HardwareVariant.AUDIO, orHardwareVariant.MISCELLANEOUS. -
hardware_variant_graphics_subclass(self) -> HardwareVariantGraphicsSubclass— Required only for graphics variants. Specifies the Metal support level, such asHardwareVariantGraphicsSubclass.METAL_31001_GRAPHICS. -
patches(self) -> dict— Returns a dictionary of patch operations required for this hardware. Combine shared patches (likeMontereyOpenCL) with model-specific overrides following thePatchTypeschema.
Define Model-Specific Patches
If your hardware requires file overrides beyond shared patches, implement a helper method commonly named _model_specific_patches(). This method returns a nested dictionary following the PatchType structure defined in the base classes.
def _model_specific_patches(self) -> dict:
return {
"MyNew GPU": {
PatchType.OVERWRITE_SYSTEM_VOLUME: {
"/System/Library/Extensions": {
"AppleMyNewGPU.kext": "12.5",
},
},
},
}
Reference the _model_specific_patches implementation in intel_skylake.py to see how model-specific kext overrides integrate with the broader patch dictionary.
Extend Hardware Enums for New Categories
If your variant introduces a completely new hardware category not covered by existing enumerations, you must extend the base definitions in oclp_mod/sys_patch/patchsets/hardware/base.py.
- Add new
HardwareVariantenum members for novel categories (e.g., a new storage controller type) - Add new
HardwareVariantGraphicsSubclassmembers for new GPU Metal support tiers
Most implementations will reuse existing enum values rather than creating new ones.
Enable Automatic Discovery
OCLP-Mod discovers hardware variants automatically through Python's pkgutil.iter_modules. The patchset loader scans all .py files in the patchsets/hardware/ tree at runtime. Simply placing your new file in the correct subdirectory makes it discoverable without explicit registration.
If the project maintains an explicit __all__ list in __init__.py files, ensure you import your class there to maintain compatibility.
Document and Test the New Variant
Add a docstring to your module explaining the hardware support and update the project README to list the new compatibility. Test your implementation by running the detection logic directly:
python -c "from oclp_mod.sys_patch import PatchsetLoader; print(PatchsetLoader().list_active())"
Verify that your class instantiates only when the target hardware is present and that patches() returns the correct dictionary structure for non-native macOS versions.
Complete Implementation Example
The following skeleton demonstrates a complete new graphics variant implementation. Save this as oclp_mod/sys_patch/patchsets/hardware/graphics/my_new_gpu.py:
"""
my_new_gpu.py – detection and patching for "MyNew GPU"
"""
from ..base import BaseHardware, HardwareVariant, HardwareVariantGraphicsSubclass
from ...base import PatchType
from .....constants import Constants
from .....detections import device_probe
from .....datasets.os_data import os_data
class MyNewGPU(BaseHardware):
def __init__(self, xnu_major, xnu_minor, os_build, global_constants: Constants):
super().__init__(xnu_major, xnu_minor, os_build, global_constants)
def name(self) -> str:
return f"{self.hardware_variant()}: MyNew GPU"
def present(self) -> bool:
# Detect the GPU by its PCI class/code or architecture
return self._is_gpu_architecture_present(
gpu_architectures=[device_probe.Intel.Archs.MyNewArch]
)
def native_os(self) -> bool:
# Assume support up to macOS Ventura
return self._xnu_major < os_data.ventura.value
def hardware_variant(self) -> HardwareVariant:
return HardwareVariant.GRAPHICS
def hardware_variant_graphics_subclass(self) -> HardwareVariantGraphicsSubclass:
return HardwareVariantGraphicsSubclass.METAL_31001_GRAPHICS
def _model_specific_patches(self) -> dict:
return {
"MyNew GPU": {
PatchType.OVERWRITE_SYSTEM_VOLUME: {
"/System/Library/Extensions": {
"AppleMyNewGPU.kext": "12.5",
},
},
},
}
def patches(self) -> dict:
if self.native_os():
return {}
# Merge shared OpenCL patches with GPU-specific ones
from ...shared_patches.monterey_opencl import MontereyOpenCL
return {
**MontereyOpenCL(self._xnu_major, self._xnu_minor,
self._constants.detected_os_version).patches(),
**self._model_specific_patches(),
}
Key Files Reference
Understanding these core files ensures your implementation aligns with the OCLP-Mod architecture:
-
oclp_mod/sys_patch/patchsets/hardware/base.py— DefinesBaseHardware,HardwareVariant, andHardwareVariantGraphicsSubclass. This is the core abstract API that all hardware variants must implement. -
oclp_mod/sys_patch/patchsets/hardware/graphics/intel_skylake.py— Concrete reference implementation showing how Intel Skylake graphics detection and patching works in practice. -
oclp_mod/sys_patch/patchsets/hardware/<category>/<your_file>.py— The destination path for your new variant, where<category>isgraphics,networking,audio, ormisc. -
oclp_mod/datasets/os_data.py(or constants file) — Contains macOS version constants used bynative_os()checks to determine support ceilings.
Summary
- Create a new Python file in the appropriate
oclp_mod/sys_patch/patchsets/hardware/subdirectory (graphics, networking, audio, or misc). - Subclass
BaseHardwareand import required modules following the pattern inintel_skylake.py. - Implement six required methods:
name(),present(),native_os(),hardware_variant(),hardware_variant_graphics_subclass()(for GPUs), andpatches(). - Define optional
_model_specific_patches()for hardware-specific kext overrides using thePatchTypeschema. - Extend
HardwareVariantorHardwareVariantGraphicsSubclassenums inbase.pyonly if introducing entirely new categories. - Place the file in the directory tree to enable automatic discovery via
pkgutil.iter_modules—no explicit registration required. - Test using
PatchsetLoader().list_active()to verify detection logic and patch output before submitting.
Frequently Asked Questions
What is the minimum number of methods I must implement to create a valid hardware variant?
You must implement six methods defined in BaseHardware: name(), present(), native_os(), hardware_variant(), patches(), and for graphics hardware, hardware_variant_graphics_subclass(). The present() method is critical as it determines whether your patch set applies to the current machine using device_probe detection logic.
Do I need to register my new hardware variant in an __init__.py or configuration file?
No explicit registration is required. OCLP-Mod uses pkgutil.iter_modules to automatically discover all Python files in the oclp_mod/sys_patch/patchsets/hardware/ directory tree at runtime. Simply placing your file in the correct subdirectory makes it available to the patchset loader.
How do I determine which HardwareVariant enum value to return?
Return HardwareVariant.GRAPHICS for GPUs, HardwareVariant.NETWORKING for Wi-Fi/Ethernet controllers, HardwareVariant.AUDIO for sound devices, or HardwareVariant.MISCELLANEOUS for other hardware types. These values are defined in oclp_mod/sys_patch/patchsets/hardware/base.py and control how the UI categorizes your patch set.
Can I reuse existing patch sets like Monterey OpenCL in my new hardware variant?
Yes. Import shared patch classes from oclp_mod/sys_patch/patchsets/shared_patches/ (such as MontereyOpenCL) and merge their patches() dictionary with your _model_specific_patches() output in your patches() method implementation. This follows the DRY principle used throughout the laobamac/oclp-mod codebase.
Have a question about this repo?
These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →