Ping Cheng wrote: > On Fri, May 21, 2010 at 10:49 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: >> Dmitry Torokhov wrote: >>> 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. >>> >> Yes. It is true that slot control is MT related, but I am looking at this from >> the perspective of future expansions like KEY_MT, KEY_REL, and such, finding a >> way to signal to user space which events are handled via slots. If we had >> ABS_MT_SLOT, we would most likely get applications which store ABS_MT_SLOT as an >> attribute of the slot together with ABS_MT_POSITION_X, ABS_MT_TOUCH_MAJOR, etc, >> which is just not right. > > Why is it not right? Do you mean ABS_SLOT can be used as a label for > both _MT_ and non _MT_ events while ABS_MT_SLOT can not? > >> So the proposal is ABS_SLOT. > > I haven't convinced myself with this proposal yet. Can you explain the > difference between ABS_SLOT and ABS_MT_SLOT with a concrete example? > Fool always ignores Mark Twain's advice, you know :). Ah. :-) At this point, we seem to be discussing which solution is the least evil. To recapitulate, the slot event should be neither an ABS event, nor an ABS_MT event, but a SYN event as proposed earlier. In my view, the real solution is to add the possibility to report usage and value range of SYN events to EVIO. To move the slot event from SYN to ABS was an act of compromise, and we now face this immaterial question. In another thread regarding these patches, I have held a monologue regarding the problem of knowing which events should be treated on a per-slot basis, and which should be treated "the usual way". Currently, events matching *_MT_* are the ones treated as slot events. One can imagine having better ways to deal with this, but we do not, currently. And this is where the difference between "ABS_SLOT" and "ABS_MT_SLOT" comes in. Henrik -- 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
