> 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?
>
> Oops! I forgot to push it the branch! It is now at the gridcal branch:
https://github.com/rainwoodman/xf86-input-wacom/tree/gridcal
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).
>
>
The Area property can still be set and retrieved as usual. It is just that
the driver won't apply it to the transformation
if CalibrationGrid is set -- does this hehavior break the alternative use
cases?
ResetArea can be made to clear the CalibrationGrid too. That way the
traditional calibration programs won't be messed up.
Two alternatives I can think of are to
1) set to are to a special value if CalibratoinGrid is set
2) Get rid of Area altogether, and replace it with a Calibration property
that supports both. Linear and non-linear calibration.
> 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.
>
I agree with you that the calibrator shall set the properties without
farming it to xsetwacom.
But I would argue for an interface in xsetwacom for the sake of
completeness: every documented property has a corresponding xsetwacom CLI.
A CLI allows advanced users to backup/restore the current calibration in a
shell script. The CLI doesn't have to be in xsetwacom, but why bother
introducing another executable?
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.
>
> The calibrator script I wrote allows regularizing to an arbitrary mesh,
which can be customized or tweaked to a lower resolution. 60x60 is a bit of
a overkill, especially given my bad calibration techniques. I also noticed
after a reboot the calibrate on the top left corner got off again -- can be
a bug, or the hardware is actually bad. Or is it usual that a digitizer
needs to be calibrated every now and then depending on the phase of the
moon?
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.
>
>
A rectangular mesh is much easier to handle than irregular points. A
bilinear interpolation on the mesh is less than 10 lines of code. But to
regularize a irregular mesh, we either have to bring in qhull, or to
implement Delaunay triangulation, or use some kernel estimators(e.g. a
gaussian process) -- it is much simpler to experiment with these in the
user-land than in the X - driver
Here are a few numbers about the size of the bytes:
My current CalibrationGrid is about 74K in size; and I had about 700
calibration vectors (which amounts to about the same size in KB).
But I do think it is likely an overkill. How many bytes is an adequate size
of an XProperty?
It is also quite likely we can find a sufficiently general parametric form
that can fit the transform sufficiently good. I promise I will play around
with this a little bit later of the year.
Best,
- Yu
> 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
