[14:56] <cnd> dandrader, can you review my grail merge proposals soon?
[14:57] <cnd> we need to get them in, and your fix in today
[14:57] <cnd> before the beta 2 freeze tomorrow
[14:57] <dandrader> cnd, sure. Right after I finish the refactoring I'm doing on my merge proposal as per your comment
[14:57] <dandrader> comments
[14:57] <cnd> cool
[14:57] <cnd> thanks :)
[15:15] <tvoss> Spending some quality time with Jenkins and Google Test/Google Mock, Prepared packaging for patched chromium
[15:16] <bregma> I got utouch-geis up-to-speed on libxorg-gtest-dev, now back to the grind on #904731 and #944822, pending merge-request-reviews
[15:17] <dandrader> I'm refactoring the test in my merge proposal for utouch-grail according to comments received from Chase
[15:18] <cnd> I'm fixing up utouch-frame for the new xorg-gtest, and then I'll be releasing frame and grail upstream and for precise
[15:18] <cnd> Satoris won't be around for standups on wednesdays for a while
[15:18] <cnd> just fyi
[15:19] <bregma> Wednesdays have always been special to his people
[15:26] <cnd> bregma, just reviewed your branch
[15:53] <cnd> I'm stumped by this failure: http://paste.ubuntu.com/893791/
[15:53] <cnd> it attempts to link a program
[15:53] <cnd> it complains about not finding the evemu symbols in libxorg-gtest.a
[15:54] <cnd> but I have -lutouch-evemu before libxorg-gtest.a on the command line
[15:54] <bregma> link order is significant
[15:54] <cnd> yeah, and I think I have it in the right order
[15:54] <bregma> no, it's in the reverse order
[15:55] <cnd> argh
[15:55] <cnd> yeah
[15:55] <cnd> I got switched up
[15:55] <bregma> now fight with libtool to get things in the right order
[15:56] <bregma> although that bug ni libtool was probably fixed years ago
[16:29] <cnd> dandrader|lunch, I just reviewed your branch
[16:29] <cnd> looking good :)
[16:36] <cnd> alright, I've got all the merge proposals out that I wanted to get into beta 2
[16:37] <cnd> as soon as they are all merged into grail and frame I'll be making releases
[16:37] <cnd> biab
[18:11] <Satoris> cnd: ping
[18:11] <cnd> Satoris, pong
[18:11] <cnd> oh right
[18:11] <cnd> sorry!
[18:11] <cnd> I should have replied
[18:21] <dandrader> cnd, about https://code.launchpad.net/~chasedouglas/utouch-grail/fix-tap-touch-accept/+merge/98478
[18:22] <dandrader> what's the effect of accepting of rejecting a touch that has already ended?
[18:22] <dandrader> s/of/or
[18:32] <cnd> dandrader, all touches must be accepted or rejected no matter what
[18:32] <cnd> if a touch has ended, then when you reject, the entire touch sequence will be replayed to further X clients
[18:32] <cnd> so imagine you have a finger paint app open
[18:33] <cnd> you tap on the screen with one finger
[18:33] <cnd> the touch ends before grail rejects the tap
[18:33] <cnd> grail still needs to reject it, and then the X server will resend the touch event sequence to the finger painting app
[18:35] <dandrader> ChickenCutlass,  you mean it will resend the touch event sequence to a X client other than the finger painting app, right?
[18:35] <dandrader> cnd, ^
[18:36] <dandrader> damn auto-completion
[18:37] <cnd> dandrader, no, it will resent it to the finger painting app
[18:37] <cnd> here, I'm assuming grail is being used through unity
[18:37] <cnd> so unity's grail touch grab is rejecting the touch
[18:37] <cnd> and then the finger paint application will receive the touch sequence
[18:38] <dandrader> ah, ok
[20:27] <cnd> dandrader|afk, bregma: I need one last review: https://code.launchpad.net/~chasedouglas/utouch-frame/fix-visibility2/+merge/98725
[20:27] <cnd> it's necessary before we make a release of utouch-frame
[20:29] <cnd> dandrader, btw, you don't need to fully resubmit a merge proposal
[20:29] <cnd> merely updating the branch will suffice :)
[20:30] <cnd> you can signify that you've fixed things and it is ready for review again by leaving a comment with a review type of "Resubmit"
[20:33] <dandrader> ok, that will probably make the review simpler as you can just look at the new commits containing the changes caused by the review comments
[20:33] <dandrader> than I can squash them all before pushing to trunk
[20:33] <dandrader> s/than/then
[20:39] <cnd> dandrader, you don't really need to squash them even
[20:39] <cnd> you just merge them in
[20:40] <cnd> and they'll appear to be one commit
[20:40] <cnd> then you can still drill down into the history if you really want
[20:45] <dandrader> but those commits that are just fixes coming from review comment just clutter the history
[20:51] <cnd> dandrader, if you don't want to see the clutter, then just diff from the beginning to the end of the rview
[20:51] <cnd> which will normally be the diff of the merge itself
[20:51] <cnd> dandrader, your testcase is failing
[20:51] <cnd> it's in the jenkins instance
[20:56] <cnd> dandrader, I can confirm the failure here
[20:56] <cnd> I need to grab a sandwich
[20:56] <cnd> then I'll try to figure out what's going wrong
[20:56] <cnd> it looks like bad events are being fed into frame though...
[20:56] <cnd> that would cause the "Warning: failed to get previous touch value"
[21:12] <dandrader> damn, I'm not getting any failure here with current trunk versions of utouch-frame and utouch-grail...
[21:13] <cnd> dandrader, I don't have the current frame installed, let me double check
[21:15] <dandrader> from the error it seems that nothing was played
[21:16] <dandrader> as the slice checker was still on its first state, which check for a Begin slice from the touch gesture
[21:17] <dandrader> cnd, have you run that ParallelAtomicGestures test before on your machine?
[21:17] <cnd> dandrader, not until just now
[21:17] <cnd> I assumed it would work
[21:17] <dandrader> :)
[21:18]  * cnd can't wait until we have proper jenkins support
[21:18] <dandrader> could you check if the recording plays correctly on your machine?
[21:18] <cnd> yeah, I'm just setting up frame right now
[21:18] <cnd> from scratch
[21:18] <cnd> to be sure
[21:19] <cnd> dandrader, with the latest utouch-frame it fails in the same way here
[21:23] <cnd> dandrader, I just noticed that you copied in the asynchronous playing of the recording
[21:23] <cnd> which I just removed from all the other tests :)
[21:23] <cnd> I should have caught that in review
[21:24] <cnd> but sadly it's not the cause of the failure
[21:24] <cnd> dandrader, here's my output with grail debugging: http://paste.ubuntu.com/894298/
[21:25] <cnd> let me know if you can make anything out
[21:25]  * dandrader reads...
[21:28] <dandrader> that touch 4 is coming way too soon
[21:28] <dandrader> with the same timestamp as touch 3
[21:29] <dandrader> causing all gestures to be canceled before they have a chance to do anything
[21:29] <dandrader> when I did the recording the 4th touch should come just by the end of the recording
[21:30]  * cnd tries to read the recording
[21:32] <cnd> the fourth touch starts at 1331926701.180596
[21:32] <cnd> the beginning is 1331926700.835657
[21:32] <cnd> the end is 1331926701.548991
[21:32] <cnd> so it's about half way between the beginning and the end
[21:33] <cnd> but the whole recording is less than one second long
[21:33] <cnd> does that seem right?
[21:34] <cnd> in the debug output, gestures 0, 1, and 2 start at time 691389450
[21:34] <cnd> the first touch began at time 691389450
[21:34] <cnd> same time
[21:35] <cnd> the fourth touch begins at time 691389450
[21:35] <cnd> which is the same time again...
[21:35] <cnd> that doesn't seem right
[21:38] <dandrader> could you try to play it with evemu-play and watch it with mtview?
[21:40] <cnd> yeah,
[21:41] <dandrader> cnd, http://ubuntuone.com/3zGHZA1ILFUm6LgFrhEYOZ
[21:41] <dandrader> this is what I get in the end
[21:41] <dandrader> the pink blot is the fourth touch that comes late
[21:44] <cnd> dandrader, using evtest, I see the three touches begin at time 1332366154.522432, and then the fourth touch begins at time 1332366154.879781,
[21:44] <cnd> so it is coming out of evdev about .35 seconds later than the first three touches
[21:45] <bregma> arthritis slows you down
[21:45] <cnd> which is accurate, according to the recording
[21:45] <cnd> so the touch events are getting coallesced in the x servre
[21:45] <cnd> server*
[21:46] <cnd> 0.35 s is a long time for the server to be sitting around...
[21:51] <dandrader> since grail now deals with timestamps, it would be nice if in the tests we could feed the events directly to grail instead of sending via an evdevice, through xserver, in realtime. Then all tests could be run in a split second and there would be less external interferences in the tests (if any)
[21:52] <dandrader> I wonder if we are running the same version of xserver...
[21:53] <cnd> dandrader, then we would be wondering why gesture recognition isn't occurring properly in real life :(
[21:53] <cnd> we could do what you suggest, but we would still need integration tests
[21:53] <cnd> I'm looking at the X code
[21:54] <cnd> and it gets its time from either clock_gettime() or from gettimeofday()
[21:54] <cnd> and events are processed in sigio context, so they should be getting their timestamps immediately
[21:54] <cnd> so what's going on...
[21:54]  * cnd goes to build a debug server with timestamp printouts
[21:58] <dandrader> I think it would be good to have both kinds of tests.
[21:59] <cnd> yeah, no doubt
[21:59] <cnd> but I think if we have only one, they should be integration
[21:59] <dandrader> I agree
[21:59] <cnd> we need to find the resources for more testing :)
[22:01] <cnd> actually, something doesn't seem right...
[22:02] <cnd> wait, nm
[22:03] <cnd> I'm wondering if the first <X> events aren't being posted
[22:03] <cnd> they are just getting dropped until the fourth touch comes along
[22:03] <cnd> dandrader, is this on a trackpad?
[22:03] <cnd> I know what's going on...
[22:03] <dandrader> yes, the apple wireless one
[22:04] <cnd> dandrader, the default X synaptics properties are filtering touch events until 4 touches are present
[22:04] <dandrader> ah! one thing is that I don't have the synaptics x driver installed on my machine!
[22:04] <cnd> aha
[22:05] <cnd> dandrader, if you redo the recording with 4 and 5 touches instead of 3 and 4, it should pass the test just fine
[22:06] <cnd> though this raises the question of why in ubuntu X synaptics is withholding 3 touch gestures
[22:06] <cnd> it shouldn't be doing that
[22:09] <cnd> hmm, I'm getting touch events
[22:10] <cnd> oh wait
[22:11] <cnd> no, I'm not
[22:11] <cnd> why...
[22:16] <cnd> ok, there's a bad default in xf86-input-synaptics
[22:18] <cnd> aha
[22:18] <cnd> ok, I know what has happened
[22:18] <cnd> I need to upload a fix to xf86-input-synaptics
[22:19] <cnd> dandrader, when I fix xserver-xorg-input-synaptics in an upload I'm making today, it should start working again
[22:19] <dandrader> great!
[22:19] <cnd> no need to make any changes, though the test needs to be made non-async
[22:19] <cnd> so we can run it through valgrind
[22:19] <cnd> if you're at your EOD, it can wait
[22:20] <cnd> phew, I was worried X timestamps were so unreliable they were coallescing events .35 seconds apart :)
[22:21] <cnd> dandrader, make sure you have synaptics installed from now on :)
[22:21] <dandrader> just installed it and rebooted
[22:21] <dandrader> because I can't seem to be able to connect to my trackpad still
[22:22] <cnd> hmm? you can connect when using evdev but not synaptics?
[22:23] <dandrader> before I installed the synaptics driver I was able to pair with it effortlessly. but after I installed I cannot pair. might just be a coincidence...
[22:24] <dandrader> well, will get back to it tomorrow. but hey, in the end you found a new bug! :)
[23:03] <cnd> bregma, will you be uploading utouch-geis soon?
[23:03] <cnd> we need to get the tap fixes into precise for beta 2, at the very least