Sorry, it's flawed, this causes a skipped range near max_coord. (i.e. from (max_coord - (max_coord/stage_num)/2) to max_coord) Will need to investigate more. On 2012-04-26, at 13:17, Jean-François Dagenais wrote: > Using "end_stage - start_stage" yields "number of used stages -1". > This makes the divisor smaller, hence the dividend greater. > > So for example, with 8 (0..7) stages, and max_coord of 1024, the > algo should figure out that 1024 should be split in 8, so 8 slices > of 128. Instead, dividing by 7 will give bigger slices of 146. > > While adding these "slices", when stages 7 and 0 are weighted to > determine the abs_pos, a dead-zone appears where we are stuck at > max_coord because of the bigger "slices" and the if that follows: > "if abs_pos > max_coord, then abs_pos = max_coord" > > Hence this commit, which re-uses variable "stag_num" initialized with > the number of used stages. > > Signed-off-by: Jean-François Dagenais <jeff.dagenais@xxxxxxxxx> > --- > drivers/input/misc/ad714x.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/misc/ad714x.c b/drivers/input/misc/ad714x.c > index 2cf26e5..29f5d10 100644 > --- a/drivers/input/misc/ad714x.c > +++ b/drivers/input/misc/ad714x.c > @@ -477,8 +477,7 @@ static void ad714x_wheel_cal_abs_pos(struct ad714x_chip *ad714x, int idx) > ad714x->sensor_val[first_before] + > ad714x->sensor_val[first_after]; > > - sw->abs_pos = ((hw->max_coord / (hw->end_stage - hw->start_stage)) * > - a_param) / b_param; > + sw->abs_pos = ((hw->max_coord / stage_num) * a_param) / b_param; > > if (sw->abs_pos > hw->max_coord) > sw->abs_pos = hw->max_coord; > -- > 1.7.9 > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
