The problem that started this
Every developer hits this eventually: you have a computer that needs typing into, and the keyboard situation is wrong.
- Your laptop hard-crashed mid-task, and the only way out is a BIOS reset — but you don't have a USB keyboard within reach.
- You need to type a long generated command into a headless server, and the only console you have is serial.
- You're standing next to a kiosk machine that needs admin input, and your hands are full of phones and coffee.
What you almost always have on you: a phone.
So the question we kept asking was: why isn't the phone in your hand already a keyboard for everything else?
Architecture
We built DexoPad, a small USB-C dongle that registers itself as a generic HID keyboard + mouse on any USB host. No driver install. No companion software on the host. It just shows up like a $10 OEM keyboard would.
The control surface is your phone. The phone runs a thin app that talks to the dongle over BLE; the dongle relays the input as USB HID reports to whatever it's plugged into.
The decision that made this actually work: all the smarts live phone-side. The dongle is intentionally dumb. It speaks USB HID. It does pairing. It rebroadcasts what the phone tells it to type, click, or scroll. That's it.
This is what lets it work in places where you can't install anything — BIOS, locked-down corporate machines, kiosks, Pi during initial boot.
Engineering details that came up while building
- BLE latency: getting typing-feel right meant tuning the connection interval down. We landed around 7.5ms with reasonable battery on the phone side.
- HID report descriptors: we ship a composite device (keyboard + mouse) so we don't have to ask the host to enumerate two separate USB devices. This also avoids the (Windows-specific) "new HID device detected" toast every time someone re-plugs.
- Cross-OS key mapping: harder than it looks. The phone runs OS-aware key translation, so AZERTY / Dvorak / Bépo on the phone keyboard maps to the host's expected scancodes correctly. The dongle just sends scancodes; the phone does layout resolution.
- AI Voice (opt-in): optional voice-to-text feature pipes phone audio through OpenAI Whisper API. Default OFF. Backer pushback on the marketing framing convinced us to add an explicit "completely disable" toggle in Settings before release.
- GPL audit: earlier demos used a couple of GPL libraries; replaced before final release.
- Painted vs raw ABS shell: under re-evaluation pending Stretch 1 (injection-mold tooling) based on backer feedback about long-term aesthetics.
Real use cases we have actually hit ourselves
- Recovering a crashed laptop from a terminal session, typing the recovery command into the host via phone.
- Initial Pi setup without dragging out a keyboard + monitor.
- BIOS-level access on machines without keyboard within reach.
- Accessibility — one Kickstarter backer who runs a residential care facility pointed out that for people with mobility limitations, "phone you're already holding as input device" is an access feature, not a convenience.
Kickstarter campaign (20 days to go, past base goal)
We're working toward Android-app and injection-mold stretches:
Happy to answer architecture / hardware questions in this thread.
Best,
Mengjie Zhang
Founder, PalmBlock
