+++ This bug was initially created as a clone of Bug #1337353 +++ Description of problem: Everytime I boot, the bluetooth mouse isn't working. I have to login, use a trackpad for navigation (lucky I have a trackpad, what if this were a desktop system?), get to Bluetooth settings a manually connect. This is not a regression, the same problem happens in Fedora 23. Version-Release number of selected component (if applicable): gnome-bluetooth-3.18.3-1.fc24.x86_64 gdm-3.20.1-1.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot 2. 3. Actual results: Bluetooth mouse doesn't work at the login window. Expected results: It's already been paired with, it's turned on, so it should just work already at the login window. Additional info: See --- Additional comment from Chris Murphy on 2016-05-18 19:43 EDT --- Shows that bluetooth is not in use and how I have to manually connect to an already paired device. This connection should just happen automatically instead of being a manual thing. --- Additional comment from Chris Murphy on 2016-05-18 19:48 EDT --- [ 2.799626] f23m.localdomain kernel: usb 1-1.1.3: Product: Bluetooth USB Host Controller [ 4.380409] f23m.localdomain kernel: Bluetooth: Core ver 2.21 [ 4.381005] f23m.localdomain kernel: Bluetooth: HCI device and connection manager initialized [ 4.381009] f23m.localdomain kernel: Bluetooth: HCI socket layer initialized [ 4.381012] f23m.localdomain kernel: Bluetooth: L2CAP socket layer initialized [ 4.381021] f23m.localdomain kernel: Bluetooth: SCO socket layer initialized [ 4.429110] f23m.localdomain kernel: Bluetooth: hci0: BCM: chip id 19 build 0847 [ 4.430763] f23m.localdomain kernel: Bluetooth: hci0: BCM: product 05ac:821a [ 4.433410] f23m.localdomain kernel: uvcvideo: Found UVC 1.00 device FaceTime HD Camera (Built-in) (05ac:8509) [ 4.415467] f23m.localdomain systemd[1]: Activating swap Swap Partition... [ 4.447770] f23m.localdomain kernel: Bluetooth: hci0: ChromeLinux_4C6D [ 4.898101] f23m.localdomain systemd[1]: Starting Bluetooth service... [ 4.909284] f23m.localdomain bluetoothd[775]: Bluetooth daemon 5.39 [ 4.932825] f23m.localdomain bluetoothd[775]: Starting SDP server [ 4.934586] f23m.localdomain systemd[1]: Started Bluetooth service. [ 4.935109] f23m.localdomain systemd[1]: Reached target Bluetooth. [ 4.961655] f23m.localdomain kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 4.961659] f23m.localdomain kernel: Bluetooth: BNEP filters: protocol multicast [ 4.961663] f23m.localdomain kernel: Bluetooth: BNEP socket layer initialized [ 4.951412] f23m.localdomain bluetoothd[775]: Bluetooth management interface 1.12 initialized [ 4.951562] f23m.localdomain bluetoothd[775]: Failed to obtain handles for "Service Changed" characteristic [ 51.143096] f23m.localdomain bluetoothd[775]: Endpoint registered: sender=:1.52 path=/MediaEndpoint/A2DPSource [ 51.143388] f23m.localdomain bluetoothd[775]: Endpoint registered: sender=:1.52 path=/MediaEndpoint/A2DPSink [ 51.232713] f23m.localdomain kernel: Bluetooth: RFCOMM TTY layer initialized [ 51.232721] f23m.localdomain kernel: Bluetooth: RFCOMM socket layer initialized [ 51.232778] f23m.localdomain kernel: Bluetooth: RFCOMM ver 1.11 And then what follows is once I'm manually connecting to this mouse. 83.409552] f23m.localdomain kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2 [ 83.409560] f23m.localdomain kernel: Bluetooth: HIDP socket layer initialized [ 83.329390] f23m.localdomain bluetoothd[775]: Can't get HIDP connection info [ 94.423105] f23m.localdomain kernel: magicmouse 0005:05AC:030D.0008: unknown main item tag 0x0 [ 94.423291] f23m.localdomain kernel: input: mouses as /devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0008/input/input17 [ 94.425159] f23m.localdomain kernel: magicmouse 0005:05AC:030D.0008: input,hidraw3: BLUETOOTH HID v3.06 Mouse [mouses] on e0:f8:47:39:5d:df [ 94.353989] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) config/udev: Adding input device mouses (/dev/input/mouse0) [ 94.354181] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) No input driver specified, ignoring this device. [ 94.354306] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) This device may have been added with another device file. [ 94.377919] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) config/udev: Adding input device mouses (/dev/input/event7) [ 94.378108] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) mouses: Applying InputClass "evdev pointer catchall" [ 94.378221] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) mouses: Applying InputClass "libinput pointer catchall" [ 94.378911] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) systemd-logind: got fd for /dev/input/event7 13:71 fd 33 paused 0 [ 94.379146] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) Using input driver 'libinput' for 'mouses' [ 94.379335] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) mouses: always reports core events [ 94.379535] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) Option "Device" "/dev/input/event7" [ 94.379735] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) Option "_source" "server/udev" [ 94.379987] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) input device 'mouses', /dev/input/event7 is tagged by udev as: Mouse [ 94.380210] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) input device 'mouses', /dev/input/event7 is a pointer caps [ 94.380403] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0008/input/input17/event7" [ 94.380591] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) XINPUT: Adding extended input device "mouses" (type: MOUSE, id 15) [ 94.380803] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) Option "AccelerationScheme" "none" [ 94.380994] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) mouses: (accel) selected scheme none/0 [ 94.381192] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) mouses: (accel) acceleration factor: 2.000 [ 94.381391] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (**) mouses: (accel) acceleration threshold: 4 [ 94.381606] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) input device 'mouses', /dev/input/event7 is tagged by udev as: Mouse [ 94.381803] f23m.localdomain /usr/libexec/gdm-x-session[1492]: (II) input device 'mouses', /dev/input/event7 is a pointer caps [ 102.325617] f23m.localdomain dbus-daemon[1522]: Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service' [ 102.325950] f23m.localdomain dbus-daemon[1522]: Activation via systemd failed for unit 'dbus-org.bluez.obex.service': Unit dbus-org.bluez.obex.service not found. This is still present on Fedora 26 and very annoying. Please somebody look into this.
Please don't clone a bug, even worse you've not added any useful information to it. Please open a new bug that isn't cloned with all the version information. My BT mice reconnect just fine *** This bug has been marked as a duplicate of bug 1337353 ***
What is the point of closing this bug as a duplicate of another closed (but unfixed) bug? How is anything supposed to get fixed in that case?
(In reply to Brian J. Murrell from comment #2) > What is the point of closing this bug as a duplicate of another closed (but > unfixed) bug? What is the point of opening a cloned bug without any new information? Your better doing a new bug with up to date information. > How is anything supposed to get fixed in that case? Well it wouldn't if it's just a clone of an already closed bug anyway
In addition, I cloned the bug because the one I cloned it from was closed prematurely and *I* have no way of reopening it. This, IMHO, is exactly what cloning is useful for. I did add useful information... that this is still happening on Fedora 26 but there is nothing else new to add, hence no reason to start the whole triage process from scratch without any of the information from the cloned, closed bug. Good for you that your BT mice reconnect fine. That doesn't change the fact that mine does not.
> This, IMHO, is exactly what cloning is useful for. I did add useful Cloning is useful for nothing. > information... that this is still happening on Fedora 26 but there is > nothing else new to add, hence no reason to start the whole triage process > from scratch without any of the information from the cloned, closed bug. So same versions of bluez, the desktop components, the hardware and firmware revisiosn? > Good for you that your BT mice reconnect fine. That doesn't change the fact > that mine does not. Doesn't change the fact the one you cloned is from F24 and a _LOT_ of bluetooth stuff has changed and the HW/firmware is unlikely to be the same.
(In reply to Peter Robinson from comment #5) > > Cloning is useful for nothing. Then why does it exist as a function? > So same versions of bluez, the desktop components, the hardware and firmware > revisiosn? Bugs, believe it or not, can propagate from one version of something to the next and typically do unless they are specifically fixed. The comment from the original description even re-enforces this: This is not a regression, the same problem happens in Fedora 23. So was in 23 and 24 per the OP. I experienced it in those versions also and up through 25 and now in 26. I finally got tired of it enough that I came to report it and found an existing bug, unfortunately closed for no other reason that nobody looked into it. Nobody even triaged it or responded to the OP. > Doesn't change the fact the one you cloned is from F24 and a _LOT_ of > bluetooth stuff has changed and the HW/firmware is unlikely to be the same. Given that this issue has happened consistently through at least 4 releases up to and including the current release would indicate that the problem is more basic than a software/firmware version change.
> Given that this issue has happened consistently through at least 4 releases > up to and including the current release would indicate that the problem is > more basic than a software/firmware version change. Yet it doesn't happen consistently for most people, and that could easily indicate that it IS a HW/firmware issue as that could be the one consistent thing between the releases.
And so then if it is a HW/firmeware issue, then the information posted to the original bug, copied here by the clone function is very relevant as it has nothing to do with which version of bluez, the desktop components, the Fedora release even. You know, we could go on and on arguing about the merits of cloning a bug. You have your opinion and I obviously have mine. Or we could just agree to disagree, admit that there are users that have an issue and keep a bug open about it so that somebody can look into it. My hardware is: Logitech M557 mouse paired with a: Bus 003 Device 003: ID 0a5c:2121 Broadcom Corp. BCM2210 Bluetooth Not sure how to collect firmware versions from those though.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.