On Tue, Apr 13, 2010 at 10:39:44AM +0200, Benjamin Tissoires wrote: > > > Le 09/04/2010 07:44, Peter Hutterer a écrit : > >On Sun, Mar 28, 2010 at 01:58:12PM +0200, Benjamin Tissoires wrote: > >>In case the driver receive a mt event, it stores it at the first > >>available place, i.e. it does not overrides older mt values. > >> > >>At the end, in the EV_SYNC event, it only send the values it has > >>filled. > >> > >>Signed-off-by: Benjamin Tissoires<[email protected]> > >>--- > >> src/evdev.c | 31 ++++++++++++++++++++++++++++--- > >> src/evdev.h | 1 + > >> 2 files changed, 29 insertions(+), 3 deletions(-) > >> > >>diff --git a/src/evdev.c b/src/evdev.c > >>index 7e59601..76af8dc 100644 > >>--- a/src/evdev.c > >>+++ b/src/evdev.c > >>@@ -422,6 +422,8 @@ EvdevProcessValuators(InputInfoPtr pInfo, int > >>v[MAX_VALUATORS], int *num_v, > >> */ > >> else if (pEvdev->abs&& pEvdev->tool) { > >> memcpy(v, pEvdev->vals, sizeof(int) * pEvdev->num_vals); > >>+ if (pEvdev->current_num_multitouch> EVDEV_MAX_TOUCHPOINTS) > >>+ pEvdev->current_num_multitouch = EVDEV_MAX_TOUCHPOINTS; > > > >do I understand this correctly that if you get 6 touchpoints the last one > >overwrites touchpoint 5? is this preferable to just dropping them once they > >overflow? > > not exactly. What you propose is already occurring: this assignment > is made in the function EvdevProcessValuators which is called at the > end of the frame (on an EV_SYNC event). > When mt-values are coming, the EvdevProcessAbsoluteMotionEvent > function is called and this function drops them if > current_num_multitouch > EVDEV_MAX_TOUCHPOINTS. > > I had to clamp current_num_multitouch at the end as I rely on it to > know how many valuators do I need to send
ah, I see. that confusion was caused by the variable naming, I'd really prefer a different variable name. Thanks for clarifying this. Cheers, Peter > >also, can we rename current_num_multitouch to mt_current_touchpoint? > >otherwise this may get confused with the number of touchpoints supported by > >the device. > > ack. > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
