Created an attachment (id=2105) [details]
pressure.py test script

Run this on a n900 device and read the output.

Comment 2 Andre Klapper 2010-02-02 22:26:37 UTC

Thanks for reporting this (and especially the testcase!).

*** This bug has been confirmed by popular vote. ***

I can confirm this bug. I had to disable pressure sensitivity on MaePad for
Fremantle because of this. Are the invalid pressure readings reliable, i.e. can
I calculate .7-(range/.25*.7) to get the "old" pressure value?

I'd like to work around this bug in my application until it's fixed, so
pressure sensitivity is possible on Fremantle, too.

I dont even know if it GTK, X or driver related bug. Liqbase uses the pressure
values right (?)- maybe one should ask lcuk's opinion on this...
All I know is that mypaint on diablo worked great with dynamic brushes and that
those readings varied from 0 to appr. 0.700.

I don't even get any useful values out of the pressure.py script (or using
gdk_event_get_axis() with GDK_AXIS_PRESSURE) right now.

Is there a workaround available? I'd really *love* to get pressure sensitivity
back into MaePad :) The method of scaling the value does not work, as the
values I get here seem to be random and not dependent on pressure at all :/

Is there any useful data I can provide to help bring the internal bug forward?

Created an attachment (id=2640) [details]
Test case in C

I'm looking into this, but I don't think this is a bug in GTK. Here's a test
case in C for what it's worth.

Created an attachment (id=2718) [details]
Graphical test case in python

Presents graphical display of current pressure reading.  Adapts dynamically to
minimum and maximum pressures read so far.

(In reply to comment #8)
> Presents graphical display of current pressure reading.  Adapts dynamically to
> minimum and maximum pressures read so far.

Thanks, I've tried it. Values here for comparison:

MIN: 0.22509765625
MAX: 0.01611328125

Apart from that, the value changes does not really correspond to the pressure
applied to the screen. Another thing to note is that the value declines when
reaching the left and right edge of the screen. The pressure readings also
increase when placing a second finger on the screen when one finger already
touches the screen.

This behaviour is both in 2.2009.51-1 and the leaked PR1.2 (10.2010.12-9), so
it's very likely in 3.2010.02-8 as well (updating the version field
accordingly).

(In reply to comment #9)
> the value changes does not really correspond to the pressure
> applied to the screen.

Hi Thomas.  It certainly seems a bit erratic for me, but it sort of works - for
instance if I press hard then reduce pressure gradually then increase again the
bar moves down and up accordingly.  


> Another thing to note is that the value declines when
> reaching the left and right edge of the screen.

Not quite sure what you mean by that.  I think you're describing what I meant
when I said the program "adapts dynamically".  This is so that the leftmost
position corresponds to the minimum pressure obtained so far, and the rightmost
position corresponds to the maximum pressure.

The pressure p is converted to a value between 0 and 1 using the formula:
value = (p-min) / (max-min)


> The pressure readings also
> increase when placing a second finger on the screen when one finger already
> touches the screen.

Yes, well I guess that's fair enough.  I actually managed to get a maximum
pressure of 0.0 by pressing very hard with 2 fingers.

For what it's worth, my minimum reading so far has been 0.3515625, and the
maximum reading (apart from 0.0) was 0.00048828125

(In reply to comment #10)
> Hi Thomas.  It certainly seems a bit erratic for me, but it sort of works - for
> instance if I press hard then reduce pressure gradually then increase again the
> bar moves down and up accordingly.

Yes, but it's not something that can be used as input data for
pressure-sensitive drawing apps (or at least I don't see how..).

> > Another thing to note is that the value declines when
> > reaching the left and right edge of the screen.
> 
> Not quite sure what you mean by that.  I think you're describing what I meant
> when I said the program "adapts dynamically".

I'm talking about the physical position of the press on the screen. You should
see the effect when you swipe your finger from the left edge of the screen all
the way to the right edge of the screen.

re comment #9, based on homebrew Nintendo DS experience, you do get a drop in
pressure readings at the edges.  also you get much bigger pressure readings by
using a finger instead of a stylus or by touching two points.

+1 for getting this sorted :-)  (the actual reported problem, not the edges and
multi-touch things)

also, presumably this means we can close bug 4256?

just thought i'd mention it as that bug might have examples which let us
examine values at a level below gtk - could be helpful for diagnosis?

In Xournal I read the pressure this way:


  if (!gdk_event_get_axis (event, GDK_AXIS_PRESSURE, &rawpressure)) {
      rawpressure = (((GdkEventMotion *)event)->state & GDK_BUTTON1_MASK) ?
1:0;
  }

  rawpressure = 1.00-10*rawpressure;

I figured out I should *amplify* the raw pressure and then invert the values.

I've found a similar behaviour with:
cat /dev/input/ts | od -x | grep 0018
(as root)

Pressure is inversed.
So the problem is the driver.