Files
openipc-builder/devices/common
OpenIPC AI teamandGitHub a0418c2987 kernel: drop CONFIG_VT from the device configs that shadow firmware's (#126)
builder.sh copies devices/<item>/* over the firmware checkout before make, so a
device directory that carries its own board .config replaces firmware's copy
outright. OpenIPC/firmware #2308 and #2309 turned CONFIG_VT and CONFIG_INPUT off
across the fleet; the 13 board configs here were never touched by that, so 21
device builds carried on shipping the virtual-terminal layer -- /dev/tty0,
/dev/tty1..63, the keyboard translation tables, console selection and screen
code -- for a monitor and keyboard no camera has. flyrouter pointed this gap out
on #2308.

The transformation is not re-derived here. For each file the symbol-level delta
was taken straight out of firmware's history (85233f0e^..HEAD) for the config it
shadows and replayed, so these land on exactly the state that was reviewed and
proven on hardware there. Every affected symbol in every copy still held
firmware's pre-sweep value, so nothing here was a deliberate customisation --
they were simply stale.

Eleven of the thirteen also needed CONFIG_EXPERT=y first. In drivers/tty/Kconfig
the symbol reads

    config VT
        bool "Virtual terminal" if EXPERT
        select INPUT
        default y

so its prompt exists only under EXPERT, and without it olddefconfig finds the
symbol invisible and forces it back to its default -- "# CONFIG_VT is not set"
on its own does nothing.

Two exceptions:

  * gk7102c keeps CONFIG_INPUT. It sets CONFIG_INPUT_EVDEV=y and firmware's
    gk710x, which it shadows, keeps INPUT for the same reason. Only VT moves.

  * CONFIG_INPUT_LEDS=m is dropped on the six FPV/OTG copies. It is the
    input-to-LED bridge, lives inside `if INPUT`, and firmware never carried it,
    so olddefconfig would have dropped it silently -- stated here so the file
    matches the kernel it generates. CONFIG_LEDS_CLASS is a separate symbol in
    drivers/leds and is untouched: the FPV status LEDs are unaffected.

Nothing consumes VT on any of these. FRAMEBUFFER_CONSOLE is its only in-kernel
consumer and no config in this repository sets it at =y or =m, so the sole
console driver compiled in was DUMMY_CONSOLE and writes to /dev/tty0 went
nowhere. The ingenic t21/t31/t40 copies already matched firmware -- VT off,
INPUT kept for their GPIO keys -- and are left alone.

Verified by generating the kernel config the way builder.sh does: copy
devices/common over a firmware checkout at master and run the configure step,
before and after. gk7205v200_fpv, comparing the two generated
build/linux-custom/.config files symbol by symbol:

    turned OFF (8)   CONSOLE_TRANSLATIONS DUMMY_CONSOLE HW_CONSOLE INPUT
                     INPUT_LEDS VT VT_CONSOLE VT_CONSOLE_SLEEP
    turned ON  (1)   EXPERT
    value changed    none

    LEDS_CLASS=m, TTY, UNIX98_PTYS, SERIAL_AMBA_PL011_CONSOLE, USB_GADGET,
    CFG80211, MAC80211, KALLSYMS, COREDUMP, NAMESPACES, ELF_CORE,
    CORE_DUMP_DEFAULT_ELF_HEADERS, DEBUG_KERNEL, DEBUG_MEMORY_INIT: unchanged.

That last line is the check #2308 missed on its first pass: EXPERT carries
`select DEBUG_KERNEL` and unhides a block of on-by-default options, which there
silently moved COREDUMP and friends. DEBUG_KERNEL was already y in these
configs, so nothing else moved.

Building the kernel both ways in that same tree, on the OpenIPC/linux goke
tarball these devices use:

    gk7205v200_fpv  uImage  2071368 -> 2036040   -35328 bytes (-1.71%)
                    zImage  2058872 -> 2023544   -35328 bytes (-1.72%)

which lines up with the -34680 bytes firmware measured on gk7205v200_lite for
the same delta. drivers/input/input-leds.ko is built in the before tree and is
not built after.
2026-08-25 21:25:13 +03:00
..