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

[Chris Bagwell]

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.

Anyways:

Reviewed-by: Chris Bagwell <chris at cnpbagwell.com>