• Peter Hutterer's avatar
    Documentation: input: define ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams · 20ccc8dd
    Peter Hutterer authored
    ABS_PRESSURE and ABS_MT_PRESSURE on touch devices usually represent
    contact size (as a finger flattens with higher pressure the contact size
    increases) and userspace translates the kernel pressure value back into
    contact size. For example, libinput has pressure thresholds when a touch is
    considered a palm (palm == large contact area -> high pressure). The values
    themselves are on an arbitrary scale and device-specific.
    
    On pressurepads however, the pressure axis may represent the real physical
    pressure. Pressurepads are touchpads without a hinge but an actual pressure
    sensor underneath the device instead, for example the Lenovo Yoga 9i.
    
    A high-enough pressure is converted to a button click by the firmware.
    Microsoft does not require a pressure axis to be present, see [1], so as seen
    from userspace most pressurepads are identical to clickpads - one button and
    INPUT_PROP_BUTTONPAD set.
    
    However, pressurepads that export the pressure axis break userspace because
    that axis no longer represents contact size, resulting in inconsistent touch
    tracking, e.g. [2]. Userspace needs to know when a pressure axis represents
    real pressure and the best way to do so is to define what the resolution
    field means. Userspace can then treat data with a pressure resolution as
    true pressure.
    
    This patch documents that the pressure resolution is in units/gram. This
    allows for fine-grained detail and tops out at roughly ~2000t, enough for the
    devices we're dealing with. Grams is not a scientific pressure unit but the
    alternative is:
    - Pascal: defined as force per area and area is unreliable on many devices and
      seems like the wrong option here anyway, especially for devices with a
      single pressure sensor only.
    - Newton: defined as mass * distance/acceleration and for the purposes of a
      pressure axis, the distance is tricky to interpret and we get the data to
      calculate acceleration from event timestamps anyway.
    
    For the purposes of touch devices and digitizers, grams seems the best choice
    and the easiest to interpret.
    
    Bonus side effect: we can use the existing hwdb infrastructure in userspace to
    fix devices that advertise false pressure.
    
    [1] https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections#windows-precision-touchpad-input-reports
    [2] https://gitlab.freedesktop.org/libinput/libinput/-/issues/562Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
    Acked-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
    Link: https://lore.kernel.org/r/20210112230310.GA149342@jellySigned-off-by: default avatarJonathan Corbet <corbet@lwn.net>
    20ccc8dd
event-codes.rst 16.5 KB