lkml.org 
[lkml]   [2008]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-08-07 07:07    [W:0.079 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site