Getting Started
What is Lokey?
Lokey is a framework for developing firmware for a variety of input devices.
Keyboards, mice, and MIDI controllers are supported out of the box, but the framework can also be extended to other kinds of input devices.
Lokey is written in Rust and built on top of Embassy. It is designed to be modular, so you can combine features and adapt them to different hardware targets. It also aims to keep APIs user-friendly, making firmware code easier to build and maintain.
WARNING
Lokey is still in an early stage of development. The information described on this site may change as the framework evolves.
Overview
Before starting to work with the lokey framework, it is important to understand how the crates are structured.
-
Core crate
The core crate
lokeyis used as a dependency for all other crates in the framework. It contains functionality and abstraction layers that are useful to different kinds of input devices, such as Components, Transports, States, and more. -
Feature crates
Feature crates provide specific functionality or a related group of capabilities. These crates are named
lokey-<feature>.EXAMPLES
- The
lokey-usbcrate contains an external transport for sending messages over USB. - The
lokey-nrfcrate adds support for the nRF series of microcontrollers. - The
lokey-keyboardcrate contains implementations for key scanning, keyboard layouts, and other keyboard-related features. - The
lokey-layercrate contains functionality for managing layers.
- The
-
Device crates
Device crates add support for a specific device or a group of devices. These crates are named
lokey-device-<device_name>.EXAMPLES
- A crate
lokey-device-cornewould add support for the Corne keyboard by defining a device type (or two, since it is a split keyboard) and implementing the relevant keyboard components (e.g. by specifying which keys are connected to which pins of the microcontroller).
- A crate
-
Binary crates
Binary crates are used to build the firmware for a concrete device setup, pulling together the chosen components, device definitions, and configuration settings. The name of these crates does not matter because they usually only contain personalized settings such as keyboard layouts and therefore should not be uploaded to crates.io. Unlike the previously mentioned crate types, these crates are not libraries.
INFO
While you are not required to structure your own implementations this way (for example, you could have a single crate containing components, device support, and configurations), it is generally a good idea to follow the structure described above. Doing so helps preserve the framework’s modularity and can also improve compile times.
Rust version
Currently a nightly version of Rust is required. The rust code doesn't actually use any nightly features, but the nightly cargo feature "per-package-target" is used.