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.
What's interesting technically
- 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): there's an optional voice-to-text feature that pipes phone audio through the OpenAI Whisper API. It is off by default. We're adding an explicit "completely disable" toggle in the app settings after backer feedback, because "off by default" wasn't a strong enough signal.
How we actually use it
We've been running DexoPad ourselves while developing it. The honest reason it stayed in the pile after the initial prototype:
- When a long-running terminal session crashes and we need to type a 200-character recovery command into a Mac that has no nearby keyboard, the dongle saves real time.
- Initial setup for Raspberry Pi / mini-PCs without dragging out a keyboard + mouse.
- BIOS settings on machines that don't expose USB keyboard over the network KVM cleanly.
It's not glamorous. It's just one of those things that quietly stops being annoying.
Where to follow
We're funding the production run on Kickstarter right now. Already past base goal, working toward the Android-app stretch.
Comments / use cases / "wait have you tried X" — welcome here or on the campaign page. We read all of them.
— MJ, PalmBlock