On 30.04.20 18:21, Marco Möller wrote:
On 30.04.20 17:01, luca.pedrielli wrote:
Il 29/04/20 16:23, Marco Möller ha scritto:
On 29.04.20 10:15, luca.pedrielli wrote:
|#!/bin/bashifrfkill list bluetooth |grep -q 'yes$';thenrfkill
unblock bluetooth elserfkill block bluetooth fi|
Hmmm. I have no rfkill installed in my system. I may install it and
try it out. The GUI button will know another trick, though.
rfkill is working here, but you can also try this(working here too):
$ dbus-send --system --dest=org.bluez --print-reply /org/bluez/hci0
org.freedesktop.DBus.Properties.Set string:org.bluez.Adapter1
string:Powered variant:boolean:true
or false
https://medium.com/@konchunas/how-to-toggle-bluetooth-with-shortcut-on-linux-the-proper-way-a440dd88605e
I notice that the dbus command uses "hci0" somewhere in the line. This
"hci0" is what I am for hours investigating already and therefore I
haven't answered back earlier. By now I did not find out how to deal
with this "hci0" correctly, but after you have kindly provided another
suggestion I think I should interrupt my investigations and first give
feedback what I so far found out:
By now the most promising hint towards a solution results from the
finding, that "hci0" seems to not be present as long as the magic GUI
button has not been triggered, and therefore all other so far tested CLI
tools (for instance bluetoothctl and hcitool) fail. The mouse click on
the magic buttons makes "hci0" present, though, and subsequently
commands work.
EXAMPLE (after reboot, "hci0" is still not detected by "hcitool dev"):
(1) System Settings - Network - Bluetooth: trigger the button
(2) bluetoothctl power off now works correctly
(3a) bluetoothctl power on now works correctly
(3b) the dbus command as a user now works correctly
(3c) hcitool dev now works correctly, reports "hci0"
with its MAC
(3d) bluetoothctl list now works correctly, reports the MAC
I followed your suggestions to
/usr/share/plasma/plasmoids/org.kde.plasma.bluetooth/contents/ui/Toolbar.qml
and towards rfkill and by this I hit into several more keywords,
which let me start study the issue for many more hours. I by now have
collected a list of available commands after searching for already
installed packages or by asking with the "apropos" command, but by now I
did not find out if any of them carries the secret:
Commands of interest could be:
by now only used for monitoring if "hci0" shows up or not
hcitool dev
bluetoothctl list
still not understanding how to maybe use them beyond above mentioned
monitoring:
bluetootctl
hcitool
hciattach - attach serial devices via UART HCI to BlueZ stack
hciconfig - configure Bluetooth devices
hcitool - configure Bluetooth connections
hid2hci - Bluetooth HID to HCI mode switching utility
btattach - attach serial devices to BlueZ stack
btmgmt - A command-line interface of BlueZ for management
obexctl - A command-line interface of BlueZ for OBEX (file
transfer)
The following tools demonstrate that in principal the driver is loaded
all the time, right after reboot already:
modinfo bluetooth
I am also searching towards systemd maybe needing to do something, as I
have found at least 4 systemd items which could be of interest, but also
here I haven't succeeded with my investigations by now:
systemctl status bluetooth.service
systemctl status bluetooth.socket
systemctl status systemd-rfkill.service
systemctl status systemd-rfkill.socket
Using the rfkill command as announced in the very first answer from
Luca is the only applicable path which I could find to make the
bluetooth device available at teh CLI. As this command (this package)
wasn't installed in my OS, the question how KDE is achieving to unblock
the soft block on bluetooth (even without this package being installed)
did not become clarified to me. :-(
