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.
--phil
On Sun, 27 Jul 2008, Philip Langdale wrote:
> 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.
Can it be used as an event that you just take as a hint to READ the state
of the switch? I.e. as "switch may have changed state, you better check"
instead of "switch changed state"?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
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