I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
Thanks, Jon
On Fri, 2016-07-08 at 00:43 -0400, Jon LaBadie wrote:
I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
Thanks, Jon
I have a Broadcom BT dongle with roughly the same issues. Years ago I created a /etc/rc.d/rc.local file containing:
hciconfig hci0 up
For recent Fedoras note that you now have to explicitly enable rc.local for it to run:
systemctl enable rc-local
I also find the dongle sometimes doesn't power on after returning from hibernation. Haven't found a fix for that other than keeping an extra mouse so I can enable it manually.
poc
On Fri, Jul 8, 2016 at 5:43 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Fri, 2016-07-08 at 00:43 -0400, Jon LaBadie wrote:
I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
Thanks, Jon
I have a Broadcom BT dongle with roughly the same issues. Years ago I created a /etc/rc.d/rc.local file containing:
hciconfig hci0 up
For recent Fedoras note that you now have to explicitly enable rc.local for it to run:
systemctl enable rc-local
I also find the dongle sometimes doesn't power on after returning from hibernation. Haven't found a fix for that other than keeping an extra mouse so I can enable it manually.
If is any consolation, my new iMac also requires that I keep a USB mouse handy for the same reason. Curiously, the wireless keyboard is generally (but not always) recognized, but sometimes I have to borrow a USB keyboard to log in.
poc
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Fri, Jul 08, 2016 at 09:43:35AM +0100, Patrick O'Callaghan wrote:
On Fri, 2016-07-08 at 00:43 -0400, Jon LaBadie wrote:
I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
Thanks, Jon
I have a Broadcom BT dongle with roughly the same issues. Years ago I created a /etc/rc.d/rc.local file containing:
hciconfig hci0 up
For recent Fedoras note that you now have to explicitly enable rc.local for it to run:
systemctl enable rc-local
I also find the dongle sometimes doesn't power on after returning from hibernation. Haven't found a fix for that other than keeping an extra mouse so I can enable it manually.
Thanks for the suggestion Patrick, I'll try it this evening.
Jon
On Fri, Jul 08, 2016 at 09:53:43AM -0300, George N. White III wrote:
On Fri, Jul 8, 2016 at 5:43 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Fri, 2016-07-08 at 00:43 -0400, Jon LaBadie wrote:
I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
Thanks, Jon
I have a Broadcom BT dongle with roughly the same issues. Years ago I created a /etc/rc.d/rc.local file containing:
hciconfig hci0 up
For recent Fedoras note that you now have to explicitly enable rc.local for it to run:
systemctl enable rc-local
I also find the dongle sometimes doesn't power on after returning from hibernation. Haven't found a fix for that other than keeping an extra mouse so I can enable it manually.
If is any consolation, my new iMac also requires that I keep a USB mouse handy for the same reason. Curiously, the wireless keyboard is generally (but not always) recognized, but sometimes I have to borrow a USB keyboard to log in.
Yeah, my other laptop was so bad I got a Logitech mouse with their miniscule "unifying receiver" dongle. But the Vostro has been fine over about an 7-10 yr period. The problem only arose after installing F24 over F17.
Jon
On Fri, 2016-07-08 at 09:53 -0300, George N. White III wrote:
I also find the dongle sometimes doesn't power on after returning
from
hibernation. Haven't found a fix for that other than keeping an
extra
mouse so I can enable it manually.
If is any consolation, my new iMac also requires that I keep a USB mouse handy for the same reason. Curiously, the wireless keyboard is generally (but not always) recognized, but sometimes I have to borrow a USB keyboard to log in.
The spare mouse I keep is in fact part of a cheap Microsoft wireless kb/mouse combo that also works via a dongle, and which has literally never failed to start. I think the difference is that the dongle emulates a USB mouse and kb directly, but there's essentially no documentation for it so that's a guess.
(Before you ask: I prefer the feel of my BT mouse, especially for scrolling, which is why I don't use the MS one except when forced to).
poc
On Fri, Jul 08, 2016 at 05:02:57PM +0100, Patrick O'Callaghan wrote:
On Fri, 2016-07-08 at 09:53 -0300, George N. White III wrote:
I also find the dongle sometimes doesn't power on after returning
from
hibernation. Haven't found a fix for that other than keeping an
extra
mouse so I can enable it manually.
If is any consolation, my new iMac also requires that I keep a USB mouse handy for the same reason. Curiously, the wireless keyboard is generally (but not always) recognized, but sometimes I have to borrow a USB keyboard to log in.
The spare mouse I keep is in fact part of a cheap Microsoft wireless kb/mouse combo that also works via a dongle, and which has literally never failed to start. I think the difference is that the dongle emulates a USB mouse and kb directly, but there's essentially no documentation for it so that's a guess.
(Before you ask: I prefer the feel of my BT mouse, especially for scrolling, which is why I don't use the MS one except when forced to).
Agreed, their scrollwheel sucks. Plus they never seem to have left and right tilt. I use that to flip between workspaces.
BTW the Broadcom BT adapter in my laptop seems to present as a USB device:
$ lsusb ... Bus 004 Device 001: ID 1d6b:0001 Linux Foundation Bus 003 Device 009: ID 0a5c:4503 Broadcom Corp. Mouse (Boot Interface Subclass) Bus 003 Device 008: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass) Bus 003 Device 007: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth Bus 003 Device 006: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation
Jon
On 07/07/2016 09:43 PM, Jon LaBadie wrote:
I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
There seems to be a bug in recent releases of the bluetooth manager that doesn't seem to talk to dbus properly or has a problem with the python stuff.
What I did is exit the bluetooth manager applet (right click, then "Exit"), then run the "blueman-adapters" utility from the command line.
It's a right pain in the arse. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Have you noticed that "human readable" configuration file - - directives are beginning to resemble COBOL code? - ----------------------------------------------------------------------
On Fri, 2016-07-08 at 16:31 -0400, Jon LaBadie wrote:
BTW the Broadcom BT adapter in my laptop seems to present as a USB device:
$ lsusb ... Bus 004 Device 001: ID 1d6b:0001 Linux Foundation Bus 003 Device 009: ID 0a5c:4503 Broadcom Corp. Mouse (Boot Interface Subclass) Bus 003 Device 008: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass) Bus 003 Device 007: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth Bus 003 Device 006: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation
Yes, the Broadcom is a USB device because it's plugged into a USB port, but still needs BT drivers for whatever is connected to it (e.g. mouse, BT speaker, my phone etc.). The MS dongle also shows as a BT device:
$ sudo lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation Bus 001 Device 005: ID 0a5c:2111 Broadcom Corp. ANYCOM Blue USB-UHE 200/250 Bus 001 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 001 Device 003: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation Bus 004 Device 001: ID 1d6b:0003 Linux Foundation Bus 003 Device 003: ID 058f:3861 Alcor Micro Corp. Bus 003 Device 002: ID 05e3:0745 Genesys Logic, Inc. Logilink CR0012 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation
but in contrast to the Broadcom the MS mouse and kb do not show up as BT devices and don't appear to need any drivers (beyond what's in the kernel anyway). IOW the dongle is doing some sleight of hand because it only works specifically with those devices and AFAIK cannot be used for general BT communication. However this is speculation.
poc
On Fri, Jul 08, 2016 at 10:50:15PM +0100, Patrick O'Callaghan wrote:
On Fri, 2016-07-08 at 16:31 -0400, Jon LaBadie wrote:
BTW the Broadcom BT adapter in my laptop seems to present as a USB device:
$ lsusb ... Bus 004 Device 001: ID 1d6b:0001 Linux Foundation Bus 003 Device 009: ID 0a5c:4503 Broadcom Corp. Mouse (Boot Interface Subclass) Bus 003 Device 008: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass) Bus 003 Device 007: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth Bus 003 Device 006: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation
Yes, the Broadcom is a USB device because it's plugged into a USB port, but still needs BT drivers for whatever is connected to it (e.g. mouse, BT speaker, my phone etc.). The MS dongle also shows as a BT device:
Sorry, what I meant to point out (poorly), was my BT is an internal adapter, not a dongle. Of course it could be connected to an internal USB port.
Jon
On Sat, 2016-07-09 at 00:11 -0400, Jon LaBadie wrote:
On Fri, Jul 08, 2016 at 10:50:15PM +0100, Patrick O'Callaghan wrote:
On Fri, 2016-07-08 at 16:31 -0400, Jon LaBadie wrote:
BTW the Broadcom BT adapter in my laptop seems to present as a USB device:
$ lsusb ... Bus 004 Device 001: ID 1d6b:0001 Linux Foundation Bus 003 Device 009: ID 0a5c:4503 Broadcom Corp. Mouse (Boot Interface Subclass) Bus 003 Device 008: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass) Bus 003 Device 007: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth Bus 003 Device 006: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation
Yes, the Broadcom is a USB device because it's plugged into a USB port, but still needs BT drivers for whatever is connected to it (e.g. mouse, BT speaker, my phone etc.). The MS dongle also shows as a BT device:
Sorry, what I meant to point out (poorly), was my BT is an internal adapter, not a dongle. Of course it could be connected to an internal USB port.
OK. I have an internal BT adapter on my laptop, which is where I originally used the /etc/rc.local hack.
poc
On Fri, Jul 08, 2016 at 12:43:07AM -0400, Jon LaBadie wrote:
I have an old Dell Vostro 1500 laptop. It was running Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't get the mouse to reconnect after a boot. Systemctl reports bluetoothd 'Failed to obtain handles for "Serviced Changed" characteristic'. Both blueman-manager and blueman-applet report the adapter is off and are unable to turn it on.
I can go into bluetoothctl, power on the adapter and connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot and the mouse auto-reconnected as it nicely did 7 Fedora releases ago.
Thanks, Jon
In another thread ("fedora 23 bluetooth connection") the "Trusted" setting for a BT device was mentioned.
Previously I had tried to set my mouse as a trusted device using the GUI configuration tool "blueman-manager". When I clicked on the "trust" icon or on the "trust" menu icon, nothing seemed to happen but no error messages came up either.
I revisited the problem and repeated the above observation. Then I tried the "bluetoothctl" command, finding "trust" and "untrust" commands were available. I ran the "trust [dev]" command, it reported "trust successfully applied to [dev]". And over in the blueman-manager, a trust icon appeared on the mouse entry.
Even better news, when I reboot, if the mouse is on it is connected and active. If the mouse is not on, turning it on automaticall connects it and it is active.
Sounds like there is a problem with blueman-manager!
Jon
On Fri, Jul 29, 2016 at 03:18:52PM +0100, Patrick O'Callaghan wrote:
On Wed, 2016-07-27 at 18:47 -0400, Jon LaBadie wrote:
Sounds like there is a problem with blueman-manager!
I assume you've reported this to Bugzilla. If so, best quote the BZ report number here so others can chip in.
poc
Bug 1361761
-
George N. White III -
Jon LaBadie -
Patrick O'Callaghan -
Rick Stevens