Testing, opinions needed: Bluetooth switching behavior

General
1

There are a couple questions about bluetooth switching behavior for you folks. Short version is here:

  • should UHK always advertise by default?

  • should UHK keep connections active in background?

  • should empty slots be shown in Agent’s host connection list, so that they can be reordered and so that low-numbered slots can be reserved for unregistered connections?

Full reasoning follows if you want to read it, but it is by no means required in order for you to contribute your preferences.

Click to show.

Background:

There was a discussion at Switchover logic: Unexpected switch to Bluetooth during boot · Issue #1471 · UltimateHackingKeyboard/firmware · GitHub .

Tl;dr;: multiple users expressed that they are uncomfortable with uhks automatic connection switching behaviors. As a result, we have redesigned bluetooth to be strictly slot oriented. Part of that transition is already released, however more changes are coming soon.

These changes can be tried out with this firmware for instance:
uhk-firmware-17.2.0-staging_260730.tar.gz
uhk-firmware-17.2.0-staging_260731_v2.tar.gz

The main changes:

  • By default, all host switching, as well as the first connection of a session, has to be initiated by the user. Once the connection is established, it is kept until the device disconnects.

    • Part of the reasoning is to have predictable behavior.

    • Part of the reasoning is security. Don’t switch unexpectedly, and don’t advertise all the time. Turn on advertising only when explicitly required by the user.

  • For those who prefer current behavior, there is a set bluetooth.alwaysAdvertise true settings which allows the devices to always connect to UHK. Still, uhk never switches to a different connection by itself.

  • The switchover flag is mostly obsoleted. Newly, it allows the connection to be used as a “backup” when current connection becomes unavailable.

  • Uhk will now support multiple bluetooth hosts at the same time, which should resolve a number of painful reconnection loop scenarios. But this change is mostly accidental, since Benedek came with the support around the right time to introduce it with the above.

Question: always advertise by default:

Should Uhk be in the “always advertising” by default, or not?

Above discussion says it should be off by default, but with the possibility to turn on. However the sample of users is clearly a bit biased.

Question: disconnect behaviors:

When testing the keyboard, I sometimes find it frustrating that uhk keeps connected to my phone, because when trying to use the phone, the onscreen keyboard doesn’t pop up when a ble keyboard is connected.

  • Given the new philosophy of ble slots, should connections be kept connected when not active at all, by default?

Pros (of keeping them connected):

  • instantaneous switching between multiple hosts
  • prevents reconnection loops

Cons:

  • background connections are increasing power consumption, although by a negligible amount.
  • background connections may be increasing latency.
  • connections kept “in background” may make the device “unusable” (the above onscreen keyboard glitch on android). It is non intuitive that a device is blocked by a keyboard when not its active host connection.

Possible solutions:

  • When switching to another connection, always disconnect the old one. Clearly, this is undesirable in some workflows, but is in line with the slot-oriented reasoning of making the keyboard less smart and more dependable, as well as more secure.

  • Allowing some easy way to disconnect a host.

  • Blame the device and let the user manage his phone’s behavior.

Slot addressing

At the moment, known, agent-registered host connections are mapped at the beginning of the connection slot list. After that, unregistered connections and empty slots are placed.

The registered slots are always identified by the registered host connection list index, which is frustrating.

This is frustrating, because those connections that can be easily identified by name occupy the low numbered slots, while the rest of the connections shift around in the unnamed slots depending on the number of registered hosts.

Proposed solution:

  • Show empty slots in Agent as well, and so allow the user to reorder the slots as he pleases. E.g., having the first 5 slots reserved for unregistered connections, and addressing registered connections by names (via macros atm).

Also here is a tentative pre-release firmware. We would appreciate testing, feedback: uhk-firmware-17.2.0-staging_260731_v2.tar.gz

2

should UHK always advertise by default?

IMO, it should not. I would like to be able to toggle this behavior.

should UHK keep connections active in background?

IMO, it should not. I would like to be able to switch the connection discretely from one machine to another w/out having active background connections.

Another personal opinion I have is that when the UHK is disconnected / reconnected, or the connected machine reboots, that it should go back to the previous slot that it was connected to, rather than falling back to a different slot. Eg: My UHK80 is connected to a Mac over BT and has a wired connection to a Linux PC. And when the PC reboots, it always goes back to the Mac BT connection as the default. Then I have to switch the UHK80 back into wired connection manually.

Thank you

Naz

2 Likes
3

I don’t have any opinions on the lists stuff in Agent as I just have the OG60, so I have not used that, but for the connection behavior, I think the defaults should be as follows, based on my usage of other BT devices:

  • Turned on while not plugged in via USB: Connect to latest connected device if available, otherwise do nothing
  • Turned on while plugged in via USB: Do not connect to BT at all
  • No advertisement/pairing mode by default, unless turned on without any defined connections or USB connection
  • Do not automatically connect to BT if USB is interrupted
  • Maintain one BT connection while connected through USB for rapid switching. Considering the above defaults, either the user actively connected BT while plugged in, or the user plugged in while connected to BT, so neither connection would come as a surprise
  • While it’s a great option to have, do not maintain two BT connections at a time, by default

Of course, the more of this is configurable, the better. Preferably through Agent and not just hidden away in macros, so the average user notices, because the simultaneous connections for rapid switching is an awesome feature.

As far as the Android keyboard goes, I have the same issues when plugging in security keys like Yubikeys, and for some reason, my Android at least generates an Enter keypress when a keyboard is pluqqed/unplugged. I don’t know what would drive anyone to implement that.

1 Like
4

Connect to everything that’s paired if it’s available. Keep all the connections alive. But don’t automatically switch the report routing unless manually switched by user or macro command.

Alternatively: establish connection only when user first switches to that slot. Then keep the connection alive (even when user switches to other slots) until lost or manually disconnected by user.

Slots need to be fixed, so I know that when I switch to my n-th connection slot it’s either the specific host that I’ve paired in that slot, or “not connected” (the slot is selected in any case). New pairings go into the slot that I’ve selected. If a slot is already taken, no new pairing into that slot. User first has to clear the slot.

Hope that makes sense.

1 Like
5

I agree; I think most of this stuff needs to be clearly configurable.

It would be nice if each device in Agent’s Connections list had a checkbox to “Keep connection alive” or whatever. Of course, I’m not a dev & I have no idea if/how that’s doable.:sweat_smile:

Regardless of defaults, I really hope we can at least get a way to disconnect specific hosts. It would be super helpful to have a quick on-demand way to tame a misbehaving Bluetooth device (those reconnection loops are an unpredictable PITA).

1 Like
6

Thanks all!

Another question: Should Agent’s native switch host action reference slots or hosts?

I.e., should changing order on the connection page change which host the switch actions refer to?