1 |
On Tuesday 28 Mar 2017 11:19:33 Foster McLane wrote: |
2 |
> On Tue, Mar 28, 2017 at 07:59:02AM -0700, Mick wrote: |
3 |
> > Mar 28 15:50:20 dell_xps bluetoothd[10619]: Unknown key AutoEnable in |
4 |
> > main.conf |
5 |
> |
6 |
> Did you use the 'AutoEnable' option in the '[Policy]' section of |
7 |
> main.conf? |
8 |
|
9 |
Yes. :-( |
10 |
|
11 |
=========================== |
12 |
#[Policy] |
13 |
# |
14 |
# The ReconnectUUIDs defines the set of remote services that should try |
15 |
# to be reconnected to in case of a link loss (link supervision |
16 |
# timeout). The policy plugin should contain a sane set of values by |
17 |
# default, but this list can be overridden here. By setting the list to |
18 |
# empty the reconnection feature gets disabled. |
19 |
#ReconnectUUIDs=00001112-0000-1000-8000-00805f9b34fb,0000111f-0000-1000-8000-00805f9b34fb,0000110a-0000-1000-8000-00805f9b34fb |
20 |
|
21 |
# ReconnectAttempts define the number of attempts to reconnect after a link |
22 |
# lost. Setting the value to 0 disables reconnecting feature. |
23 |
#ReconnectAttempts=7 |
24 |
|
25 |
# ReconnectIntervals define the set of intervals in seconds to use in between |
26 |
# attempts. |
27 |
# If the number of attempts defined in ReconnectAttempts is bigger than the |
28 |
# set of intervals the last interval is repeated until the last attempt. |
29 |
#ReconnectIntervals=1,2,4,8,16,32,64 |
30 |
|
31 |
# AutoEnable defines option to enable all controllers when they are found. |
32 |
# This includes adapters present on start as well as adapters that are plugged |
33 |
# in later on. Defaults to 'false'. |
34 |
AutoEnable = true |
35 |
=========================== |
36 |
|
37 |
> > So, what's the solution if hciconfig et al are not installed with future |
38 |
> > versions of bluez and the AutoEnable option does not seem to take? |
39 |
> |
40 |
> I'm pretty sure the future solution is to use bluetoothctl as a console |
41 |
> user interface or find a more scriptable alternative (I don't know of |
42 |
> any) that also use the DBus interface. |
43 |
> |
44 |
> I just hit this problem with the upgrade as I was using scripts to manage |
45 |
> turning bluetooth on and off and I was able to get by with just the |
46 |
> AutoEnable option. I did not find much else in my cursory research as to |
47 |
> a replacement for hciconfig. The following is from the release notes for |
48 |
> |
49 |
> BlueZ 5.35: |
50 |
> > A noteworthy new feature is the ability to configure bluetoothd to |
51 |
> > automatically enable (power on) all new adapters. One use of this is to |
52 |
> > replace unreliable "hciconfig hci0 up" commands that some distributions |
53 |
> > use in their init/udev scripts. The feature can be enabled by having |
54 |
> > AutoEnable=true under the [Policy] section of /etc/bluetooth/main.conf. |
55 |
> |
56 |
> Foster |
57 |
|
58 |
Yes, but the same AutoEnable option is present in main.conf of 5.43-r1 which I |
59 |
am running at present. Perhaps it only becomes effective in a later version, |
60 |
but then why would it be added as an option in the current stable version? |
61 |
|
62 |
Meanwhile, I did some additional experimentation. If I run bluetoothctl after |
63 |
'/etc/init.d/bluetooth start' and then set: |
64 |
|
65 |
power on |
66 |
agent on |
67 |
scan on, and |
68 |
quit |
69 |
|
70 |
the adapter is now up and I can connect with bluetooth as if I had run |
71 |
hciconfig up. If I run neither bluetoothctl, nor hciconfig the adapter stays |
72 |
disabled. Of course, hciconfig is just an one liner (run as root) so it is |
73 |
more convenient than running bluetooth control each time. |
74 |
|
75 |
-- |
76 |
Regards, |
77 |
Mick |