Settings control pattern (p1-xxxsvc + xxxctl + GUI)

This file defines the standard settings architecture for P1Start control domains.

1. Why this pattern exists

Without a standard pattern, settings drift into ad-hoc paths:

  • GUI-only toggles with no shell/operator equivalent

  • CLI tools that bypass GUI-visible state

  • Daemons and apps disagreeing about current policy

The platform standard avoids this by unifying behavior across all domains.

2. Required components

Each settings domain should implement:

  1. Service daemon: p1-<domain>svc.elf

  2. CLI tool: <domain>ctl.elf

  3. GUI panel: Settings integration for common users

  4. RegCube keys: canonical persisted state

All four are part of one contract.

3. Responsibility split

Component

Responsibility

p1-<domain>svc

Owns control-plane behavior, validation, policy transitions, status updates

<domain>ctl

Operator/scripting interface to inspect/update state and trigger actions

Settings GUI

User-facing controls mapped to the same keys/service operations

RegCube

Persisted source of truth for defaults, overrides, and status

Rule: GUI and CLI should converge on the same behavior and outcomes.

4. Contract checklist for a new domain

When adding a domain (network, time, display, sound, power, etc.):

  1. Define key namespace under HIVE_LOCAL_MACHINE/<domain>/...

  2. Define service readiness + control IPC wire(s)

  3. Implement daemon load/apply logic from RegCube at startup

  4. Implement CLI read/write/status actions

  5. Implement Settings panel that uses the same key/service paths

  6. Add last_apply_status-style diagnostics key(s)

  7. Document contract in newdocs/

5. Current domain status

Domain

Daemon

CLI

GUI

Notes

Time

p1-timesvc

timectl

Present

SNTP + timezone/region policy

Display

p1-dispsvc

dispctl

Present

Resolution/refresh/scale/brightness policy; apply updates compositor logical workspace immediately

Networking

p1-netmgr (+ p1-dhcp)

ifconfig/nslookup/others

Partial

Contract still maturing

Game runtime

p1-gamesvc

gamectl

In progress

Engine governance + lifecycle

Input / keyboard

ps2d, gterm (US via p1keyboard-layout)

inputctl (TBD)

Planned Settings tile

Locale + RegCube deferred — keyboard-input-and-layout.md

6. Anti-patterns (do not add)

  • Persisting settings only in process-local globals

  • GUI state not mirrored to RegCube

  • CLI bypassing daemon policy logic

  • Multiple sources of truth for the same domain state