On Sat, Dec 13, 2014 at 11:33 PM, Feng Yu <rainwood...@gmail.com> wrote: > 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 > Glad to see you tackling this problem :) It would be nice to have a way to provide finer-grained calibration to the driver, for those tablets like yours which have non-linear edge behavior which can't be solved simply by tweaking the 'Area' property. I can't seem to find any of the patches on Github though -- are you sure you've pushed them up?
> 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. > Ignoring the Area property isn't ideal since it can be used for purposes other than calibration. I'm not sure if there's anything better that can be done though (and practically speaking, I don't know if there are many people that use it in such alternate ways). > 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) > The xsetwacom patch should probably be skipped since it doesn't really make sense for the user to set or get the raw value. Calibration apps should modify the property directly, and if for whatever reason the user needs to get/set the raw value they should use the `xinput` command. > 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'm not sure if having the properly expect a particular mesh is a good idea. Every calibration application would need to use the same grid and we'd be tied to that particular grid for the future. Also, a 60x60 mesh would make for a pretty huge property that I imagine would often be overkill unless you have a poorly factory-calibrated sensor. What do you think about having the property contain just the sampled [devx, devy, (0,1)x(0,1)] vectors? This would be very easy for calibration applications to generate, and provides quite a bit of flexibility in how the data is used within the driver (perhaps for now it calculates a static mesh, perhaps in the future we update it to use an adaptive mesh). The size of the property can be variable, which means that it doesn't have to be any larger than necessary. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours.... > 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 > ------------------------------------------------------------------------------ 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
