>>> @@ -467,6 +480,8 @@ static void elantech_set_input_params(struct psmouse >>> *psmouse) >>> break; >>> >>> case 2: >>> + __set_bit(BTN_TOOL_QUADTAP, dev->keybit); >>> + input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2, ETP_WMAX_V2, >>> 0, 0); >> Is there an appropriate signal-to-noise ratio for the width? How does the device >> handle fingers going away? Does it send one or several zero-width events? > What do you mean by SNR for the width? The minimal variation which is > significant for an actual change in the width of the finger? On my > hardware it was fairly precise, and a unit was stable as long as I kept > the finger pressed the same way. Yes, that was what I was thinking of. If there is a lot of variation, it makes sense to use the fuzz parameter to reduce the number of events emitted from the input core. > Actually at some low pressures I could > swear it detects my blood pulse ;-) It probably does - question is if that means the fuzz should be increased somewhat. :-) > That said, in all the measures the > values were between 13 and 55, but I put as min and max 0 and 64. I did > this because I'm not sure it's the same with every version of the > hardware (apparently some old versions of the hardware even just report > 0 all the time). It sounded more conservative this way. Is that the > right way? It sounds fine. The min and max are not exactly enforced by the input core, but having the theoretic scale helps a lot when setting up applications. > When you leave the last finger, the device sends one message with "0 > finger". However, as it is currently working, the driver then just sends > one "BTN_TOUCH 0", but not any change in the ABS_TOOL_WIDTH. According > to the input protocol, should it also sends in this case a > "ABS_TOOL_WIDTH 0"? It is fine with just BTN_TOUCH for the non-MT protocol. The reason I asked specifically about this is partly because the current defuzz mechanism might need to be extended for some special values, like zero for the width and pressure events. For example, rather than emit zero, the input core will emit anything between zero and the value of the fuzz parameter, upon receiving a zero value. Dmitry, this problem is very similar, but not identical to, the flat parameter used for joysticks. Is there or has there been any thought about a similar mechanism for the ABS events? 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
