Re: Hardware button support for Wireless cards
On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote: Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Distributions will need to accommodate to the way d80211 stack works anyway, so I see no problem with this. B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Voting for this. It brings more flexibility. This is not a problem of your card only. Is there a standard ACPI rf-kill event? Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Monday 15 May 2006 15:25, Jiri Benc wrote: On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote: Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Distributions will need to accommodate to the way d80211 stack works anyway, so I see no problem with this. B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Voting for this. It brings more flexibility. This is not a problem of your card only. Is there a standard ACPI rf-kill event? Not sure actually. the approach rt2x00 takes is sending an event ACPI_TYPE_EVENT with as argument a 0 or 1 depending on the new state of the button. But I don't know if there is another event that would be more suitable for a hardware button. pgp49L2gsD2N8.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
On Mon, 15 May 2006 22:57:12 +1000 Mark Wallis wrote: What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Using ACPI events for this purpose seems wrong: - ACPI is not available on all architectures supported by Linux, therefore it cannot be an universal solution; - even if ACPI is available, it may be turned off for some reason. In fact, many people consider the separate /proc/acpi/event interface for ACPI events to be a mistake, and there is some movement to make ACPI use the input layer instead: http://lkml.org/lkml/2006/4/19/275 There is even a KEY_RADIO defined in linux/input.h (however, it was probably intended to be used for a remote control key, like TV/VCR/CD/Tape/... defined near it, so I'm not sure whether it would be the proper event to use here). pgpSYqPPUc94E.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote: Hi everyone, Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. (had this issue in the back of my head for a while already...) Isn't the rf-kill switch specific to the manufacturer lots of times? Is the switch connected directly to the card, or is it incumbent on the driver to notice the event and disable the card via software? We need to handle this for Bluetooth too, in situations where there's both a bluetooth and an 802.11 card in the box. Does the rf-kill apply to both? Or just to one? WRT to disabling the radio, I'm not sure it makes a difference either way. Hitting a button generally means do this _NOW_, so it makes sense for the driver to disable the radio and then send out the event. Apps need to be able to deal with these resources going out from underneath them, and I'm not sure it makes sense to wait around for some scripts to run that just might possibly at some future point disable it, but you're never sure. In the end, an ACPI event is probably fine. I must stress that we NEED to have a common event structure for this, such that every driver and card presents the same interface. I don't want to have to write stuff for each of 3 or 4 different cards to notice the rf-kill stuff. Witness all the extra binaries that each driver has already for this sort of thing. What interface does the ipw[2|3]xxx driver and hardware present? What common bits can be drawn out from both? Ideally, here's what would happen: the driver/card/whatever generates an ACPI event, which is noticed by HAL. HAL sets a property on the _exact_ device which the event is for, and propagates the signal out over dbus. Any interested application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Monday 15 May 2006 16:37, Dan Williams wrote: On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote: Hi everyone, Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. (had this issue in the back of my head for a while already...) Isn't the rf-kill switch specific to the manufacturer lots of times? Is the switch connected directly to the card, or is it incumbent on the driver to notice the event and disable the card via software? We need to handle this for Bluetooth too, in situations where there's both a bluetooth and an 802.11 card in the box. Does the rf-kill apply to both? Or just to one? The rt2x00 device itself does nothing when the button is pressed, it only updates certain fields in a register to indicate the button is pressed. The driver should read from the EEPROM if a hardware button is available, after that it should poll the register to see if the button has been pressed, and it is up to the driver what to do. WRT to disabling the radio, I'm not sure it makes a difference either way. Hitting a button generally means do this _NOW_, so it makes sense for the driver to disable the radio and then send out the event. Apps need to be able to deal with these resources going out from underneath them, and I'm not sure it makes sense to wait around for some scripts to run that just might possibly at some future point disable it, but you're never sure. Well I would think it is cleaner to inform userspace that the button is pressed and let userspace sort out what exactly should happen. But I doubt it will be a good idea when the driver is sending and event _and_ disabled the radio. It could be that the user wants something to be done before the radio is being disabled. In the end, an ACPI event is probably fine. I must stress that we NEED to have a common event structure for this, such that every driver and card presents the same interface. I don't want to have to write stuff for each of 3 or 4 different cards to notice the rf-kill stuff. Witness all the extra binaries that each driver has already for this sort of thing. What interface does the ipw[2|3]xxx driver and hardware present? What common bits can be drawn out from both? Ideally, here's what would happen: the driver/card/whatever generates an ACPI event, which is noticed by HAL. HAL sets a property on the _exact_ device which the event is for, and propagates the signal out over dbus. Any interested application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) This idea sounds good, but is ACPI the thing to be used. Escpially since ACPI is a bit architectures dependent. And the solution should be supported on various architectures. But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) system-wide would not be a good idea, we need something to determine which driver exactly has triggered the event. Some laptops have several hardware buttons 1 for Bluetooth and 1 for Wifi for example. So we could just pass the name the driver has created for that button to userspace. At least that is a similar approach to ACPI where the class, bid and name fields are all names set by the driver. pgpdHFhb9PNpa.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
[EMAIL PROTECTED] said: Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. This is actually quite nice for testing roaming setups. You can roam in and out of range by toggling the button. The other laptop in the house has a physical _switch_, which implies that it too cuts off the radio in hardware (though I haven't investigated this, so I'm only speculating). So if there's any desire for consistency of wireless button support, then I think the software-controlled ones should always shut off the radio, and optionally inform userspace or the wireless stack using some event mechanism. What is the purpose of these switches anyway? Power saving? Or is it for situations like an airplane or hospital where you want to be sure your wireless won't cause any interference? If the latter, than that also argues for always shutting off the radio immediately. Jason - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Monday 15 May 2006 17:27, you wrote: [EMAIL PROTECTED] said: Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate some Radio is hardware-disabled state. We currently don't use that flag correctly in the driver. Could you please assist me on testing if your switch actually toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Mon, 2006-05-15 at 10:37 -0400, Dan Williams wrote: Ideally, here's what would happen: the driver/card/whatever generates an ACPI event, which is noticed by HAL. HAL sets a property on the _exact_ device which the event is for, and propagates the signal out over dbus. Any interested application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) Yes, I agree this needs to happen in user space partly because it's policy even though I can only come up with crack reasons on why you wouldn't want to turn off the radio when the button is pressed. However, I suppose we need to do it in user space for some laptops anyway since I'm not sure the RF Kill Switch button and the networking hardware may be related; see below. But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers Right, this would be nice. This is sorta like the mess that is hotkeys on laptops. We sorta deal with those in HAL but it's a lot of ugly code to present a sane abstract interface to user space. 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) No, I'm not really sure we need to know exactly what device this is triggered for and I'm not even sure that the kernel can figure this out anyway: the RF Kill buttons may be implemented as a USB HID device for example which may have little relation to the hardware. Another example is where the user is using a USB or PC Card Wifi adapter instead of the built-in Wifi. We want to turn off the radio on the USB or PC Card in these cases too. So what we need from user space is basically just an event saying RF Kill button pressed perhaps with some detail such as 'bluetooth' or 'wifi' depending on the graphics of the button (no, I'm not kidding). It would also be nice with some way to query state, e.g. is the button pressed or not if the hardware supports this. So, I think perhaps it may make sense to model this as an input device. Then we can simply query this input device from user space (in HAL) and emit the right events and provide an interface to query whether the button is pressed or not [1]. Specifically, on startup, NetworkManager would just ask HAL whether the button is pressed or not (if the hardware supports it) and do the right thing, e.g. selectively suspend all networking devices with a radio via the power/state file in sysfs which will turn off the radio. When the user presses the button, NetworkManager enables / disables the device [2] and so on. Hope this helps. David [1] : we do the same thing for other buttons in HAL; e.g. the power button on some Powerbooks. [2] : this raises another problem. What happens to class devices when a bus device is turned off (e.g. selective suspend). For example, does the class device /sys/class/net/eth0 go away when I put the physical to sleep via the /sys/class/net/eth0/device/power/state file? Maybe off topic, but what happens in general? For example what happens when I selectively suspend a USB harddisk enclosure, does /sys/block/sda go away? If it doesn't, does '# touch /dev/sda' wake it up? (it probably shouldn't)... This kind of stuff needs to be precisely defined, yes? Is it already defined? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Mon, 2006-05-15 at 18:01 +0200, Michael Buesch wrote: On Monday 15 May 2006 17:27, you wrote: [EMAIL PROTECTED] said: Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate some Radio is hardware-disabled state. We currently don't use that flag correctly in the driver. Could you please assist me on testing if your switch actually toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users When those bits get set in the register, is the radio already disabled? ie, for the bcm43xx chip, is it really force-disabled by the button, or does the driver have some control? Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Monday 15 May 2006 21:12, you wrote: There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate some Radio is hardware-disabled state. We currently don't use that flag correctly in the driver. Could you please assist me on testing if your switch actually toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users When those bits get set in the register, is the radio already disabled? ie, for the bcm43xx chip, is it really force-disabled by the button, or does the driver have some control? Hm, actually, We don't know what the bit means. Could be some completely different meaning. That is what I am trying to find out. But it seems to have something to do with the power control of the chip. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Mon, May 15, 2006 at 03:27:54PM +, Jason Lunz wrote: So if there's any desire for consistency of wireless button support, then I think the software-controlled ones should always shut off the radio, and optionally inform userspace or the wireless stack using some event mechanism. FWIW, I think this position makes the most sense... John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware button support for Wireless cards
On Monday 15 May 2006 21:46, Jason Lunz wrote: On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote: When those bits get set in the register, is the radio already disabled? ie, for the bcm43xx chip, is it really force-disabled by the button, or does the driver have some control? I assume it disables the radio without any help from the driver, because it definitely turns off my radio, but the bcm43xx driver i'm using (in 2.6.17-rc4) currently doesn't pay any attention to those registers afaik. Correct, my laptop with an integrated BCM43xx chip works this was as well. I can use the button to enable and disable the device (led is switching on and off) without a bcm43xx driver installed. Hardware detection just picks it up when I enable the device with the button as new device. So the hardware button works directly with the hardware. pgpfqFfVjvAF7.pgp Description: PGP signature
RE: Hardware button support for Wireless cards
On Tue, May 16, 2006, Jouni Malinen wrote: Some hardware designs disable the radio in hardware, some don't.. In other words, the behavior would not be consistent between hardware designs unless the radio would be disabled unconditionally in software-processed case. I would like to be able to trust on the rfkill to really kill the radio regardless of whether the user space mechanism is in place or not, i.e., I see this as a function that can be used to disable radio in environments were use of wireless devices is not allowed for some reason. Sending an event to user space would be a good additional indication that the radio was disabled. If user space wants to do something first, I would think that doing this with full software control (i.e., not depending on any particular hardware button and just having a UI mechanism for triggering this) would allow more consistent behavior. Sounds like this is the popular option - I agree that immediate radio-off is the safe way to go here as at least the driver can guarantee that the radio is disabled no matter the userspace config. Does someone want to put their hand up and specify the userspace interface here and now so we all keep to a standard ? Working as an input device as David suggested seems to give us the most flexibility. Regards, Mark Wallis E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
