Pixel 7 Pro

• Boot

  Works

  Mainline on slot B, stock Android kept on slot A; the boot-success marker sets the slot's flags in devinfo

  Plan: BRINGUP-M1

• Storage

  Works

  UFS, behind the read-only partition guard; the Arch root on userdata

  Plan: NOTES

• Display

  Works

  Our flip-only KMS driver (gs-decon) on DECON0 → DSIM0 → S6E3HC4, 120 Hz by default, brightness, DPMS; the panel sleeps when the screen is off

  Plan: DISPLAY-PLAN

• GPU

  Works

  Mali-G710 on Panthor, with Mesa patched for G710; frequency scaling through ACPM

  Plan: GPU-PLAN, ACPM-PLAN

• Touch

  Works

  Synaptics S3908 over SPI, our TouchComm driver

  Plan: NOTES

• Buttons

  Works

  Power and volume through gpio-keys

  Plan: NOTES

• USB networking

  Works

  CDC NCM gadget plus an ACM console; reconnects after a replug (omamobile-usb-rescue) until the Type-C driver lands

  Plan: USB-C-PLAN

• Wi-Fi

  Works

  BCM4389 on PCIe through brcmfmac, behind a restricted DMA pool

  Plan: WIFI-BATTERY-PLAN

• Bluetooth

  Works

  BCM4389 on the APM UART through hci_bcm; pairing, A2DP audio through PipeWire. Headset calls (HFP) need the chip's SCO routing changed first

  Plan: BLUETOOTH-PLAN

• Battery

  Works

  MAX77759 fuel gauge with the stock battery model

  Plan: WIFI-BATTERY-PLAN

• Charging

  Works

  The MAX77759 charger driver and its battery temperature guard load at boot (device-cheetah 0.1.33; G1, G2 and D1 passed, replug included, 2026-10-19); the gauge reads Charging and Full on the cable. Type-C and the role switch (B4) not yet run

  Plan: USB-C-PLAN

• Haptics

  Works

  CS40L26A, through feedbackd

  Plan: HAPTICS-TORCH-PLAN

• Torch

  Works

  LM3644TT, quick-settings tile

  Plan: HAPTICS-TORCH-PLAN

• GNSS

  Works

  omamobile-gnss: Google's GNSS stack in a vendor chroot, started on demand through GeoClue, with a Location quick-settings tile. The chip streams NMEA; version 0.2.0 adds orbit assistance and time injection for a fast first fix (SUPL opt-in). First outdoor fix (G4b, 2026-10-13): four constellations in view, GPS and Galileo used, HDOP 0.4, fixes within about 4 m. GNOME Maps (in omamobile-apps) reads GeoClue; its outdoor check with the GPS is still to do

  Plan: GNSS-PLAN

• AoC

  Works

  The audio and sensor DSP starts at boot (omamobile-aoc.service) through the GSA and Trusty, with 82 services; sensors and the sound card use it

  Plan: AOC-PLAN

• Speakers/mics

  Partial

  quiet, thin

  Through the AoC sound card and PipeWire (omamobile-audio): "Built-in Audio Speaker" (both speakers in stereo, stock channel map) and "Built-in Audio Microphone", the volume keys and quick settings. The amplifiers run Google's speaker protection firmware with the phone's factory calibration, and a watchdog mutes them on any fault. Known gaps: the everyday level (stage media, digital 737, analog 10) is about 17 dB below stock and sounds thin; stock's gains still trip the coil temperature (C9d-3..6). The bottom speaker's static was a word-length bug, fixed in the kernel (C9d-6, 2026-10-13). Version 0.4.1's speaker filter (bass management, limiter per speaker) is built, not yet tuned on the phone (C9h); stock's Waves processing on the AoC (omamobile-speaker-tuning, off by default) is still research (T3b/T4)

  Plan: AOC-PLAN C7-C9, AOC-TUNING-RESEARCH, AUDIO-PLAN

• Sensors

  Works

  omamobile-sensors: an iio-sensor-proxy D-Bus service from the AoC's USF, started at boot. Accelerometer, light, proximity and compass at every boot (the sensor rails are power-cycled before the AoC starts); auto-rotate, switched from the rotation lock tile

  Plan: AOC-PLAN C6, USF-PROTOCOL

• Modem

  In progress

  boots; needs a SIM

  S5300 on PCIe at Gen3 x2: the modem boots Google's firmware from RAM copies of its NV to ONLINE (M3.4.5b, M3.4.6), the CP serves the SIT IPC (SIM state, radio state, AT +CFUN; M4.1h) and idles its link as stock does, with NV unchanged across ten minutes of idle cycles (M4.1i). It needs the phone's own board id (omamobile-modem 0.1.4). A reboot with the modem up hung once (a DBI access while the PHY was isolated); the fix passed on the phone, and reboots with the modem up are clean (M4.1j, M4.1k, 2026-10-13). omamobile-mmd shows the modem to NetworkManager and the phone apps (T1). No SIM has been in the phone yet, so registration, SMS, data and calls (M4.2 on) are untested; the SIM runbook is ready. Open: each modem power-off (so each reboot with the modem up) causes one recovered UFS error-handler pass, so the modem stays on once up

  Plan: MODEM-PLAN, MODEM-CLIENT, MODEM-SIT-RESEARCH

• NFC

  Works

  ST54J over I2C through st-nci with our plain-NCI link, loaded at boot; neard (patched for empty Type 4 tags) reads and writes tags, and tapping a tag with a web link opens it (omamobile-nfc-open): writing a tag and opening its link tested on the phone (N3). Card emulation and the secure element are not used

  Plan: RADIOS-CAMERA-PLAN §3

• Cameras

  Works

  telephoto fixed-focus

  Ultrawide (Sony IMX386, D-PHY link 2): works end to end through our CSIS/WDMA driver and libcamera's software ISP (CAM5), basic quality (no Google ISP or tuning); a libcamera build with autofocus and low-light patches is installed, not yet evaluated (CAM5.3). Front (Samsung S5K3J1, D-PHY link 0): real images, raw and through libcamera (cam -c1, 30 fps, no WDMA errors; F.5-F.7, 2026-10-13). Main (Samsung S5KGN1, C-PHY link 1): 2016x1136 at 30 fps through libcamera with no WDMA errors. Telephoto (S5KGM5, C-PHY): 26 fps through libcamera, colour bars correct; its lens (SEM1215) isn't driven yet, so it stays at its resting focus: distant subjects are sharp (outdoors, 2026-10-26), close ones soft, and tap to focus does nothing. The CSIS write DMA (not the link) loses lines that arrive faster than about 400 MB/s within a line, so the sensors lengthen their lines to stay under samsung,max-line-throughput (360 in cheetah's DT for the main, telephoto and front cameras; the front's full 3840x2736 mode runs at 26 fps). The ultrawide (imx386) follows the same rule, so its full 4032x3016 mode streams (23 fps; one run in several still showed WDMA errors), and with 384 MiB of CMA cam without options runs every camera at full size (main 12 MP at 9.4 fps). The telephoto's lens (SEM1215) answers on a 950 kHz bus but holds the bus when driven longer, so the telephoto runs at fixed focus. Sensor and DC-PHY settings come from the user's own camera software (tools/extract-camera-data), never shipped. Since omamobile-device-cheetah 0.1.30 the camera modules load after boot (omamobile-camera.timer), the DMA-BUF heaps are open to the session (libcamera's software ISP), WirePlumber names them Main, Ultrawide, Telephoto and Front camera (0.1.31). The default camera app is omacam ("Camera", omamobile-apps 0.2.0; CAMERA-APP-PLAN): libcamera directly, zoom across the three back lenses, full-resolution photos. GNOME Snapshot is optional, named "Snapshot", for video until omacam records it; browsers and video calls use the cameras through PipeWire (pipewire-libcamera). Picture quality: libcamera 0.7.2-4.21 adds chroma noise reduction and defective pixel correction, and omacam 0.3.3 has Night mode and an HDR chip, bursts of raw frames aligned, merged and finished on the phone (Night: 12 frames in about 4.6 s, Q5.3 on 2026-10-21); single shots are still well below stock's

  Plan: CAMERA-PLAN, CAMERA-QUALITY-PLAN

• Suspend

  In progress

  s2idle works when asked for (systemctl suspend, rtcwake): pm_test dry runs, wakes on a volume key and on the RTC alarm, 20 of 20 unattended cycles (S3b, S4); UFS powers down in suspend by default (spm_lvl 5). Wi-Fi stays connected across sleep: 31 of 31 freezes with the D3 handshake (S5b-3, S5c, 2026-10-19), and the sleep hook keeps it loaded. The AoC and sensors work across sleep, and a running sensor stream doesn't wake the phone (S6, 2026-10-19). Screen off, with Wi-Fi up, it draws 434 mA awake and 312 mA in s2idle: about 16 h of standby on the 4986 mAh battery (S7, 2026-10-19), against 32-50 mA in stock's deep sleep. Not on by default: the phone doesn't sleep by itself when the screen goes off until S8 (Power to sleep and wake, idle sleep, a day of use) has run. Wi-Fi traffic and a USB plug can't wake it, a few RTC cycles wake early on a PMIC interrupt not yet identified, and the modem has never run across a suspend. Deep sleep (SYS_SLEEP), which stock's standby numbers need, is research and not started

  Plan: SUSPEND-PLAN

• Fingerprint

  Works

  opt-in

  Google's HAL in a chroot behind a bridge and Trusty's fingerprint TA on our kernel (F3-F9), fprintd with our libfprint driver: enrollment from the shell, and the lock screen unlocks with a finger alongside the PIN pad or password, with the keyboard usable over the lock (F16b). A verify stays open across system sleep, and an enrollment interrupted by sleep fails cleanly (libfprint 1.6, 2026-10-19). Opt-in: omamobile-fp.service ships disabled, because its first run writes Trusty's secure storage

  Plan: FINGERPRINT-PLAN, FINGERPRINT-RESEARCH

Source: docs/DEVICES.md in the Omarchy Mobile repository.