On Mon, Mar 10, 2014 at 01:41:32PM -0700, Jason Gerecke wrote:
>
> On Tue, Mar 4, 2014 at 6:15 AM, Egbert Eich <e...@freedesktop.org> wrote:
> > From: Egbert Eich <e...@suse.com>
> >
> > Worn out devices send a non-zero pressure even when not in contact
> > with the tablet. To compensate for this the driver detects if the
> > pressure sent by the device immediately after indicating proximity
> > is non-zero. It substracts this value from any pressure value sent
> > later and rescales the pressure range to the full device range.
> > If it later on sees the pressure value fall below this inital value
> > it will readjust it this lower value.
> > The downside of this is that when the pen is pushed onto the tablet
> > really fast the initial pressure reading may be non-zero also the
> > pen isn't worn. This can lead to lost events.
> > This patch tries to address this: when there is a pressure bias
> > and no regular button press event is generated it records the highest
> > pressure value seen. When the pressure bias drops it uses this value
> > to determine if it would have triggered a press event. This maximum
> > pressure is reset as soon as a regular pressure event is generated.
> >
> > Signed-off-by: Egbert Eich <e...@suse.com>
>
> NAK: If I'm reading this patch correctly, the logic does not work if a
> pen is worn and has a non-zero `priv->minPressure` while not in
> contact. If the "click if maxpressure was sufficient" logic is
> triggered (e.g. by "stabbing" the pen onto the display), the button
> will not be released until the pen completely leaves prox since that
> logic requires `priv->minPressure` to reset to zero before sending the
> un-click event. I've tried to think of a clever way to work around
> that issue, but no simple solutions present themselves.
What I've been contemplating about was to reset maxPressure when the
button press has triggered (due to maxPressure) and minPressure is no
longer decreasing.
I need to test this tomorrow, though.
>
> With the second patch in this set looking okay, I'd rather pass on
> merging this since it doesn't seem to really be all that ideal...
But the same is true for the entire pressure recalibration code. It
may trigger false positives it is not ideal either.
Thus with the very same argument it shouldn't have been merged either.
What I desperately try to do here is to remedy the fallout of the
attempt to detect pen wear which is more noticeable (and annoying)
in some use cases (which may not be the usual ones).
Cheers,
Egbert.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
