Re: Wacom calibration results are off (wrong area)



Awesome, apologies for the radio silence over this.  Should I submit a bug?

Also, I am hoping to have free time soon.  If there is anything else I can try to do to fix this, I am more than willing.  Is there a general design document over this code?  (Essentially, what is the goal for basing current calibration off of old calibration?)

Thanks!

-josh


On Tue, Jun 25, 2013 at 11:59 AM, Joaquim Rocha <jrocha redhat com> wrote:
Thanks for the investigation Josh. I will look into this.

--
Joaquim Rocha
http://www.joaquimrocha.com

----- Original Message -----
> From: "Josh Berry" <taeric gmail com>
> To: "Joaquim Rocha" <jrocha redhat com>
> Cc: gnomecc-list gnome org
> Sent: Friday, June 21, 2013 7:04:44 PM
> Subject: Re: Wacom calibration results are off (wrong area)
>
> I think I'm now able to reproduce exactly what we are seeing.  The problem
> seems to be that once the calibration goes wrong once, it can not correct
> itself.  Specifically, if we set the area value in dconf to be a bogus
> value, then the calibration will remain bogus.  My hunch is simply because
> the values of the Calib struct old_axis are used to "scale" the resulting
> configuration.
>
> This actually describes what I was seeing rather well, which was that the
> area of the calibration will get smaller and smaller with each successive
> attempt at calibration.  (That is, each successive calibration would reduce
> the "usable" area of my screen for the pen, such that moving the pen across
> a subset would move the cursor across the whole screen.)
>
> I will run some tests to really show this, but it seems that the assumption
> that the scale of the last calibration was correct is problematic.   Other
> than being nuclear on that code, is there a way I could modify the code
> such that a terrible calibration does not make it impossible to get a good
> calibration?
>
> Thanks!
>
>
>
> On Mon, Jun 17, 2013 at 11:26 AM, Josh Berry <taeric gmail com> wrote:
>
> >
> >
> >
> > On Mon, Jun 17, 2013 at 9:32 AM, Joaquim Rocha <jrocha redhat com> wrote:
> >
> >> Hi Josh,
> >>
> >> Looks like the commit you refer to is in included from GNOME Control
> >> Center's release 3.7.1 on.
> >>
> >> The ideal way to test this would be for you to compile and test GNOME
> >> Settings Daemon and GNOME Control Center.
> >> This may not be the "easy way" you are asking for though so one idea that
> >> occurs to me is for you to try a recent Fedora 19 live image:
> >>
> >> http://koji.fedoraproject.org/koji/tasks?method=createLiveCD&owner=kevin&state=all&view=tree&order=-id
> >>
> >> To make sure that the image you try has a recent version of the Control
> >> Center, don't forget to run "gnome-control-center --version".
> >>
> >>
> > Apologies, the "easy thing" I am unsure how to do is build and run an old
> > version.   I have actually compiled and run the latest
> > gnome-control-center.  And that seems to set the correct values.  At least,
> > running it several times consistently sets similar values that work.
> > (Before I put in a bug, I wanted to make sure I could reproduce in the
> > latest version.)
> >
> > However, I am now unable to reproduce this with the control center that is
> > default on my system.  The version on my machine is 3.6.3, the version I
> > built and ran is 3.8.3.  So, at this point my hunches are up.   I had
> > thought I had seen a message about defaulting to "last device calibrated"
> > somewhere.  I will try and hunt that down when I can this evening.
> >
> > Anything else I can run to try and isolate this?  (I can still run a live
> > image, if that might provide clues.)
> >
> > Thanks!
> >
> > -josh
> >
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]