[PATCH evdev 3/3] Add use_proximity bit for BTN_TOOL handling.

[Peter Hutterer]

On Mon, Dec 20, 2010 at 09:41:32PM -0600, Chris Bagwell wrote:
> On Mon, Dec 20, 2010 at 9:28 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Mon, 20 Dec 2010 20:38:30 -0600, Chris Bagwell <chris at cnpbagwell.com> wrote:
> >> I ack on patch concept.  Its easy to see this invalid data on
> >> synaptics hardware and needs to be accounted for.
> >>
> >> I'm not up on current proximity support in evdev but patch makes sense
> >> overall.  Just two comments to consider.
> >>
> >> 1) Will BTN_TOUCH always be sent when you need it to?  I'm wondering
> >> if an if() is needed at BTN_TOOL_FINGER to prevent in_proximity from
> >> being set in first place.  The below is needed to re-turn it back on.
> >
> > not sure I fully understood the question, but:
> > in_proximity is set to 1 by default intentionally (there's a comment in
> > the code but it's cut off by the context). it's so that proximity is
> > always set for those devices that don't report proximity. this way we
> > ensure that data coming from the device is posted.
> 
> What I meant is that touchpad starts out at BTN_TOOL_FINGER=0 and
> BTN_TOUCH=0.  Lets say user is hovering slightly so X/Y values are
> sent but not enough to send BTN_TOUCH=1.
> 
> Since BTN_TOUCH=0 when driver started, you'll never get event to
> trigger in_proximity=0 setting, right?  Maybe this is only an issue on
> device start up.
>
> If I recall correctly, most these invalid events occur when going from
> touch to no touch.  So probably what I'm worrying about is not an
> issue in the wild.

yeah, you're right. this bug is probably there but I doubt that it's a
problem. This bug has been in evdev 2.5 and no-one seems to have noticed.
The only reason why Dave found it is because he didn't have the synaptics
driver installed and evdev ended up dealing with the touchpad.
 
> Reviewed-by: Chris Bagwell <chris at cnpbagwell.com>

thanks
 
Cheers,
  Peter