On Fri, Jan 7, 2011 at 2:52 PM, Ping Cheng <[email protected]> wrote: > I'll explain the rationale behind the code inline. Let's see if that > helps or not. > > Ping > > On Fri, Jan 7, 2011 at 7:49 AM, Chris Bagwell <[email protected]> wrote: >> The following area of code in wcmCommon.c seems suspicious to me: >> >> if (!priv->oldProximity) >> priv->minPressure = filtered.pressure; >> else >> priv->minPressure = min(priv->minPressure, >> filtered.pressure); > > minPressure is the minum pressure we get from the tool. In theory, it > should be 0. However, after the tool used heavily, i.e., hard pressure > applied often, the tip would "register" an initial pressure (this > could be Andrew's case). This initial pressure needs to be considered > otherwise users don't get a click or press with the default threshold > set. The above code is to check for the smallest pressure we got so > far. > > >> /* normalize pressure to FILTER_PRESSURE_RES */ >> tmpP = (filtered.pressure - priv->minPressure) >> * FILTER_PRESSURE_RES; >> tmpP /= (common->wcmMaxZ - priv->minPressure); >> filtered.pressure = (int)tmpP;
This is the part I missed. Its filtered.pressure and not filtered->pressure. So its throw away values and doesn't last next cycle. I see why its no issue now. Thanks. > > This chunk is only to apply the formula in two steps instead of one. > The formula is: > > normP = (currentP - minP) * NOMP / (maxP - minP). > >> The whole block is in a feedback loop as best I can tell. The logic >> is invoked every time a package is received from HW; even if pressure >> does not change in the packet. So we can normalizing pressure values >> that have already been normalized which would explain it being scaled >> to high. > > The filtered.pressure in the first block was from the device. So, it > is raw. The filtered.pressure after the second block is normalized. > This value never goes back to the first block. So, there is no loop > back for filtered.pressure. The potential changing factor is only > minPressure. > >> Another concern is that in first tmpP statement, it acts like >> minPressure is un-normalized and in second tmpP statement, it acts >> like minPressure is already normalized. I would think that has some >> side affect on outcome as well. > > We do not normalize minPressure. minPressure is only used as a > parameter for normalization. > >> I see no pressure issues in my usage of Bamboo but perhaps its >> pressure range is same as FILTER_PRESSURE_RES and so hides problems. > > No, Bamboo has a pressure range of 0 - 511 (I think). > FILTER_PRESSURE_RES is 2048, which is at Intuos4 max. Good guess > though ;). > > Ping > ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
