Hi Emmanuel, >> if we have WiFi chips that have these kind of information, then shouldn't it >> be better exposed via a generic subsystem for motion events. Having this >> exposed over nl80211 seems a bit too limited. >> >> I am thinking that either an input event or maybe via hwmon or IIO. Since at >> the end of the day such an event should be considered just a sensor. It >> doesn't matter which piece of hardware is doing the sensing or who it is >> doing for. >> >> We are also not exposing RFKILL switches over nl80211. We have a dedicated >> RFKILL subsystem where all kinds of switches can integrate into. >> > > I can't sayI totally disagree, but the point here I guess is that the > precision is very limited - WiFi based after all - and hence, I don't > think we really want to expose a real motion detection device to the > whole system. This is not a gyro or anything of this kind. The commit > message gives example of use cases where the flows that are triggered > by this kind of notifications. The user aren't aware of these flows. > The frequency of the scan isn't something the user is aware of but > more a WiFi system parameter. So basically, I don't think we can > really talk about a real sensor, but more of a heuristic that will > likely help WiFi to behave better. Might there be other components > interested in this heuristic with its level of (im)precision, good > question.
even if the precision is limited, I think exposing this in a generic way (maybe just an input event) is a lot cleaner. So what if you want to have Bluetooth LE background scanning also use this to adjust the scan intervals. Or when to spin up the GPS to get a more precise location. There might be other subsystems that can benefit from these notifications and it makes no sense for them to talk nl80211. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
