This bug was fixed in the package gnome-bluetooth - 3.2.2-0ubuntu4
---
gnome-bluetooth (3.2.2-0ubuntu4) precise; urgency=low
* debian/patches/menu_update_on_rfkill.patch: make sure the menu gets updated
properly when the killswitch state is changed. Specifically, notify for the
This bug was fixed in the package bluez - 4.98-2ubuntu7
---
bluez (4.98-2ubuntu7) precise; urgency=low
* debian/patches/10-unregister_interface_on_exit.patch: unregister the SAP
interface on exit. Thanks to Jesse Sung for the patch.
* debian/patches/11-explicitly_close.patch:
In progress :) I'll upload this in a few minutes once I can
successfully test this.
It's nice to see we got the same patch for the gnome-bluetooth part of
the fix independently.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Hi Mathieu,
Sorry, didn't notice that it's deprecated. An updated patch is attached.
And yes, please sponsor these patches, thank you. :)
** Patch added: "updated patch"
https://bugs.launchpad.net/ubuntu/precise/+source/bluez/+bug/907818/+attachment/2908563/+files/11-explicitly_close.patch
** Tags removed: rls-p-tracking
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/907818
Title:
Bluetooth is not fully re-initialized when rfkill switch is toggled
To manage notifications about this bu
** Tags removed: patch
** Tags added: patch-needswork
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/907818
Title:
Bluetooth is not fully re-initialized when rfkill switch is toggled
To manage notif
Well, patch
https://launchpadlibrarian.net/96987064/11-explicitly_close.patch seems
at least a little incorrect; it seems to be as though you should be
closing the io channel before it gets unref'd ;)
Also, g_io_channel_close() is deprecated, it would be better to use
g_io_channel_shutdown().
Do
The attachment "patch for bluez (optional)" of this bug report has been
identified as being a patch. The ubuntu-reviewers team has been
subscribed to the bug report so that they can review the patch. In the
event that this is in fact not a patch you can resolve this situation by
removing the tag
** Changed in: bluez (Ubuntu Precise)
Status: Incomplete => In Progress
** Changed in: bluez (Ubuntu Precise)
Assignee: (unassigned) => Jesse Sung (wenchien)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
Patched bluez and gnome-bluetooth packages can be found at
http://people.canonical.com/~jesse/lp907818/
Please give them a try to see if this issue is gone, and also make sure
that they do not break anything on other platforms. :)
Thank you.
--
You received this bug notification because you are
This patch is for
bluetoothd[5416]: audio/manager.c:gateway_server_init() audio.conf: Key file
does not have key 'Master'
bluetoothd[5416]: rfcomm_bind: Address already in use (98)
bluetoothd[5416]: audio-gateway: Operation not permitted (1)
** Patch added: "patch for bluez"
https://bugs.lau
On certain devices, module would be powered off after RFKILL enabled. When
RFKILL is disabled again, update_menu_items() would be called with
has_powered_adapter set to TRUE, but the
bluetooth_applet_get_killswitch_state() still thinks RFKILL is in a blocked
state and refuses to enable full men
This patch is not mandatory for this issue, but it fixes an error
message when RFKILL switch is turned off:
bluetoothd[5416]: sap/manager.c:sap_server_probe() path /org/bluez/5416/hci0
bluetoothd[5416]: sap-dummy interface org.bluez.SimAccessTest init failed on
path /org/bluez/test
bluetoothd[541
Yes, this is a Dell device. And will killswitch is enabled, device no
longer shows in lsusb.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/907818
Title:
Bluetooth is not fully re-initialized when rf
Anthony or James, please confirm: this was for a Dell device right? It's
the only place so far I've been able to reproduce this kind of behavior.
Seems to be because the killswitch actually removes the bluetooth device
altogether.
--
You received this bug notification because you are a member of
** Also affects: bluez (Ubuntu Precise)
Importance: Medium
Status: Incomplete
** Also affects: gnome-bluetooth (Ubuntu Precise)
Importance: Medium
Assignee: Mathieu Trudel-Lapierre (mathieu-tl)
Status: Confirmed
** Tags removed: rls-mgr-p-tracking
** Tags added: rls-p-tra
This seems to work pretty well for me right now if you omit the issue of
the bluetooth applet not properly seeing the new enabled state after
rfkill has been toggled (it never comes back with the full menu unless
you change a config in the wizard or turn it off/on again via the menu).
Bluetooth fun
** Tags removed: rls-p-tracking
** Tags added: rls-mgr-p-tracking
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/907818
Title:
Bluetooth is not fully re-initialized when rfkill switch is toggled
To
** Changed in: bluez (Ubuntu)
Assignee: (unassigned) => 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/907818
Title:
Bluetooth is not fully re-initialized wh
** Changed in: bluez (Ubuntu)
Importance: Undecided => Medium
** Changed in: bluez (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/907818
Title:
Bluetooth
The only noticeable differences in output between initialization and
the re-enablement of device via rfkill.
1) aforementioned idx{0,1} are blocked until initialization is done
2) bluetoothd[1982]: src/rfkill.c:rfkill_event() RFKILL event idx 4 type 2 op 0
soft 0 hard 0
bluetoothd[1982]: src
On second thought, the last event is not cleanup, since it is
recognizing the switch as _on_ for idx{0,1}. It looks like the device
might have to be initialized first before it sends the signal that the
rfkill switch has been turned on. Here is more complete what's going on
before that:
bluetoothd
Initial analysis :
Init:
bluetoothd[1982]: src/main.c:main() Entering main loop
bluetoothd[1982]: src/rfkill.c:rfkill_event() RFKILL event idx 0 type 1 op 0
soft 0 hard 0
bluetoothd[1982]: src/rfkill.c:rfkill_event() RFKILL event idx 1 type 2 op 0
soft 0 hard 0
bluetoothd[1982]: src/rfkill.c:rf
output of bluetoothd -nd . rfkill switch started on, was turned off,
then on again. Please let me know if there are other diagnostic steps
that you would like to help move this along.
** Attachment added: "bluetooth.output.log2"
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/907818/+atta
Workaround
==
61-rfkill-nm-disable-enable.rules
==
#the rfkill device number for wifi is inconsistent between platforms * is used
KERNEL!="rfkill*", GOTO="rfkill_nm_disable_enable_end"
ACTION!="change", GOTO="rfkill_nm_disable_enable_end"
#only switch once on wlan
25 matches
Mail list logo
