[PATCH evdev 3/3] Add use_proximity bit for BTN_TOOL handling.
Peter Hutterer
peter.hutterer at who-t.net
Mon Dec 20 19:28:31 PST 2010
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.
> 2) Touchscreens have same concept. Until BTN_TOUCH, it would be
> safest to ignore the reported X/Y values. Of course, majority of
> touchscreens do not send BTN_TOOL_FINGER right now but that will
> change I think.
for most of the touchscreens, we have to go on a per-device
basis. so unless we start seeing touchscreens with this event stream,
I'd rather not worry about it because chances are that whatever we do,
there will be cornercases outside of it anyway. and the more complex we
try now, the harder it gets to fit those.
from the devices that I've seen, they either set BTN_TOOL_FINGER in the
same frame as BTN_TOUCH or they just don't have BTN_TOOL_FINGER
anyway. synaptics is a special case here because the data in between is
garbage, but for valid data it shouldn't matter.
Cheers,
Peter
>
> Chris
>
> On Mon, Dec 20, 2010 at 7:21 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > Touchpads send garbage data between BTN_TOOL_FINGER and BTN_TOUCH. This
> > leads to cursor movement towards invalid positions (bottom left corner,
> > usually).
> >
> > Add a new flag "use_proximity" as a delimiter for BTN_TOUCH handling. If
> > unset, the actual proximity bits are ignored, no proximity events are sent
> > and BTN_TOUCH is used for the tool handling.
> >
> > Example event stream for synaptics:
> >
> > Event: time 1292893041.002731, -------------- Report Sync ------------
> > Event: time 1292893041.015807, type 1 (Key), code 330 (Touch), value 0
> > Event: time 1292893041.015812, type 3 (Absolute), code 0 (X), value 4283
> > Event: time 1292893041.015813, type 3 (Absolute), code 1 (Y), value 4860
> > Event: time 1292893041.015815, type 3 (Absolute), code 24 (Pressure), value 23
> > Event: time 1292893041.015817, type 3 (Absolute), code 28 (Tool Width), value 5
> > Event: time 1292893041.027537, -------------- Report Sync ------------
> > Event: time 1292893041.038854, type 3 (Absolute), code 0 (X), value 1
> > Event: time 1292893041.038857, type 3 (Absolute), code 1 (Y), value 5855
> > Event: time 1292893041.038859, type 3 (Absolute), code 24 (Pressure), value 1
> > Event: time 1292893041.038861, type 3 (Absolute), code 28 (Tool Width), value 5
> > Event: time 1292893041.038864, -------------- Report Sync ------------
> > Event: time 1292893041.062432, type 3 (Absolute), code 24 (Pressure), value 0
> > Event: time 1292893041.062435, type 3 (Absolute), code 28 (Tool Width), value 0
> > Event: time 1292893041.062437, type 1 (Key), code 325 (ToolFinger), value 0
> > Event: time 1292893041.062438, -------------- Report Sync ------------
> >
> > Reported-by: Dave Airlie <airlied at redhat.com>
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> > src/evdev.c | 13 ++++++++++++-
> > src/evdev.h | 1 +
> > 2 files changed, 13 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/evdev.c b/src/evdev.c
> > index b6591ce..50847a8 100644
> > --- a/src/evdev.c
> > +++ b/src/evdev.c
> > @@ -486,6 +486,9 @@ EvdevProcessProximityEvent(InputInfoPtr pInfo, struct input_event *ev)
> > {
> > EvdevPtr pEvdev = pInfo->private;
> >
> > + if (!pEvdev->use_proximity)
> > + return;
> > +
> > pEvdev->prox_queued = 1;
> >
> > EvdevQueueProximityEvent(pInfo, ev->value);
> > @@ -679,7 +682,10 @@ EvdevProcessKeyEvent(InputInfoPtr pInfo, struct input_event *ev)
> >
> > switch (ev->code) {
> > case BTN_TOUCH:
> > - pEvdev->in_proximity = value ? ev->code : 0;
> > + /* For devices that have but don't use proximity, use
> > + * BTN_TOUCH as the proximity notifier */
> > + if (!pEvdev->use_proximity)
> > + pEvdev->in_proximity = value ? ev->code : 0;
> > if (!(pEvdev->flags & (EVDEV_TOUCHSCREEN | EVDEV_TABLET)))
> > break;
> > /* Treat BTN_TOUCH from devices that only have BTN_TOUCH as
> > @@ -1346,6 +1352,9 @@ EvdevAddAbsClass(DeviceIntPtr device)
> >
> > for (i = 0; i < ArrayLength(proximity_bits); i++)
> > {
> > + if (!pEvdev->use_proximity)
> > + break;
> > +
> > if (TestBit(proximity_bits[i], pEvdev->key_bitmask))
> > {
> > InitProximityClassDeviceStruct(device);
> > @@ -2039,6 +2048,7 @@ EvdevProbe(InputInfoPtr pInfo)
> > if (pEvdev->flags & EVDEV_TOUCHPAD) {
> > xf86Msg(X_INFO, "%s: Configuring as touchpad\n", pInfo->name);
> > pInfo->type_name = XI_TOUCHPAD;
> > + pEvdev->use_proximity = 0;
> > } else if (pEvdev->flags & EVDEV_TABLET) {
> > xf86Msg(X_INFO, "%s: Configuring as tablet\n", pInfo->name);
> > pInfo->type_name = XI_TABLET;
> > @@ -2205,6 +2215,7 @@ EvdevPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags)
> > * proximity will still report events.
> > */
> > pEvdev->in_proximity = 1;
> > + pEvdev->use_proximity = 1;
> >
> > /* Grabbing the event device stops in-kernel event forwarding. In other
> > words, it disables rfkill and the "Macintosh mouse button emulation".
> > diff --git a/src/evdev.h b/src/evdev.h
> > index b04f961..f640fdd 100644
> > --- a/src/evdev.h
> > +++ b/src/evdev.h
> > @@ -126,6 +126,7 @@ typedef struct {
> >
> > int flags;
> > int in_proximity; /* device in proximity */
> > + int use_proximity; /* using the proximity bit? */
> > int num_buttons; /* number of buttons */
> > BOOL swap_axes;
> > BOOL invert_x;
> > --
> > 1.7.3.4
> >
> > _______________________________________________
> > xorg-devel at lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
> >
>
More information about the xorg-devel
mailing list