New Ble Hid Connection placeholder.

[kareltucek]

Similarly as host connections contain a generic "usb right" alias, they should contain an alias for a ble hid device that is not present in the host connections list - i.e., when a device is paired without any aid of Agent.

(This would be a new host connection type enum value.)

Or alternative - ban routing over such connections?

[mondalaci]

Similarly as host connections contain a generic "usb right" alias, they should contain an alias for a ble hid device that is not present in the host connections list - i.e., when a device is paired without any aid of Agent.

I think this is a firmware-related question because, at this point, the BLE host connection is not part of the user configuration. I'd name such connections "Bluetooth device" and then "Bluetooth device 2", "Bluetooth device 3" and so on. Agent should name them accordingly.

The same convention should be followed for dongles: First, "Dongle" then "Dongle 2", "Dongle 3", etc.

Or alternative - ban routing over such connections?

I'd make new BLE host connections accessible even if they're not part of the user configuration yet. There can be scenarios in which the user quickly wants to pair a BLE host without being unable to use Agent.

[kareltucek]

I think this is a firmware-related question because, at this point, the BLE host connection is not part of the user configuration.

I thought they should be managed as regular host connections, and also that firmware side supports the needed usb commands. (Although to be fair this is not tested )

So are you just saying that Robi hasn't managed to implement that yet?

I'd name such connections "Bluetooth device" and then "Bluetooth device 2", "Bluetooth device 3" and so on. Agent should name them accordingly.

I don't understand. We have agreed that Benedek shouldn't work towards supporting multiple ble hids at the same time, and we can't query device name from peripheral, so there is no point in remembering their names, and consequently I believe that we just want to name these anonymous connections "Bluetooth".

The same convention should be followed for dongles: First, "Dongle" then "Dongle 2", "Dongle 3", etc.

I don't understand.

We don't allow anonymous dongle connections - dongles are always paired and named via Agent. Do you mean that Agent should assign names according to this pattern?

I'd make new BLE host connections accessible even if they're not part of the user configuration yet.

Agreed on that at least.

[mondalaci]

I think this is a firmware-related question because, at this point, the BLE host connection is not part of the user configuration.

I thought they should be managed as regular host connections,

I don't understand your terminology. What's the difference between "regular" host connections and BLE host connections in this context?

and also that firmware side supports the needed usb commands. (Although to be fair this is not tested )

Which USB commands?

So are you just saying that Robi hasn't managed to implement that yet?

#2451 is not implemented yet.

I'd name such connections "Bluetooth device" and then "Bluetooth device 2", "Bluetooth device 3" and so on. Agent should name them accordingly.

I don't understand. We have agreed that Benedek shouldn't work towards supporting multiple ble hids at the same time, and we can't query device name from peripheral, so there is no point in remembering their names, and consequently I believe that we just want to name these anonymous connections "Bluetooth".

I'm not against using the "Bluetooth" name for all BLE host connections that are not in the configuration yet. Numbering them would make them a bit easier to differentiate them until they're saved and properly named.

Benedek shouldn't support multiple BLE HID connections simultaneously. The BLE connection of the actual host should be used, then the host should be disconnected when switching to another host.

As for the Dongle 1, 2, ... names, I meant that Agent should assign default names accordingly.

Please let's try to be as explicit as possible. This issue is rather vague from the beginning, and it's possible we're crossing wires.

[kareltucek]

I don't understand your terminology. What's the difference between "regular" host connections and BLE host connections in this context?

Well, I believe that BLE HID host connection should be a type of a host connection.

By "regular" above I meant "those other kinds of connections that we already routinely save into UserConfig" , such as dongle connections.

Which USB commands?

The one that allows querying the list of bonds that are not present in the host connection list.

So are you just saying that Robi hasn't managed to implement that yet?

#2451 is not implemented yet.

Ah, I see.

Please let's try to be as explicit as possible. This issue is rather vague from the beginning, and it's possible we're crossing wires.

I mean that Robi should extend the host connection type enum with a new value (say HostConnectionType_NewBleHidDevice). Furthermore, a list of host connections should always contain one (anonymous = with no ble address) record of the type HostConnectionType_UsbHidRight and one (anonymous) record of the type HostConnectionType_NewBleHidDevice.

[mondalaci]

Let's see if I understand your suggestion correctly. You propose a HostConnectionType_NewBleHidDevice enum to represent BLE HID host connections that have not yet been saved in the user configuration. The device protocol command that returns the list of bonds would return this enum. This suggestion makes sense to me.

According to the original host connections specification, host connections should always contain a HostConnectionType_UsbHidRight entry.

I don't understand why host connections should always contain a HostConnectionType_NewBleHidDevice entry. Please elaborate.

[kareltucek]

Let's see if I understand your suggestion correctly. You propose a HostConnectionType_NewBleHidDevice enum to represent BLE HID host connections that have not yet been saved in the user configuration. The device protocol command that returns the list of bonds would return this enum. This suggestion makes sense to me.

No.

I don't understand why host connections should always contain a HostConnectionType_NewBleHidDevice entry. Please elaborate.

The one HostConnectionType_UsbHidRight host connection record represents any PC that happens to be connected via USB.

Similarly, the one HostConnectionType_NewBleHidDevice host connection record would represent any ble hid device that happens to connect over ble hid and is not registered in the host connection list.

Furthermore, just as the one HostConnectionType_UsbHidRight allows user to specify behavior (priority and switchover) towards usb hosts, the one HostConnectionType_NewBleHidDevice would allow to specify the behavior towards unknown ble hid hosts.

[mondalaci]

Your proposal is sensible, although it makes me feel uneasy. Users can misconfigure this badly, making their BLE devices unable to connect to the UHK for seemingly no reason.

When pairing a new BLE device, I think we should always switch over to it. As for subsequent connections of this device, if it hasn't been saved to the configuration, respecting the behavior according to the HostConnectionType_NewBleHidDevice entry makes more practical sense than pairing.

[kareltucek]

Sounds sensible.

Users can misconfigure this badly, making their BLE devices unable to connect to the UHK for seemingly no reason.

They can't misconfigure it any worse than they can misconfigure their USB, can they?

[mondalaci]

They can't misconfigure it any worse than they can misconfigure their USB, can they?

Indeed. Let's give them the freedom to mess things up badly, and if necessary, we can make things stricter later. Alternatively, we can make Agent warn them about possibly problematic configurations in this respect. Let's think hard about this when host connections become usable.