> > The device seems to send finger changes sequentually, resulting in one > > packet (terminated with input sync) for each finger change. Is this > > the intention/necessary? Some egalax firmware (hid version) seems to > > work this way. > > When I make v2 patch, I've a look the Protocol B's driver in upstream, > but there were two type of multi-point report fashion, > One type is report all the finger status in one input sync(), and > separate each mt point with mt_input_slot(), like wocom driver. > > But there was some driver (like egalax hid version), send each mt > point with one input_sync(), but I'm worry about if main stream user > space frameworks(xorg mtouch etc,) support this behavior well. Sequential reporting works reasonably well, although there are potential problems (applying methods for smooth motion, for instance). Wakeups and cpu intensity also increases. > What's your point of view about this ? If possible, I think batched reporting is preferred, i.e., using the same method as all hid drivers _but_ the egalax one. > > The usage of REPORT_MODE_* is unclear to me too. > > In the programming manual this mode 's name is "single touch mouse > mode", may be it will be a better name for this mode ? Ok, sounds like the equivalent of the hid generic mouse, which could either be ignored or assigned its own input device node. Nothing out of the ordinary, in other words, and the patch looks good in this respect. Thanks for clarifying. 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
