[12:36] <dandrader> bregma, any news on that geisv1 bug that doesn't report existing devices on start up? should I report it?
[12:37] <dandrader> make a bug report, I mean
[12:47] <bregma> I'm looking in to it this morning
[13:13] <bregma> yep, there's definitely a bug in the geis v1 implementation introduced by the synchronous start feature
[13:14] <bregma> I'll create a bug and work on that today
[13:19] <dandrader> ok.
[13:19] <dandrader> I wish we could have dependencies between bugs in launchpad
[14:14] <tvoss> added doxygen documentation for frame's generic backend, worked on chromium patch to get rid of duplicated enumeration values
[14:14]  * bregma drains the cold dregs from his mug
[14:15] <bregma> fixin' a GEISv1 bug
[14:15] <bregma> #979855
[14:15] <cnd> I think I have fixed all the big touchscreen bugs, I'm waiting on user testing
[14:15] <dandrader> rebasing my port of unity gestures code to geisv2 api on top of the changes made by the fix for https://bugs.launchpad.net/unity/+bug/978378
[14:16] <Satoris> I have been slightly ill today, so I have done some research, read code and rested.
[14:16] <bregma> is that because you have a bug touchscreen?
[14:16] <bregma> s/bug/big/
[14:16] <cnd> so I'll have to find bugs to work on, or make architectural diagrams :)
[14:16] <cnd> bregma, no, just big bugs :)
[14:21] <Satoris> cnd: did you get my mail yesterday?
[14:22] <cnd> Satoris, yeah, I just didn't get time to respond
[14:22] <cnd> Satoris, thanks for pushing for the unity 2d fix :)
[14:23] <Satoris> No prob. I'm just glad the devs fixed it once I had traced it to a single line. The D-Bus fix they produced was quite magical.
[14:23] <cnd> heh
[14:24] <Satoris> And not magical as in ponies and rainbows.
[14:27] <bregma> dbus is the devil's work
[15:19] <cnd> bregma, in the test case for the device report fix, I don't see any device being created
[15:19] <cnd> if the test is run on a machine without a multitouch input device, won't this fail?
[15:23] <bregma> gtest_instance.cpp:31 is the line where the device is created
[15:26] <cnd> oh I see
[15:26] <cnd> why do you have the comma on the next line?
[15:41] <cnd> bregma, if you make a release you might be able to get it in right before the final freeze later today
[15:43] <bregma> all I need is a an acceptable merge request review and I'm good to go
[15:43] <bregma> I particularly want to get the fix for 973539 in
[15:44] <bregma> (crash using remote access from a machine without XI2.2)
[15:49] <cnd> bregma, I approved the device report MP
[15:49] <cnd> bregma, is there another outstanding?
[15:50] <bregma> nope, that should be it (unless I can repro #976432 and find a fix, which is unlikely)
[15:53] <dandrader> Does geis v2 also provides the attributes GEIS_GESTURE_ATTRIBUTE_TOUCH_N_[ID|X|Y] in its frames or is it only used by Geis v1?
[15:53] <bregma> only GEISv1
[15:53] <bregma> it's a terrible way to reportdata
[15:56] <dandrader> true
[16:31] <cnd> dandrader|lunch, your merge for https://code.launchpad.net/~dandrader/utouch-grail/tap_threshold_doc/+merge/101648 is fine, I'm sure, but note that no one actually approved it :)
[16:32] <cnd> just fyi, a reminder to double check before merging
[16:52] <bregma> hmm, I think the fix for #973539 should also prevent #976432 (crashes in geis) but unless I can repro it I can not be certain
[16:57] <cnd> bregma, you can mark it as fix released but ask people to reopen if they hit it again
[16:58] <cnd> bregma, actually, you should dupe it, but ask people to undupe if they reproduce it
[17:02] <bregma> it's not a dupe so much as the fix for  #973539 should prevent whatever causes #976432 from resulting in a crash, so marking as fixed released (once #973539 is released) is the best plan
[17:08] <bregma> dandrader|lunch, I went ahead and merged https://code.launchpad.net/~dandrader/utouch-geis/doc_touch_defines/+merge/101765 so I can get a geis release out before cutoff (in less than 3 hours)
[17:53] <bregma> geis 2.2.9 is uploaded to the UNAPPROVED queue, should be in by deadline.....
[17:59] <bregma> for those keeping score at home, https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[18:17] <dandrader> bregma, great!
[18:18] <dandrader> cnd, I merged with the modification you said
[18:18] <cnd> yeah, it's not a big deal, it's just a pedanticism ;)
[18:19] <dandrader> got it
[20:45] <dandrader> cnd, should unity support moving two different windows at the same time (e.g. one with each hand)?
[20:45] <cnd> dandrader, I think so
[20:45] <cnd> but it will only be possible with geis 2 and without atomic gestures
[20:46] <cnd> that's one valid use case for the "regular" recognizer path
[20:46] <dandrader> finally i found a case for geis v2 in unity :)
[20:47] <cnd> yep :)
[20:47] <dandrader> now if compiz support such things (two windows being moved at the same time) is another question
[20:47] <cnd> well, that and the threshold setting
[20:47] <cnd> I would be surprised if compiz didn't
[20:48] <dandrader> who knows, maybe that's tied to focus or something... (only focused window can move)
[20:48] <dandrader> but probably it's fine
[21:00] <cnd> yay, I have block diagrams of utouch, utouch-frame, and utouch-grail
[21:00] <cnd> it should be shared with you guys now
[21:07] <cnd> bregma, the window for uploading geis is closing quickly :)
[21:29] <dandrader> cnd, is it possible for unity and an application to both receive the touch events from xserver, at the same time?
[21:29] <cnd> dandrader, yes and no
[21:29] <cnd> applications *can* receive events as soon as they physically occur
[21:30] <cnd> however they do not become owners until everyone before them rejects
[21:30] <cnd> that's one option
[21:30] <cnd> but normally, unless they really care, they will only receive events once they become the owner of the touch sequence
[21:32] <dandrader> what does it mean to be an owner?
[21:33] <cnd> it's easiest to give an example
[21:33] <cnd> you have a finger painting application
[21:33] <cnd> running in unity
[21:34] <cnd> if I perform a three touch drag over the application, unity will intercept the touches
[21:34] <cnd> unity is always the first owner because it listens on the root window
[21:35] <cnd> if the painting app has requested for "ownership" semantics, it will also receive the touch events
[21:35] <cnd> however, once unity has accepted the touches (by accepting the gesture or by grail doing it through the atomic recognizer), the painting app will be notified
[21:35] <cnd> and it will have to undo anything it might have done
[21:36] <cnd> so the painting app could have started drawing immediately, effectively allowing for 0 latency drawing even with unity in the way
[21:36] <cnd> but then it would have to undo the drawing as soon as it is notified that someone above it has accepted the touches
[21:37] <cnd> if a client owns the sequence through a touch grab, like unity does, it must accept or reject the sequence
[21:37] <cnd> if a client owns a sequence through an X event selection, then it will implicitly accept the touch sequence once it receives it
[21:40] <dandrader> cnd,  is this ownership concept coming from XInput?
[21:40] <cnd> yes
[21:42] <dandrader> so if unity does a touch grab the painting app will never get any 3-touch stuff because unity immediately owns the touches until it rejects them?
[21:42]  * dandrader a bit confused now
[21:42] <cnd> dandrader, it depends on what the painting app has asked for
[21:42] <cnd> if it only asks for normal touch events, then it will never get any 3-touch events
[21:43] <cnd> because unity will always receive ownership and then accept them
[21:43] <cnd> however, if the painting app asks for ownership events, then it will get all the events at the same time as unity receive them
[21:43] <cnd> but it will never become the owner of them
[21:43] <cnd> because unity will always accept them
[22:02] <dandrader> this seems to explain things well http://lwn.net/Articles/485484/ :)
[22:19] <cnd> heh