T100-CHI needs its bluetooth device ID added to /drivers/bluetooth/hci_bcm.c static const struct acpi_device_id bcm_acpi_match[] = { + { "BCM2E71", 0 } Bluetooth works great in patched 4.3.5 with Ubuntu15.10, bluez5.3.5, blueman and using "/usr/local/btattach --bredr /dev/ttyS4 -P bcm" in /etc/rc.local. Pairing is preserved boot to boot and the devices (keydock, bt mouse) reconnect after inactivity timeouts. Bluetooth also works in Manjaro15.12 kernel 4.3.x using /dev/ttyS1. With kernel 4.4.5 I have to manually search with blueman to connect after each boot. Pairing is preserved. In 4.5, the manual search is also needed after inactivity timeouts. Any thoughts as to why manual re/connection is needed in 4.4/4.5 vs. auto connect with 4.3.x?
I forgot to mention the need to leave the device search dialog open (minimized is OK). Otherwise the bt connection is lost with kernels 4.4.x/4.5-rcx. Again, 4.3.4+ works great until 4.4.x The affected platform is the Asus T100-CHI. The CHI has a bt keyboard, so this issue hampers usability. Will update if problem is resolved in new 4.5.0 release.
Created attachment 209181 [details] bt_device_ID_T100CHI.patch Patch to add bluetooth device ID for Asus T100-CHI for kernel 4.5.x
kernel-4.5.0-next-20160321: Bluetooth self-starts, now - similar to 4.3.6. Still need to open device manager to maintain bluetooth connections but manual searching for paired devices appears to be no longer necessary. Progress is appreciated. -- Device ID BCM2E71 still missing from list --
Created attachment 210681 [details] Dmesg of sem-freeze 4.5.0, 4.5.0-next Semi-freeze (4.5.0 & 4.5.0-next...) takes 10+ hours, mostly while idle and multiple bluetooth inactivity timeouts. Seconds display (panel clock) freezes, mouse/touchscreen cursor moves freely, human interface (mouse clicks, keyboard, screen updates) is processed once every 20-90 seconds. dmesg will eventually fill with error -110s. Human interface events are queued, so it is possible to enter commands in terminal and wait up to 90 seconds for response. Semi-freeze dmesg attached, 1 full and 2 excerpts. If I turn off bluetooth right after boot, this semi-freeze does not happen nor do I get the odd mmcblk0p2 file system warnings (4.5.0-next only). 4.3.6 does not have this problem, bluetooth works as expected. CHI needs working bluetooth due to bt keydock.
Looks like semi-freeze may have been fixed in 4.6-rc1-next..30.
(In reply to jbMacAZ from comment #6) > Looks like semi-freeze may have been fixed in 4.6-rc1-next..30. Better (less frequent) not fixed.
Looks like someone got the device ID into 4.6-rc2-next-20160411. Will mark it solved when it is in one of the -rc's! Thanks to who ever got this included. semi-freeze seems to be resolved as of next-20160407.
T100-CHI bluetooth Device ID now present in latest 4.6-rc3 + Thanks, hope it gets back-ported to 4.5, 4.4, 4.3.
Device ID missing from rc5, was in rc3, rc4
Device ID still missing 4.6-rc6.
Device ID not fixed in 4.6-rc7 but is in 4.6-rc7-next series.
No bluetooth ID in 4.6.0
Seems that id is in the newest kernel now, so try and see if the newest kernel 4.6 rc 1 fixes your reported issue of no id for the bluetooth device you stated.
ID is present in 4.7-rc1 - 4.7 does not boot on baytrail, so I can't test it, yet. No ID in 4.4.12, 4.5.6, 4.6.1 Older kernels work when I patch the ID, so as long as it is there, it should be fine. I will retest again after 4.7-rc2 is published. Any chance of backports to any older kernels?
Depends, I would recommend trying to back port through the stable kernel patch as that is generally has back ports of fixes similar to the one you are reporting here. In addition try asking on the bluetooth kernel mailing list at this address, linux-bluetooth@vger.kernel.org about if and what kernels this is being back ported to.
4.7-rc2 booted with the bluetooth active without patching. Thanks for your help.