Re: [Linuxwacom-devel] [PATCH] Fix message if the detected pressure falls below the initially detected pressure
On Thu, Feb 13, 2014 at 05:13:41PM -0800, Jason Gerecke wrote: > It would be nice to be more intelligent (see other patch :D) but > agreed that this situation shouldn't be considered a bug. > After looking at this code some more: the check we perform here does not make much sense and should go entirely: in rebasePressure() we do: if (!priv->oldProximity) priv->minPressure = ds->pressure; else priv->minPressure = min(priv->minPressure, ds->pressure); immediately thereafter (in normalizePressure()) we essentially do: if (ds->pressure < priv->minPressure) LogMessageVerbSigSafe(X_INFO, 0, "%s: Pressure %d lower than expected minimum %d.\n", priv->pInfo->name, ds->pressure, priv->minPressure); Unless we don't trust the implementation of min() we should not expect this condition to ever trigger. I assume the test was a leftover from a time where minPressure was only taken on proximity in. 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
Re: [Linuxwacom-devel] [PATCH] Add an option to disable pressure recalibration
On Fri, Feb 14, 2014 at 4:07 AM, Egbert Eich wrote:
> Jason Gerecke writes:
> > On Thu, Feb 13, 2014 at 2:10 PM, Peter Hutterer
> > wrote:
> > > On Wed, Feb 12, 2014 at 08:04:07PM +0100, Egbert Eich wrote:
> > >> From: Egbert Eich
> > >>
> > >> 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.
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.
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.
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");
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.
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.
>
> >
> > 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' klic
Re: [Linuxwacom-devel] [PATCH] Log when the pen device appears to be too worn out
> > Fwiw, this is a complex but obscure enough issue that's hard to explain in > two sentences. It will trigger false positives that result in bug reports, > especially with messages like "maybe not broken" - that's probably quite > confusing to users. > > So how about changing the warning to include a link to a wiki page that > explains what the warning means and what the effect is? Something like: > > "High initial pressure detected, your tool may be worn out. For more info, > see http://linuxwacom.sourceforge.net.."; > > Then we can be as verbose as needed and have an easy way to avoid > bugreports, and to close them quickly when they are erroneously reported. > Let me revisit this together with an algorithm to make pressure recalibration a bit smarter. Maybe I can come up with a heristic which warns only in situations where it is very certain that a problem exists - ie when the device proxies out, there have been a certain number of pressure events in between and none of them has dropped signifficantly below the min value. If a device is worn out the situation will persist. We won't necessarily have to log it the first time we encounter it and not every time do. 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
Re: [Linuxwacom-devel] [PATCH] Add more detailed messaging in code that handles abnormal situations
On Thu, Feb 13, 2014 at 05:16:13PM -0800, Jason Gerecke wrote: > I'm not sure I see the reason for adding a log line here. The only way > you'd overflow is due to a bug, and I don't think that knowing the > serial numbers that were in-prox at the time of overflow is going to > help much. > I'm not going to insist on this patch. It was left from a set of patches for the legacy driver that I have inherited and from where I ported those pieces over that were still somewhat meaningful for xf86-input-wacom. The customer at that time required a complete trace of which devices came in and which left together with a reason. This is not a hard requirement any more. 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
Re: [Linuxwacom-devel] [PATCH v2] Fix loads of 'redundand declaration' warnings in test suite
On Fri, Feb 14, 2014 at 07:50:26AM +1000, Peter Hutterer wrote: > > > > -_X_EXPORT void > > -InitValuatorAxisStruct(DeviceIntPtr dev, int axnum, Atom label, int > > minval, int maxval, > > - int resolution, int min_res, int max_res, int mode) > > + > > +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) > 14 > > +_X_EXPORT Bool InitValuatorAxisStruct(DeviceIntPtr dev, int axnum, Atom > > label, > > please split this up into two lines for > > _X_EXPORT Bool > InitValuatorAxisStruct... Ok, will do. > > also, the rest of this file uses spaces insted of tabs (sorry), please just > re-indent accordingly. > No, it isn't. In fake-symbols.c there are several functions towards the end which are indented with tabs. I've replaced any tabs with spaces in my code now regardless. 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
Re: [Linuxwacom-devel] [PATCH] Add an option to disable pressure recalibration
Jason Gerecke writes: > On Thu, Feb 13, 2014 at 2:10 PM, Peter Hutterer > wrote: > > On Wed, Feb 12, 2014 at 08:04:07PM +0100, Egbert Eich wrote: > >> From: Egbert Eich > >> > >> 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
