Jason Gerecke writes:
> On Thu, Feb 13, 2014 at 2:10 PM, Peter Hutterer
> <peter.hutte...@who-t.net> wrote:
> > On Wed, Feb 12, 2014 at 08:04:07PM +0100, Egbert Eich wrote:
> >> From: Egbert Eich <e...@suse.com>
> >>
> >> If the initial pressure of a device is != 0 the driver recalibrates
> >> the pressure range. This is to account for worn out devices.
> >> The downside is that when the user hits the tablet very hard the
> >> initial pressure reading may be unequal to zero even for a perfectly
> >> good pen. If the consecutive pressure readings are not higher than
> >> the initial pressure by a threshold no button event will be generated.
> >> This option allows to disable the recalibration.
> >
> > can we be smarter about this? e.g. disable worn-out pen detection once a
> > tool has shown that it repeatedly sent events below the threshold. I don't
> > think an option is the right way to go here, with the driver and desktop
> > environments repeatedly interfering with each other I'm hesitant to add
> > options for something that we could probably solve for the >90% use-case.
Peter, I thought about this but wasn't able to come up with a satisfactory
solution
for the use case I had to deal with. Point is, we don't keep a history for the
pens
we see. Whenever a pen comes into proximity it is treated like a new pen once
it goes out of proximity it is forgotten.
Let me give a bit more insight on the use case I'm dealing with:
These Wacom tablets are used for air traffic controlling - you may remember XDC
in Toulouse where we visited a development center for air traffic control
software.
Here pens are only used for klicking and dragging. Thus the pressure
information
is never evaluated by software, it is only used to synthesize klick events in
the driver.
Moreover air traffic controllers do not use pens like artists do: in situations
with heavy traffic it happens that the controller taps the pen quite fast and
hard.
This is what happens then: the pen comes from far away, thus is out of
proximity.
It will come into proximity, immediately have a non-zero pressure reading then,
when the hand pulls back quickly, it will go out of proximity again.
Here the tablet will frequently only get a single pressure event sent
immediately
when the pen comes into proximity> Here recalibration kicks in and no click
will be generated.
In this situation we have too little data to determine if the pen is worn or
not.
Moreover, what will happen in this situation is what will always happen in such
situations:
in order to trigger a press event the pen will be hit against the tablet even
harder only exaggerating the problem.
Thus for air traffic safety it is a requirement that pressure recalibration can
be
turned off.
Instead pens will be exchanged routinely and in situations where the logs
indicate
they are worn.
>
> Agreed.
>
> Based on how the pressure transducer works, I would think that a drop
> in pressure of more than a few percent should be a clear indication
> that the pen isn't simply worn out. Once its clear that the user has
> triggered this condition, we could send the click and temporarily
> disable remapping. If we wanted to get fancy, we could remember the
> last "good" pressure that the pen entered with and use that value for
> remapping instead.
>
I've thought about a similar scenario already and I'm happy to explore
if the algorithm can be designed a bit smarter ie if it has initially
recalibrated and thus not synthesized a pressure event but later detects
that the pressure falls below the initial pressure by more than 10 percent
the 'dropped' klick event will 'emulated' if the pressure readings
meets the threshold criteria.
I have not implemented this so far as from the tests I've done here
I was not convinced that this will will reliably fix the issue for our
use case.
Moreover this feature would be a bit experimental.
Thus the requirement to be able to turn off calibration completely
will remain.
I would therefore suggest to make this an option with multiple values:
on/smart/off. If you want, we can make 'smart' the default.
Even if disabling recalibration is only meant for < 10 percent of
the use cases would this an acceptible compromise?
Cheers,
Egbert.
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
