linux-kernel - Re: ALPS Trackpoint & pressure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180208235703.GA4300@jelly>
Date:   Fri, 9 Feb 2018 09:57:03 +1000
From:   Peter Hutterer <peter.hutterer@...-t.net>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Masaki Ota <masaki.ota@...alps.com>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ALPS Trackpoint & pressure

On Fri, Feb 09, 2018 at 12:21:41AM +0100, Pali Rohár wrote:
> On Tuesday 06 February 2018 10:29:47 Peter Hutterer wrote:
> > On Mon, Feb 05, 2018 at 02:49:55PM -0800, Dmitry Torokhov wrote:
> > > On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote:
> > > > Hi! Now playing again with trackpoint connected to ALPS rushmore
> > > > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it
> > > > reports pressure of trackpoint. Parser for it is already implemented in
> > > > alps.c and value is assigned to variable "z". When I just move
> > > > trackpoint z is zero, when I push trackpoint while moving, then z is
> > > > number higher, maximally 32. Variable "z" is set, but unused.
> > > > 
> > > > Do we have some input interface which can be used to report this
> > > > pressure of trackpoint to userspace? I can use this feature e.g. as
> > > > additional button...
> > > 
> > > We could either do the conversion in kernel and emit BTN_LEFT, or
> > > report ABS_PRESSURE and see if userspace will be able to handle
> > > REL_X/REL_Y/ABS_PRESSURE device.
> > > 
> > > Adding Peter.
> > 
> > judging by trackpoint history, I'd leave the pressure->click conversion to
> > userspace because every trackpoint may need a different threshold setting.
> > "easier" to have this in userspace with dmi matches etc. plus, converting to
> > BTN_LEFT in the kernel means we cannot use it as a separate interaction
> > anymore.
> 
> Also BTN_LEFT is already reported when left button under trackpoint is
> pressed. Therefore it would not be possible to distinguish between
> trackpoint "press" and real left button press.

yep, that's what I meant with "we cannot use it as separate interaction",
we'd have no way to know how the click was generated.

> 
> > That aside, I think exporting ABS_PRESSURE is fine, that's what it's there
> > for. Nothing will use it for now though, tbh not sure yet how that would be
> > exported from libinput. but worth filing a bug for, please assign it to me.
> 
> Ok, so ABS_PRESSURE? Also then question is, how to report minimal and
> maximal (possible) value? If we are going to "standardize" API for it,
> we should also define min/max values, so userspace would be able to
> normalize this pressure event. I can imagine that some devices can
> report 8bit value, but ALPS rushmore reports only 5bit value.

tbh, I'm not putting my hopes on this being an accurate range ever. So
what's likely going to happen is that you pick a best-guess min/max for the
kernel and then we have dmi-based overrides for every single trackpoint in
userspace to tell us what a realistic threshold value for a click is and
what the actual min/max ranges is.

This is relatively easy to measure in userspace, we can pop it into
60-evdev.hwdb to override the min/max and ship the threshold values as
libinput-specific files. It's awful, but most likely the best we can do.

But hey, at least a min of 0 will be accurate ;)

Cheers,
   Peter