Created attachment 1170011 [details] terminal output for version 2.0.4-2.fc23 Description of problem: The bluetooth disabled icon appears after startup even though the adaptor is enabled. No control of bluetooth adaptor from blueman-applet. Version-Release number of selected component (if applicable): blueman-2.0.4-2.fc23 How reproducible: Consistently Steps to Reproduce: 1. Install blueman update 2. exit running version of blueman or restart PC (either work) 3. try changing the state of the bluetooth adaptor Actual results: See attached output file, there is a problem with state changes. Expected results: bluetooth adaptor should be enabled after logging into MATE and fully controllable from the applet. Additional info: F23 MATE 1.14.1 GTK+2 with Compiz as Window Manager. It is a clean install today which enabled me to pinpoint where this issue actually came from. It affects the notebook with F24 as well. The issue is fixed by downgrading to blueman build 2.1-0.3.git7a2e20e.fc23.
Created attachment 1170012 [details] terminal output for build 2.1-0.3.git7a2e20e.fc23 2.1-0.3.git7a2e20e.fc23 terminal output showing downgrade and subsequent output of working build for comparison with a power state change from the blueman-applet
Created attachment 1170013 [details] lsusb -v output for the adaptor It's an intel bluetooth device integrated internally into my notebook.
Missed a step to Reproduce: 1. Install blueman update 2. exit running version of blueman or restart PC (either work) 3. start blueman-applet 4. try changing the state of the bluetooth adaptor
Known bug and it happens mostly after system resumes from suspend. Try to fix with 'hciconfig hci0 up' in a root terminal and restart blueman.
Filed upstream https://github.com/blueman-project/blueman/issues/537
(In reply to Raphael Groner from comment #4) > Known bug and it happens mostly after system resumes from suspend. > Try to fix with 'hciconfig hci0 up' in a root terminal and restart blueman. Thanks for the answer. I don't suspend my notebook, it happens from cold boot as well or just running the applet from terminal. That command worked but do I have to enter that every time I turn the notebook on? If so, it still needs addressing properly as that is not an acceptable long term solution to be fair.
as suspected it's a session only fix. even then I'm reliant on this terminal command to turn the device on or off as needed. sudo hciconfig hci0 up|down
the applet works properly with sudo rights when run from terminal: sudo blueman-applet
(In reply to Mike Simms from comment #8) > the applet works properly with sudo rights when run from terminal: > > sudo blueman-applet blueman has full control like this but you still need to issue the hciconfig hci0 up command beforehand.
@arehtykitna, this is intended behaviour. BlueZ does not power the adapter automatically any-more since version 5.0. There are two options, enable auto-power on in the PowerManager plugin or create a udev rule as described here. The former will power the adapter when you login and the latter will do it as soon as the adapter is detected. from infirit - https://github.com/blueman-project/blueman/issues/537 solution: Create a file in /etc/udev/rules.d/ (eg 50-bluetooth-hci-auto-poweron.rules) with the following content ACTION=="add", SUBSYSTEM=="bluetooth", KERNEL=="hci[0-9]*", RUN+="/bin/hciconfig %k up" ________________________________________________________________________________ I was not aware of this policy change, sorry for any inconvenience caused.
(In reply to Mike Simms from comment #10) > @arehtykitna, this is intended behaviour. BlueZ does not power the adapter > automatically any-more since version 5.0. There are two options, enable > auto-power on in the PowerManager plugin What do you mean with PowerManager plugin? How to do in Cinnamon (or other desktop environment)? > or create a udev rule as described > here. The former will power the adapter when you login and the latter will > do it as soon as the adapter is detected. > > from infirit - https://github.com/blueman-project/blueman/issues/537 > > solution: > > Create a file in /etc/udev/rules.d/ (eg 50-bluetooth-hci-auto-poweron.rules) > with the following content > > ACTION=="add", SUBSYSTEM=="bluetooth", KERNEL=="hci[0-9]*", > RUN+="/bin/hciconfig %k up" Thanks for forwarding from upstream documentation. https://github.com/blueman-project/blueman/wiki/Troubleshooting#turn-on-bluetooth-device-on-boot This should get fixed in udev (or bluez) to provide it as a standard rule, independent from any used DE.
> This should get fixed in udev (or bluez) to provide it as a standard rule, > independent from any used DE. Indeed, the udev rule would be best if possible. That's why I chose it as the solution for my own purposes. Suppose I want to install and use a different DE, the same fix covers all of them.
*** Bug 1348669 has been marked as a duplicate of this bug. ***
Hi, I added to bluez a month or two ago a conf file from upstream, /etc/bluetooth/main.conf. At the bottom of that file is a Policy action AutoEnable=true I set it to true for default installs currently. This is supposed to solve the problem reported here. Of course, for those worried about security/power, setting it to 'false' is easy to do. Just note, there is no 'agent' running (though blueman provides one I believe), so be careful walking around with an active bluetooth radio enabled. All this means is there is no 'agent' running to authenticate a transaction, so everything should get rejected when trying to connect, in theory.. Cheers, Don
(In reply to Don Zickus from comment #14) What happens if there's no such entry for AutoEnable at all in the mentioned conf file? As it seems adding that entry (either with false or true as the value) allows the manual activation / deactivation of the device via the context menu entry what was the original issue as far as I understand: "fully controllable from the applet". I wonder if there's another default value than either true or false assumed if the AutoEnable entry is missed.
(In reply to Raphael Groner from comment #15) > (In reply to Don Zickus from comment #14) > > What happens if there's no such entry for AutoEnable at all in the mentioned > conf file? As it seems adding that entry (either with false or true as the > value) allows the manual activation / deactivation of the device via the > context menu entry what was the original issue as far as I understand: > "fully controllable from the applet". I wonder if there's another default > value than either true or false assumed if the AutoEnable entry is missed. Hi Raphael, AutoEnable is only useful when set to true. Otherwise it is assumed false and the device is not enabled (as is currently). :-) So setting it to false or removing the file or entry is equivalent to the same thing. Only forcing it to be true is key difference. Cheers, Don
Don, then I don't understand the duplication in bug #1348669 that talks about DBus.
Hi Raphael, Hmm, I see your point. Enabling bluetooth from a conf file or udev doesn't quite fix https://bugzilla.redhat.com/show_bug.cgi?id=1348669, so the duplicate doesn't make sense. I believe that is what you are implying, no? Cheers, Don
I agree with https://bugzilla.redhat.com/show_bug.cgi?id=1348669#c2 : Bluetooth should be switched off by default and manually enabled if needed, is it possible to get it switched off automatically after some time like mobile devices can do? That's the best solution IMHO for both border cases, power saving and security issues.
I submitted bz#1348669 originally, and closed it as a DUP because I read above that blueman did not allow enabling from blueman by design. If I misread that, I can reopen my bug. Since my bluetooth adapter is a USB dongle, I just pull it out to save power - so my problem is solved! :-) I agree it would be annoying to have to continue to use bluetoothctl to power an internal adapter on/off.
(In reply to Stuart D Gathman from comment #20) … > Since my bluetooth adapter is a USB > dongle, I just pull it out to save power - so my problem is solved! :-) I > agree it would be annoying to have to continue to use bluetoothctl to power > an internal adapter on/off. But think about all the laptops or other mobile devices around in the world, I know of some models that do not have any hardware switch to disable bluetooth.
(In reply to Don Zickus from comment #16) … > AutoEnable is only useful when set to true. Otherwise it is assumed false > and the device is not enabled (as is currently). :-) > > So setting it to false or removing the file or entry is equivalent to the > same thing. Only forcing it to be true is key difference. Indeed. AutoEnable=false or commented breaks blueman-applet and it's not possible for the user to enable bluetooth with the context menu.
(In reply to Don Zickus from comment #14) > Hi, > > I added to bluez a month or two ago a conf file from upstream, > /etc/bluetooth/main.conf. At the bottom of that file is a Policy action > > AutoEnable=true > > I set it to true for default installs currently. This is supposed to solve > the problem reported here. Of course, for those worried about > security/power, setting it to 'false' is easy to do. > > Just note, there is no 'agent' running (though blueman provides one I > believe), so be careful walking around with an active bluetooth radio > enabled. All this means is there is no 'agent' running to authenticate a > transaction, so everything should get rejected when trying to connect, in > theory.. > > Cheers, > Don Hi Don, many thanks for this main.conf addition. It does indeed resolve the power toggling issue. Apologies for the late reply, it's the first time I've been able to sit in front of the machine and attempt a clean install to check it out properly again.