On Friday 09 February 2018 09:57:03 Peter Hutterer wrote:
> 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
Now I see that alps.c already has following initialization code for
tracksticks:
if (priv->flags & ALPS_DUALPOINT_WITH_PRESSURE) {
input_set_capability(dev2, EV_ABS, ABS_PRESSURE);
input_set_abs_params(dev2, ABS_PRESSURE, 0, 127, 0, 0);
}
And for ALPS SS4 S2 devices alps.c sets that flag. And in function
alps_process_packet_ss4_v2() for SS4_PACKET_ID_STICK it calls:
input_report_rel(dev2, REL_X, SS4_TS_X_V2(packet));
input_report_rel(dev2, REL_Y, SS4_TS_Y_V2(packet));
input_report_abs(dev2, ABS_PRESSURE, SS4_TS_Z_V2(packet));
Therefore ABS_PRESSURE is already used for one trackstick device.
I will prepare patch to export "z" axes also for other ALPS trackpoints
via that ABS_PRESSURE attribute.
Above input_set_abs_params() call already sets minimal and maximal
value, therefore this problem is solved too.
--
Pali Rohár
pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
