On Wed, 05 Jul 2006, Johannes Berg wrote: > > Also, there's a small issue with polling frequency. hdapsd needs a > > fairly high frequency (say, 50Hz) to gather statistics and keep > > response latency low, whereas the hdaps driver's internal polling > > (routing to the input infrastructure) is currently done at only 20Hz. > > We'll need to increase the latter, thereby slightly increasing system > > load when hdaps isn't running. > > Note that with AMS we're better off -- it has two interrupts telling us > when something is wrong. > > Hence, most of the discussion about loads of input values only applies > to hdaps, the actual head-park functionality can be implemented with AMS > without ever reading any sensor values. > > Hence we also need much less complexity in userland -- once an interrupt > comes in we trigger the hd park... Looks nice. For AMS, then, the userspace daemon can choose between deciding for itself when to park heads using accel data, or to trust the firmware and do it when told, or even to do both. IBM *could* have done the same, since they already have an H8 microcontroller looking at that accelerometer :( Anyway, IMHO it would be good to have AMS-like behaviour where the kernel driver exposes head-park events to userspace in the generic interface. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
