Philip Langdale wrote:

As requested by Henrique, I have reworked this patch against 
wireless-testing
and it uses the new-style rfkill API and to report the input device as a 
switch.

I did some digging to try and find a usable gpe event but had only limited
success. From another look through the AML, it uses GPE08 for almost 
everything
- inspecting a bunch of state for each event and then sending 
notifications on
different objects. I couldn't find one for the hardware kill switch 
itself but I
did manage to find one that's emitted when the bluetooth device enters the
equivalent of the SOFT_BLOCKED state. This is useful for noticing that the
hardware switch has been released, but it also fires on transitions from 
UNBLOCKED
to SOFT_BLOCKED - so I had to try and avoid turning around and 
unblocking the
device! I'm not particularly happy with how I did it 
(ignore-the-next-event)
but I can't think of a better way.

I've updated the diff to use force_state instead of get_state. I'm a little
unhappy in that it requires poking the rfkill state from the input poll
function but that's the only way we know anything changed.

The event handling is still the same as before because I realised that there's
no fundamental state I can use to distinguish the two transitions - at the time
the event fires, the kill switch is inactive and the bluetooth device is
disconnected but we simply don't know where we came from (hard killed or on),
so we have to maintain some form of state in the driver and the current mechanism
is as good (or bad) as any other.

--phil