On Sun, Nov 7, 2010 at 8:30 AM, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: >> 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. Sorry for the noise (hit a wrong key). There are two major differences between #1 and #3: 1. #3 does not report any ABS_XY data when both pen and touch data are received (#1 still sends pen ABS_X/Y); 2. #3 sends both pen and touch data as MT events when both types of data are received (#1 only sends pen data). Which option do you like? We could go with a simple option. But that would close the door to those feature rich applications. Ping Ping -- 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