After further investigation, the reason why triple tap works with the natty kernel and not the oneiric kernel is that has_touch in xserver-xorg-input-synaptics/src/eventcomm.c is set to false with the natty kernel (probably do to the lack of semi multi-touch data), so the active_touches code from patches 120 and 121 is skipped and the BTN_TOOL_TRIPLETAP data from the kernel is used instead.
With the oneiric kernel, double tap works correctly because the coordinate for each finger is reported separately, so active_touches is incremented once for each slot, but the elantech driver reports triple taps the same as single taps, so active_touches is only incremented once.
I don't really know how to fix this without possibly breaking something else.
As an aside, I did find a bug in detecting semi mt devices (unfortunately, it doesn't help at all). When initializing ecpriv->semi_mt in eventcomm.c, the code reads the props and then does:
proc & INPUT_PROP_SEMI_MT
to test if the device is a semi mt device. However, INPUT_PROP_SEMI_MT = 0x03, it specifies the bit position, not the bit itself, so something like:
proc & (1 << INPUT_PROP_SEMI_MT)
is probably needed here (or a suitable macro that does something similar).
After further investigation, the reason why triple tap works with the natty kernel and not the oneiric kernel is that has_touch in xserver- xorg-input- synaptics/ src/eventcomm. c is set to false with the natty kernel (probably do to the lack of semi multi-touch data), so the active_touches code from patches 120 and 121 is skipped and the BTN_TOOL_TRIPLETAP data from the kernel is used instead.
With the oneiric kernel, double tap works correctly because the coordinate for each finger is reported separately, so active_touches is incremented once for each slot, but the elantech driver reports triple taps the same as single taps, so active_touches is only incremented once.
I don't really know how to fix this without possibly breaking something else.
As an aside, I did find a bug in detecting semi mt devices (unfortunately, it doesn't help at all). When initializing ecpriv->semi_mt in eventcomm.c, the code reads the props and then does:
proc & INPUT_PROP_SEMI_MT
to test if the device is a semi mt device. However, INPUT_PROP_SEMI_MT = 0x03, it specifies the bit position, not the bit itself, so something like:
proc & (1 << INPUT_PROP_SEMI_MT)
is probably needed here (or a suitable macro that does something similar).