On Fri, Sep 26, 2014 at 09:50:32AM -0400, Benjamin Tissoires wrote: > 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. OK, so should we then say that we will continue reporting binary hovering with ABS_MT_DISTANCE 0/1 and such devices must report resolution of 0; devices reporting wider ABS_MT_DISTANCE ranges should also report appropriate resolution, same as X/Y coordinates? Thanks. -- Dmitry -- 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
