Unnamed pairable keyboards

[cschramm]

Hiding devices was implemented under the assumption that unnamed devices are generally not pairable and that they get hidden on other systems like Android and Windows as well, see #1258.

We seem to encounter some cases where unnamed devices are pairable:

• Goldtouch wireless keyboard not pairing/showing on search - previously worked on Linux 20.3 #1824 - Goldtouch Keyboard
• Blueman is not listing my bluetooth keyboard #1898 - Logitech K480 Keyboard
• Same issues as most of the users. with Linux mint 21 blueman cannot find any devices #1953 - Keyboard

I'm wondering if those devices show up (unnamed) on systems that we expect to hide them.

[infirit]

All the unnamed devices I have around me are hidden by my android phone and windows. To give an example for
61:E8:A8:73:D6:04 doesn't show up normally on my phone, only when I go into developer options and enable showing unnamed devices. I'm thinking to change the default for 2.4 as this clearly is confusing lot's of people.

I also don't have one of these devices. I'm willing to get one but paying over €100 for a goldtouch keyboard is too much for me.

[cschramm]

I'm willing to get one but paying over €100 for a goldtouch keyboard is too much for me.

😄 I hope we can gather some more data from affected users. The question remains how those devices (keyboards) work with other systems that hide unnamed devices. I see basically two possible answers:

• It is possible to get a name from the devices but BlueZ either does not know it or just not expose it on the API.
• Hiding on other systems depends on more properties than just the missing name.

[cschramm]

In #1824 it actually looks like the name was missing due to some system issue. It might all just be a symptom of broken drivers or something.

[infirit]

I found an open box Logitech K480 Wireless which I ordered. I'll report back when I tried it.

[infirit]

I found an open box Logitech K480 Wireless which I ordered. I'll report back when I tried it.

This is how this devices behaves. It is unnamed for a good while (minute+) and at some point BlueZ discovers the name. This also matches on my android phone. Interestingly Windows does show "keyboard" instead of nothing at all.

What is clear (to me), we should rethink how we handle discovery. 60 seconds is definitely too short for the name to show up.

[cschramm]

BlueZ needs to be scanning to discover the name?

Android only shows the device after discovering the name?

Windows shows "keyboard" immediately? Does it change the name later?

What is clear (to me), we should rethink how we handle discovery. 60 seconds is definitely too short for the name to show up.

I guess there's no real reason for blueman's discovery timeout. We just need to make sure to stop the discovery at some point if the user does not do it explicitly. It'd probably be a good idea to just bind discovery to blueman-manager's lifetime. In comparison: In bluetoothctl you start scanning and either stop it explicitly or exit bluetoothctl to stop it implicitly, so that's the same. On Android, discovery even auto-starts when you enter the Bluetooth devices view and auto-stops when you close it.

[infirit]

BlueZ needs to be scanning to discover the name?

Yes. I can delete the cached data and reproduce it quite reliably. I can post any info you like.

Android only shows the device after discovering the name?

Yes. When I have it show unnamed devices I see the change happen. Here I can also reproduce by removing the cache of the bluetooth app.

Windows shows "keyboard" immediately? Does it change the name later?

I don't remember. Now that it has discovered and paired it once it immediately shows up with name. I don't know where windows caches this.

What is clear (to me), we should rethink how we handle discovery. 60 seconds is definitely too short for the name to show up.

I guess there's no real reason for blueman's discovery timeout. We just need to make sure to stop the discovery at some point if the user does not do it explicitly. It'd probably be a good idea to just bind discovery to blueman-manager's lifetime. In comparison: In bluetoothctl you start scanning and either stop it explicitly or exit bluetoothctl to stop it implicitly, so that's the same. On Android, discovery even auto-starts when you enter the Bluetooth devices view and auto-stops when you close it.

I have been thinking about this but haven't come up with a satisfactory option yet. But for now, I do like to increase the timeout and perhaps make it configurable.

edit:
device info

info F4:73:35:0C:D6:01 
Device F4:73:35:0C:D6:01 (public)
        Name: Keyboard K480
        Alias: Keyboard K480
        Class: 0x00002540
        Icon: input-keyboard
        Paired: no
        Bonded: no
        Trusted: no
        Blocked: no
        Connected: no
        LegacyPairing: yes

[cschramm]

Dropping the timeout is absolutely reasonable, I think. It's just not dead easy for us due to blueman's design where blueman-manager is just a client to the long-lived blueman-applet which is the client to BlueZ. BlueZ stops discovery when its client disconnects but blueman-applet is meant to stay alive. The best solution is probably to have blueman-applet handle client disconnects the same way and stop discovery when all clients (should be blueman-manager and blueman-sendto processes) disconnected.

[cschramm]

Turns out I'm completely wrong. blueman-manager does use BlueZ' adapter API directly, so there's really no point for the timeout as when blueman-manager gets closed, BlueZ will automatically stop discovery. A quick experiment that drops the timeout as well as the related progress indicator (the progressbar is always pulsing now) and keeps the cancel button to stop discovery: cschramm@ee8e427

[infirit]

I was thinking about bringing back the add new device functionality. It could be a seperate application or integrated in blueman-manager. It would be made responsible for pairing, pin and trustimg new devices.

blueman-manager main window would still be able to block, trust, remove devices and connect to services. Something like the DeviceSelectorWidget but expanded.

However I first want to finish the listbox replacement for the lists.

[gt4w4al]

Hi,
I am also facing the issue. I don't know if this is 100% the same issue, or if I should create a dedicated issue, but it seems similar to the 3 items in the first post. So here is the situation for me, and I hope it would help for troubleshooting.

My keyboard is a Microsoft QSZ-00005. It is not seen in the Blueman manager, nor with the bluetoothctl command. Not seen at all, even if my computer is set to "always visible", and even if I untick the box "hide the unnamed devices". So it's even worse than other reported issues !

blueman: 2.3.4+mint1+vanessa
BlueZ: 5.64-0ubuntu1
Distribution: Mint 21.1
Desktop environment: XFCE

I can also said I tried on another PC, which is on Mint 20.3 Cinnamon (so with Blueberry package), and the connection was made straightaway, the keyboard was working properly.

Instructions in the "troubleshooting" page are not 100% clear for me, I am a newbie, starting in Linux, and english is not my own language... What can I provide you for debbuging information ?

[cschramm]

@gt4w4al: Not the same issue at all. This one is about keyboards (or devices in general, but the only confirmed cases are keyboards) that are affected by our option to hide unnamed devices but are expected to show in that state for pairing. They do show if the option is disabled and they always show in bluetoothctl which does not ever actively hide any device.

Please open a new issue. We can try to provide guidance there. In general, when you think the device is discoverable, check if you see it with a different device, e.g. your phone. If that's the case, most probably you're facing an issue with your firmware, driver or whatever. Check kernel and bluetooth.service logs in that case.

[infirit]

Just confirmed, on windows it initially shows up as Keyboard and later updates to the full name Keyboard K480

[cschramm]

Well, it knows that it's a keyboard from the device class but I don't see how it knows that it should not filter the unnamed device. 🤔 Possibly Windows just never filters out any keyboard class devices? Doing the same would fix this in general for sure.

[infirit]

Well this is interesting... I now am heavily leaning on BlueZ being silly here.

[cschramm]

Er, what?! Looking at BlueZ (dev_property_get_alias) that would mean something explicitly set that alias (otherwise it would show the non-empty name property) and it's not BlueZ, it must have been some client.

[infirit]

That may have been a fluke as I can not reproduce it now, so silly me 🤣

How about we do something like #1994 and never filter keyboards, pointers and combos?

[cschramm]

#2034 is another case with a Targus KB55 AKB55TT

[infirit]

Oh, right let me finish the PR and hopefully not have this happen any more.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cschramm]

The handling should be solved with #1994 merged.