[PATCH evdev 2/3] Add proximity support.

[Peter Hutterer]

On Tue, Oct 12, 2010 at 09:25:28AM +0200, Benjamin Tissoires wrote:
> >urgh, yes. that was a bad commit split, if you squash this patch and the
> >next one it makes more sense.
> >
> >>>              break;
> >>>
> >>>          case BTN_TOUCH:
> >>>@@ -645,6 +667,27 @@ EvdevPostAbsoluteMotionEvents(InputInfoPtr pInfo, int num_v, int first_v,
> >>>      }
> >>>  }
> >>>
> >>>+static void
> >>>+EvdevPostProximityEvents(InputInfoPtr pInfo, int which, int num_v, int first_v,
> >>>+                                  int v[MAX_VALUATORS])
> >>>+{
> >>>+    int i;
> >>>+    EvdevPtr pEvdev = pInfo->private;
> >>>+
> >>>+    for (i = 0; pEvdev->prox&&   i<   pEvdev->num_queue; i++) {
> >>>+        switch (pEvdev->queue[i].type) {
> >>>+            case EV_QUEUE_KEY:
> >>>+            case EV_QUEUE_BTN:
> >>>+                break;
> >>>+            case EV_QUEUE_PROXIMITY:
> >>>+                if (pEvdev->queue[i].val == which)
> >>
> >>You call EvdevPostProximityEvents with only TRUE and FALSE. However,
> >>.val can have BTN_TOOL_PEN..BTN_TOOL_LENS isn't it? These value will
> >>not ever be send...
> >
> >no, that was the old code but it was rather pointless since we didn't use it
> >for checks or anything. with this code, val is value, thus 0 or 1.
> >
> >Cheers,
> >   Peter
> 
> oups, sorry...
> 
> BTW, I did not found that the patch set transfers the tool type to
> the client. Thus Gimp and others will not now them (if it's a
> rubber, an airbrush, etc)? It is maybe a lack in the protocol, but I
> know we use this field in our applications.

IIRC, evdev has never forwarded this value.
this is partly historical. the only device supporting multiple tools was
wacom and it split up the tools into separate X devices (which IMO is a good
idea and I'm sort-of working on evdev doing the same).

Cheers,
  Peter