Additional calibration is impossible to finish as the second (top right) target keeps showing up, not accepting the tap.

Created attachment 256452 [details] [review]
wacom: Fix device filtering in calibration UI

We receive ClutterEvents, not GdkEvents for button presses on
ClutterActors, so use the correct functions to filter devices.

This also fixes the offset used to access the coordinates of the
events. We were actually using the pointer to the source and x
struct members instead of x and y.

Comment on attachment 256452 [details] [review]
wacom: Fix device filtering in calibration UI

This was the obvious fix. Please test again, and attach the output
of "gnome-control-center --verbose" if you can reproduce the problem.

Attachment 256452 [details] pushed as 55744f6 - wacom: Fix device filtering in calibration UI

Created attachment 256680 [details]
debug output following application of patch in attachment 256452 [details] [review]

I have a Thinkpad X220 Tablet, and I experienced the exact same symptoms as Jakub with gnome-control-center 3.10.0:
- On the first calibration, I completed the calibration and received the check mark indicating a successful calibration.  However, the tablet pointer was mapped to the upper left corner at all times.
- On subsequent calibrations, the first (top left) target registered a tap and then the second (top right) target appeared.  When tapping the second target, the timeout timer reset and the target did the shrinking animation indicating that a tap was detected.  However, the target simply reappeared after the tap.  It continued to reappear after repeated taps.  The only way to end the calibration was to let it time out or kill it.

(In reply to comment #3)
> This was the obvious fix. Please test again, and attach the output
> of "gnome-control-center --verbose" if you can reproduce the problem.

After applying your patch to gnome-control-center 3.10.0, the calibration does not register any taps at all.  Tapping on the first target has causes no response (no shrinking animation) and the timer does not reset.  The calibration eventually times out.  The debug output is in the attachment above.  (I apologize for not attaching it to this comment; I'm still learning how to use Bugzilla.)

This is garbage, I'm not sure how we got to that result:
(gnome-control-center:3383): wacom-cc-panel-DEBUG: Current calibration: -2147483648, -2147483648, -2147483648, -2147483648

(In reply to comment #5)
> I have a Thinkpad X220 Tablet, and I experienced the exact same symptoms as
> Jakub with gnome-control-center 3.10.0:

You really need to use the latest master of gnome-control-center, not just the tarball. I added debug output for that purpose, but I can't help if I don't have that.

> (In reply to comment #3)
> > This was the obvious fix. Please test again, and attach the output
> > of "gnome-control-center --verbose" if you can reproduce the problem.
> 
> After applying your patch to gnome-control-center 3.10.0, the calibration does
> not register any taps at all.  Tapping on the first target has causes no
> response (no shrinking animation) and the timer does not reset.  The
> calibration eventually times out.  The debug output is in the attachment above.
>  (I apologize for not attaching it to this comment; I'm still learning how to
> use Bugzilla.)

The patch is correct, but it looks like there's other things that are broken.

The obvious one being that we don't have a way to reset the "Wacom Tablet Area" to factory values before doing calibration. I'm pretty certain that's the problem, but the lack of hardware makes this nigh on impossible to fix.

Created attachment 256701 [details] [review]
wacom: Fix event filtering in the calibrator

We were always getting the events from the core pointer instead
of the device itself. We need to get the real source device from
the event.

Created attachment 256703 [details] [review]
wacom: Fix event filtering in the calibrator

We were always getting the events from the core pointer instead
of the device itself, so threw all of them away.
We need to get the real source device from the event.

Created attachment 256713 [details] [review]
wacom: Fill in the default calibration values from the driver

When calibrating with the default values, we really don't want
to do calculations using -1 as the values. Fill in the old
configuration from the driver itself rather than relying on
the calibration tool passing us useful data.

Comment on attachment 256713 [details] [review]
wacom: Fill in the default calibration values from the driver

This was done differently.

There's 2 sets of patches, now in master.

One for gnome-settings-daemon, so it recognises and acts correctly when confronted with a "-1, -1, -1, -1" tablet area. This isn't a value supported by the driver, so we would just end up with huge calibration values instead of the default ones.

The 2nd part is in gnome-control-center, we now reset the device's calibration before starting it, and resets it to the previous value if it was cancelled or didn't succeed.

Let me know if that works for you.

> This is garbage, I'm not sure how we got to that result:
> (gnome-control-center:3383): wacom-cc-panel-DEBUG: Current calibration:
> -2147483648, -2147483648, -2147483648, -2147483648

Yeah, I thought that looked pretty far off. My guess is that one of the initial calibrations caused that, and that's why the cursor is stuck in the upper left corner following calibration. Using trial-and-error with xsetwacom, I've determined that the Area for my hardware should be approximately 0, 0, 27650, 15470. My current workaround for this bug is a shell script that runs xsetwacom to set the correct Area.

> You really need to use the latest master of gnome-control-center, not just the
> tarball. I added debug output for that purpose, but I can't help if I don't
> have that.

I'm doing testing on Arch Linux with GNOME 3.10.0.1. I'm happy to help, but since this is my primary (i.e. only) computer, I'm trying to avoid breakage by rebuilding/patching as little as possible. Is it sufficient for testing to rebuild only gnome-settings-daemon and gnome-control-center? Is the master branch still compatible with the other components of GNOME 3.10.0.1, or has it diverged too much already? Basically, do I need to rebuild other parts of GNOME from master as well?

Tested by Jakub, and working.

The fixes will be in gnome-settings-daemon and gnome-control-center 3.10.1 (or you can test master of both of those if you need early access).

Okay, thanks for fixing this! I'll just wait for 3.10.1 to come out. If I experience any remaining issues with this, I'll add another comment.

Created attachment 260079 [details]
debug output of 3.10.2 calibration, landscape orientation

I finally got around to testing this again. I'm using the released v3.10.2 of gnome-settings-daemon and gnome-control center from the Arch Linux repos. The calibration always succeeds -- all four taps register and I get a check mark at the end. However, the resulting calibration always maps the pointer to one edge of the screen, even after repeated calibrations. (It is now no longer restricted to one corner, but rather a single edge.)

I am testing on a Lenovo X220 tablet with a rotatable screen. After calibration in landscape orientation, the pointer is stuck to the right edge of the screen. After calibration in portrait orientation, the pointer is stuck to the top edge of the screen. (This is the same absolute edge of the physical tablet.) The correct calibration for the tablet area is approximately [0,0,27650,15470]. The landscape calibration gives [-38893,24,-11444,15363], and the portrait calibration gives [-69459,69,-42086,15601].

This debug output is for calibration when in landscape orientation.

Created attachment 260080 [details]
debug output of 3.10.2 calibration, portrait orientation

See comment #15.

This debug output is for calibration when in portrait orientation.