Kalau ditanya hobi, orang biasanya jawab mancing, gowes, atau nonton. Punyaku agak aneh: keyboard mekanikal. Bukan sekadar beli yang RGB-nya kece terus dipajang, tapi benar-benar dibongkar sampai ke level firmware — matrix scanning, debounce, sampai protokol HID-nya. Dan kalau dipikir-pikir, ini bukan hobi yang muncul tiba-tiba. Ini kelanjutan langsung dari kebiasaan lama: dulu di dunia banking programming, aku terbiasa mikir dalam layer — ada logika inti yang jalan di mesin (firmware), ada interface yang bicara ke situ lewat protokol tanpa perlu rebuild image (configurator). Ternyata pola pikir yang sama persis muncul lagi di dunia keyboard.

Semua Bermula dari Satu Pertanyaan Sederhana

Titik masuknya sepele: aku cuma mau cari barebone keyboard yang beneran support QMK dan VIA — bukan yang cuma ngaku-ngaku “programmable” di listing marketplace tapi ternyata jalan di firmware tertutup. Dari situ aku mulai ngerti hierarkinya lebih dalam. QMK itu firmware sesungguhnya yang jalan di MCU — dia yang menentukan matrix scanning, layer, keycode, tap-dance, combo, RGB, semuanya. Di atasnya, VIA adalah GUI configurator yang ngobrol ke QMK secara real-time lewat raw HID, remap key dan macro tersimpan di EEPROM tanpa perlu reflash. Vial, fork dari QMK, malah lebih ekstrem: definisi layout-nya disimpan langsung di keyboard, jadi nggak perlu nunggu approval vendor buat masuk ke central repo.

Begitu paham hierarkinya — dari yang paling rendah dan powerful (edit keymap.c langsung, reflash tiap ubah) sampai yang paling nyaman (VIA/Vial, remap real-time) — aku langsung sadar ini sweet spot yang aku cari buat kebutuhan spesifik: bikin macro callsign YD0ABC dan shortcut kontes di radio amatir, langsung dari keyboard, tanpa reflash tiap kali ubah layout.

Barebone, Case Frosted, dan Drama “Voyager”

Pencarianku sempat nyasar ke board bernama “Voyager68”. Ternyata itu bukan yang open-source ai03 Voyager series, juga bukan ZSA Voyager yang split ergonomic — tapi board PressPlay/PressPlayID, prebuilt budget dengan driver proprietary, nol hubungan sama QMK. Pelajarannya: nama board di marketplace lokal sering menjebak, dan “programmable” itu kata yang gampang disalahgunakan buat marketing.

Ujung-ujungnya aku balik lagi ke ekosistem yang sudah kukenal: KBD67 Lite, yang sudah kupunya dalam warna Black dan Steel Gray, case-nya polycarbonate frosted dan PCB-nya sudah masuk resmi ke repo QMK — tinggal build dan flash Vial. Nggak perlu cari yang baru kalau yang sudah di tangan justru paling solid secara firmware.

Ngoprek Sampai ke Level Firmware JSON

Bagian yang paling “aku banget” adalah waktu masuk ke urusan konversi definisi VIA dari format V2 ke V3. Ini bukan kerjaan yang seksi — cuma ganti modul qmk_lighting jadi qmk_rgb_matrix_keycodes eksplisit, tambah field firmwareVersion, dan mastiin VIA_PROTOCOL_VERSION di firmware minimal 11 supaya definisi baru kebaca. Tapi justru di detail sekecil itu aku menemukan hal yang bikin gregetan: salah satu keyboard, APOLLO61-Lite, ternyata punya custom keycode toggle V2/V3 di level firmware sendiri — kayak dual-mode compatibility yang lumrah di board OEM Cina generik. Kalau mode itu nggak di-set ke V3 dulu di keyboard-nya, definisi JSON yang sudah kubetulin pun percuma, nggak akan match protokol yang dikirim firmware.

Ini persis pola kerja yang aku suka: bukan cuma “asal jalan”, tapi ngerti kenapa sesuatu bisa gagal di lapisan yang nggak keliatan dari luar.

RP2040, Splinky, dan Semangat “Overkill”

Untuk build TG4x — keyboard 45% open-source yang pakai socketed Pro Micro — aku sengaja pasang RP2040 Pro Micro, padahal jelas-jelas lebih bertenaga dari yang dibutuhkan board sekecil itu. Aku tahu ini overkill. Tapi ada kepuasan tersendiri pakai hardware yang “kelebihan tenaga” buat hal sesederhana keyboard 45%. Board yang kubeli ternyata clone dari desain open-source 0xB2 “Splinky” — replacement Elite-C/Pro Micro berbasis RP2040, USB-C, castellated holes, kompatibel pinout QMK RP2040 Community Edition. Awalnya kukira harganya kemahalan buat sekadar clone, tapi begitu tahu itu spek Splinky asli, jadi masuk akal.

Proses convert-nya pakai flag CONVERT_TO = rp2040_ce — satu baris config, tapi di baliknya ada pemahaman soal bagaimana QMK abstraksi hardware layer supaya firmware yang sama bisa jalan di MCU berbeda tanpa nulis ulang logic dari nol. Ini juga yang bikin aku selalu balik ke KBD67 Lite buat urusan configurator: MCU-nya terintegrasi, jadi nggak bisa diganti-ganti controller kayak TG4x — beda karakter, beda strategi modding.

Kenapa Ini Nggak Pernah Berasa Selesai

Kalau ditarik benang merahnya: keyboard buat aku bukan soal estetika atau keycap langka. Ini soal kontrol penuh atas stack — dari matrix scanning di firmware, protokol HID yang ngobrol ke configurator, sampai ke JSON definition yang menentukan menu apa yang muncul di UI. Sama persis kayak cara aku bangun infrastruktur Bimbel ISC atau Otomasi: aku nggak nyaman kalau ada lapisan yang black-box. Kalau ada sesuatu yang “kebetulan jalan”, aku pengen tahu kenapa dia jalan — dan kalau suatu hari berhenti jalan, aku udah tahu di lapisan mana harus nyari.

Keyboard di meja kerjaku sekarang bukan cuma alat ngetik. Dia proyek yang nggak pernah benar-benar “selesai” — selalu ada satu firmware yang bisa di-tweak, satu definisi JSON yang bisa dirapihin, atau satu MCU yang bisa diganti cuma karena penasaran apa bisa. Dan jujur, itu bagian yang paling aku nikmatin.