[Sugar-devel] Wacom Bamboo with XO?

[Chris Marshall]

Wade Brainerd wrote:
> 
>     The only catch is that the drawing output
>     lags the tablet strokes by quite a bit.  My
>     guess is that the event processing cannot
>     keep up with the data rate.  I seem to remember
>     that there was a driver configuration related
>     to that which might be used to throttle down
>     the fire hydrant.
> 
> 
> The mouse events go at a higher priority than the expose events, so the 
> screen update waits until you stop moving if it gets behind.  But, at 
> the end your entire stroke should appear.  I would be concerned about 
> reducing the update rate, it might lead to less accurate drawing.

It is true that reducing the update rate would lower the
pen position resolution of lines...but the Bamboo tablet
has a linear resolution of 2400+ lines per inch which is
about 12X the XO pixel resolution and 24X your 2X reduced
drawing canvas.  As a result, even with skipping pen
deltas of 24 or less the pen output events will still
be at the finest drawing precision.  This is not even
including the fact that the brush is more than a single
pixel wide typically.

If you add an entry under the first wacom Xinput entry in
your xorg-dcon.conf file like:

   Option "Suppress" "60"

you'll get much better drawing response with the existing
infrastructure.  I tried 10-72 and to keep up with faster
sketching or larger brushes, the rate needs to be at 50 or
greater.  After the above edit and a 3-finger-salute to
restart the X server on the XO, Colors! basically worked
well with the tablet.

There is a command line configuration program (xsetwacom)
that could be used to configure Wacom tablet settings
without editing the xorg-dcon.conf file.  I don't know
if a restart of X would then be required.  It might be
possible to base a control panel interface calling the
underlying utility per Tomeu Vizoso's previous mention
in this thread.

To improve beyond the Suppress technique will require
improved event handling optimization in colors.py.  My
guess is that the best approach will be to encapsulate
tablet specific handling at a lower level for efficiency.


> I've got some optimizations planned to the C module which should make it 
> better, and I think there are some bottenecks in the X server that slow 
> things down and could be fixed, but my recommendation for now is to draw 
> slower :)

Cool!

>     BTW, Colors! version 11 did not appear to have
>     the photo snap capability.  Was that removed?
> 
> 
> See Nirav's response.  I'm also planning to add Paste support so you can 
> just snap the photo in Record (or whatever) and paste it into the 
> Reference image, then paint over that.

I tried the earlier photo snap and it was awkward to toggle
the underlying photo image.  It would be more helpful if the
photo could be drawn over as if on tracing paper.  The toggle
on/off would still be useful at different levels of refinement
of the painting.

There appeared to be a problem with the Zoom in and
out function as zooming all the way out, and then back in
results in the canvas offset by various amounts.  I was not
able to make it shift back without restarting the Activity.

Finally, I'm not sure how to handle this but it was difficult
to trigger the Frame exposure via the tablet since the drawing
area seems to be exactly the entire screen.  If it were to be
extended a bit at the top then the Frame would be easier to
get to from the tablet only.

I've got an old serial Intuos that I'll try to get configured
this weekend.  I'll let you know how it goes...  If we get
this working, maybe Amazon could add a "People who bought this
item [the XO], also bought this [Wacom Bamboo]"...  :-)

Best regards,
Chris