Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#66133 - [bluez] "input-hog profile accept failed" from bluettothd prevents BLE device use.

Attached to Project: Arch Linux
Opened by Lutz Vieweg (lvml) - Sunday, 05 April 2020, 15:02 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 10 September 2020, 14:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No



After upgrading from bluez-5.53-1-x86_64 to bluez-5.54-1-x86_64.pkg my "Bluetooth Low Energy" mouse (Model: Rapoo M500) is not usable as an input device anymore. When the mouse is switched on, the following message is emitted to the system journal:

Apr 05 00:41:32 hostname bluetoothd[655]: input-hog profile accept failed for ED:8E:0E:XX:XX:XX

(last three bytes replaced by XX by me)

pacman -U /var/cache/pacman/pkg/bluez-5.53-1-x86_64.pkg.tar.zst \
/var/cache/pacman/pkg/bluez-libs-5.53-1-x86_64.pkg.tar.zst \
systemctl restart bluetooth
the mouse immediately works again, and vice versa.

I assume this to be a consequence of this commit:
since this Rapoo Mouse is not "paired" and cannot be "paired" in BLE Mode.

But from what I read, it seems that the options "ClassicBondedOnly" and "LEAutoSecurity" in
were meant to deal with compatibility to non-pairable BLE devices.

Thus I tried both options, with either "false" or "true" settings, but alas, that makes no difference, the symptom stays the same.
And while the system journal does indicate that bluez-5.54-1-x86_64.pkg has found the "ClassicBondedOnly" option in input.conf -

Apr 05 00:28:07 hostname bluetoothd[20516]: profiles/input/manager.c:input_init() input.conf: ClassicBondedOnly=false

- there is no indication that the "LEAutoSecurity" option was recognized, as if the code of bluez-5.54-1-x86_64.pkg did not know about it.

Additional info:
* package version(s)

bluez-5.54-1-x86_64.pkg - worked fine with previous versions

Steps to reproduce:

Just enabling the mouse shows the symptom.

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Thursday, 10 September 2020, 14:38 GMT
Reason for closing:  Fixed
Comment by Andreas Radke (AndyRTR) - Sunday, 05 April 2020, 16:01 GMT
Please check for upstream bug reports and maybe ask at some IRC channel:
Comment by Lutz Vieweg (lvml) - Monday, 13 April 2020, 21:40 GMT
There would not be a reason to check for an upstream bug report, because the current git head at works just fine - I compiled it and tested it. It is only the bluez-5.54-1-x86_64.pkg contained version of bluetoothd that causes the symptom.

The git head version works fine for my mouse with the compiled-in default values of options "ClassicBondedOnly" and "LEAutoSecurity", it also works fine if I use

ClassicBondedOnly = true
LEAutoSecurity = true

in /etc/bluetooth/input.conf - only if I use ClassicBondedOnly = true and LEAutoSecurity = false with the current git-head version, then my mouse also causes the above mentioned "input-hog profile accept failed for ..." errors.
Comment by Andreas Radke (AndyRTR) - Wednesday, 15 April 2020, 05:49 GMT
Please try if adding this single commit on top of 5.54 also fixes the issue. I can't find any other related commit in master after the release.
Comment by Lutz Vieweg (lvml) - Wednesday, 15 April 2020, 09:12 GMT
"this single commit" meaning which one?
Comment by Lutz Vieweg (lvml) - Wednesday, 15 April 2020, 09:28 GMT
zstd -d -c /tmp/bluez-5.54-1-x86_64.pkg.tar.zst | tar xOf - "usr/lib/bluetooth/bluetoothd" | strings -a | grep LEAutoSecurity
displays no match.

zstd -d -c /tmp/bluez-5.54-1-x86_64.pkg.tar.zst | tar xOf - "usr/lib/bluetooth/bluetoothd" | strings -a | grep ClassicBondedOnly
does display a match - and that tells me commit
contributing among others code line
is not part of bluez-5.54-1-x86_64.pkg.tar.zst - which explains why the option is not supported by bluez-5.54-1-x86_64.pkg.tar.zst.
Comment by Andreas Radke (AndyRTR) - Wednesday, 15 April 2020, 09:33 GMT
Sorry, I wanted to that commit you to try:
Maybe your additional commit is required.

But it's probably better to wait for another release and not worth picking random commits.
Comment by Lutz Vieweg (lvml) - Saturday, 09 May 2020, 22:49 GMT
The Arch package update from bluez 5.54-1 to bluez 5.54-2 at 2020-04-25 did not fix this issue.

bluez-5.54-2-x86_64.pkg.tar.zst also does still not contain the LEAutoSecurity input.conf option.

The current git master branch head from upstream still works fine.
Comment by Andreas Radke (AndyRTR) - Monday, 11 May 2020, 05:20 GMT
Still waiting for a new upstream release or a more hints of required backports. I guess you should keep running your custom git master branch for now.
Comment by Andrey Teplitskiy (teplik) - Sunday, 31 May 2020, 19:01 GMT
This is a bug from bluez 5.54: when I compile bluez from master or 5.53 tag, my keyboard works.
When i build it from 5.54 tag, i also have this error message and my keyboard paired, but not usable as input device.
Comment by Espen Hammer Kjellstadli (neeps) - Friday, 14 August 2020, 07:58 GMT
Same error message given for Microsoft Surface Keyboard (bluetooth).
Tried reverting to 5.53, this solved the issue for me. Currently ignoring 5.54 for now.
Comment by Sebastian (Deathcrow) - Friday, 04 September 2020, 20:34 GMT
Unbelievable that this bug is still a thing and upstream hasn't released a functioning version yet. Took me hours to chase this down to the root cause of bluez (I assumed it was some kind of kernel issue).

Downgrading to 5.53 makes the Logitech "Keyboard K600 TV" functional via bluetooth. Trying anything with 5.54 is a waste of time.
Comment by Lutz Vieweg (lvml) - Sunday, 06 September 2020, 20:12 GMT
Version 5.55 has been released (upstream), and that version definitely does include the option "LEAutoSecurity":
Comment by Andreas Radke (AndyRTR) - Monday, 07 September 2020, 19:42 GMT
Please try new release 5.55-1 from testing repo.