Hi,
Quote from Documentation/rfkill.txt:
"
The driver should implement the toggle_radio() hook, that:
=2E..
3. Deactivates the soft rfkill line if none of the hardware rfkill line=
s
are active and the caller asked for RFKILL_STATE_UNBLOCKED.
"
It doesn't say what to do if both the hardware and software rfkill line=
s
are active when RFKILL_STATE_UNBLOCKED is asked. Should we deactivate
the software rfkill in this case? Otherwise below usage won't turn on
the radio:
hardware rfkill activate
software rfkill activate
RFKILL_STATE_UNBLOCKED request
hardware rfkill deactivate
=46urthermore, if we permit double block, what should get_state() retur=
n?
Shouldn't rfkill_state =EF=BB=BFbe bitmap instead of enum?
Thanks,
-yi
On Wed, 2008-07-02 at 15:03 +0800, Zhu Yi wrote:
> Hi,
>=20
> Quote from Documentation/rfkill.txt:
> "
> The driver should implement the toggle_radio() hook, that:
>=20
> ...
>=20
> 3. Deactivates the soft rfkill line if none of the hardware rfkill li=
nes
> are active and the caller asked for RFKILL_STATE_UNBLOCKED.
> "
>=20
> It doesn't say what to do if both the hardware and software rfkill li=
nes
> are active when RFKILL_STATE_UNBLOCKED is asked. Should we deactivate
> the software rfkill in this case? Otherwise below usage won't turn on
> the radio:
>=20
> hardware rfkill activate
> software rfkill activate
> RFKILL_STATE_UNBLOCKED request
> hardware rfkill deactivate
>=20
> Furthermore, if we permit double block, what should get_state() retur=
n?
> Shouldn't rfkill_state =EF=BB=BFbe bitmap instead of enum?
That would be more useful than the current enum, yes.
Dan
On Fri, 2008-07-04 at 16:55 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 02 Jul 2008, Dan Williams wrote:
> > That would be more useful than the current enum, yes.
>
> Dan, you do have a strong user case for "just software rfkilled", "just
> hardware rfkilled" and "soft+hard rfkilled" as opposed to simply "software
> rfkilled" and "hardware rfkilled, maybe software rfkilled as well" ?
No, I don't have a _NetworkManager_ usecase for being able to
distinguish between HW and HW+SW. Just an observation that stuff other
than NM might want to figure that out for UI or something.
But if the HW block is on, NM doesn't care about softblock because you
can't use the radio anyway. If the HW switch is unblocked, NM will
un-SW-block the radio anyway, since HW-unblock is definitely a
user-initiated option and signals user intent to unblock the radio
irregardless of SW block state from something else.
Dan
On Wed, Jul 2, 2008 at 10:32 PM, Henrique de Moraes Holschuh
<[email protected]> wrote:
> On Wed, 02 Jul 2008, Zhu Yi wrote:
>> It doesn't say what to do if both the hardware and software rfkill lines
>> are active when RFKILL_STATE_UNBLOCKED is asked. Should we deactivate
>> the software rfkill in this case? Otherwise below usage won't turn on
>> the radio:
>
> Well, we allow double-blocking to make sure the radio isn't unblocked by
> mistake. The bias in rfkill is to block, as that is safer.
>
> The issue is that if we get a RFKILL_STATE_UNBLOCKED request, and we are at
> RFKILL_STATE_HARD_BLOCKED, we need to return an error (we can't set the
> requested state). But since we returned an error, should we do the best we
> can, or should we do nothing?
>
> I am really not sure what would be better: to remove the double-blocking
> while still returning an error, or to leave the radio as is (be it
> double-blocked or just blocked by the hardware rfkill line) and return an
> error.
>
> Both would work just fine as far as the rfkill class goes, it wouldn't get
> confused by either as far as I can tell (*as long as an error is
> returned!*). But we really should pick one of the two, and document that
> IMHO.
>
> My best guess is that doing a half-unblock would be less confusing to the
> user, but we can ask the userspace GUI people about it ;-) Dan?
>
>> hardware rfkill activate
>> software rfkill activate
>> RFKILL_STATE_UNBLOCKED request
>> hardware rfkill deactivate
>>
>> Furthermore, if we permit double block, what should get_state() return?
>
> get_state() returns RFKILL_STATE_HARD_BLOCKED when any hardware rfkill lines
> are active. If ALL hardware rfkill lines are inactive, it will return
> RFKILL_STATE_SOFT_BLOCKED if any software rfkill lines are ative.
>
> And if EVERY rfkill line is inactive, it returns RFKILL_STATE_UNBLOCKED.
>
> This makes sense, as you are basically stuck without being able to go
> anywere when in RFKILL_STATE_HARD_BLOCKED, until something external changes
> the hardware rfkill lines.
>
>> Shouldn't rfkill_state ???be bitmap instead of enum?
>
> We could do that, too. But a bitmap would cause trouble due to the ABI we
> inherited from the rfkill in the stable kernels, so it would be cleaner to
> just add a fourth state (RFKILL_STATE_DOUBLE_BLOCKED).
>
> However, I am pretty certain we will find firmware (hardware is less likely
> to be this stupid) that has erratic behaviour when RFKILL_STATE_HARD_BLOCKED
> (and thus you don't really know if you managed to double-block or remove a
> double-block). In fact, that's the kind of crap I am used to fight in
> thinkpad-acpi, although I sure hope thinkpads don't have this particular
> quirk.
>
> So, I pose this question: Four states would allow us to tell the user the
> radio is JUST hardware-killed or JUST software-killed for some hardware, but
> does THAT enhance the user experience in any way? Do GUIs really need that
> detail?
>From my experience from other OS the states of SW and HW RF KILL
switches should be independent and visible to user space
otherwise it's very hard to make something coherent out of it. It
should be visible to user himself so he/she knows what switch actually
press. And also to let say unmanned application, most important in
preserving SW switch state across reboots and resume/suspend events.
Radio state is just simple AND function of all the switches in the
game anything else just leads to confusion.
Currently we have rkill switch from sysfs, hw rfkill, iwconfig txpower
off, the last one is better to eliminate but still we have TRIPLE
BLOCKING
Thanks
Tomas
Dan Williams wrote:
> But if the HW block is on, NM doesn't care about softblock because you
> can't use the radio anyway. If the HW switch is unblocked, NM will
> un-SW-block the radio anyway, since HW-unblock is definitely a
> user-initiated option and signals user intent to unblock the radio
> irregardless of SW block state from something else.
Removing the SW switch after the user unblocks the HW switch seems wrong to me:
HW-unblock doesn't necessarily mean the user wants to unblock WLAN if it was
SW-blocked before (which is most likely the user's choice).
Consider the following situation:
- the computer has a WLAN device and Bluetooth device
- both devices can be HW-blocked with a single physical switch
- each device can be toggled with a key
With the following scenario:
- I (the user) don't want to use WLAN for whatever reason (like using a wired
network, or to save energy)
- I want to have Bluetooth enabled for my wireless mouse
- I temporarily enable the HW switch (because I don't need the mouse anymore, or
to let someone else use it on his/her own computer)
- A bit later, I want to use Bluetooth again and disable the HW switch
- Both Bluetooth and WLAN would now be enabled
This can be annoying, especially if NM connects to a wireless network
automatically. It would consume energy needlessly, or break the network config if
both the wired and wireless connections are configured for the same IP.
So generally, I would say that assuming to know what the user wants is dangerous,
as it can result in doing something against his will. If the user wants to enable
WLAN, there is a key for it.
Also note that this would still happen without NM but with rfkill-input, since
currently it doesn't restore the previous state when the HW switch is disabled.
It just unblocks the device (Andy posted about it half an hour ago).
Any news on this, Henrique? I think you talked about it some time ago, and with
the new double block enum, it should be easier to know the previous state.
- Fabien.
On Mon, 07 Jul 2008, Dan Williams wrote:
> On Fri, 2008-07-04 at 16:55 -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 02 Jul 2008, Dan Williams wrote:
> > > That would be more useful than the current enum, yes.
> >
> > Dan, you do have a strong user case for "just software rfkilled", "just
> > hardware rfkilled" and "soft+hard rfkilled" as opposed to simply "software
> > rfkilled" and "hardware rfkilled, maybe software rfkilled as well" ?
>
> No, I don't have a _NetworkManager_ usecase for being able to
> distinguish between HW and HW+SW. Just an observation that stuff other
> than NM might want to figure that out for UI or something.
Ok. I will still *try* to implement the fourth state, but I will post the
patch as a RFC. If it is too messy or complex, I will recommend that we
drop it.
> But if the HW block is on, NM doesn't care about softblock because you
> can't use the radio anyway. If the HW switch is unblocked, NM will
> un-SW-block the radio anyway, since HW-unblock is definitely a
> user-initiated option and signals user intent to unblock the radio
> irregardless of SW block state from something else.
I intend to offer the *possibility* of using the HW switch like this on
rfkill-input: on block, block all (EPO). On unblock, restore previous state
(so, e.g. if WLAN was enabled and bluetooth was disabled, after a HW switch
on/off/on cycle, you will not get bluetooth and WLAN enabled). But that's
not ready yet, and I am not sure I will be able to do it cleanly. If I
can't, I will drop it.
--
"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
On Mon, Jul 7, 2008 at 2:47 PM, Andrew Lutomirski <[email protected]> wrote:
> On Mon, Jul 7, 2008 at 12:56 PM, Henrique de Moraes Holschuh
> <[email protected]> wrote:
>> On Mon, 07 Jul 2008, Andy Lutomirski wrote:
>>
>>> If I'm missing something I need to make rfkill suddenly work on my
>>> machine, please give me some hints, too :)
>>
>> [...]
>
> Now I'm running wireless-testing + thinkpad-acpi 0.21-20080703 and
> everything appears to work (the button controls just bluetooth, the
> switch works and gets noticed by the driver, etc). I turned off
> Ubuntu's hotkey-setup, which had some alternate thinkpad thing.
>
> Nice work on the new thinkpad-acpi, BTW. It's quite an improvement.
>
> I'll play around with the new stuff.
OK, got a "bug" for you. I'm not sure whether it's a bug in rfkill,
rfkill-input, iwlwifi, thinkpad-acpi, or the way they all interact.
If I press the button on the keyboard (the icon makes it look like
wifi), then bluetooth is toggled on and off and nothing happens to
wlan rfkill. This is fine with me.
But if I toggle bluetooth off (killed and therefore not present in the
system per thinkpad-acpi), then block wlan with the switch, then
unblock wlan with the switch, then bluetooth turns back on. This only
happens with rfkill-input loaded. I hope this isn't the intended
behavior.
The radio button does this (from evtest on "ThinkPad Extra Buttons"):
Event: time 1215457292.276962, type 1 (Key), code 385 (Radio), value 1
Event: time 1215457292.276977, -------------- Report Sync ------------
Event: time 1215457292.276982, type 1 (Key), code 385 (Radio), value 0
Event: time 1215457292.276984, -------------- Report Sync ------------
Toggling the switch to blocked then back to unblocked does:
Event: time 1215457296.509094, type 5 (?), code 3 (?), value 0
Event: time 1215457296.509107, -------------- Report Sync ------------
Event: time 1215457297.544226, type 5 (?), code 3 (?), value 1
Event: time 1215457297.544244, -------------- Report Sync ------------
So the right input events are generated (or maybe not -- should
thinkpad-acpi generate events at all for a hardware switch?), but it
looks like rfkill-input thinks that it's supposed to turn bluetooth on
when the switch goes on.
Is this an artifact of the present design or is it just a bug?
(My mental picture of how it should work is that there should be
"switches" and "switchable things," both of which show up in sysfs,
and which can be wired up arbitrarily (consistent with hardware, so a
switch that physically controls an rfkill line couldn't be unwired
from it) in sysfs, kinda like led triggers. "switches" would be
things like the radio switch (which thinkpad-acpi can ignore
completely because iwlwifi or presumably any other wireless driver can
also see it), the rfkill minipci line, and virtual switches
synthesized from buttons (the bluetooth button, the light button, etc)
and switchable things could be radios, bluetooth devices, keyboard
lights, etc.)
--Andy
On Wed, 02 Jul 2008, Zhu Yi wrote:
> It doesn't say what to do if both the hardware and software rfkill lines
> are active when RFKILL_STATE_UNBLOCKED is asked. Should we deactivate
> the software rfkill in this case? Otherwise below usage won't turn on
> the radio:
Well, we allow double-blocking to make sure the radio isn't unblocked by
mistake. The bias in rfkill is to block, as that is safer.
The issue is that if we get a RFKILL_STATE_UNBLOCKED request, and we are at
RFKILL_STATE_HARD_BLOCKED, we need to return an error (we can't set the
requested state). But since we returned an error, should we do the best we
can, or should we do nothing?
I am really not sure what would be better: to remove the double-blocking
while still returning an error, or to leave the radio as is (be it
double-blocked or just blocked by the hardware rfkill line) and return an
error.
Both would work just fine as far as the rfkill class goes, it wouldn't get
confused by either as far as I can tell (*as long as an error is
returned!*). But we really should pick one of the two, and document that
IMHO.
My best guess is that doing a half-unblock would be less confusing to the
user, but we can ask the userspace GUI people about it ;-) Dan?
> hardware rfkill activate
> software rfkill activate
> RFKILL_STATE_UNBLOCKED request
> hardware rfkill deactivate
>
> Furthermore, if we permit double block, what should get_state() return?
get_state() returns RFKILL_STATE_HARD_BLOCKED when any hardware rfkill lines
are active. If ALL hardware rfkill lines are inactive, it will return
RFKILL_STATE_SOFT_BLOCKED if any software rfkill lines are ative.
And if EVERY rfkill line is inactive, it returns RFKILL_STATE_UNBLOCKED.
This makes sense, as you are basically stuck without being able to go
anywere when in RFKILL_STATE_HARD_BLOCKED, until something external changes
the hardware rfkill lines.
> Shouldn't rfkill_state ???be bitmap instead of enum?
We could do that, too. But a bitmap would cause trouble due to the ABI we
inherited from the rfkill in the stable kernels, so it would be cleaner to
just add a fourth state (RFKILL_STATE_DOUBLE_BLOCKED).
However, I am pretty certain we will find firmware (hardware is less likely
to be this stupid) that has erratic behaviour when RFKILL_STATE_HARD_BLOCKED
(and thus you don't really know if you managed to double-block or remove a
double-block). In fact, that's the kind of crap I am used to fight in
thinkpad-acpi, although I sure hope thinkpads don't have this particular
quirk.
So, I pose this question: Four states would allow us to tell the user the
radio is JUST hardware-killed or JUST software-killed for some hardware, but
does THAT enhance the user experience in any way? Do GUIs really need that
detail?
If the answer is "yes, it is good, let's do it", I can certainly try to cook
up a patch. But if it is "no, it wouldn't do much for the user", or if the
answer is too uncertain, I don't think we should do it.
--
"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
Henrique de Moraes Holschuh wrote:
> On Mon, 07 Jul 2008, Dan Williams wrote:
>> On Fri, 2008-07-04 at 16:55 -0300, Henrique de Moraes Holschuh wrote:
>>> On Wed, 02 Jul 2008, Dan Williams wrote:
>>>> That would be more useful than the current enum, yes.
>>> Dan, you do have a strong user case for "just software rfkilled", "just
>>> hardware rfkilled" and "soft+hard rfkilled" as opposed to simply "software
>>> rfkilled" and "hardware rfkilled, maybe software rfkilled as well" ?
>> No, I don't have a _NetworkManager_ usecase for being able to
>> distinguish between HW and HW+SW. Just an observation that stuff other
>> than NM might want to figure that out for UI or something.
>
> Ok. I will still *try* to implement the fourth state, but I will post the
> patch as a RFC. If it is too messy or complex, I will recommend that we
> drop it.
I'm still a bit confused.
Suppose I have a laptop with a physical switch marked "radio" which
tells the OS which position it's in *and does nothing else* (via ACPI or
whatever) and a radio which has a (pure) software rfkill controller.
Suppose further that this laptop has a radio button as well.
This would look exactly like my Thinkpad X61s, except that the rfkill
switch would be connected to the rfkill controller in software, not
hardware.
I think it would have the exact same problem and the fourth state
wouldn't help because it would never be any variety of HARD_BLOCKED.
--Andy
On Tue, 08 Jul 2008, Andy Lutomirski wrote:
> I'm still a bit confused.
>
> Suppose I have a laptop with a physical switch marked "radio" which
> tells the OS which position it's in *and does nothing else* (via ACPI or
> whatever) and a radio which has a (pure) software rfkill controller.
> Suppose further that this laptop has a radio button as well.
Is that a hot key that also does nothing else but sit there and report "I
have been pressed" ? I will assume so in the rest of this reply.
> This would look exactly like my Thinkpad X61s, except that the rfkill
> switch would be connected to the rfkill controller in software, not
> hardware.
>
> I think it would have the exact same problem and the fourth state
> wouldn't help because it would never be any variety of HARD_BLOCKED.
Correct. The fourth state doesn't help with ANY problem I know of (I
thought it could help in sleep/resume, but I found out that I can't use it
because not every driver will be able to implement double-blocking, even if
it has a hardware rfkill line).
The fourth state ends up being just more information for the user.
What would happen in the scenario that you describe is this: the switch will
command rfkill-input. The key will ALSO command rfkill-input. So it will
override the switch, which I agree is not the best way to deal with it, to
put it lightly.
This is a problem in rfkill-input, and I suppose we should fix it.
Basically, rfkill-input will have to find out, and keep track of the input
device switches (the information is there, but it will add some complexity),
and not let other events override them. It can't just keep track of changes
caused by switches, because you need to query the switches about their
initial state to do it right (and that's another bug in current
rfkill-input).
More stuff for the TODO. Argh.
--
"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
On Mon, 07 Jul 2008, Andy Lutomirski wrote:
> Perhaps it's time to throw out the userspace interface and start over,
> or at least replace it and emulate the old one, too.
[...]
> NIC." Wireless-compat's driver just confuses network-manager.) The
> rfkill module seems to have no effect, and 'find /sys -name *rfkill*'
> shows nothing (other than the rfkill class and module). Rfkill doesn't
Make sure rfkill is loaded and didn't bitch anything to the kernel log about
errors. If it is loaded, and there is nothing in /sys/class/rfkill, it
means that the version of the drivers in your kernel lack rfkill class
support.
I understand you're using either 2.6.25.10 or a released Ubuntu kernel, in a
released Ubuntu userspace? That doesn't have the latest rfkill work in it,
be it core rfkill code or network device driver code. That's not a small
ammount of stuff. So, it is quite possible that the iwl driver in there
doesn't have rfkill class support (I don't know for sure, but you can check.
Grep for linux/rfkill.h in the driver source).
So, what you have in a released Ubuntu kernel is not the same rfkill we are
working on yet, unless you managed to patch it in yourself. And if you
patch it in, you need to check Ubuntu userspace as it might need
configuration changes to not double-handle KEY_WLAN, or thinkpad-acpi HKEY
events for fn+f5, etc. I understand Ubuntu did a lot to try to get some
wireless hot key support in their releases, but this certainly means they
hooked some stuff in acpid or HAL to do it.
E.g. thinkpad-acpi cannot do anything to your WLAN device directly, and your
kernel apparently has nothing registered in the rfkill subsystem, so
rfkill-input cannot, either. This means that userspace must be the one that
is processing KEY_WLAN and toggling WLAN rfkill (non-rfkill class based).
What happens to bluetooth might be either the firmware (unlikely), or
something in userspace that is asking thinkpad-acpi to enable/disable
bluetooth (VERY likely). Maybe it is trying to cycle through NONE, WLAN,
BLUETOOTH, WLAN+BLUETOOTH or somesuch?
[...]
> Maybe the new semantics should be something sensible with a read-only
> file called "rfkill" that's backwards-compatible and shows the overall
> state. Then we could do gnarly things like making *every* mac80211
> driver have software rfkill control, add inotify or something to the
> rfkill file, and generally have good and easily comprehensible control
> over all radios. Hardware switches (and momentary swtiches and buttons
Might as well add "support poll()/select() on the rfkill/state attribute in
sysfs" to the TODO list, then. That might not be trivial to do, the sysfs
interface for poll/select (at least in 2.6.23 which was the last time I
checked it) requires an pathname relative to /sys to work, which is not
something rfkill knows about its attributes. And I don't know if
poll()/select() support in sysfs is all that is needed for inotify to work
in sysfs.
But events to userspace have already been added (not in mainline yet), so
even if it can't be through inotify, you will get it through udev (and,
after it is modified to care about/relay those events, HAL and DBUS).
wireless network device driver support for the rfkill class is on the way,
but I don't think the mac80211 layer can help much (it is a very device
specific thing, rfkill is not about stopping data transfers, it is about
stopping energy emissions from the antennae). If I am wrong about this,
someone will step up and correct me quite soon :-)
> I'd suggest that nothing visible to userspace on the rfkill side go into
> 2.6.27 until it can be done right and it's clear what this whole
> mechanism is supposed to do. I might even be talked into writing some
> patches, because it would be kind of nice for all this stuff to work
> right on my laptops.
Well, please get the very latest wireless-testing tree, and read
Documentation/rfkill.txt to see what has been done already (and remember
that there could be some recent patches in this ML that have not been
applied to wireless-testing yet). You may need to read some threads from
the last month too.
In particular, read the small, recent thread about rfkill double-locking
after you read Documentation/rfkill.txt.
That will bring you up to speed with what is being done, and then we can
talk more about it. A lot of what you commented about is already in there,
although not exactly in the same way as you talked about it. The various ML
threads (you can search linux-wireless and LKML for "rfkill" to find them)
have the reasoning behind most of the details.
> If I'm missing something I need to make rfkill suddenly work on my
> machine, please give me some hints, too :)
That depends. You want help to get a current Ubuntu setup working as well
as it can given what exists in 2.6.25.10, or do you want hints on how to
help test and develop the bleeding edge rfkill stuff?
I can't help much with the Ubuntu setup, but I think some Ubuntu power users
in linux-thinkpad could, as they likely have fixed that problem already on
their boxes.
Now, for the bleeding edge, you need wireless-testing (or wireless-compat, I
believe it has rfkill in it, now). For a thinkpad, you will either need
thinkpad-acpi 0.21-20080703 from ibm-acpi.sf.net (filter out patches to
net/rfkill/* and include/linux/rfkill.h, if any of them clash with the ones
in wireless-compat), or the patches I sent to linux-acpi (no net/rfkill
changes there, it is just the thinkpad-acpi part). And you may need to get
up to speed with what acpid and HAL are doing on your Ubuntu system, you
will want to try to have rfkill-input do all the work, and that means
userspace is to not do anything...
--
"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
On Mon, 07 Jul 2008, Andrew Lutomirski wrote:
> OK, got a "bug" for you. I'm not sure whether it's a bug in rfkill,
> rfkill-input, iwlwifi, thinkpad-acpi, or the way they all interact.
Just in case it is not a bug, please add a printk to thinpad-acpi's sysfs
and procfs handle to get notified when something in userspace orders it to
enable/disable bluetooth through the non-rfkill interface. You might catch
some userspace script doing the nasty ;-)
> But if I toggle bluetooth off (killed and therefore not present in the
> system per thinkpad-acpi), then block wlan with the switch, then
> unblock wlan with the switch, then bluetooth turns back on. This only
> happens with rfkill-input loaded. I hope this isn't the intended
> behavior.
It is, but I have plans to try to give rfkill-input a different behaviour.
Right now, EV_SW SW_RFKILL_ALL ON means "turn every radio on" for
rfkill-input. I'd like to give it an option of doing instead "revert last
EV_SW SW_RFKILL_ALL OFF".
But that patch has to wait a bit, still. There are others in the TODO queue
before it, some of which will change the way rfkill_epo has to work, so I
want to do them first to not do the same work twice.
> So the right input events are generated (or maybe not -- should
> thinkpad-acpi generate events at all for a hardware switch?), but it
Yes, it is an input device, and thinkpad-acpi is the closest driver to the
switch, so it is the one which should handle it.
Imagine that you have a WLAN USB dongle. Wouldn't you want it to also be
subject to the hardware switch in the general case? If thinkpad-acpi
doesn't issue input events for the switch, that would never happen.
> looks like rfkill-input thinks that it's supposed to turn bluetooth on
> when the switch goes on.
Exactly.
> Is this an artifact of the present design or is it just a bug?
Current implementation, actually. The design says it could do anything.
rfkill-input implements the easier behaviour (unblock all), but it could do
other things too (including nothing, to let an application call up a GUI
pannel and ask the user).
It is in the TODO queue.
> (My mental picture of how it should work is that there should be
> "switches" and "switchable things," both of which show up in sysfs,
Can you use the terms "rfkill controller", "rfkill line" and "input device"
(as defined in the rfkill documentation) so that I know for sure what you
mean, please?
> and which can be wired up arbitrarily (consistent with hardware, so a
> switch that physically controls an rfkill line couldn't be unwired
> from it) in sysfs, kinda like led triggers. "switches" would be
The current design asks for a topology-agnostic model. To do otherwise
would mean we have to teach rfkill about the topology, which is something
that is machine-model-specific... and much more complex.
*WHEN* the rfkill work I am attempting to do is finally ready, you will be
able to just move rfkill-input out of the way (either disable it or just
rmmod it), and implement in userspace whatever your heart desires.
When rfkill-input is inactive, the only thing that messes with the rfkill
state of the devices is the "non-modifiable wiring" done by hardware or
firmware. So you'd be able to do the "custom virtual wiring" you want.
In fact, right now you can already do what you want by just rmmoding
rfkill-input. The only thing you can't really do from userspace right now
is to tell rfkill what the state of a newly-registered rfkill switch should
be. You will have to change it to the state you want after it is
registered.
--
"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
On Mon, Jul 7, 2008 at 12:56 PM, Henrique de Moraes Holschuh
<[email protected]> wrote:
> On Mon, 07 Jul 2008, Andy Lutomirski wrote:
>> Perhaps it's time to throw out the userspace interface and start over,
>> or at least replace it and emulate the old one, too.
>
>> Maybe the new semantics should be something sensible with a read-only
>> file called "rfkill" that's backwards-compatible and shows the overall
>> state. Then we could do gnarly things like making *every* mac80211
>> driver have software rfkill control, add inotify or something to the
>> rfkill file, and generally have good and easily comprehensible control
>> over all radios. Hardware switches (and momentary swtiches and buttons
>
> wireless network device driver support for the rfkill class is on the way,
> but I don't think the mac80211 layer can help much (it is a very device
> specific thing, rfkill is not about stopping data transfers, it is about
> stopping energy emissions from the antennae). If I am wrong about this,
> someone will step up and correct me quite soon :-)
I agree that rfkill is about stopping rf emission, but rf devices with
the emission turned off are generally useless (other than monitor
mode) and it might be nice to do everything possible to reduce power
consumption when rfkill is blocked. Also, even if a device can't
specifically block RF emission, having an easy-to-use off switch is
still handy.
>
>> I'd suggest that nothing visible to userspace on the rfkill side go into
>> 2.6.27 until it can be done right and it's clear what this whole
>> mechanism is supposed to do. I might even be talked into writing some
>> patches, because it would be kind of nice for all this stuff to work
>> right on my laptops.
>
> Well, please get the very latest wireless-testing tree, and read
> Documentation/rfkill.txt to see what has been done already (and remember
> that there could be some recent patches in this ML that have not been
> applied to wireless-testing yet). You may need to read some threads from
> the last month too.
>
> In particular, read the small, recent thread about rfkill double-locking
> after you read Documentation/rfkill.txt.
>
> That will bring you up to speed with what is being done, and then we can
> talk more about it. A lot of what you commented about is already in there,
> although not exactly in the same way as you talked about it. The various ML
> threads (you can search linux-wireless and LKML for "rfkill" to find them)
> have the reasoning behind most of the details.
>
>> If I'm missing something I need to make rfkill suddenly work on my
>> machine, please give me some hints, too :)
>
> [...]
Now I'm running wireless-testing + thinkpad-acpi 0.21-20080703 and
everything appears to work (the button controls just bluetooth, the
switch works and gets noticed by the driver, etc). I turned off
Ubuntu's hotkey-setup, which had some alternate thinkpad thing.
Nice work on the new thinkpad-acpi, BTW. It's quite an improvement.
I'll play around with the new stuff.
--Andy
On Mon, 2008-07-07 at 00:44 -0400, Andy Lutomirski wrote:
> Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Jul 2008, Tomas Winkler wrote:
> >> From my experience from other OS the states of SW and HW RF KILL
> >> switches should be independent and visible to user space
> >> otherwise it's very hard to make something coherent out of it. It
> >> should be visible to user himself so he/she knows what switch actually
> >> press. And also to let say unmanned application, most important in
> >> preserving SW switch state across reboots and resume/suspend events.
> >> Radio state is just simple AND function of all the switches in the
> >> game anything else just leads to confusion.
> >> Currently we have rkill switch from sysfs, hw rfkill, iwconfig txpower
> >> off, the last one is better to eliminate but still we have TRIPLE
> >> BLOCKING
> >
> > I am not convinced it is the best way to go, but I thought on it, and that
> > fourth state will at least help on sleep-to-ram resume, so you guys will get
> > four states.
> >
> > But I can't give you a bitmap. Sorry, there is a stablished sysfs ABI in
> > mainline that says this:
> >
> > 00 - BLOCK ("off")
> > 01 - UNBLOCK ("on")
> >
> > I hate it, but I can't change it. We can *extend* it, but that's it.
>
> Perhaps it's time to throw out the userspace interface and start over,
> or at least replace it and emulate the old one, too.
>
> I'm not even kidding. I have an iwl4965, and I've tried 2.6.25.10's
> built-in driver and wireless-compat from a couple days ago. The rfkill
> switch *works* but the userspace interface does nothing. (2.6.25.10's
> module at least causes network-manager to notice that the interface went
> down and gets a ton of "Requesting MAC access during RFKILL wakes up
> NIC." Wireless-compat's driver just confuses network-manager.) The
NM talks to HAL for rfkill information as an abstraction over all the
random rfkill implementations that came before the kernel one, so you'll
have to see if the HAL rfkill callouts correctly determine state for
your driver.
Note that the HAL killswitch interface does not yet support soft-block,
which as something that I was going to poke at after this patch landed
if nobody fixed up HAL first.
Dan
> rfkill module seems to have no effect, and 'find /sys -name *rfkill*'
> shows nothing (other than the rfkill class and module). Rfkill doesn't
> work on my ath5k system either (no rfkill file). This is Ubuntu Hardy,
> which has nm 0.6, but I once tried nm 0.7 from svn and I don't recall it
> working any better.
>
> Not to mention the fact that I have both an rfkill switch and an rfkill
> button. Pressing the button turns WLAN off (same RFKILL messages
> spammed to dmesg) and Bluetooth *on*. Maybe it's thinkpad_acpi's fault,
> but I don't really see how it's supposed to work right.
>
> So it seems to me that the status quo is:
> - If there's a sysfs file called rfkill, it has such and such
> semantics, and you probably can't change it by writing to it.
> - There probably isn't an rfkill file.
> - Userspace, at least on my laptops, doesn't currently use the rfkill
> ABI in any meaningful manner.
> - Software rfkill control can easily do the wrong thing and there's no
> obvious way to make it do the right thing from userspace, .config, or sysfs.
>
> Maybe the new semantics should be something sensible with a read-only
> file called "rfkill" that's backwards-compatible and shows the overall
> state. Then we could do gnarly things like making *every* mac80211
> driver have software rfkill control, add inotify or something to the
> rfkill file, and generally have good and easily comprehensible control
> over all radios. Hardware switches (and momentary swtiches and buttons
> and whatnot) could all be exposed directly to userspace. Who knows --
> there could even be files like "hard_rf_enable" (read-only, only there
> if there's a readable switch, like on iwl4965) and "soft_rf_enable"
> (read-write, unconditionally present), and a mechanism for userspace to
> control the software part (i.e. userspace could tell rfkill-input to
> stop doing anything and take control itself).
>
> I'd suggest that nothing visible to userspace on the rfkill side go into
> 2.6.27 until it can be done right and it's clear what this whole
> mechanism is supposed to do. I might even be talked into writing some
> patches, because it would be kind of nice for all this stuff to work
> right on my laptops.
>
> If I'm missing something I need to make rfkill suddenly work on my
> machine, please give me some hints, too :)
>
> --Andy
>
On Wed, 02 Jul 2008, Dan Williams wrote:
> That would be more useful than the current enum, yes.
Dan, you do have a strong user case for "just software rfkilled", "just
hardware rfkilled" and "soft+hard rfkilled" as opposed to simply "software
rfkilled" and "hardware rfkilled, maybe software rfkilled as well" ?
--
"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
On Sun, 06 Jul 2008, Tomas Winkler wrote:
> From my experience from other OS the states of SW and HW RF KILL
> switches should be independent and visible to user space
> otherwise it's very hard to make something coherent out of it. It
> should be visible to user himself so he/she knows what switch actually
> press. And also to let say unmanned application, most important in
> preserving SW switch state across reboots and resume/suspend events.
> Radio state is just simple AND function of all the switches in the
> game anything else just leads to confusion.
> Currently we have rkill switch from sysfs, hw rfkill, iwconfig txpower
> off, the last one is better to eliminate but still we have TRIPLE
> BLOCKING
I am not convinced it is the best way to go, but I thought on it, and that
fourth state will at least help on sleep-to-ram resume, so you guys will get
four states.
But I can't give you a bitmap. Sorry, there is a stablished sysfs ABI in
mainline that says this:
00 - BLOCK ("off")
01 - UNBLOCK ("on")
I hate it, but I can't change it. We can *extend* it, but that's it.
rfkill is difficult enough already without a state field whose usage
description claims that bit 1 is active high and bit 0 is active low... So,
please do NOT look at the rfkill->state as you would look at a bitmap, look
at it as an enum, let the compiler do whatever bit-op optimizations might
apply behind the scenes, and all will be well ;-)
I will start working on a patch for the DOUBLE_BLOCKED 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
On Mon, 07 Jul 2008, Andrew Lutomirski wrote:
> I agree that rfkill is about stopping rf emission, but rf devices with
> the emission turned off are generally useless (other than monitor
> mode) and it might be nice to do everything possible to reduce power
> consumption when rfkill is blocked. Also, even if a device can't
Well, I assume the wireless device drivers will do their best to save power
on its own. It already knows it is rfkilled, after all... I don't see what
else rfkill could do to help :-)
> specifically block RF emission, having an easy-to-use off switch is
> still handy.
I can't agree with that unless we rename the whole rfkill stuff to something
else. Otherwise, you are giving the user the wrong idea (that the
transmitter is silent, when it is still sending out a carrier, or beacons,
or whatever), and that can be dangerous.
IMHO, the easy-to-use generic off switch for data is "ip link set ethX
down"...
> Now I'm running wireless-testing + thinkpad-acpi 0.21-20080703 and
> everything appears to work (the button controls just bluetooth, the
> switch works and gets noticed by the driver, etc). I turned off
> Ubuntu's hotkey-setup, which had some alternate thinkpad thing.
Some stuff might have lingered inside HAL or acpid, though. Just a head's
up.
> Nice work on the new thinkpad-acpi, BTW. It's quite an improvement.
Thanks.
--
"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
Henrique de Moraes Holschuh wrote:
> On Sun, 06 Jul 2008, Tomas Winkler wrote:
>> From my experience from other OS the states of SW and HW RF KILL
>> switches should be independent and visible to user space
>> otherwise it's very hard to make something coherent out of it. It
>> should be visible to user himself so he/she knows what switch actually
>> press. And also to let say unmanned application, most important in
>> preserving SW switch state across reboots and resume/suspend events.
>> Radio state is just simple AND function of all the switches in the
>> game anything else just leads to confusion.
>> Currently we have rkill switch from sysfs, hw rfkill, iwconfig txpower
>> off, the last one is better to eliminate but still we have TRIPLE
>> BLOCKING
>
> I am not convinced it is the best way to go, but I thought on it, and that
> fourth state will at least help on sleep-to-ram resume, so you guys will get
> four states.
>
> But I can't give you a bitmap. Sorry, there is a stablished sysfs ABI in
> mainline that says this:
>
> 00 - BLOCK ("off")
> 01 - UNBLOCK ("on")
>
> I hate it, but I can't change it. We can *extend* it, but that's it.
Perhaps it's time to throw out the userspace interface and start over,
or at least replace it and emulate the old one, too.
I'm not even kidding. I have an iwl4965, and I've tried 2.6.25.10's
built-in driver and wireless-compat from a couple days ago. The rfkill
switch *works* but the userspace interface does nothing. (2.6.25.10's
module at least causes network-manager to notice that the interface went
down and gets a ton of "Requesting MAC access during RFKILL wakes up
NIC." Wireless-compat's driver just confuses network-manager.) The
rfkill module seems to have no effect, and 'find /sys -name *rfkill*'
shows nothing (other than the rfkill class and module). Rfkill doesn't
work on my ath5k system either (no rfkill file). This is Ubuntu Hardy,
which has nm 0.6, but I once tried nm 0.7 from svn and I don't recall it
working any better.
Not to mention the fact that I have both an rfkill switch and an rfkill
button. Pressing the button turns WLAN off (same RFKILL messages
spammed to dmesg) and Bluetooth *on*. Maybe it's thinkpad_acpi's fault,
but I don't really see how it's supposed to work right.
So it seems to me that the status quo is:
- If there's a sysfs file called rfkill, it has such and such
semantics, and you probably can't change it by writing to it.
- There probably isn't an rfkill file.
- Userspace, at least on my laptops, doesn't currently use the rfkill
ABI in any meaningful manner.
- Software rfkill control can easily do the wrong thing and there's no
obvious way to make it do the right thing from userspace, .config, or sysfs.
Maybe the new semantics should be something sensible with a read-only
file called "rfkill" that's backwards-compatible and shows the overall
state. Then we could do gnarly things like making *every* mac80211
driver have software rfkill control, add inotify or something to the
rfkill file, and generally have good and easily comprehensible control
over all radios. Hardware switches (and momentary swtiches and buttons
and whatnot) could all be exposed directly to userspace. Who knows --
there could even be files like "hard_rf_enable" (read-only, only there
if there's a readable switch, like on iwl4965) and "soft_rf_enable"
(read-write, unconditionally present), and a mechanism for userspace to
control the software part (i.e. userspace could tell rfkill-input to
stop doing anything and take control itself).
I'd suggest that nothing visible to userspace on the rfkill side go into
2.6.27 until it can be done right and it's clear what this whole
mechanism is supposed to do. I might even be talked into writing some
patches, because it would be kind of nice for all this stuff to work
right on my laptops.
If I'm missing something I need to make rfkill suddenly work on my
machine, please give me some hints, too :)
--Andy
On Mon, Jul 7, 2008 at 3:18 PM, Andrew Lutomirski <[email protected]> wrote:
> On Mon, Jul 7, 2008 at 2:47 PM, Andrew Lutomirski <[email protected]> wrote:
>> On Mon, Jul 7, 2008 at 12:56 PM, Henrique de Moraes Holschuh
>> <[email protected]> wrote:
>>> On Mon, 07 Jul 2008, Andy Lutomirski wrote:
>
> OK, got a "bug" for you. I'm not sure whether it's a bug in rfkill,
> rfkill-input, iwlwifi, thinkpad-acpi, or the way they all interact.
>
> If I press the button on the keyboard (the icon makes it look like
> wifi), then bluetooth is toggled on and off and nothing happens to
> wlan rfkill. This is fine with me.
Nevermind this part. It was some leftover cruft in Ubuntu Hardy's acpid.
>
> But if I toggle bluetooth off (killed and therefore not present in the
> system per thinkpad-acpi), then block wlan with the switch, then
> unblock wlan with the switch, then bluetooth turns back on. This only
> happens with rfkill-input loaded. I hope this isn't the intended
> behavior.
This still happens with rfkill-input, though.
--Andy