On 10/10/07, Michael Buesch <mb@xxxxxxxxx> wrote: > On Wednesday 10 October 2007 16:51:38 Dmitry Torokhov wrote: > > > > I don't think that broadcom driver should depend on RFKILL_INPUT... > > > > RFKILL_INPUT is a default link between input and rfkill layers but it > > > > is by no means a mandatory component. > > > > > > > > I think proper dependency should be: > > > > > > > > depends on B43 && RFKILL && INPUT > > > > select INPUT_POLLDEV > > > > > > > > > > b43 rfkill support is useless without also having RFKILL_INPUT, as > > > the button reporting is done though it. > > > b43 does _not_ depend on RFKILL_INPUT, but b43-rfkill support is disabled, > > > if there's no RFKILL_INPUT compiled. > > > > > > > No, it is not. One can have a userspace daemon claiming the rfkill > > switch... > > No, that's impossible with b43. > Ah, OK. I see that you added "user_claim_unsupported" to rfkill and just rely on rfkill-input to update internal state of rfkill. I don't think it is a good solution - userspace may issue EVIOCGRAB on corresponding evdev node which will cause rfkill-input to miss all events. It looks like we need to allow rfkill-implementing drivers that do not allow software control their RF state to change rfkill state directly. -- Dmitry - 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
