Report routing revisited

[kareltucek]

@benedekkupper, we would like to have more control over the bt/usb HID interfaces.

Until now, whenever an unknown bluetooth device connected, we have (very naively) assumed it is a HID device, and disabled USB HID, and consequently, have treated the connection states as mutually exclusive. This doesn't fit the bill for muliple reasons.

• we would like to know the connection states independently (i.e., call the DeviceState_SetConnection in void hidmgr_set_transport(const hid::transport* tp) less naively)
• when both are connected, we would like to be able to decide where a report is to be sent (basically implementing a kvm switch) (e.g., something like mouse_app.selec_destination(bt / usb); would fit the bill nicely.)
• specifically, if I am not mistaken, in certain situations, we would like to send the commands app reports over USB, while sending keyboard app reports over bluetooth

(Do we already have such ability? If now, what course of action do you suggest?)

[benedekkupper]

What you are asking for is to keep both connections alive at the same time, maintaining their state independently. That to me translates to having multiple instances of keyboard_app, etc, so when you swap between the transports, you take over the new transport's configuration (boot mode, more importantly caps/num/scroll lock, etc). Additionally, care should be taken that a switch happens at a time when the keys state is clear, so no key is stuck on the old transport.

That means instead of having a keyboard_app::handle(), you will have ble_handle() and usb_handle(), where you can hook into their start and stop methods to know which transport is available, and use the sending method of the appropriate handle.

[kareltucek]

That means instead of having a keyboard_app::handle(), you will have ble_handle() and usb_handle(), where you can hook into their start and stop methods to know which transport is available, and use the sending method of the appropriate handle.

Sounds about right.

It also sounds like it might result in a lot of code duplication. If that is the case, then we should probably think about it a bit more deeply. (Like, what if we decide we want to maintain multiple ble hid connections at the same time?)

(Please make it happen when time and priorities allow.)

[benedekkupper]

Like, what if we decide we want to maintain multiple ble hid connections at the same time?

That's trickier actually, and another thing to consider altogether, it would need a significant rewrite of the BLE HID implementation in the c2usb library.

[kareltucek]

Alright, me and Laszlo have agreed that:

• we definitely don't need simultaneous BLE HID connections at the moment. In the future, there is a slim chance we might like to support them, or maybe not, but either way, it is not an important feature for us, so the time investment is not justified.
• the original request - being able to send keyboard/mouse over different HID than the command interface (Agent) holds.

If I understand you correctly:

• implementing simultaneous BLE HIDS would be laborous
• implementing the 1 usb hid + 1 ble hid variant is much less laborous
• the two scenarios are more or less independent and do not impose major costs on each other.

To be clear, in case it simplifies matters, we don't strictly need simultaneous connection of the keyboard_app (mouse_app, control_app) over both HIDs. We just need for command_app to be connected to potentially different HID than the rest of the interfaces.

Should I clarify / elaborate on anything?

[benedekkupper]

If I understand you correctly:

you do, in all areas

To be clear, in case it simplifies matters, we don't strictly need simultaneous connection of the keyboard_app (mouse_app, control_app) over both HIDs. We just need for command_app to be connected to potentially different HID than the rest of the interfaces.

It would simplify matters indeed, as in the case of BLE, (due to Android limitation) the HID interfaces are all or nothing, while on USB we can pick and choose which interfaces are desired - with the caveat that the command interface's index will be shifting around if we do switch things around at runtime. I'm hoping that Agent doesn't have this hardcoded anymore, and instead searches for the HID usage code. Is this what you want as a first step? Have the agent command interface be always available via USB, even when BLE HID is connected?

[kareltucek]

Sorry 😅.

with the caveat that the command interface's index will be shifting around if we do switch things around at runtime. I'm hoping that Agent doesn't have this hardcoded anymore, and instead searches for the HID usage code.

No idea. @ert78gb ?

Is this what you want as a first step? Have the agent command interface be always available via USB, even when BLE HID is connected?

Yes, I think so.

So we are talking about:

• command interface always available via USB
• knowing independently whether BLE HID is available and whether USB HID is available
• being able to switch or pick the target connection for HID reports one way or another

Or just part of them?

[ert78gb]

Agent use usage, usePage USB descriptors to identify the communication USB interface.

https://github.com/UltimateHackingKeyboard/agent80/blob/22cd23cf578d5de82c83498043812fa833e42f9b/packages/uhk-usb/src/util.ts#L89