Re: [PATCH] bluetoothd: add option to automatically power on the first adapter found

[Alexander Holler <holler@ahsoftware.de>]

Am 11.04.2015 um 07:07 schrieb Alexander Holler:
> Am 11.04.2015 um 06:06 schrieb Alexander Holler:
>> Am 10.04.2015 um 19:15 schrieb Alexander Holler:
>>> Am 10.04.2015 um 19:10 schrieb Marcel Holtmann:
>>
>>>> We took the power on policy out of BlueZ 5 on purpose.
>>>
>>> Nobody has to use the option which is by default off.
>>
>> Sorry, but I just have to ask that in order to keep my reputation as
>> troll:
>>
>> What's that purpose?
>>
>> Defeating usability? ;)
>
> Just to clarify my patch. Its purpose is not to reimplement a "power on
> by default" policy because I understand that it's a good idea to not
> power on bt-adapters by default.
>
> The purpose of my patch is to offer users a simple, fast and reliable
> way to power on an adapter on startup, without the need to wait until
> dbus and udev are ready and without the need for additional tools (or
> complications) like udev-rules, hciconfig or bluetootctl.


And just in case some people don't understand why I'm calling a simple 
looking udev-rule a complication, here is an incomplete list what all 
might fail when using such error-prone mechanisms:

As example I use the rule

ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"

which might work as a bad replacement for the patch I've posted.

- There is the devicename (hci0). That might change.
- There is the need for a working hciconfig-executable.
- The path to the executable might change (think at /usr/bin -> /bin)
- The call to hciconfig (like options) might change without notice
- The partition the unnecessarily needed third executable (besides 
bluetoothd and dbus) might be mounted to late (maybe through a change in 
some mount order)
- the udev-rule syntax might change
- udev might not be available at all (there are still some alternatives)
- ...

And please don't try to tell me that all of the above possiblities for 
errors are pure fiction which only might be found inside my brain. I've 
experienced almost all of them (not in regard to bluez or hciconfig) and 
most of them not just once or on systems I (mis)configured myself.


> E.g. one of my use-cases is to be able to use a bt-keyboard right after
> the system shows me a login. Without that patch waiting 4 seconds
> haven't been enough, and with the patch the keyboard is now usable
> almost immediately.
>
> And there are many other use cases where people do want that an adapter
> is turned on after it's found. E.g. I assume on most systems which don't
> have a fixed bt-adapter but rely on usb-dongles, people might prefer
> that their dongle will be automatically turned on when it's plugged in
> (otherwise they likely wouldn't plug it in). And the patch offers just a
> very simple, clean and easy to use way to reach that goal and is not a
> try to change the default policy.
>
> Regards,
>
> Alexander Holler