-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manjaro-Arch Linux Kernel 4.17 #28
Comments
That script can not always find the correct serial device. In addition, it has to guess at the starting rate. Have you looked at file hciattach.txt? I thought that kernels as new as 4.17 had code built in for serial BT devices. |
No bluetooth adapters are being detected by default. 4.17 might have code for serial BT but, not the driver for my tablet. For ttyS1 - hciattach.txt: For ttyS2 - hciattach.txt: Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 2, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 3, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 4, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 5, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 6, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 7, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 8, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 9, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 10, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 11, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 12, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 13, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 14, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 15, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 16, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 17, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 18, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 19, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 20, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 21, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 22, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 23, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 24, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 25, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 26, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 27, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 28, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 29, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 30, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 31, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 32, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 33, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 34, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 35, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 36, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 37, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 38, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 39, len: 8 Realtek Bluetooth :3-wire sync pattern resend : 40, len: 8 Realtek Bluetooth ERROR: H5 sync timed out For ttyS2 I simplified your script: Shell script to install Bluetooth firmware and attach BT part ofRTL8723BSTTY="/dev/ttyS2" if [ ! -f /lib/firmware/rtl_bt/rtlbt_config ]; I also tried: $ sudo hwdetect --show-bluetooth --> displays nothing Thank you for helping :-) |
Please run the following to determine what ttyS devices are on your system: In addition, please copy the output of the dmesg command to some pastebin location and post the link here. |
$ /dev/ttyS* |
Hi, since hciattach is depreciated, I tried to use btattach (the replacement): $ sudo btmgmt power on $ dmesg | grep Bluetooth |
Confirmed this issue still persist in Arch Linux on 1.8.2018, and appears to not being fixed |
Does a kernel bug report exist for this issue? |
I doubt so. I analyzed the commits on the r8723bs driver in staging tree, and it seems there is little to no work being done on it, sooo... So you are probably not going to see it anytime soon, unless you are C guru and willing to move throught the commit submitting hassle. |
Did you also look at the commits for drivers/bluetooth/btrtl.c? That is where any BT changes would be made. I know there are significant additions of code for serial devices in kernel 4.19-rc1, thus you probably should get the source for the mainline kernel and test with it. If your device does not work with that kernel (no external drivers needed), then that should be reported to the mailing list linux-bluetooth@vger.kernel.org. FYI, my only part of this activity is to take drivers sent to me by Realtek and verify that they build. I do no testing of such drivers, thus I have no means of fixing them, other than build errors. Others are involved in the current work to ensure that the devices work with btrtl.ko in conjunction with btusb.ko. |
I looked it up today in the kernel tree, and in 4.18 appears to be nothing related to the rtl8723BS in the drivers/bluetooth/btrtl.c, but in the upcoming release, 4.19 (rc3 currently), the btrtl.c appars to be supplied with some rtl8723BS-relevant code, so we could see some improvements soon I think. I currently don't have enought machines to test it on, so I can't test it anytime soon. |
I switched to kernel Some dumb questions: Should I recreate this ttyS1 or will it be deleted by the (incorrect) boot process? It the former, how? Do I have to uninstall some files from this repo? All firmware files in /lib/firmware/rtl_bt have a .bin suffix except for the ones from this repo. Should they be renamed? I tried and followed the scheme in the Orochimarufan repo - no change. Any findings whether rtlbt_fw or rtlbt_fw_new should be preferred? |
No, manually creating the device file probably won't help you. At least it didn't for me. And... Let the files be as they are. Renaming them only confuses the software, so don't do it. |
I can confirm that a missing device file (ttyS1 in my case) is a fatal symptom after booting. It is explained in issue #26. |
In kernel 4.19, no patch is needed. Neither start_bt.sh nor rtk_hciattach are needed. |
The kernel .config for manjaro seems to be ok (checked for kernel 4.19), except that CONFIG_BT_HCIUART_RTL is not set. Is this a problem? Furthermore, the binaries hciconfig / hcitool are deprecated and not contained in newer distros like Manjaro. |
Yes, it is a problem. Even CONFIG_BT_HCIUART_RTL=m does not work, CONFIG_BT_HCIUART_RTL=y is needed. In my distribution (CentOS7) the commands hciconfig and hcitool are in a package named bluez. |
If your kernel has CONFIG_BT_HCIUART_RTL=m, you might have to manually load module hci_uart. The serial BT device would not be able to be found by a bus scan. I cannot think of any other reason for the "m" option to fail. |
Manjaro kernel 4.19.1 contains all required modules. Instead of hciconfig, one can use bluetoothctl, see https://wiki.archlinux.org/index.php/Bluetooth_keyboard . |
I upgraded Ubuntu 18.10 Kernel to 4.20.3 using the Ukuu Kernel Update Utility Reboot. As a normal user configure bluetooth (only needed once) by starting bluetoothctl and then entering the following command at its prompt: Your bluetooth device should work now. If you need to reconnect (after a reboot etc.), you only need power on and connect. The issue is at the connect stage, it successfully pairs however, devices (laptop and android phone) don't connect to the tablet. Unified Remotes using SDP bluetooth protocol below instructions: |
If you want to pair non-keyboard devices, the command |
Hi, I am trying to get bluetooth to work on Manjaro-Arch Linux Kernel 4.17. Have a CHUWI Hi10 Pro (CWI529, HQ64G4216xxxx). I followed the instructions with no errors. Start_bt.sh when run prints "Using device /dev/ttyS1 for Bluetooth" But when I try to start Bluetooth Manager, states "no Bluetooth Adapters Detected" and "sudo hwdetect --show-bluetooth" shows nothing.
Any advise appreciated.
The text was updated successfully, but these errors were encountered: