Bluetooth Human Interface Device peripherals are on BTHIDD architecture, rather than UHID, IICHID or USBHID architectures. BTHIDD is based on libusb, so it doesn't have the range of hardware compatibility that USBHID has. HID-over-I2C was by Microsoft, so wasn't supported by Apple, and it isn't as flexible for newer kinds of hardware. IICHID seems to be named from it, and FreeBSD drivers that used it were adapted to USBHID.
Human Interface Device (HID) Support in FreeBSD 13 of July/August 2021 in the FreeBSD Journal, states how work is being done to move bthidd to usrhid. Does this mean, that it still relies on uhid? What's the progress on it for 13.1 or Stable?
I was considering attempting to set up my Bluetooth dongle as much as possible, even if it relies on older drivers, or if the dongle isn't fully supported yet. It has recognized a peripheral device over Bluetooth before in this state. Thinking about it, my only Bluetooth device uses hgame, and a gamepad driver may not be available on uhid. If I use uhid, I'll have to recompile my kernel. I've used this controller before with Antimicro and x11-drivers/xf86-input-joystick on older versions of FreeBSD that didn't have hgame(4).
Bluetooth on FreeBSD works on top of Netgraph, which has many functions and drivers outside of Bluetooth. You can see this by typing
It's better to have these compiled into the kernel:
Without these, there can be minor warning messages about drivers loading after "domainfinalize()". The drivers can also be loaded through
When attaching dongle:
When detaching dongle:
The Bluetooth dongle's permissions may need to be set up, so other programs have a chance to access it and peripheral potentially connected to it. This will be the hub, and may not be ugen for peripherals connected. Permissions and configurations of peripherals connected to this dongle may need to be set with Bluetooth's drivers as a hub, rather than based on ugen.
In this, additional o+rx permissions are added, as well as additional permissions to user and group. Run
After setting up the bthidd(8) connection with hccontrol(8) (from instructions in https://freebsdfoundation.org/freebsd-project/resources/networking-basics-wifi-and-bluetooth/, and adapted as https://forums.freebsd.org/threads/...oysticks-for-desktop-usbhid.84464/post-570160):
Received this in
No other
Then, the device was shown as disconnected:
Before, and after reloading the Bluetooth connection, it had:
After reconnecting it, tried Antimicro, emulators/joytran, and xev, but no result.
I don't have much more expectations for this on FreeBSD 13.1, which I'm using now, but I wonder if it's possible to make my system go a little further. Looking at comms/hcidump to see about communications between the gamepad and the dongle.
Human Interface Device (HID) Support in FreeBSD 13 of July/August 2021 in the FreeBSD Journal, states how work is being done to move bthidd to usrhid. Does this mean, that it still relies on uhid? What's the progress on it for 13.1 or Stable?
I was considering attempting to set up my Bluetooth dongle as much as possible, even if it relies on older drivers, or if the dongle isn't fully supported yet. It has recognized a peripheral device over Bluetooth before in this state. Thinking about it, my only Bluetooth device uses hgame, and a gamepad driver may not be available on uhid. If I use uhid, I'll have to recompile my kernel. I've used this controller before with Antimicro and x11-drivers/xf86-input-joystick on older versions of FreeBSD that didn't have hgame(4).
Bluetooth on FreeBSD works on top of Netgraph, which has many functions and drivers outside of Bluetooth. You can see this by typing
man -k netgraph
.It's better to have these compiled into the kernel:
Code:
options NETGRAPH
options NETGRAPH_SOCKET
options NETGRAPH_BLUETOOTH
options NETGRAPH_BLUETOOTH_SOCKET
kldload
before plugging in the dongle. Other specific drivers to the dongle's needs that aren't pre-loaded will also be auto-loaded when attaching the hardware.When attaching dongle:
Code:
usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
ugen0.2: <vendor 0x0a12 product 0x0001> at usbus0
ubt0 on uhub0
ubt0: <vendor 0x0a12 product 0x0001, class 224/1, rev 2.00/52.76, addr 9> on usbus0
hardware_error: ubt0hci - hardware error 0x37
When detaching dongle:
Code:
ubt0: ubt_bulk_read_callback:1119: bulk-in transfer failed: USB_ERR_IOERROR
ubt0: ubt_intr_read_callback:1020: interrupt transfer failed: USB_ERR_IOERROR
ugen0.2: <vendor 0x0a12 product 0x0001> at usbus0 (disconnected)
ubt0: at uhub0, port 1, addr 8 (disconnected)
ubt0: detached
The Bluetooth dongle's permissions may need to be set up, so other programs have a chance to access it and peripheral potentially connected to it. This will be the hub, and may not be ugen for peripherals connected. Permissions and configurations of peripherals connected to this dongle may need to be set with Bluetooth's drivers as a hub, rather than based on ugen.
Code:
# testing Bluetooth dongle;
# permissions for /dev/usb/
notify 100 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "ATTACH";
match "vendor" "0x0a12";
match "product" "0x0001";
action "chgrp wheel /dev/$cdev; chmod 775 /dev/$cdev";
};
service devd restart
to adjust these permissions. This is for testing.After setting up the bthidd(8) connection with hccontrol(8) (from instructions in https://freebsdfoundation.org/freebsd-project/resources/networking-basics-wifi-and-bluetooth/, and adapted as https://forums.freebsd.org/threads/...oysticks-for-desktop-usbhid.84464/post-570160):
Received this in
dmesg
which occurs from time to time inconsistently:
Code:
ng_l2cap_lp_discon_ind: ubt0l2cap - unexpected LP_DisconnectInd event. Connection does not exist, con_handle=42
dmesg
message has come up than this, and for connecting and reconnecting the dongle.Then, the device was shown as disconnected:
Code:
Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
Code:
hccontrol -n ubt0hci read_connection_list
Before, and after reloading the Bluetooth connection, it had:
Code:
Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
01:06:8b:5c:61:07 42 ACL 0 MAST NONE 0 0 OPEN
After reconnecting it, tried Antimicro, emulators/joytran, and xev, but no result.
I don't have much more expectations for this on FreeBSD 13.1, which I'm using now, but I wonder if it's possible to make my system go a little further. Looking at comms/hcidump to see about communications between the gamepad and the dongle.