| === tvoss|gftd is now known as tvoss | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| dandrader | bregma, any news on that geisv1 bug that doesn't report existing devices on start up? should I report it? | 12:36 |
|---|---|---|
| dandrader | make a bug report, I mean | 12:37 |
| bregma | I'm looking in to it this morning | 12:47 |
| bregma | yep, there's definitely a bug in the geis v1 implementation introduced by the synchronous start feature | 13:13 |
| bregma | I'll create a bug and work on that today | 13:14 |
| dandrader | ok. | 13:19 |
| dandrader | I wish we could have dependencies between bugs in launchpad | 13:19 |
| 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:14 | |
| 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:15 |
| 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:16 |
| === dandrader is now known as dandrader|afk | ||
| Satoris | cnd: did you get my mail yesterday? | 14:21 |
| cnd | Satoris, yeah, I just didn't get time to respond | 14:22 |
| cnd | Satoris, thanks for pushing for the unity 2d fix :) | 14:22 |
| 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:23 |
| Satoris | And not magical as in ponies and rainbows. | 14:24 |
| bregma | dbus is the devil's work | 14:27 |
| === dandrader|afk is now known as dandrader | ||
| 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:19 |
| bregma | gtest_instance.cpp:31 is the line where the device is created | 15:23 |
| cnd | oh I see | 15:26 |
| cnd | why do you have the comma on the next line? | 15:26 |
| cnd | bregma, if you make a release you might be able to get it in right before the final freeze later today | 15:41 |
| 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:43 |
| bregma | (crash using remote access from a machine without XI2.2) | 15:44 |
| cnd | bregma, I approved the device report MP | 15:49 |
| cnd | bregma, is there another outstanding? | 15:49 |
| bregma | nope, that should be it (unless I can repro #976432 and find a fix, which is unlikely) | 15:50 |
| 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:53 |
| dandrader | true | 15:56 |
| === dandrader is now known as dandrader|lunch | ||
| 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:31 |
| cnd | just fyi, a reminder to double check before merging | 16:32 |
| 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:52 |
| cnd | bregma, you can mark it as fix released but ask people to reopen if they hit it again | 16:57 |
| cnd | bregma, actually, you should dupe it, but ask people to undupe if they reproduce it | 16:58 |
| 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:02 |
| 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:08 |
| bregma | geis 2.2.9 is uploaded to the UNAPPROVED queue, should be in by deadline..... | 17:53 |
| bregma | for those keeping score at home, https://launchpad.net/ubuntu/precise/+queue?queue_state=1 | 17:59 |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | bregma, great! | 18:17 |
| 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:18 |
| dandrader | got it | 18:19 |
| 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:45 |
| 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:46 |
| 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:47 |
| dandrader | who knows, maybe that's tied to focus or something... (only focused window can move) | 20:48 |
| dandrader | but probably it's fine | 20:48 |
| === dandrader is now known as dandrader|afk | ||
| 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:00 |
| === dandrader|afk is now known as dandrader | ||
| cnd | bregma, the window for uploading geis is closing quickly :) | 21:07 |
| 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:29 |
| 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:30 |
| dandrader | what does it mean to be an owner? | 21:32 |
| cnd | it's easiest to give an example | 21:33 |
| cnd | you have a finger painting application | 21:33 |
| cnd | running in unity | 21:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| dandrader | cnd, is this ownership concept coming from XInput? | 21:40 |
| cnd | yes | 21:40 |
| 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:42 |
| 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 | 21:43 |
| dandrader | this seems to explain things well http://lwn.net/Articles/485484/ :) | 22:02 |
| cnd | heh | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!