On Sun, Nov 7, 2010 at 8:30 AM, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: >> The existing solution for single touch events is to arbitrate touch >> when pen is in prox. This is based on the assumption that we do not >> want to have two cursors competing on the screen. > > What do you mean by 'arbitrate' here? I guess you're talking about which > events should send ABS_[XY]? It means ignoring touch data when pen is in prox. >> 1. Arbitrate all touch data in the kernel. >> >> This is the simplest solution for device driver developers. But I do >> not feel it is end user and userland client friendly. >> >> [...] >> >> 3. Report first finger touch as ABS_X/Y events when pen is not in prox; >> Report pen data as ABS_X/Y events when there is no finger touch; >> Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN >> events when both pen and touch data are received. No ABS_X/Y are >> reported when pen and tocuh or multi-touch data are received. >> >> I feel this one makes sense to userland since pen can be considered as >> another touch. > > I'd say that either #1 or #3 is the best idea here, simply because they > seem to be the most straightforward, and thus easier to support. There are two major difference between # > Assuming that xf86-input-wacom will track the state itself and decide > (using whatever criteria) which events should send core x/y motion, then > all you need to do with ABS_[XY] is just make a best effort to have it > more or less work for dumb userspace clients. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
