Greetings.
Recently I purchased a x230 tablet; it has an on-screen digitizer. My first
stylus computer and I was quite excited.
I was pretty sad when I figured that no matter how I calibrated the stylus,
in much of the screen the stylus and the mouse pointer couldn't happily
match up.
Then I found that people with the Windows have reported similar issues. But
there is a finer-grid calibration mode in the wacom windows driver:
http://forum.tabletpcreview.com/threads/pen-calibration-trick.43622/
The user reportedly is having near-perfect calibration afterward enabling
the finer-grid.
This got me thinking:
the finder-grid is essentially a non-linear calibration. It makes sense --
the non-linear, non-parametric calibration can essentially fit any function
from dev coordinates to screen coordinates give enough resolution.
Unfortunately our xf86-input-wacom driver only allows a linear calibration,
via the Area property.
To test this idea out, I had to piece together a prototype system for
non-linear calibration in xf86-input-wacom.
A few weekend's tweaking and I think I've got the entire prototype system
working. I've put these patches up at
http://github.com/rainwoodman/xf86-input-wacom
After calibrating with these tools, my stylus and mouse pointer agrees at
most of the screen, except the very left and bottom side where the
digitizer seems to have ran out. In general, I feel that non-linear
calibration solved my problems.
My prototype contains three parts:
1) patch to the driver: (wcmCommon.c + wcmCalibrate.c)
- the driver accepts a new property: CalibrationGrid. CalibrationGrid is
a large string that describes the (devx, devy) -> (0, 1)x(0, 1) mapping.
The mapping is represented by a bi-linear interpolation of (x,y)
values on a non-uniform rectangular grid.
- modifying wcmRotateAndScaleCoordinates in wcmCommon.c: if
CalibrationGrid is set, the Area property is ignored; the transform is
obtained from the bilinear interpolation.
2) patch to xsetwacom:
- add support to CalibrationGrid. xsetwacom reads the value of the atom
from the filename provided on the command-line. The reason for this is that
the calibration tool has to write the grid to somewhere -- it is kind of
big (I am currently using a 60x60 grid)
3) a non-linear calibrator. (tools/calibrator.py)
- collecting unlimited number of calibration points [pairs of devx,
devy -> (0, 1)x(0,1)]
- The work-flow scenario:
a) user clicks with the stylus, and hold
b) program predicts the screen coordinate, and puts a crosshair
c) user drags the stylus to the crosshair, and release (collecting the
pair)
d) goto a until the user finds the prediction matches the stylus click
good enough, everywhere.
- the collected points are regularized to a mesh with a triangulation
interpolation
the output is written to stdout, and can be used directly by the
patched xsetwacom.
I have attached a screenshot of the calibration tool (I used an insane
number of points, but it is so easy to add points), and a figure showing
how a regular mesh on the device maps to screen coordinates. In the figure,
the dev mesh is built on (0.0, 0.01, .... 0.1, 0.2, ..... 0.9, .91, ....
1.0)^2. You can see the corners are pretty messed up in my device (and
that's where most of the controls are, eg, the activities menu of
gnome-shell, close window button, etc).
I suspect that I didn't not get a very malfunctioning unit, and other
people's devices may have similar issues too (why otherwise would the
windows driver have this?)
My gut feeling is that there can be a demand for this as more people
installs linux on tablets equipped with on-screen-digitizers, but correct
me if I am wrong.
Is there an interest in the devel team in adding a non-linear calibration
mode to the upstream driver?
If so, I am more than happy to contribute, either directly or indirectly.
The code I currently have obviously needs quite a lot of polishing before
becoming ready to for prime use. At least, there are:
1) unsafe array access / parsing in the driver;
2) calibration tool depends on too many things: python, pygobject,
gtk3, numpy, scipy (and even matplotlib for plotting debugging figures);
3) lack of documentation; and I used a different indentation of source
code. (I thought it would be rewritten anyways)
Best,
Yu
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
