On Monday 09 July 2007 01:29, Shem Multinymous wrote: > On 7/9/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > input-polldev uses a separate workqueue, not keventd, and so should not > > > > suffer from other workqueue users loading keventd. But if entire box > > > > is under stress then workqueue vs timer context does not matter much - > > > > your daemon which is in userspace may not get to run in a timely manner > > > > anyway. > > > > > > The daemon itself typically runs with a higher priority (and sleeps a > > > lot so it gets further dumped). More importantly, the daemon depends > > > not only on the latest measurement, but also on recent measurements > > > have been obtained from the hardware in a regular fashion and with > > > reasonably accurate timestamps. And *this* depends solely on the hdaps > > > driver. > > > > > > > Every input event carries a timestamp so even if there are irregularities > > in taking the samples you should be able to account for it. > > The issue is how good are the input event timestamps. The way it works > is that the EC samples the analog sensor at some fixed rate and makes > them available over the LPC bus. If the hdaps driver consumes these > samples at the same rate then the timestamps will be accurate up to a > small phase difference, which is mostly inconsequential. But if the > hdaps driver gets scheduled irregularly, its timestamps will be offset > by varying amounts, which will completely throw off computation (e.g., > think of estimating the angular velocity). >
Timers do not guarantee you that they will be fired at the exact time. If system is under load and there are hard IRQs they will also be delayed. > > > > > However I am open to bumping up priority of ipolldevd a little. > > > > > > Will this result in scheduling tha'ts as reliable as rearming timers > > > from softirq? I saw claims to the contrary, but it it's true then I > > > withdraw the first objection. > > > > Probably not. But I still think that if system is so busy that it can't > > get aroung to schedule one of workqueues it will not be able to part > > the driver fast enough anyway. > > A delay of 20ms in invoking the userspace daemon is negligible, but a > timing variance of 20ms in the driver's measurements is devastating. > Even if you know that there is such variance? > > > > > I am curious why you can't use the current device, since the calibration > > > > done in hdaps does not alter the scale but merely moves '0' point > > > > around. > > > > And fuzz should only remove small jitters, not rapidly changing data > > > > that you shoudl get when your box is falling. > > > > > > Recent versions of the hdapsd daemons do much more than a simple > > > threshold check: they gather some 2nd-order and decaying averages > > > statistics to catch subtle abnormal movement (e.g., sliding off a > > > surface) that's indicative of potential shock. As pointed out in IBM's > > > HDAPS whitepaper, by the time the box is actually in free fall, it's > > > too late to start parking the heads. Now, that kind of movement is not > > > very far from the noise floor, so hdapsd needs all the accuracy it can > > > get -- hence fuzzing is very disruptive. Calibration is currently > > > harmless, but I can certainly imagine more advanced hdapsd that uses > > > heuristics based, e.g., on the absolute orientation of the laptop, so > > > let's not ruin this data. > > > > If hdaps is the main consumer for the data it may be a good idea to > > just remove the fuzz setting from input device. I don't have the hardware, > > how bad is it without fuzz? > > People are using the existing input device as a joystick input for > things like Neverball. Current fuzz is 4 and the observed std dev is > roughly 2, so eliminating fuzz will certainly affect the values. The > implications are app-specific, but I guess some apps do care about > such noise, otherwise we wouldn't have fuzz built into the input > infrastructure. > OK. > > > > You could one input device open, or the other, or both. How would you > > > set up input-polldev to handle this? > > > > Have 2nd input device's ->open() method call input_open_device() for > > the first one. > > Won't that create an overhead by the redundant, unused notifications? > They won't leave input core so nothing really noticeable. > Shem > -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
