No confirmation that wi-fi hardware is turned on/off
Bug #1255097 reported by
Matthew Paul Thomas
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| indicator-network (Ubuntu) |
Triaged
|
Wishlist
|
Matthew Paul Thomas | ||
Bug Description
On a PC with a wi-fi or Bluetooth hotkey:
1. Turn off wi-fi or Bluetooth.
2. Turn on wi-fi or Bluetooth.
What you see:
1. Nothing.
2. Nothing.
What you should see:
1. Some kind of visible confirmation.
2. Some kind of visible confirmation.
As described in public bug 404658, this is implemented for a Canonical OEM project in private bug 1213507, using a separate hotkey daemon. <https:/
It is probably better implemented in indicator-network, tracking actual rfkill events rather than hotkeys that might or might not be heeded.
| Changed in indicator-network (Ubuntu): | |
| assignee: | nobody → Matthew Paul Thomas (mpt) |
| Changed in indicator-network: | |
| status: | New → Confirmed |
| Changed in indicator-network (Ubuntu): | |
| status: | New → Confirmed |
| Changed in indicator-network: | |
| importance: | Undecided → Low |
| Changed in indicator-network (Ubuntu): | |
| importance: | Undecided → Low |
| no longer affects: | indicator-network |
| Changed in indicator-network (Ubuntu): | |
| importance: | Low → Wishlist |
| Changed in indicator-network (Ubuntu): | |
| status: | Confirmed → Triaged |
To post a comment you must log in.
On Touch, we use urfkill for monitoring rfkill events and implementing flight-mode.
For desktop, we should consider using urfkill instead of implementing this directly in indicator-network ( which AFAIK has not yet being used on desktop either ) or creating yet another daemon process.