On Thu, Sep 22, 2011 at 3:32 PM, cheshirekow <cheshirekow@...> wrote:
> That's interesting. That sounds like what was happening with my Bamboo
> touch back in the day. Whenever I pressed a button the cursor would jump
> to the top left corner. This problem with the Slate is different: the
> cursor moves *toward* the actual pen location, it just doesn't get all
> the way there. If I move the pen around a little bit then the cursor
> finishes moving under the pen. Maybe I can make a youtube video of the
> This is the reason I suspected something involving smoothing settings:
> * Perhaps the N-Trig hardware (or the kernel driver) only generates an
> interrupt (or event) when the pen location changes more than some
That is very possible. The kernel driver also applies filtering on
top of it. As long as the values are the same, it will not send new
ones to X. You can verify how many samples your getting by installed
the "evtest" app and running somthing like:
sudo /dev/input/eventX <-- X is whatever your pen is and if you
search your Xorg.0.log file it will be listed in there... Or dmesg
also prints it.
> * Perhaps the kernel driver or the x-input driver expects pen location
> at some fixed "Frame rate"
Kernel and xf86-input-wacom do not. Maybe cursor acceleration logic
inside X server does but since your in absolute mode that shouldn't be
the case I think.
> * If one of the drivers expects a fixed stream of input it may be
> reasonable to low-pass that input (i.e. take the average of the last 5
> absolute positions)
Yes, that is what xf86-input-wacom is doing. Its a sliding window
average over last 4 samples and can be changed with RawSample using
xsetwacom (I forget name with xinput offhand).
> If either of these is the case (which, I'm not saying it is, but if) it
> would explain what I'm seeing. If I pick up the pen and put it down
> somewhere else on the screen very slowly, it appears as if only one
> motion event is generated. The cursor moves partially towards the
> location of the pen, but not all the way. If I then very slowly start to
> slide the pen location (still touching the screen) then I can see the
> cursor jump again closer to where the pen is. If I continue to move the
> pen it will jump a little closer. In this way the cursor gets closer and
> closer to the pen, but only if I'm moving the pen enough to "generate
> more events".
> Like I said I don't know that this in fact how the hardware/drivers
> work, but it would explain what I'm seeing. Since the input is much
> smoother in Maverick, I suspect it's not actually a hardware thing. I
> suspect instead that somewhere in stream of processing, one of the
> drivers has a large threshold for movement (so that it only generates an
> event if motion is larger than some number of pixels) and that somewhere
> downstream from there another piece of software is averaging some 3-5
> position events to smooth the cursor location. If this is the case, I
> believe the problem can be fixed by reducing the number of events
> averaged to 1, or to reduce the threshold number of pixels for a motion
> event to be generated.
If thats the problem then yes. But 4 samples if very small. At least
with Bamboo's (all that I have experience with) the pressure changes
so often that it more than defeats the 4 sample window. The window is
over 4 changes of ANYTHING... Not just X/Y values. That also explains
why pressing a button will also cause averaging to be defeated and
cause the cursor to move.
As Dave mentioned, you should be able to change RawSample and see if
it helps. I was doing something the other day with it though and I'm
not real sure anymore that setting it to 1 actually turns off
I don't know if your interested in hacking xf86-input-wacom but I
created a patch a while back related to filtering that you can play
with. It never got submitted since no one reported major improvements
from it on Wacom hardware.
What the patch does is:
* Only move sliding window when X/Y values change (stop movement when
only button is pressed or pressure changes).
* Reduces sliding window down to size of 1 as time moves on. This
will cause cursor to move exact location of pen when you stop moving
If a pen was not sending any samples, then it could still be an issue
with patch. We'd need a timer or something to cause 1 last window
reduction in the case of zero movements.
This was written so long ago, I can't remember what state the patch is
in (maybe its buggy). But it at least gives you an idea of area of
software thats related to filtering samples.