[01:32] <kenvandine> RAOF, hmm... i'm testing it on mako with silo 0
[01:32] <kenvandine> not mir_demo_server
[02:00] <RAOF> Hm.
[02:01] <RAOF> I don't know what input changes are in silo 0.
[02:34] <bschaefer> RAOF, would you know how trunk could possibly mess up reading umockdev recordings?
[02:35] <bschaefer> as ... once i merged from trunk the recordings no longer generate events in mir
[02:35] <bschaefer> soo either somehow trunk messed up new code you put in or the under the hood mir is different for handling events?
[02:51] <RAOF> bschaefer: I don't know. I'll pull your branch and investigate.
[02:52] <bschaefer> RAOF, alright, ill spend more time on it tomorrow if you've other things to get done
[02:53]  * bschaefer slightly assumes he might have messed up fixing merge conflicts
[02:53] <bschaefer> but i dont think so
[02:54] <bschaefer> RAOF, also i dont think we need the mir cookie for the basic surface validation meaning we can reduce a lot of code changing
[02:54] <bschaefer> (since a 0 should be a find value). Though i want to check if i even need to edit that make_event to begin with
[02:54] <RAOF> Right. You can certainly get part of the way through without actually plumbing in the real cookie.
[02:55] <RAOF> It'll just be useless :)
[02:55] <bschaefer> yup, i was slightly lost when doing it at first and am trying to refine a lot of my changes
[02:56] <bschaefer> mainly wanted to get all touch/keyboard/pointer to get cookies, but really only keyboard events + up/down events *need*
[02:56] <bschaefer> cookies
[02:58] <RAOF> Right.
[02:59] <RAOF> Well, mostly.
[02:59] <RAOF> Touch begin/end probably need cookies, too. (As that's how “clicks” happen on touchscreens)
[03:05] <bschaefer> well hmm right from what i can tell the validator does a very small touch event
[03:05] <bschaefer> only 3 args
[03:05]  * bschaefer needs to figure out the best way for that
[10:05] <duflu> greyback: On my way to EOD, but was wondering... Do you have any idea why scrolling with a constant finger touch in Qt feels like it's missing frames? Significantly less smooth than a fling...
[10:05] <greyback> duflu: it's something I've also observed, but thus far I've no good explanation
[10:06] <duflu> I would have said it's just keeping up with the finger by jumping. But then noticed Android doesn't have the problem and neither to mir-demos
[10:06] <duflu> neither do
[10:06] <greyback> I investigated if the input events received by the client were smooth - and they are
[10:07] <duflu> greyback: I know... we have some roughly equivalent mir-demos and they are smooth
[10:07] <greyback> duflu: yeah but I'm testing using unity8 here
[10:07] <duflu> greyback: On that note, does the --desktopfile trick still work?
[10:07] <greyback> duflu: yep
[10:08] <duflu> Hmm, OK. Another day.
[10:08] <greyback> I want to improve qtmir's releasing buffer after swap, which might help
[10:09] <duflu> greyback: Yeah I've got it "done". Just held up by the related Mir fix waiting to land. Then I need to recombine and retest them
[10:09] <greyback> duflu: really? care to share?
[10:10] <duflu> greyback: Work in progress, and don't expect to see any benefit without the Mir fix coming in 0.16... https://code.launchpad.net/~vanvugt/qtmir/supersmooth
[10:10] <greyback> duflu: ok cool
[10:12] <duflu> greyback: Hmm, actually that looks old
[10:12] <duflu> I think I had a newer one
[10:13] <greyback> well you're doing the right things
[10:13] <duflu> greyback: Oh, that is the latest
[10:14] <ogra_> duflu, fyi, i'm running my arale with GPU at full speed (using the sysfs hack from the mail thread) ... it ois a lot smoother and less stuttery ... but i'D guess it also eats about 10% more battery over time
[10:14] <ogra_> (i dont think we have any GPU scaling at all on the other phones)
[10:14] <duflu> ogra_: Yeah I noticed raising the minimum frequency helped, but not as much as having the extra cores enabled
[10:15] <ogra_> we need ToyKeeper to measure the different scenarios for us ;) she has accurate power measurement tools
[10:18] <greyback> duflu: what mir commit would I need to test?
[10:18] <duflu> greyback: The current MP "earlier release"
[10:19] <duflu> greyback: https://code.launchpad.net/~vanvugt/mir/earlier-release/+merge/267321
[10:19]  * duflu wanders off
[10:19] <greyback> duflu: thanks!
[11:35] <alan_g> alf_: got headspace to discuss the remaining test failure I've got?
[11:35] <alf_> alan_g: sure
[11:36] <alan_g> I'm seeing an FD leak in some of the VariousDevices/EventHubDeviceEnumerationTest* tests. Specifically, those that call add_standard_device()
[11:37] <alan_g> That allocates FDs in umockdev_testbed_load_ioctl() - which are never released
[11:37] <alan_g> But none of this is new code - so how did it ever pass?
[11:38] <alf_> alan_g: Can you point me to a failure backtrace?
[11:40] <alan_g> http://paste.ubuntu.com/12117630/
[11:47] <alan_g> alf_: ^ any thoughts?
[11:49] <alf_> alan_g: Yes. I had put an exception for this case in detect_fd_leaks (checking for "g_dbus" in the backtrace), but in the new backtrace there is "bin doc src lib" instead of the g_dbus_* function names
[11:50] <alf_> alan_g: That's a thought, let me confirm this
[11:50] <alan_g> alf_: that makes sense.
[11:51] <alan_g> (although the backtrace doesn't)
[11:53] <alan_g> I guess another exception for "mir_test_framework::UdevEnvironment::add_standard_device" would be specific enough
[12:07] <alf_> alan_g: So, yes, I remembered that I was getting the g_dbus related errors locally, not in CI (probably because dbus is not running in the CI chroot?).
[12:07] <alf_> alan_g|lunch: ^^
[12:09] <alan_g|lunch> alf_: yep. I've MP'd the above (to see if anything remains that I haven't got locally)
[12:54] <mterry> alf_, hello!  Thanks for taking over that timeout branch for me.  I added a comment in your MP
[12:55] <alf_> mterry: No problem, thanks for the original fix :)
[12:59] <alf_> mterry: Let me try your idea...
[13:11] <alf_> mterry: Your idea looks good. Would you like to incorporate the tests in your branch (+the max() idea)?
[13:12] <mterry> alf_, I'm in a meeting right now, so you can run with it
[13:12] <alf_> mterry: ok
[13:22] <alf_> mterry: Change applied. Thanks!
[13:22] <alf_> mterry: (and tested on arale)
[13:22] <mterry> alf_, sweet, I approved the branch from my side.  But maybe get a real mir folk to also look at it
[21:56] <bschaefer> RAOF, for when you get on, thanks for fixing that test (had no idea i had to include that...)
[21:56] <bschaefer> now for the basic_suface validator
[21:56] <bschaefer> i would love to remove the need for the cookie factory, the only issue is the default event that is needed
[21:56] <bschaefer> if theres no prev events
[21:57] <bschaefer> now... i've clue when a default event would ever happen, or if its save enough to ignore the mac for a default event that we needed to generate
[21:57] <bschaefer> (im assuming yes its ok to ignore a mac for it since its just a bare bone vent)
[21:57] <bschaefer> evet*
[21:59] <bschaefer> soo now im starting to think the default touch event will have 0 pointer count meaning it will not have a down/up action
[21:59] <bschaefer> meaning we can remove the need to generate a valid mac for that
[21:59]  * bschaefer double checks the default value for a make_event for a touch event
[22:01] <bschaefer> hmm  and now looking at that, the pointer_count variable for the new motion event is not being defined and everything is memset to 0
[22:01] <bschaefer> soo yay no need for a cookie there since there will never be a up/down event or a default event if theres no prev touch event
[22:01] <bschaefer> RAOF, IGNORE MY PING