Hello On 7 November 2010 17:30, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > Hi, > > On Fri, Nov 05, 2010 at 11:47:28AM -0700, Ping Cheng 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]? > >> 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. > 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. > This is horrible. If I understand this correctly if you use #1 then you can never get events from both pen and touch. If you use #3 then devices would suddenly start to send completely different events depending on state of *other* devices, like if you are moving cursor with the pen and touch the pad with your hand you create a) MT even with pen and finger which does not make sense at all b) out of prox for the ABS device and effectively lose input for non-MT clients I think that there should be either #1 or separate devices for pen and touch both with their own ABS events. In no event should devices report different events at random, decoding that from the client side would be a nightmare. Thanks Michal -- 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