Le 12/10/2010 03:38, Peter Hutterer a écrit :
On Mon, Oct 11, 2010 at 12:58:06PM +0200, Benjamin Tissoires wrote:Hi Peter,see my comments: Le 11/10/2010 01:33, Peter Hutterer a écrit :When one of the tools comes into proximity, queue up a proximity event and send it accordingly. Signed-off-by: Peter Hutterer<[email protected]> --- src/evdev.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- src/evdev.h | 4 ++- 2 files changed, 64 insertions(+), 2 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 9e1fb10..634c174 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -322,7 +322,18 @@ EvdevQueueButtonEvent(InputInfoPtr pInfo, int button, int value) pQueue->key = button; pQueue->val = value; } +} +void +EvdevQueueProximityEvent(InputInfoPtr pInfo, int value) +{ + EventQueuePtr pQueue; + if ((pQueue = EvdevNextInQueue(pInfo))) + { + pQueue->type = EV_QUEUE_PROXIMITY; + pQueue->key = 0; + pQueue->val = value; + } } /** @@ -459,6 +470,16 @@ EvdevProcessValuators(InputInfoPtr pInfo, int v[MAX_VALUATORS], int *num_v, } } +static void +EvdevProcessProximityEvent(InputInfoPtr pInfo, struct input_event *ev) +{ + EvdevPtr pEvdev = pInfo->private; + + pEvdev->prox = 1; + + EvdevQueueProximityEvent(pInfo, ev->value); +} + /** * Take a button input event and process it accordingly. */ @@ -583,6 +604,7 @@ EvdevProcessKeyEvent(InputInfoPtr pInfo, struct input_event *ev) return; switch (ev->code) { + /* keep this list in sync with InitProximityClassDeviceStruct */ case BTN_TOOL_PEN: case BTN_TOOL_RUBBER: case BTN_TOOL_BRUSH: @@ -591,7 +613,7 @@ EvdevProcessKeyEvent(InputInfoPtr pInfo, struct input_event *ev) case BTN_TOOL_FINGER: case BTN_TOOL_MOUSE: case BTN_TOOL_LENS: - pEvdev->proximity = value ? ev->code : 0; + EvdevProcessProximityEvent(pInfo, ev);You removed the pEvdev->proximity assignment, and you did not add it in EvdevProcessProximityEvent. Is it normal? Otherwise, pEvdev->proximity will still be 1 in the rest of the code (and the life of the device), and so the related tests do not need to exist.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.
Cheers, Benjamin
+ xf86PostProximityEventP(pInfo->dev, which, first_v, num_v, + v + first_v); + break; + } + } +} + /** * Post the queued key/button events. */ @@ -672,6 +715,8 @@ static void EvdevPostQueuedEvents(InputInfoPtr pInfo, int num_v, int first_v, xf86PostButtonEvent(pInfo->dev, 0, pEvdev->queue[i].key, pEvdev->queue[i].val, 0, 0); break; + case EV_QUEUE_PROXIMITY: + break; } } } @@ -689,15 +734,19 @@ EvdevProcessSyncEvent(InputInfoPtr pInfo, struct input_event *ev) EvdevProcessValuators(pInfo, v,&num_v,&first_v); + EvdevPostProximityEvents(pInfo, TRUE, num_v, first_v, v); EvdevPostRelativeMotionEvents(pInfo, num_v, first_v, v); EvdevPostAbsoluteMotionEvents(pInfo, num_v, first_v, v); EvdevPostQueuedEvents(pInfo, num_v, first_v, v); + EvdevPostProximityEvents(pInfo, FALSE, num_v, first_v, v); memset(pEvdev->delta, 0, sizeof(pEvdev->delta)); memset(pEvdev->queue, 0, sizeof(pEvdev->queue)); pEvdev->num_queue = 0; pEvdev->abs = 0; pEvdev->rel = 0; + pEvdev->prox = 0; + } /** @@ -1226,6 +1275,17 @@ EvdevAddAbsClass(DeviceIntPtr device) free(atoms); + /* keep this list in sync with EvdevProcessKeyEvent */ + if (TestBit(BTN_TOOL_PEN, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_RUBBER, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_BRUSH, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_PENCIL, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_AIRBRUSH, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_FINGER, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_MOUSE, pEvdev->key_bitmask) || + TestBit(BTN_TOOL_LENS, pEvdev->key_bitmask)) + InitProximityClassDeviceStruct(device); + if (!InitPtrFeedbackClassDeviceStruct(device, EvdevPtrCtrlProc)) return !Success; diff --git a/src/evdev.h b/src/evdev.h index b382670..08f3c13 100644 --- a/src/evdev.h +++ b/src/evdev.h @@ -109,6 +109,7 @@ typedef struct { enum { EV_QUEUE_KEY, /* xf86PostKeyboardEvent() */ EV_QUEUE_BTN, /* xf86PostButtonEvent() */ + EV_QUEUE_PROXIMITY, /* xf86PostProximityEvent() */ } type; int key; /* May be either a key code or button number. */ int val; /* State of the key/button; pressed or released. */ @@ -131,7 +132,7 @@ typedef struct { BOOL invert_y; int delta[REL_CNT]; - unsigned int abs, rel; + unsigned int abs, rel, prox; /* XKB stuff has to be per-device rather than per-driver */ #if GET_ABI_MAJOR(ABI_XINPUT_VERSION)< 5 @@ -198,6 +199,7 @@ typedef struct { /* Event posting functions */ void EvdevQueueKbdEvent(InputInfoPtr pInfo, struct input_event *ev, int value); void EvdevQueueButtonEvent(InputInfoPtr pInfo, int button, int value); +void EvdevQueueProximityEvent(InputInfoPtr pInfo, int value); void EvdevPostButtonEvent(InputInfoPtr pInfo, int button, int value); void EvdevQueueButtonClicks(InputInfoPtr pInfo, int button, int count); void EvdevPostRelativeMotionEvents(InputInfoPtr pInfo, int num_v, int first_v,Cheers, Peter
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
