On Fri, Feb 14, 2014 at 08:55:41AM -0600, Chris Bagwell wrote:
[...]
>
> Here is my suggestion for a slightly smarter "priv->minPressure".
> First, instead updating priv->minPressure the whole time pen is in
> proximity (via rebasePressure()), we could have that routine store in
> priv->minPressureSeen instead. Storing history seems to be common
> theme. We could then move updating priv->minPressure to only when
> going out of proximity.
Unfortunately it doesn't work that way: The device (stylus, eraser ...)
is forgotten as soon as it goes out of proximity. When it comes back
it is treated like a new device.
Reason is that people may want to use the tablet with different devices
even of the same kind giving them different properties (in the application).
If you wanted to keep information on each device that once had proximity
in the driver you'd have to add a table (most likely a hash table indexed
by the serial number of the device). This could be added I'm just not
sure if this pressure recalibration satisfies the effort required.
>
> That delayed reaction should account of above use case. Although one
> might slam down a pen with speed, I suspect average case is to pull up
> with a lot less speed... so your likely to get enough samples to have
> accurate low pressure.
Not in the use case I have. Here the pen is both tapped onto the tablet
and retracted very quickly. Like I said: it's not the normal use case.
>
> Also, this gives us a nice time period to log a message as well. If
> priv->min_pressure > X then log_once("likely have worn tip. consider
> replacing");
I've already reworked the worn pen detection. There I can wait until
enough events have come in as I do not have to print the message every
time the device comes in. The log file will be cluttered with messages
anyway.
>
> comon->wcmThreshold may be a good starting point for what "X" should
> be. If we never see a value below that and table claims a maxZ value
> then likely warn tip.
Sure. I've implemented it differently atm (calculating 60 percent of
wcmMax) but we could use wcmThreshold as well.
>
> The main negative: upon first connection of tablet and first stroke of
> pen, your pressure will be very high until you go out of prox. For
> very first proximity cycle, we could probably fall back to todays
> behavior and make min be what ever it was at first proximity.
Currently we have this behavior whenever the pen goes into proximity
as we don't keep the state of an individual pen.
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
