I can't match that to bluez debug logs attached above. Any chance you could try that again? We should be seeing some "Transport XXXX: read lock acquired" messages, if things were working properly. Or it's just failing earlier than that point.
Regardless, we'll need to file this bug upstream with the bluez authors.
Seems like maybe bluez doesn't actually support the device all that well after all:
Apr 12 08:39:57 bkerensa bluetoothd[1043]: Discovery session 0x7fd800edf2c0 with :1.111 activated 0,0,0,1, 1,1,0 virtual/ input/input19 card.50_ C9_71_26_ 51_3E" card.50_ C9_71_26_ 51_3E" bluetooth- device" (argument: "address= "50:C9: 71:26:51: 3E" path="/ org/bluez/ 1043/hci0/ dev_50_ C9_71_26_ 51_3E"" ): initialization failed.
Apr 12 08:40:05 bkerensa bluetoothd[1043]: Stopping discovery
Apr 12 08:40:11 bkerensa bluetoothd[1043]: Badly formated or unrecognized command: AT+BIA=
Apr 12 08:40:12 bkerensa kernel: [ 5040.289440] input: 50:C9:71:26:51:3E as /devices/
Apr 12 08:40:13 bkerensa pulseaudio[2137]: [pulseaudio] card.c: Created 4 "bluez_
Apr 12 08:40:13 bkerensa bluetoothd[1043]: Operation not supported (95)
Apr 12 08:40:13 bkerensa pulseaudio[2137]: [pulseaudio] bluetooth-util.c: Failed to acquire transport fd: Input/output error
Apr 12 08:40:13 bkerensa pulseaudio[2137]: [pulseaudio] card.c: Freed 4 "bluez_
Apr 12 08:40:13 bkerensa pulseaudio[2137]: [pulseaudio] module.c: Failed to load module "module-
I can't match that to bluez debug logs attached above. Any chance you could try that again? We should be seeing some "Transport XXXX: read lock acquired" messages, if things were working properly. Or it's just failing earlier than that point.
Regardless, we'll need to file this bug upstream with the bluez authors.