There is absolutely no reason why delaying bluez from starting should
affect S3/S4 or killswitches in any normal case, especially not in a
relation with dbus, for which the connection is only established on
startup.
There *is* a chance where bluetooth would start and not have dbus
available, but in this case it would fail immediately on startup, which
does not appear to be the issue at hand. That said, since it's a
possibility I have a test patch ready.
Please attach a full copy of /var/log/syslog to this bug report so we
can see all the messages from bluez and from the kernel bluetooth
subsystem. It really seems to me like this is an issue caused by an
incomplete initialization of the bluetooth device by the time bluez
starts, which is something that really should get fixed in the kernel
itself rather than as a workaround in bluez.
** Changed in: bluez (Ubuntu)
Status: New => Incomplete
** Changed in: bluez (Ubuntu Precise)
Status: New => Incomplete
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: bluez (Ubuntu)
Assignee: Canonical Desktop Team (canonical-desktop-team) => Mathieu
Trudel-Lapierre (mathieu-tl)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1221618
Title:
Bluetooth doesn't work after S3/S4 or after turning bluetooth on/off
several times by toggle key
To manage notifications about this bug go to:
https://bugs.launchpad.net/bluez/+bug/1221618/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
