Switchover logic: Unexpected switch to Bluetooth during boot

[vpal]

Greetings,

I'm on 16.1.1.
I have no battery.
My connections look like this:
PC > USB + Permanent Power > Keyboard
Mac > Bluetooth > Keyboard

My connection configuration looks like this:

The issue I'm experiencing

1. I shut down the PC, the keyboard is connected to it via USB, so the connection configured on the keyboard is USB, not just the physical connection.
2. I start up the PC and the keyboard is connected to USB still
3. When I get to the GRUB password the connection is already switched to Mac (Bluetooth) and the Mac is woken up
4. I switch back to PC, wait for the Mac to go to sleep again, type the password, the boot continues
5. During the boot once again the connection switches to Mac (Bluetooth) and the Mac is woken up
6. When the PC boots up and I get to the window manager I switch back to PC again
7. From here everything works as expected

My understanding is that based on my configuration the keyboard should never switch to Bluetooth unless I explicitly trigger the switch.
My config is a bit special as the Keyboard gets the power from one of the PC USB ports even if I use the Mac as I do not have a battery.

This is very frustrating and I think is also a bit of a security issue as one might type a password on a computer where it is not supposed to be typed.

The expected behavior is that when the keyboard boots up it connects to USB and it keeps being connected to it unless I switch to any other connection.

Let me know if you need more information.

[pcooke9]

If I'm not mistaken, if you select the USB switchover box, the USB should always take priority unless manually switching hosts.

[mhantsch]

Something is not quite right in the firmware. I've experienced similar things. Despite the switchover checkbox not being ticked, my UHK80 in the office switches over to my Pixel phone despite being plugged into USB to my laptop. I have to unplug/replup USB, sometimes reboot the UHK until it goes back to USB. But with the switchover box unchecked, it should NEVER switch hosts on its own.

[pcooke9]

I was under the assumption that if no hosts are selected in switchover settings, then the next available device auto-connects. So when booting the USB device, there are temporary disconnections, and another host will connect.

[mhantsch]

But then what's the checkbox for if it always automatically switches? I don't want it to switch to BT unless I explicitly hit a switch key.

[pcooke9]

I just double checked, and my previous comments do seem to be the case. It appears that whenever the current device is disconnected, the UHK80 tries to auto-connect to the next available host. If multiple devices are available, then the next device as it appears in the connections list will take precedence.

I tested with Windows PC connected via USB, and a dongle connected to a different host:

•With USB switchover selected; when rebooting PC, the UHK will very briefly (half second) switch to the dongle and back a couple of times, and then remains connected to USB once it reaches the login screen.

•No hosts selected in switchover; when rebooting PC, the UHK will switch to the next available host, and stay on that device, unless I manually switch back to USB.

I'm not sure if that's the intended behavior, but I'm pretty sure that's the way it's always been (for me, at least). Maybe an option to never auto-connect to a different host would be a good idea 🤷🏻‍♂️?

[pcooke9]

I kinda wonder if auto-switching/connecting might be a big part of what's causing the BT issues in general. Especially the reconnect loops. I'm not a dev though, and I don't really know what I'm talking about so, I'll just stop speculating now 😅.

[vpal]

@pcooke9 thanks for your comments.
I tried this setting and it kinda works in theory, but not in practice though.
Why it does not work is that it wakes up the Mac once or twice during PC boot, that is not part of the intended behavior.
This improves the behavior by switching back, but does not solve the problem in a whole.
This is the setting we are talking about:

A few notes from my side.
Based on what happens here I assume that these configurations produce the same results and this does not make intuitively sense to me:

From a user perspective the missing piece is the explicit or the implicit default connection with the fact of no switching to a connection when none of checkboxes is checked.
By explicit connection I mean something similar to the default keymap and how that behaves: when the keyboard boots up that keymap is selected and there is no automatic switching away from that keymap.
This in my opinion is either done by implicitly making the USB or the first connection in the list as "default" or "boot up" connection or adding a column to that list with a radio button that lets the user select the default connection.
And when that is selected and all the switchover checkboxes are unchecked no automatic switch between connections should happen.

[kareltucek]

I was under the assumption that if no hosts are selected in switchover settings, then the next available device auto-connects. So when booting the USB device, there are temporary disconnections, and another host will connect.

This is spot on.

But then what's the checkbox for if it always automatically switches? I don't want it to switch to BT unless I explicitly hit a switch key.

With switchover, UHK switches to that host automatically whenever the host connects.

In the scenario described in the first post, most of the problems should be mitigated by checking the USB's switchover.

I kinda wonder if auto-switching/connecting might be a big part of what's causing the BT issues in general. Especially the reconnect loops.

I very much doubt it.

Based on what happens here I assume that these configurations produce the same results and this does not make intuitively sense to me:

No.

• When both are checked, UHK will actively switch to the newly connected one.
• Wnen neither is checked, UHK will only switch away from a host once it has been disconnected.

---

So far this looks to me like correct (although maybe nonintuitive) behavior.

I also find it hard to wrap head around, but we have not figured out anything better when designing the host connection flows.

Leaving open for further discussion.

[kareltucek]

One idea is to change the switchover box to an enum that would have options switchover { never | fallback | everytime }. Current state of affairs would correspond to fallback and everytime options.

The suggested behavior would be achieved by everytime on USB and never on Bt.

[kareltucek]

When designing the flows, it seems we assumed the following assumptions that turned out to be wrong 🤔:

• that a connection (usb in this case) is stable without spurious reconnects. We didn't realize that for usb there are reconnects due to nkr/boot protocol switches.
• that users have their bluetooth devices under control.

[mondalaci]

When writing this application logic, please elaborate on these cases in the comments; otherwise, few will ever understand why it works the way it does.

[kareltucek]

Guys ( @vpal @pcooke9 @mhantsch @mondalaci ) any actual opinions or suggestions?

(Would switchover { never | fallback | everytime } suggestion solve the issue in your eyes? Or does there still need to be a setDefaultHost <hostname> with special handling @vpal?)

[mhantsch]

I wouldn't switch anywhere that doesn't have a "switchover" box checked. So for me, there would only be never and fallback. The choice of 'everytime' makes not much sense to me because I don't want anything to automatically switch away from a working connection just because something else connected.

[pcooke9]

I guess switchover { never | fallback | everytime } seems reasonable to me. Default for new host devices should probably be never. I agree with Max that I generally prefer to switch manually. I don't feel strongly about a setDefaultHost option, but I imagine the everytime/never choices should be sufficient for that usecase.