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
