Replies: 16 comments 20 replies
-
Trust means that the bluetooth device is allowed to connect automatically,
Normally no, once paired or trusted that state should persist.
Devices that have been paired/trusted/connected to once should persist.
Searching for devices is an expensive operation which causes lots of radio traffic. It is not something you want to keep on.
Switching between linux and macos is likely the cause of the devices to disappearing. If you repair after switching a new pairing key is generated and stored. When you go back to the other and repair again you will get a new pair key again. There is a way to workaround this but it is somewhat involved and differs between devices (eg LE), see following link for windows. https://unix.stackexchange.com/questions/255509/bluetooth-pairing-on-dual-boot-of-windows-linux-mint-ubuntu-stop-having-to-p I don't use macos so I wouldn't know how to get the pairing keys on it. |
Beta Was this translation helpful? Give feedback.
-
|
Closing after a week of no activity. If you have further questions feel free to add them and we'll respond to them. |
Beta Was this translation helpful? Give feedback.
-
Any idea how to get it to stop spamming offers to connect despite being untrusted? This is the top thread when googling about blueman trust / untrust, so figured it would be efficiently found / asked here. |
Beta Was this translation helpful? Give feedback.
-
The device is trying to connect to your Bluetooth adapter. The device being untrusted doesn't prevent this from happening. You can block it which makes the adapter ignore it completely. If you need further assistance open a new issue or discussion and explain your specific situation. |
Beta Was this translation helpful? Give feedback.
-
|
Just stumbled upon this page by accident. It is still difficult to find good information about this topic on the web. A google search for "bluez blocked trusted" actually came up with this page as best hit, and it was. Thanks! It would be really nice to have this information directly in the FAQ. I believe that having a device paired, but not wanting it to autoconnect, is a frequent situation. For example on my BT hearing aids the battery drains about twice as fast than usual if a BT connection is active; thus I don't want them to autoconnect. |
Beta Was this translation helpful? Give feedback.
-
|
@mwilck: I'm not sure if I get your intentions. You mean the fact that blocking a device - well - blocks it from connecting? You mean https://github.com/blueman-project/blueman/blob/main/FAQ? That's completely focused on blueman, not BlueZ / Linux Bluetooth in general and I doubt that it's frequently used. |
Beta Was this translation helpful? Give feedback.
-
|
I find @mwilck's intention pretty clear: he wants to make this information more easily discoverable by making it more prominent in the documentation. He has made no statements about blocking whatsoever — where did that impression come from? We already know from previous comments that trust is what prevents devices from autoconnecting, which was his concern.
Well, this is the blueman repo, so isn't his request in the exactly right scope?
If it therefore warrants no official documentation, then why is Trust this Device a prominent and exposed action in the toolbar, clearly intended for manual use? |
Beta Was this translation helpful? Give feedback.
-
|
PS. Personally I don't see why the feature isn't simply called "Allow Autoconnect" with the subtitle "Automatically accept incoming connections from this device" instead of requiring instructions at all. |
Beta Was this translation helpful? Give feedback.
-
|
My intention was to say that I was glad to find this information here, but I would have preferred if it was more "easily discoverable", as @anohren correctly guessed. And yes, it's a bluez thing and not a blueman thing, but I didn't couldn't find documentation about it for bluez, either. This page was the best source of information I could find. @cschramm, my comment wasn't meant as issue report or criticism wrt blueman, but I wouldn't mind if this information was added to the FAQ. @anohren, bluez / bluetoothctl also uses the terms "trust" and "block", thus I am not sure if changing this to "allow autoconnect" in blueman would be wise. While more expressive, it would again cause confusion about how it is related to the low-level terms in bluez. For me as a bluetooth noob, it wasn't even clear if I could still actively connect to a device after setting it "untrusted" or "blocked". The semantics are still kind of shady to me. Is there a difference between a device that's only "blocked" and a device that's both "blocked" and "untrusted"? FWIW, I had to use "block" with my headset because otherwise I'd get spammed with connection requests. |
Beta Was this translation helpful? Give feedback.
-
|
The FAQ file is focused on blueman and I doubt that the FAQ file is frequently used. Trusted and blocked devices are concepts of BlueZ, i.e. the Linux Bluetooth stack, in general. I agree that there does not seem to be any official user documentation. I think the best you can get is https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/org.bluez.Device.rst#n215 which is actually an API documentation and does not describe what One might argue that it's the frontend's job to document generic concepts for the user. blueman does not have any comprehensive user documentation, though. That's totally up to distributors right now. Some wikis do a decent job, like Arch Linux's, Gentoo Linux's or Debian's. Actually, Debian's seems to be the only source that even vaguely describes what trusted means. I'm open to starting a user guide e.g. in the GitHub wiki here, that should definitely describe such things and not leave the user alone with just "blueman is a frontend to BlueZ - period", but I'm personally not motivated to start one. It's kind of annoying that our GitHub issues feel like a generic Linux Bluetooth helpdesk lately, mainly for a group of users of what I'd paraphrase as "Linux Mint and weird things like ParrotOS" (no offense!). Our history of GitHub issues is actually a pile of Bluetooth issue knowledge that I regularly consult to help in newly opened, not blueman related issues. 😆 You guys are very welcome to start it. I guess it might even feel easy to extend once a certain base is laid. |
Beta Was this translation helpful? Give feedback.
-
Oh, I see.
I can understand that completely. At the same time, that's exactly what can be expected when leaving these things to chance: if blueman is truly just some visual education tool to introduce and ease users into the use of BlueZ / bluetoothctl — which @mwilck's argument for not making GUI terminology better and easier than CLI makes it sound like — then I'm left asking myself "Why bother with a GUI at all at that point?" Surely the ambitions of a GUI is to be more obvious than the corresponding CLI, whose non-obvious terminology is the problem that's the premise for the discussion. My point is that the whole "generic Linux Bluetooth helpdesk" problem is a design issue and as such can be designed away; if blueman is at the frontline of user interaction then naturally it'll get lots of interaction in the issues section as well. Apparently Bluetooth is a domain that needs user education, which can be done either directly through user interface design — including terminology — or in GitHub issues. Personally I don't want to know much about Bluetooth while using it, so looking up a faq or wiki is a last resort. Maybe the effort of writing documentation can be better placed elsewhere (like in finding alternative terminology). As an example, I'd be happy with "trust" completely abstracted away; it is in macOS and it works just fine. If I really need it then I can reach for either an Advanced menu, or a more advanced CLI tool. I imagine that that alone would get rid of most questions about trust. I'm probably just repeating things everyone already knows at this point 🤓🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
@cschramm, thanks. You've already done a lot to make bluetooth more accessible on Linux. Nobody is asking you to spend additional efforts on documentation. I understand that questions like this popping up here is annoying for you. It's a shame that bluez itself hasn't been able to provide useful documentation. The idea of collecting information here in the wiki is good, but I wouldn't expect a lot of community contributions. I would like to contribute but I am afraid I can't. While I'm a professional Linux developer working for a Linux distro, my knowledge about bluetooth is minimal. I think this applies to many experienced Linux people. I have put "learn bluetooth" on my personal agenda multiple times, but the complexity of the stack is just too discouraging. |
Beta Was this translation helpful? Give feedback.
-
I was about tot write something similar, if someone wants to start a user manual that would be awesome. Personally have little time right now. |
Beta Was this translation helpful? Give feedback.
-
MacOS is generally better in the "just works" area than Linux, so I am told. But they have dedicated engineers working on functionality, UI, and documentation, and manufacturers work hard to make their devices MacOS-compliant. All that can't be said about Linux/bluez, unfortunately.
That's my point: Once you start using the "advanced" tool, you need to understand how the settings in the simple tool you'd been using before map to the advanced ones. Using consistent terminology (or at least explaining the mapping between different terms) is extremely important to avoid confusion. Note that blueman is already the "advanced tool". For dummies we have GNOME bluetooth. It's interface is GNOME-ish simple and hides all the complexity away — and leaves the user clueless if something doesn't work. Which, unfortunately, happens quite often. If we had the Wiki we're talking about, I'd be perfectly fine if the setting in blueman was called "autoconnect", as long as the Wiki was there to explain how "autoconnect" settings translate to combinations of "trusted" and "blocked". Side question: Is there a difference between "blocked + untrusted" and just "blocked"? If not, I guess "autoconnect" would allow 3 different settings: "yes", "yes with confirmation", and "no", corresponding to "trusted/unblocked", "untrusted/unblocked", and "blocked". Right? |
Beta Was this translation helpful? Give feedback.
-
|
The blueman UI is 100x better than that of gnome bluetooth. I mean it. |
Beta Was this translation helpful? Give feedback.
-
The protocol does not really allow that. We could implement it with dirty tricks, i.e. give those options on the first request (no matter if it's for pairing or a service), then yes => confirm any requests within a certain period / no => decline / always => confirm and mark the device trusted / never => not sure; block? 🤷
It explicitly does not time out, but Gnome (or at least Cinnamon) shows it for the configurable period of 4 seconds, then puts it in the pile. As far as I know, any other notification daemon acts reasonable. |
Beta Was this translation helpful? Give feedback.
-
|
I can see that doing this right for different desktops is close to impossible. From my dumb end user perspective, I wouldn't show the connect/disconnect notifications at all. Or better maybe, if a connect was seen, I would wait a short amount of time whether it's followed by an authorization request, and if yes, I would only show the latter notification. Then if the auth request was declined, I'd suppress the disconnect notification as well. Just wishful thinking, no idea if that would be feasible. |
Beta Was this translation helpful? Give feedback.
-
|
Iirc, Notifications are not even guaranteed to show up under Gnome as notification can be disabled per application or globally. Not sure if the same applies to Cinnamon. |
Beta Was this translation helpful? Give feedback.
-
As I said, it does respect
Yes, at least globally: |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
That change things. I was not aware of that. I've mainly come in contact with blueman in Ubuntu/Debian Mate, and there it has always looked like the main graphical interface. I've gotten the wrong impression.
Well, you said it. If it's just a matter of adding one sentence to a FAQ/wiki, does it still need to be raised as an objection to revising the term? Anyway, all of this would only apply if the GUI did not have as its goal to mimic the CLI, but as an advanced tool I get the impression that it does (implicitly). That's fine — I was just given a different impression from the desktop environments that (mis)use it. Considering the allegedly over-engineered nature of Bluetooth, I don't have any particular expectations on advanced tools for it. When Android Bluetooth engineers make it sound like quite an accomplishment to be able to save volume levels for individual Bluetooth devices in 2018, you know it's bad 😅 Best not to get too close. |
Beta Was this translation helpful? Give feedback.
-
blueman: 2.0.5
BlueZ: don't know
Distribution: Ubuntu Mate 18.04 32-bit
Desktop environment: mate
Hello, I was having a little trouble using the manager so I thought I'd ask some basic questions that perhaps are obvious to most users:
I don't doubt that my mental model of bluetooth is lacking, but I'm just used from e.g. Macos to paired devices being remembered indefinitely until I remove them. I use the device interchangeably between Ubuntu and Macos, but Macos seems to have no trouble remembering the device despite this. Am I confusing different concepts?
Beta Was this translation helpful? Give feedback.
All reactions