USB "backchannel" for switching keyboard state(s) from host?

[TheDiveO]

Is there a means besides the standard caps lock, etc. LED control to tell a Keybow USB device which keyboard (layout) state it should be in? E.g., to switch into a "debugging keyboard layout" while my IDE is in program debug mode?

[David Glaude]

You can use a variable in LUA to remember the state.
So you can assign a key to "state switching" and use the LED to indicate the "current state", then you can have has many state as the number of color you can distinguish.

Here key 00 is the state indicator and switching, you can switch between Red, Green and Blue mode.
Pressing key 01 with send the key stroke R, G or B depending of the current mode.

`
require "keybow"

state = 0

function setup() -- Set custom lights up
keybow.auto_lights(false)
keybow.clear_lights()
state = 0
keybow.set_pixel(0, 255, 0, 0) -- Red
end

function handle_key_00 (pressed)
if pressed then
state = state + 1
if state == 1 then
keybow.set_pixel(0, 0, 255, 0) -- Green
end
if state == 2 then
keybow.set_pixel(0, 0, 0, 255) -- Blue
end
if state == 3 then
keybow.set_pixel(0, 255, 0, 0) -- Red
state = 0
end
keybow.sleep(500)
end
end

function handle_key_01 (pressed)
if state == 0 then
keybow.set_key("R", pressed)
end
if state == 1 then
keybow.set_key("G", pressed)
end
if state == 2 then
keybow.set_key("B", pressed)
end
end
`

[TheDiveO]

thanks, but that isn't exactly what I'm asking for: I'm rather asking for switching keymaps under control of the USB host, where some host app instructs the keybow as opposed to the user switching keymaps using a keybow key.

FYI, my multibow project already allows for cycling through multiple layouts, with easy separation of the layouts into separate modules, as well as hiding nasty things like automatic LED feedback and switching acording to active layout. And multibow allows easy binding in one place per layout, so switching key positions is easy, and located in a single place. Avoids scattering key nos and LED nos in many places, which makes rewiring error prone.

[Philip Howard]

The trouble with adding more USB functionality is the compatibility tradeoff- I'm keen to investigate just how far we can push it, but I'd like to avoid needing custom drivers (inf or otherwise) or any changes that will make the Keybow a hassle to get working with certain platforms.

There are certainly numberous ways to allow control of Keybow from the Host, and I suspect the most accessible of those would be USB Serial where - in C - we could run a readline on the Serial port and pass each "command" received directly into a Lua function. Picade takes advantage of this quite effectively- showing up as a Keyboard/Gamepad combo that can be entirely reconfigured over Serial.

An open Serial port would also give us a pipeline for debugging information, which could be handy.

Right now on my list to investigate is:

1. Media Key functionality
2. USB Serial
3. USB MIDI

If I can pack this all into the Keybow firmware without having variants for different use-cases, that'd be ace.

[Maker's End]

The USB serial would be the most versatile and would allow sending data based on things like app-switch events (as @thediveo is asking for) but it's not clear to me if we can have both the HID and debug ports open on the same USB port. If we can then this should be pretty straight-forward.

The NepoTrellis supports media keys, so adding that shouldn't be complicated, and that's still under normal HID functionality.

[Philip Howard]

My big fear with Serial is Windows compatibility. CDC aerial drivers weren’t introduced until Windows 10, installing unsigned drivers on 8 is a nightmare, and 7 is at least tolerable.

If I can make the serial port available alongside MIDI then I’ll certainly do so. We’ve got enough CPU overhead to have a thread pulling the serial comms into a queue that Lua can process on a timer event or key press.

I’d like to have full key remapping and perhaps even dynamic Lua file reloading available with Serial commands, alongside full control of the lighting. I don’t plan to do much but document the API for the client software side though, since that’s a can of worms I can’t afford the time to open right now.

It might well be that it’s “send what you like over serial with \n as a command terminator” and then the Lua code you write on the device would be responsible for parsing and understanding the commands either as binary data or text. IE: no rules, just an open port to use however you need.

Uploading new code over serial would be cool- too. It’s on my TODO list to allow limited write access to /boot for saving permanant state (using a remount,rw, write, remount,ro cycle). Saving entire Lua files would probably come free with this functionality. It’s something that- for the sake of robustness- should be done carefully and infrequently though.

[htmlcsjs]

i see thay added somthig like this in v0.0.4 but is it avalibe in lua?