Skip to content

code-map.md

Latest commit

 

History

History
136 lines (116 loc) · 4.52 KB

code-map.md

File metadata and controls

136 lines (116 loc) · 4.52 KB
Raw

Code map

Build targets

Target Responsibility
glinux-core Pure device types, validation and policy.
glinux-asusd-backend Typed access to the installed asusd service.
glinux-linux-backend Read-only kernel and sysfs discovery.
glinux-system-backend System operations implemented through logind.
glinux-application Domain services and the Qt-facing controller.
g-linux Production QML application and tray integration.
g-linux-nvidia-helper Narrow KAuth helper for NVIDIA offsets.

Targets below are created only when tests are enabled:

Target Responsibility
glinux-test-support Virtual hardware specifications and state oracle.
g-linux-simulator Production QML over test-only hardware state.
g-linux-hardware-test Explicit hardware verification commands.
g-linux-*-tests Core, service, backend, controller and QML tests.

Source directories

src/
  core/                  UI-independent types and policies
    aura/                Aura descriptors and parameter schema
    device/              capability registry and device specification
    display/             refresh-rate summary and selection
    fan/                 eight-point fan-curve rules
    gpu/                 GPU mode planner
    power/               power-limit catalog
  backend/
    asusd/               IAsusdClient and D-Bus implementation
    linux/               ILinuxSystem and sysfs implementation
    system/              ISystemPower and logind implementation
  application/
    aura/                AuraService and asusd transport
    device/              discovery projection and diagnostics
    display/             KScreen operations
    fan/                 fan orchestration
    gpu/                 MUX transaction and NVIDIA controls
    platform/            ASUS platform devices and switches
    power/               profiles, charge, EPP and tuning
  systemcontroller.*     lifecycle and QML facade
  colorprofilemanager.*  exact-match ICC/GameVisual resources
  hotkeymanager.*        discovered M-key actions
  inputportal.*          Wayland portal key sequences
  traymanager.*          Plasma tray integration
  main.cpp               command line and application startup

qml/
  Main.qml               application shell and navigation
  NavigationPolicy.js    capability-driven page selection
  components/            reusable compact controls
  pages/
    DashboardPage.qml    profiles, GPU, display, battery and lighting
    FansPage.qml         Custom fan, power, EPP and clock controls
    PeripheralsPage.qml  discovered ASUS USB devices
    SystemPage.qml       firmware and platform features
    AutomationPage.qml   AC/battery and hotkey rules
    DiagnosticsPage.qml  capability and log report

Main data flows

Refresh

SystemController::refresh
  -> IAsusdClient::managedObjects
  -> ILinuxSystem snapshots
  -> domain-specific reads
  -> DeviceSpecification and capability registry
  -> Qt properties and change signals
  -> capability-gated QML sections

GPU mode and MUX

Dashboard confirmation
  -> SystemController::setGpuModeAndRestart
  -> core::gpu::planTransition
  -> GpuModeService
       validate PossibleValues
       snapshot CurrentValue
       write CurrentValue to asusd queue
       verify QueuedGpuValue
  -> ISystemPower::reboot
  -> logind PrepareForShutdown
  -> asus-shutdown applies the deferred firmware value

Display preset

Dashboard preset
  -> SystemController::setDisplayPreset
  -> core::display selects a mode at current resolution
  -> KScreen applies refresh rate
  -> verified panel_overdrive write when available
  -> display and platform state refresh

Custom fan and power settings

Fans page Apply
  -> validate all values before first write
  -> snapshot active firmware values and curves
  -> apply fixed-order asusd calls
  -> read back every changed value
  -> restore the snapshot if verification fails

GameVisual

DMI board + GPU vendor + panel EDID
  -> exact profile manifest match
  -> hash-checked ASUS resource extraction
  -> Little CMS profile/LUT application
  -> current mode exposed to QML

Adding hardware support

New reusable rules belong in src/core. New hardware protocols implement a backend interface. Domain orchestration belongs under src/application, and QML receives only high-level properties and commands. Every capability needs absent, read-only and writable test coverage before its control is published.