Hi Benjamin, > > Why [-1,1] here? > > At first, I only used [0,1]. However, it's still the same problem with > the information being kept between the touches: > if you start an application after having touched your device, you > normally have to ask for the different per-touche states to get x, y, > distance, pressure, etc... > However, this is not much mandatory because the protocol in its > current form ensures that you will get the new states of the axes when > a new touch occurs. Right, the stateful communication requires a full state read after opening the deivce, although in most cases this is not really necessary. This is no different for ABS_MT_DISTANCE, of course. > ABS_MT_DISTANCE is a little bit different here because the protocol > guarantees that once you get the "not in range" state through > tracking_id == -1, distance should be 1. > When the new touch of the very same slot occurs, you also have the > guarantee that distance is at 1 too. ABS_MT_DISTANCE is just another attribute of the slot, so it really is no different. > So basically, if you don't ask for the slot states, you will never get > that very first distance. Which will not be important either; as long as the slot is unused, it does not matter what the attributes of that slot are. > I know that it's a user-space problem, but honestly, I don't want to > fix several user-space problems when we could fix it through the > protocol. > > I can see 2 solutions: > - set the range to: [0,1] and still sending -1 (or 2) for the invalid > distance value (if it's not clamped) > - set the range to: [0,2] and having: 0 for touch, 1 for hovering, and > 2 for not in range > > Does that make sense? I just do not see what problem you want to solve here. Thanks, 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
