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
