Messages in this thread | | | Date | Wed, 06 Aug 2008 21:40:47 -0700 | From | Philip Langdale <> | Subject | Re: [PATCH 1/1] toshiba_acpi: Add support for bluetooth toggling through rfkill (v2) |
| |
Henrique de Moraes Holschuh wrote: > > Well, the textbook way to connect that to rfkill is something like this, > please check if it makes sense: > > Export (1) as a input device (you have events to hook to when it changes > state) or polled input device (you don't have said events). Do NOT register > (1) with a struct rfkill at all. It is purely an input device. > > DO NOT expose (2) as an input device at all. Instead, register it to a > rfkill struct, of type bluetooth. > > On the event handler for (1), you issue the EV_SW SW_RFKILL_ALL input event. > Since you *do* know events from (1) are likely to also have messed with the > state of (2), you also check (2)'s state at this time and update it through > rfkill_force_state(). > > Due to the interaction of 1 and 2, you need to implement and deal with > RFKILL_STATE_HARD_BLOCKED. Since you do know the firmware will be > hard-blocking (2) when (1) is active, you return RFKILL_STATE_HARD_BLOCKED > for (2)'s state every time (1) is active. Otherwise, you return > RFKILL_STATE_SOFT_BLOCKED when (2) is blocked, and RFKILL_STATE_UNBLOCKED > otherwise. > > This will cause the state of (2) to go to either RFKILL_STATE_HARD_BLOCKED > or RFKILL_STATE_SOFT_BLOCKED when (1) changes state. > > [Note: the above does assume (1) blocks (2) in some way you cannot override, > and that trying to unblock (2) while (1) is blocking it is futile]. > > rfkill-input (now) or userspace (someday) will take care of kicking the > radio to RFKILL_STATE_UNBLOCKED when (1) issues an event that signals that > radios don't have to remain blocked. Maybe this is why you see the WLAN > going on when you deactivate the radio kill switch? > > And rfkill-input will soon be enhanced to let the user configure it to do > something different if he wants. Your driver doesn't (and shouldn't) > hardcode policy about it.
Hmm. So, I've updated the diff to do this, but rfkill-input is not kicking the bluetooth device back on after I release the kill switch. it just returns to SOFT_UNBLOCKED and stays there.
--phil
| |