On Wed, Sep 24, 2014 at 1:28 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: >>>> FWIW, hid-multitouch already support those devices. >>>> ABS_MT_DISTANCE is set with a min/max of 0/1 when we detect win8 >>>> certified panels with hovering capability. By default the spec does not >>>> provide the distance IIRC, and you only have one byte: InRange. >>> >>> Hmm, I missed that and this is unfortunate. The ABS capabilities >>> advertised by the devices should match their real capabilities. If >>> device can't properly report distance it should not be using >>> ABS_MT_DISTANCE/ABS_DISTANCE... >> >> I think the hid-mt behaviour makes sense. Without explicit resolution (and >> no device sets that anyway, IIRC) any distance value > min tells us only that a >> tool is within detectable range, but not yet touching. Anything between >> min/max is only useful as a relative scale, but effectively that [min,max] >> range could be a metre or a millimeter, we can't know. So a device with a >> 0/1 range simply has low granularity and is only able to detect whether >> something is within range or touching the surface. > > I agree with this, but I also share Dmitry's concern. > > A device that can detect hovering, if only binary, does in fact coarsely > estimate the distance from the touching surface. A device allowing for a smooth > approach of objects would simply support a better resolution. From that > perspective, using the ABS_MT_DISTANCE capability makes sense. Pragmatically. I agree. > > However, at no point are we really changing the coordinate system, which remains > euclidian space. We are simply changing resolution and thresholds for what > constitues a touch. Forcing userland to step away from the simple interpretation > is what eventually makes the capability impossible to use as intended. I think you are missing a point here. My maths are a little bit rusty, but if euclidian space there is, the space is *not* normalized. Peter remembered me the other day that the touchpad found on the Lenovo x220 has a x resolution of 75 and a y resolution of 129. So every sane library/driver/tool has to take the individual resolution into account if they want to provide accurate results. Given that libinput, xorg-evdev and xorg-synaptics all take this into account, then it is safe to say that they can simply consider that a resolution of 0 is simply absolute and a binary explanation fits well (was it 1 mm, 1 cm, 1 inch or 1 meter). > > So, if we cannot express, using the abs_info data, something like "contains a > detector which can coarsely estimate the distance and then uses a detector > threshold to set that distance to zero or one", we had better express it in some > other way, which is less ambiguous. IMO, your sentence is already ambiguous enough :-) Seriously, I think that we should not worry too much about the binary ABS_MT_DISTANCE: Think about the wacom pens: they report hovering and distance, but I don't think any application uses the absolute distance to change the behavior. The user can not maintain a constant distance with the tip of the finger or the stylus from the surface, so most of the time the value is ignored while the hovering matters. A binary ABS_MT_DISTANCE is enough to send this info to the driver, and then, the driver can decide to transfer it or not to its clients. > > How about ABS_MT_PRESENT and/or ABS_PRESENT? It would complement TOUCH in the > case of hovering, allow the state where the tool is there but not touching, and > would unambiguously advertise the capability of detecting presence. It would > also be forward compatible with additional capabilities, such as reporting the > actual distance to the surface. I don't think adding such a new axis is a good idea. We do *not* have a per slot MT_TOUCH. We only have the tracking id which says that the slot is *valid*. Then, the spec already explains how can the device convey the hovering information: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/input/multi-touch-protocol.txt#n259 "ABS_MT_DISTANCE: The distance, in surface units, between the contact and the surface. Zero distance means the contact is touching the surface. A positive number means the contact is hovering above the surface." The problem here is the "surface units", but given that the units on each axes depends on the per axis resolution, a resolution of 0 says that the units are undefined, and that the client should use only the last part of the definition: zero = touch, >0 = hovering. my 2 cents. Benjamin -- 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
