Re: [Linuxwacom-discuss] Pen-Cursor lag on Wacom on Asus Slate ep121

[Chris B. <ch...@cn...>]

On Tue, Aug 30, 2011 at 11:53 AM, AbeOwitz <abe...@gm...> wrote:
> Thanks for the info, Chris.  :)
>
>> Your other email reply shows its detected as a "Wacom ISDv4 90" USB
>> device.  You can ignore the ISDv4 part.  Its fast USB communication
>> for most part.  Not sure if there is a serial link behind that USB
>> part though.
>
> So, which protocol is in use then?

This page attempts to sum it up.  I'll call it the "HID-Wacom
TabletPC" protocol; which is a USB protocol.  I do not think your
hardware is using the real Serial ISDV4 protocol.

http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview

>
>> I will offer this bit of info.  I have a Eee PC T101MT with a Mosart
>> touchscreen but no Wacom pen part.  I've been switching between
>> "evdev" X driver and "wacom" X driver.  With the wacom driver, I do
>> notice a similar lag when using touch.  Evdev is noticably faster with
>> same touches.   So one option is to use that driver to reduce the lag.
>
> On the ep121, the touchpad is a separate piece of hardware:
> http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm
>
> Not too interested in touch anyway, just the Wacom Pen, so it is
> turned off on startup.
>
>> I think this is just a function of no integrated display for you to
>> notice the lag.  I don't notice it so much on my Bamboo tablet either.
>>  It wasn't until I dragged my finger across the screen and noticed how
>> much further behind my finger the cursor lagged that it was real
>> obvious.
>
> There's a definite performance difference between the two Wacoms.
>
> On the Intuos tablet, the cursor and application keep up with the pen
> movement.  With the screen Wacom, the cursor lags the pen, but the
> application keeps up with the cursor.
>
> Pen->Cursor->Application->delay->result  --  is application delay.
> Seen in the Gimp and MyPaint, for example.
>
> Pen->delay->Cursor->Appllication->result  --  is pen-cursor delay and
> will occur everywhere in X.
>
> So, I'm experiencing the 2nd.  I need to identify where in the
> Pen->Cursor chain the delay is:
>
> Pen->Wacom Tablet hardware->Kernel driver->Event System->Xorg Event
> System->Wacom Driver->Xorg Input System->Cursor Location...?
>
>
>> If your recompiling code, one idea is to throw away every other packet
>> to see if an event overload issue.
>
> Not sure how to do this given the variable length of the ISDV4
> protocol...  Isn't this what the Suppress and Sample settings did?  Do
> they apply to the ISDV4 protocol?

Suppress is not very useful when your doing real work.  It suppresses
changes below a certain value but once your moving the pen around fast
or have good pressure, your going to be much beyond your suppress
level.

Sample is just the size of a floating average window.  It is
responsible for smoothing out your circles but does not suppress any
data.  I think you mentioned unsmooth circles in original emails.
Thats what you want to play with for that.

If your sample window is very large, you'll also get lag because the
averaging will cause the reported location to be closer to middle of
current position and the location X samples ago.  The default sample
size is 4.

Wacom's usually send between 100-133 samples (Bamboo's and TabletPC's)
and 200 samples a second (Intuos's) in case your interested.  If my
quick math is right, that means up to 20ms averaging induced lag for
Intuos's and 40ms for TabletPC's.  You could reduce Sample window to 2
on your Tablet to get down to Intuos's lag and see if that makes them
seem the same.

We have nothing currently to discard samples blindly to throttle the
events sent to applications/window managers.

>
> I'm more than willing to experiment and compile code.  I'm not a C
> programmer, though...
>

Here is a rough idea to reduce sample rate from 133 to 66 pps.
Assuming you have source code, edit the file src/wcmCommon.c.

Around line 664 (after "int valuators[priv->naxes];"), add this:

const int skip = 0;

skip++;
if (ds->proximity && skip > 2)
{
  skip = 0;
  return;
}

If lag gets better then its probably an issue outside of driver (X
server, window manager, or apps)  were it can't handle large amounts
of events; probably because of not enough CPU cycles.  If it gets
worse or stays the same then probably something inside
xf86-input-wacom we need to look into.

Chris