Hi Matthew, > > actually I would prefer if we name this key KEY_RFKILL and not put the > > policy of ALL into the kernel. Since we wanna get rid of rfkill-input. > > That needs to be done in userspace and by users policy. If they wanna > > map that key to ALL then that is fine. If they just wanna toggle WiFi, > > then that is also fine. If the wanna have to popup some UI, that is also > > reasonable. > > My reasoning was that this conceptually maps to a key that controls all > of the radios in the system - whether a single press actually kills all > of them or not is kind of irrelevent (having the simple policy in > rfkill-input works fine for this, but userspace will obviously want > something more cunning). My concern with KEY_RFKILL is that it it's not > obvious that it refers to a specific type of key - ones that purely > control wifi should still be KEY_WLAN, for instance. actually if the key is clearly hardwired to WLAN, then it should not even show up as input event at all. This is one of the mis-concepts of the old RFKILL subsystem. No need to send an input event if the platform driver is going to rfkill that device anyway. If a key is clearly labeled as WLAN then it should emit only KEY_WLAN. And if it is just a generic key with some radio on it like FN-F5 on my ThinkPad, then it better just emits KEY_RFKILL and we let userspace (or rfkill-input do the policy). Remember that in the end it is just a key and whatever the user does with it is users policy. So in summary it is up to the platform driver to emit the proper key. For some it might be still KEY_WLAN, for other it might be KEY_RFKILL. Sounds fair? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
