On Sunday 13 April 2008, Henrique de Moraes Holschuh wrote:
quoted text
> On Sat, 12 Apr 2008, Inaky Perez-Gonzalez wrote:
> > Most rfkill hw keys are attached to the device. So I can plug wifi, wimax,
> > 3G, UWB and BT dongles (or cards) into a system and they each provide a HW
> > switch (or should provide).
> > 
> > If each overrides another one, we have a problem.
> 
> Yeah, and we have to avoid such problems.
> 
> But let me ask you one thing.  Are we talking of different rfkill
> switches, OR are we talking about different KEYs or BUTTONS in the
> keyboard/keypad/console/remote control?
> 
> Because one thing has very little to do with the other.  No network
> device driver shall generate an input event after I am done with the
> next patch set...

Not sure if that will be the desired course of action.
The original rfkill function didn't work with input devices either and just
handled everything in rfkill.
But the input layer people requested the change to use input devices and let
rfkill hook into that, because a rfkill switch/key can be considered an input device.

I've CC'ed Dmitry into this discussion since he was the one who suggested the
input device interaction initialy (and created the rfkill-input module).

quoted text
> On the other hand, if you DO have a WiMax, 3G, or EDGE *key* or
> *button*, THEN you need a KEY_WIMAX, KEY_3G, KEY_EDGE, or whatever. Even
> if there was no rfkill class in existence :-) and that's only if you
> would find more than one of them in a keyboard/console/remote
> control/keypad, otherwise KEY_WWAN would be enough.  Adding input events
> is *expensive*.
> 
> The same idea is also true for switches, which must use EV_SW SW_* and
> NEVER try to simulate a switch using KEY_* or BUTTON_*.
> 
> So, we CAN keep RFKILL_TYPE_WIMAX, and this is decoupled to keeping
> KEY_WIMAX.  These are two different decisions, and are not related to
> each other in any way.
> 
> Do we *have* devices with WiMAX keys or buttons that ALSO have non-WiMAX
> WWAN keys or buttons [that support Linux]?  If so, you need KEY_WIMAX
> events (and/or BUTTON_WIMAX, depends on the type of event being
> generated).  This has nothing to do with rfkill.   The same question and
> rationale applies to devices with switches (i.e. stuff that latches to a
> state), and SW_* events.
> 
> Is it a good idea to have WiMAX as a separate type for rfkill switches?
> Probably.  I'd actually say we should have a two-tier approach:
> 
> 1. switch class:
>    WLAN - (wifi stuff and whatever else looks like a WLAN)
>    WWAN - (3G, WiMAX, etch)
>    personal devices (or whatever the right name for this is): UWB, Bluetooth
>    ALL/ANY - "all radios" button/switches/etc
> 
> 2. switch type:
>    802.11abgn(WiFi), 802.16(WiMAX), EDGE/UMTS/X-RTT(Cell), UWB,
>    BLUETOOTH, ANY...  this can certainly be granular to the technology
>    level.
> 
> That would make it easier for rfkill-input to decide on what switches it
> should operate when it gets an specific input event.  We would make it
> operate on all WWAN-class rf switches for KEY_WWAN (and that would
> include WiMAX), and we could make it operate on all switches of a
> specific type, e.g. only bluetooth (and not bluetooth+UWB) for
> KEY_BLUETOOTH.
> 
> > I guess before I didn't have it as clear as I do now, but I am just seeing
> > more and more that each radio has its own kill switch and then the system
> > might have a generic one (for example fn+F5 on thinkpads) for killing all
> > of them at the same time.
> 
> Exactly, and we have to enhance rfkill to address that model properly.
> 
> My current idea of how it could work is:
> 
> 1. "Master" switches: those who are to control an entire class of radios
> (i.e. all devices of the same type), or all radios (type "any").  The
> most typical example is a RO rfkill switch in a laptop or gadget, and
> buttons and hot-keys in laptops or gadgets.  Master switches may issue
> input events when needed (it usually is).
> 
> 2. "slave" switches: this is what you usually have on the chipsets and
> their drivers (typically, two of them: a hardware one driven by an input
> pin in the hardware that the driver can *read* (i.e. it is read-only),
> and a software one in the driver code, which is read-write).  They
> *never* issue input events.
> 
> The big bad thing we need to always keep in mind is that that input pin
> in a radio chipset that is exported as a read-only rfkill switch might
> be a slave in one gadget/platform, and a master in another
> gadget/plaftform.  Let userspace or a platform/gadget-specific platform
> driver configure this.  Place all glue related to this in the rfkill
> class.
> 


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/