On Fri, May 21, 2010 at 07:29:39PM +0200, Henrik Rydberg wrote: > Dmitry Torokhov wrote: > > On Fri, May 21, 2010 at 06:56:35PM +0200, Henrik Rydberg wrote: > >> Dmitry Torokhov wrote: > >>> On Friday 21 May 2010 09:36:03 am Henrik Rydberg wrote: > >>>> Ping Cheng wrote: > >>>>> Hi Henrik, > >>>>> > >>>>> Thank you for your quick turnaround. Two minor comments in line. > >>>>> > >>>>> Ping > >>>> Thanks for those, yes, both mistakes. Dmitry, in case you find these last > >>>> versions acceptable, perhaps one could change them manually: > >>>> > >>>> 1. Patch description: s/SYN_MT_SLOT/ABS_SLOT/ > >>> Not ABS_MT_SLOT? > >> I wrote an argument for ABS_SLOT in the first patch, in short there is a > >> namespace clash I would like to avoid. > >> > > > > Hm, I am not sure I follow that argument. While you are saying that slot > > is not an MT event it is certainly not an ST event either. I would even > > say that slot _is_ an MT event since it signals current "slot" or group > > of MT data to userspace. Am I missing something? > > > > It is really a SYN or control event, since it sets which slot is currently being > updated. However, as argued earlier in this thread, since the presence and value > range of the slot variable is needed in user space, converting it to an ABS > event makes sense. But ABS_SLOT is not a property of the slot, and is thus not > an MT event in that respect. Currently, all ABS_MT events are either bypassing > filtering altogether, or (with these patches) being routed via a slot. The > naming convention ABS_MT is the only clue to user space that this is event will > appear once per slot. I think it should remain that way. > I guess this is where our disconnect lies as when I am looking at the event names I view all *_MT_* events as related to the multitouch protocol handling. -- Dmitry -- 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
