Install the HDMI CEC and HDMI connection APEX packages plus the
android.hardware.hdmi.cec.xml feature file, set the playback-device
CEC properties, and give system ownership of /dev/cec0 in ueventd.
The connection HAL now reports a single HDMI output port and monitors
/sys/class/drm/card0-HDMI-A-1/status with poll(), reporting hotplug
transitions through the AIDL callback and shutting the monitor thread
down through an eventfd.
The CEC HAL now polls POLLPRI for CEC_DQEVENT and POLLIN for
CEC_RECEIVE, guards the ioctl paths against an uninitialised adapter,
and bounds message length by CEC_MAX_MSG_SIZE.
ro.boot.wificountrycode was set in two places: androidboot.wificountrycode=US
on the kernel cmdline (mkimg.sh extlinux heredoc) and ro.boot.wificountrycode=00
in vendor.prop. Because ro.* properties are set-once and init processes the
cmdline first, the cmdline always won and the vendor.prop value silently lost
(init logs 'Read-only property was already set' every boot). Worse, the
vendor.prop value was 00 (world regulatory domain), a landmine that would
activate if the cmdline param were ever dropped.
Remove the cmdline param and set vendor.prop to US so the country code lives
in exactly one place, delivered via vendor.img instead of a hand-maintained
boot heredoc. Note this only feeds the Android framework (WifiCountryCode);
the kernel side additionally needs regulatory.db to actually apply it (fixed
separately by embedding it via CONFIG_EXTRA_FIRMWARE in the kernel).
The ro.boot.wificountrycode property is a ro.boot.* namespace property
that can ONLY be populated from the kernel cmdline (androidboot.xxx).
Setting it in vendor.prop had no effect — the value stayed '00'.
This caused the WiFi regulatory domain to default to 'country 00'
(world), which forced passive scanning on all 5GHz channels and
capped TX power at 3 dBm. On a DFS channel this meant 60s CAC
delays, failed scans, and crippled TX power causing SAE handshake
failures.
This is the actual fix — adding the boot parameter that the WiFi
framework reads to set the regulatory domain via nl80211.
Users in other regulatory domains should edit this line.
The world regulatory domain (00) forces passive scanning on all 5GHz
channels and limits TX power to 3 dBm. For a device whose AP is on
channel 144 (5720 MHz, DFS), this means:
- Scans must wait for beacons instead of actively probing
- DFS channel availability check adds up to 60s delay
- Transmit power is crippled to 3 dBm
Setting to US enables active scanning, proper TX power, and standard
DFS handling, which eliminates the 2-3 minute connection delay.
Users in other regulatory domains should override this via their own
vendor.prop or the build system.
- Rename product makefile: lineage_tart.mk (PRODUCT_NAME=lineage_tart)
- Update AndroidProducts.mk for lineage_tart lunch target
- Change androidboot.hardware and TARGET_BOOTLOADER_BOARD_NAME to tart
- Rename ramdisk files: fstab.tart, init.tart.rc, ueventd.tart.rc
- Update device.mk ramdisk copy targets for tart names
- Update vendor makefile reference to tart-vendor.mk
- Update extlinux.conf kernel cmdline with tart hardware ID
- Fix bluetooth device name in vendor.prop
Copyright (C) 2026 Brendan Szymanski <hello@bscubed.dev>
