feat(kernel): add generic KeyboardService abstraction
#158
Conversation
There was a problem hiding this comment.
Does this empty file need to go away? Or did something weird happen?
There was a problem hiding this comment.
whoops, i started on this in a different branch and i must have accidentally committed it, good catch!
| /// returning a [`KeySubscription`]. | ||
| pub async fn subscribe_to_keys(&mut self) -> Result<KeySubscription, Error> { | ||
| if let Response::SubscribeToKeys(sub) = self.request(Request::SubscribeToKeys).await? { | ||
| /// Subscribe to raw keyboard input from `i2c_puppet`'s Blackberry Q10 |
There was a problem hiding this comment.
technically we use the Q20 keyboard. The OG solder.party hardware used the Q10, the beepy (and newer solder.party hardware) uses the q20. It doesn't really matter, as that hardware is all downstream of the i2c puppet chip we actually talk to though.
There was a problem hiding this comment.
thanks, will update docs
| @@ -426,7 +486,7 @@ impl I2cPuppetServer { | |||
| } | |||
| } | |||
|
|
|||
| if !self.subscriptions.is_empty() { | |||
| if !self.subscriptions.is_empty() || self.keymux.is_some() { | |||
There was a problem hiding this comment.
Do you know if the i2c puppet automatically overwrites oldest chars? doesn't really matter, but if not we might still want to drain it periodically, or on first connect to discard potentially stale data?
This is really nitpicky tho.
There was a problem hiding this comment.
i think we can configure that behavior with the OVERFLOW_ON config flag. we're not currently setting that, so we probably should enable it.
| Pause, | ||
| /// Menu key. | ||
| Menu, | ||
| /// The "Begin" key (often mapped to the 5 key when Num Lock is turned on). |
There was a problem hiding this comment.
Is this beepy specific?
There was a problem hiding this comment.
no, i believe this is a normal keyboard thing (i copied it from crossterm). idk if the beepy keyboard even has this behavior at all.
| settings: KeyboardMuxSettings, | ||
| ) -> Result<(), RegistrationError> { | ||
| let (key_tx, key_rx) = KChannel::new_async(settings.buffer_capacity).await.split(); | ||
| let (sub_tx, sub_rx) = KChannel::new_async(8).await.split(); |
There was a problem hiding this comment.
Should this be DEFAULT_MAX_KEYBOARDS?
yup, looks like i still need to fix Pomelo before merging this... |
jamesmunns
added
area: kernel
Currently, we have an implementation of a driver for the Blackberry Q10
keyboard on the Beepy in the
mnemos-beepycrate. However, there's noway for cross-platform code in the kernel, such as the graphical forth
shell, to consume keyboard input, because the keyboard driver is
Beepy-specific. This branch fixes this by adding a generic
KeyboardServiceinkernel::services, which is not hardware-specific.In addition, in order to support multiple keyboards, such as the SerMux
pseudo-keyboard, we also add a new
KeyboardMuxServer, which allowstasks which want to consume keyboard input to subscribe to key events
from all available keyboards. This type implements the
KeyboardService, for consumers of keyboard events, as well as aKeyboardMuxService, which keyboard drivers can use to publish keyboardevents to any task subscribed to the mux. The graphical forth shell now
consumes the
KeyboardService, allowing it to handle input from boththe SerMux pseudo-keyboard and the Beepy Q10 keyboard without being
aware of either implementation specifically.
This allows us to type on the Beepy keyboard and get text on the screen!
It's currently a bit laggy, which I think is at least partially due to the 50ms
poll interval in the
i2c_puppetdriver. I hope changing the driver to use aGPIO interrupt instead will reduce this lag...
It does work, though!!!!
