>> + report->field[0]->value[2] = 1; /* if this field is 0, then pressure >> + buttons won't be reported as digital button presses any more */ Hi all, I may have missed earlier conversations around this subject, but is this something we really want? I mean if a pressure sensitive button reports both digital and analogue values at the HID level, shouldn't we pass both onto userland. Many games and applications may be coded to only see one or the other, and break with usage of a controller which masks one or the other. As an example SpeedDreams (racing car simulator) has configurable inputs which sense what is pressed during the calibration process. It prefers to use buttons for simple things (ie. turn lights on/off) and axis for 'analogue' things (ie brake/accel). Until recently these functions could not be mixed; If a controller presents all it's buttons as axis (and not additionally as buttons) then none of them would have been usable in game. SpeedDreams recently 'learnt' to treat axis for button functions, but requires an additional calibration stage to determine which range of axis value represents a simple control. This schema is not (/can not be) perfect, and has some issues. In the case where a controller is both a button and axis it can choose which to use for the control, depending on the control.... please don't take than away from it/me... :-) In summary - please don't mask buttons where axis are also available, it will break many user land applications. Simon. -- 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