Re: How to indicate hover touch when exact distance unknown?

Re: How to indicate hover touch when exact distance unknown?

[Benjamin Tissoires]

Hi Andrew,

On Sep 23 2014 or thereabouts, Andrew de los Reyes wrote:
> Hi folks,
> 
> More and more we're seeing touch input devices that support detection of
> fingers that are above the surface and not touching. We were thinking of
> writing a kernel patch for one such device. Normally we would indicate
> distance with ABS_MT_DISTANCE, but we ran into the problem that sometimes
> the hardware will not be able to report a distance (or will stop reporting
> a distance when it's too great a number), and we had the (bad) idea to
> simply report a value or 1 or 255 or something like that when distance is
> unknown.

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.

I think Xorg can deal with that (the touch emulation discards the
ABS_MT_DISTANCE, but the xorg-evdev driver should be smart enough to not
take BTN_TOUCH into account).

> 
> Dmitry warned that a similar thing happened with PRESSURE a while ago, and
> it was a mess as different drivers did different things.

As I said, IIRC, xorg-evdev is fine with that. For generic desktop, we
have to make sure libinput is aware, and then you only have to handle
your own xorg chromebook driver. This is not something which scares me
that much, especially given that this is what hid-multitouch reports
since the v3.9 kernel.
libinput is based on a per slot device information, so it is really easy
to implement if it is not already in place. xorg-Synaptics and xorg-Wacom
should not be ported to wayland from what I understood, so the mess with
several implementations can be solved easily.

> 
> We are now wondering if we should come up with a standard way to indicate
> hover with or without distance (or with distance being optional). Dmitry
> had the idea for a new tool type, HOVER; FINGER would be for touches that
> are actually touching.

The tool is still the finger. So I am not very happy with having a new
tool. In the end, it may also disturb older clients which will not know
what to do with HOVER.
And the ABS_MT_DISTANCE approach used to be fully retro-compatible
(assuming that the hovering distance is small enough for the user not to
detect it).

> 
> What do folks here think?
> 

I made my point. Unfortunately, I never had in my hand such device, so
I can not guarantee this approach is the best.

Cheers,
Benjamin

Re: How to indicate hover touch when exact distance unknown?

[Dmitry Torokhov]

Hi Benjamin,

On Tue, Sep 23, 2014 at 10:59:16AM -0400, Benjamin Tissoires wrote:
> Hi Andrew,
> 
> On Sep 23 2014 or thereabouts, Andrew de los Reyes wrote:
> > Hi folks,
> > 
> > More and more we're seeing touch input devices that support detection of
> > fingers that are above the surface and not touching. We were thinking of
> > writing a kernel patch for one such device. Normally we would indicate
> > distance with ABS_MT_DISTANCE, but we ran into the problem that sometimes
> > the hardware will not be able to report a distance (or will stop reporting
> > a distance when it's too great a number), and we had the (bad) idea to
> > simply report a value or 1 or 255 or something like that when distance is
> > unknown.
> 
> 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 Xorg can deal with that (the touch emulation discards the
> ABS_MT_DISTANCE, but the xorg-evdev driver should be smart enough to not
> take BTN_TOUCH into account).
> 
> > 
> > Dmitry warned that a similar thing happened with PRESSURE a while ago, and
> > it was a mess as different drivers did different things.
> 
> As I said, IIRC, xorg-evdev is fine with that. For generic desktop, we
> have to make sure libinput is aware, and then you only have to handle
> your own xorg chromebook driver. This is not something which scares me
> that much, especially given that this is what hid-multitouch reports
> since the v3.9 kernel.
> libinput is based on a per slot device information, so it is really easy
> to implement if it is not already in place. xorg-Synaptics and xorg-Wacom
> should not be ported to wayland from what I understood, so the mess with
> several implementations can be solved easily.
> 
> > 
> > We are now wondering if we should come up with a standard way to indicate
> > hover with or without distance (or with distance being optional). Dmitry
> > had the idea for a new tool type, HOVER; FINGER would be for touches that
> > are actually touching.
> 
> The tool is still the finger.

Do we reliably know that it is a finger and not a pen or eraser or some
other tool? If we do then obviously introducing new tool will not fly.

> So I am not very happy with having a new
> tool. In the end, it may also disturb older clients which will not know
> what to do with HOVER.
> And the ABS_MT_DISTANCE approach used to be fully retro-compatible
> (assuming that the hovering distance is small enough for the user not to
> detect it).

Except that if we start getting devices that can actually tell the
distance we'd need special casing 0/1 handling, no?

Thanks.

-- 
Dmitry

Re: How to indicate hover touch when exact distance unknown?

[Andrew de los Reyes]

On Tue, Sep 23, 2014 at 9:28 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Benjamin,
>
> On Tue, Sep 23, 2014 at 10:59:16AM -0400, Benjamin Tissoires wrote:
>> Hi Andrew,
>>
>> On Sep 23 2014 or thereabouts, Andrew de los Reyes wrote:
>> > Hi folks,
>> >
>> > More and more we're seeing touch input devices that support detection of
>> > fingers that are above the surface and not touching. We were thinking of
>> > writing a kernel patch for one such device. Normally we would indicate
>> > distance with ABS_MT_DISTANCE, but we ran into the problem that sometimes
>> > the hardware will not be able to report a distance (or will stop reporting
>> > a distance when it's too great a number), and we had the (bad) idea to
>> > simply report a value or 1 or 255 or something like that when distance is
>> > unknown.
>>
>> 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 Xorg can deal with that (the touch emulation discards the
>> ABS_MT_DISTANCE, but the xorg-evdev driver should be smart enough to not
>> take BTN_TOUCH into account).
>>
>> >
>> > Dmitry warned that a similar thing happened with PRESSURE a while ago, and
>> > it was a mess as different drivers did different things.
>>
>> As I said, IIRC, xorg-evdev is fine with that. For generic desktop, we
>> have to make sure libinput is aware, and then you only have to handle
>> your own xorg chromebook driver. This is not something which scares me
>> that much, especially given that this is what hid-multitouch reports
>> since the v3.9 kernel.
>> libinput is based on a per slot device information, so it is really easy
>> to implement if it is not already in place. xorg-Synaptics and xorg-Wacom
>> should not be ported to wayland from what I understood, so the mess with
>> several implementations can be solved easily.
>>
>> >
>> > We are now wondering if we should come up with a standard way to indicate
>> > hover with or without distance (or with distance being optional). Dmitry
>> > had the idea for a new tool type, HOVER; FINGER would be for touches that
>> > are actually touching.
>>
>> The tool is still the finger.
>
> Do we reliably know that it is a finger and not a pen or eraser or some
> other tool? If we do then obviously introducing new tool will not fly.

On a capacitive sensor, I think we do know, at least for finger vs
active stylus. To be fair, I do not spend much time working with
styluses, so I may not have the most info.

>
>> So I am not very happy with having a new
>> tool. In the end, it may also disturb older clients which will not know
>> what to do with HOVER.
>> And the ABS_MT_DISTANCE approach used to be fully retro-compatible
>> (assuming that the hovering distance is small enough for the user not to
>> detect it).
>
> Except that if we start getting devices that can actually tell the
> distance we'd need special casing 0/1 handling, no?
>
> Thanks.
>
> --
> Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to indicate hover touch when exact distance unknown?

[Henrik Rydberg]

>>> So I am not very happy with having a new
>>> tool. In the end, it may also disturb older clients which will not know
>>> what to do with HOVER.
>>> And the ABS_MT_DISTANCE approach used to be fully retro-compatible
>>> (assuming that the hovering distance is small enough for the user not to
>>> detect it).
>>
>> Except that if we start getting devices that can actually tell the
>> distance we'd need special casing 0/1 handling, no?

Logically, a hovering object which does not support real distance reporting
would simply be present in the contact list but have ABS_MT_TOUCH = 0. However,
I do not think all layers of the stack supports this notion.

Henrik

Re: How to indicate hover touch when exact distance unknown?

[Dmitry Torokhov]

On Tue, Sep 23, 2014 at 08:52:12PM +0200, Henrik Rydberg wrote:
> >>> So I am not very happy with having a new
> >>> tool. In the end, it may also disturb older clients which will not know
> >>> what to do with HOVER.
> >>> And the ABS_MT_DISTANCE approach used to be fully retro-compatible
> >>> (assuming that the hovering distance is small enough for the user not to
> >>> detect it).
> >>
> >> Except that if we start getting devices that can actually tell the
> >> distance we'd need special casing 0/1 handling, no?
> 
> Logically, a hovering object which does not support real distance reporting
> would simply be present in the contact list but have ABS_MT_TOUCH = 0. However,
> I do not think all layers of the stack supports this notion.

That unfortunately does not give us indication whether device supports
hover or not: we'll know only when we see it.

-- 
Dmitry

Re: How to indicate hover touch when exact distance unknown?

[Peter Hutterer]

On Tue, Sep 23, 2014 at 09:28:11AM -0700, Dmitry Torokhov wrote:
> Hi Benjamin,
> 
> On Tue, Sep 23, 2014 at 10:59:16AM -0400, Benjamin Tissoires wrote:
> > Hi Andrew,
> > 
> > On Sep 23 2014 or thereabouts, Andrew de los Reyes wrote:
> > > Hi folks,
> > > 
> > > More and more we're seeing touch input devices that support detection of
> > > fingers that are above the surface and not touching. We were thinking of
> > > writing a kernel patch for one such device. Normally we would indicate
> > > distance with ABS_MT_DISTANCE, but we ran into the problem that sometimes
> > > the hardware will not be able to report a distance (or will stop reporting
> > > a distance when it's too great a number), and we had the (bad) idea to
> > > simply report a value or 1 or 255 or something like that when distance is
> > > unknown.
> > 
> > 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.

Cheers,
   Peter

> 
> > 
> > I think Xorg can deal with that (the touch emulation discards the
> > ABS_MT_DISTANCE, but the xorg-evdev driver should be smart enough to not
> > take BTN_TOUCH into account).
> > 
> > > 
> > > Dmitry warned that a similar thing happened with PRESSURE a while ago, and
> > > it was a mess as different drivers did different things.
> > 
> > As I said, IIRC, xorg-evdev is fine with that. For generic desktop, we
> > have to make sure libinput is aware, and then you only have to handle
> > your own xorg chromebook driver. This is not something which scares me
> > that much, especially given that this is what hid-multitouch reports
> > since the v3.9 kernel.
> > libinput is based on a per slot device information, so it is really easy
> > to implement if it is not already in place. xorg-Synaptics and xorg-Wacom
> > should not be ported to wayland from what I understood, so the mess with
> > several implementations can be solved easily.
> > 
> > > 
> > > We are now wondering if we should come up with a standard way to indicate
> > > hover with or without distance (or with distance being optional). Dmitry
> > > had the idea for a new tool type, HOVER; FINGER would be for touches that
> > > are actually touching.
> > 
> > The tool is still the finger.
> 
> Do we reliably know that it is a finger and not a pen or eraser or some
> other tool? If we do then obviously introducing new tool will not fly.
> 
> > So I am not very happy with having a new
> > tool. In the end, it may also disturb older clients which will not know
> > what to do with HOVER.
> > And the ABS_MT_DISTANCE approach used to be fully retro-compatible
> > (assuming that the hovering distance is small enough for the user not to
> > detect it).
> 
> Except that if we start getting devices that can actually tell the
> distance we'd need special casing 0/1 handling, no?
> 
> Thanks.
> 
> -- 
> Dmitry

Re: How to indicate hover touch when exact distance unknown?

[Henrik Rydberg]

>>> 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.

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.

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.

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.

Henrik

Re: How to indicate hover touch when exact distance unknown?

[Benjamin Tissoires]

On Wed, Sep 24, 2014 at 1:28 AM, Henrik Rydberg <rydberg@euromail.se> 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

Re: How to indicate hover touch when exact distance unknown?

[Dmitry Torokhov]

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@euromail.se> 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

Re: How to indicate hover touch when exact distance unknown?

[Henrik Rydberg]

Hi Dmitry,


> 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?

Yes, I think this makes sense, after all.

Thanks,
Henrik

Re: How to indicate hover touch when exact distance unknown?

[Chung-Yih Wang (王崇懿)]

>>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.
>>
>>Henrik

Or how about ABS_MT_TYPE which indicates touch type of a slot (finger,
hovering, stylus, ...)?

Chung-yih

How to indicate hover touch when exact distance unknown?

[Andrew de los Reyes]

[resending as plain text for the list]

Hi folks,

More and more we're seeing touch input devices that support detection
of fingers that are above the surface and not touching. We were
thinking of writing a kernel patch for one such device. Normally we
would indicate distance with ABS_MT_DISTANCE, but we ran into the
problem that sometimes the hardware will not be able to report a
distance (or will stop reporting a distance when it's too great a
number), and we had the (bad) idea to simply report a value or 1 or
255 or something like that when distance is unknown.

Dmitry warned that a similar thing happened with PRESSURE a while ago,
and it was a mess as different drivers did different things.

We are now wondering if we should come up with a standard way to
indicate hover with or without distance (or with distance being
optional). Dmitry had the idea for a new tool type, HOVER; FINGER
would be for touches that are actually touching.

What do folks here think?

Thanks,
-andrew