Re: [PATCH] Document the units for resolution of size axes

[Jeff LaBundy <jeff@labundy.com>]

Hi Siarhei,

On Fri, May 20, 2022 at 01:45:14AM -0700, Siarhei Vishniakou wrote:
> Today, the resolution of size axes is not documented. As a result, it's
> not clear what the canonical interpretation of this value should be. On
> Android, there is a need to calculate the size of the touch ellipse in
> physical units (millimeters).
> 
> After reviewing linux source, it turned out that most of the existing
> usages are already interpreting this value as "units/mm". This
> documentation will make it explicit. This will help device
> implementations with correctly following the linux specs, and will
> ensure that the devices will work on Android without needing further
> customized parameters for scaling of major/minor values.
> 
> Signed-off-by: Siarhei Vishniakou <svv@google.com>
> Change-Id: I4a2de9e6d02e5fd707e5d312f5c3325734266a6e
> ---
>  include/uapi/linux/input.h | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index ee3127461ee0..328cf545c029 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -78,10 +78,13 @@ struct input_id {
>   * Note that input core does not clamp reported values to the
>   * [minimum, maximum] limits, such task is left to userspace.
>   *
> - * The default resolution for main axes (ABS_X, ABS_Y, ABS_Z)
> - * is reported in units per millimeter (units/mm), resolution
> - * for rotational axes (ABS_RX, ABS_RY, ABS_RZ) is reported
> - * in units per radian.
> + * The default resolution for main axes (ABS_X, ABS_Y, ABS_Z,
> + * ABS_MT_POSITION_X, ABS_MT_POSITION_Y) is reported in units
> + * per millimeter (units/mm), resolution for rotational axes
> + * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
> + * The resolution for the size axes (ABS_MT_TOUCH_MAJOR,
> + * ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MAJOR, ABS_MT_WIDTH_MINOR)
> + * is reported in units per millimeter (units/mm).
>   * When INPUT_PROP_ACCELEROMETER is set the resolution changes.
>   * The main axes (ABS_X, ABS_Y, ABS_Z) are then reported in
>   * units per g (units/g) and in units per degree per second
> -- 
> 2.36.1.124.g0e6072fb45-goog
> 

Thanks for raising this point; it's a valid one. However, I'm not
convinced this is the right approach.

On all the controllers I've worked on, ABS_X and ABS_Y are mapped
to arbitrary resolution values that don't necessarily map to real-
world units. I don't think we can make any assumption at the input
layer as to the physical size of the touch surface.

It is the same problem for ABS_MT_PRESSURE; the values are typically
controller-specific and we can't reasonably try to map this axis to
any standard unit (e.g. Pascals).

If user space needs to understand the mapping between axis range and
physical size, maybe it is better to adopt the approach from the IIO
subsystem wherein the input_dev offers a property that maps each axis
(i.e. "raw" value) to some SI unit?

In that case, dts could define the scaling factor between raw values
and physical dimensions. At any rate, that is just my $.02.

Kind regards,
Jeff LaBundy