[00:01] <bschaefer> RAOF, hmm the only thing i can do with a surface event is: MirSurfaceAttrib mir_surface_event_get_attribute(MirSurfaceEvent const* ev);
[00:02]  * bschaefer thought a new function to check if surface was visible was around
[00:02] <bschaefer> though: mir_surface_attrib_focus should be set
[00:03] <RAOF> Right.
[00:03] <RAOF> You get mir_surface_event_get_attribute, check that it's mir_surface_attrib_focus, and can then mir_surface_event_get_attribute_value, which should be mir_surface_focused.
[00:04] <RAOF> bschaefer: Hah!
[00:04] <bschaefer> RAOF, ?
[00:05] <RAOF> Fun fact: load_device_evemu doesn't wait for the device replay to finish before returning.
[00:05] <RAOF> Which is sensible.
[00:05] <bschaefer> RAOF, so the test is finishing before the events get through?
[00:05] <RAOF> So what's happening is that the test is quitting before the device replay starts.
[00:05] <RAOF> Yup.
[00:05] <bschaefer> dang, i like... thought about that
[00:05] <bschaefer> last week and ended up looking at the udev source code
[00:05] <RAOF> If you put a sleep after load_device_evemu you get events.
[00:05] <bschaefer> but stopped
[00:05] <bschaefer> haha
[00:06]  * bschaefer was getting focused events
[00:06] <RAOF> Yup.
[00:06] <RAOF> So the right thing to do will be to block the test until an input event is received.
[00:06] <bschaefer> RAOF, is there a reasonable way to get when the replay starts?
[00:06] <bschaefer> o right thats better
[00:06] <RAOF> :R(
[00:06] <RAOF> :)
[00:07] <bschaefer> sad face its failing
[00:07]  * bschaefer wonders what he did wrong
[00:07] <bschaefer> HERE WE ARE: 1439251644004809000 - 14631743400016030123
[00:07] <bschaefer> its close ...
[00:08]  * bschaefer doesnt remember where that print statement even is
[00:09] <bschaefer> whats weird is that print statement isnt even there any more ... hmm why didnt that get recompiled out of there
[00:09]  * bschaefer most likley forgot to install the changes
[00:10] <RAOF> :)
[00:10] <RAOF> Install?
[00:10] <RAOF> You can run out of the build tree easily.
[00:10] <bschaefer> yeah
[00:10] <bschaefer> o really?
[00:10] <bschaefer> i just usually run off staging
[00:11] <bschaefer> RAOF, just do a LD_LIBRARY_PATH to where they are built?
[00:12] <RAOF> Everything's built with a wrapper that sets the right variables.
[00:12] <bschaefer> RAOF, o so just use that wrapping in bin?
[00:12] <RAOF> You should be able to do build/bin/mir_unit_tests and have it all run correctly.
[00:12] <RAOF> Yeah.
[00:12] <bschaefer> well that makes things easier
[00:12] <bschaefer> RAOF, i think whats happening is your tests runs off the android lexicon
[00:12] <bschaefer> which is set to 0
[00:12] <bschaefer> for the timestamp
[00:13] <bschaefer> no
[00:13] <bschaefer> wait...
[00:13] <bschaefer> T: (18954176 + 12574245) 7571075335272719900 which is
[00:13] <bschaefer> cookie.timestamp, cookie.mac == calculated mac
[00:13] <bschaefer> hmm somethings is off somewhere
[00:14] <bschaefer> as your verify uses the cookie timestamp to get a mac
[00:15] <RAOF> That would be right?
[00:15] <bschaefer> yeah it is .. im just wondering whats going on with my mac
[00:16] <bschaefer> ie. why is my mac not the correct value, as it should either be 0 or a correct value (from what i've done so far)
[00:16] <bschaefer> so it seems i've either missed a spot, or am doing something wrong :)
[00:16] <RAOF> Is it just random stack garbage?
[00:17] <RAOF> If you haven't explicitly set it to something it's quite possible that it's just whatever happened to be on the stack.
[00:17] <bschaefer> RAOF, right which means i've missed a location
[00:18] <bschaefer> (in where an event is created)
[00:18] <bschaefer> which could be in the test code it self :)
[00:18] <bschaefer>     at /home/bschaefer/src/attestable-timestamps-client/tests/mir_test_framework/fake_input_device_impl.cpp:246
[00:19] <bschaefer> RAOF, the thing is i already came through here and gave all the mac values a 0
[00:19] <bschaefer> as it wouldnt have compiled otherwise
[00:19] <RAOF> Ah, this isn't a fake input device.
[00:20] <RAOF> This is a fully armed and operational input device.
[00:20] <bschaefer> RAOF, hmm this is where the code path is coming from for a make event
[00:20] <bschaefer> on a mir key event
[00:20] <bschaefer> but still, i set the mac to 0 :)
[00:20] <bschaefer> unless i just miss placed the mac ...
[00:21] <bschaefer> with a random uint64
[00:21] <RAOF> :)
[00:23] <bschaefer> but i did it after the timestamp, and thats what i did in the fake inptu device
[00:23] <bschaefer> RAOF, are you saying that we shouldnt be getting the events through the fake input stack?
[00:23] <RAOF> Right.
[00:23] <RAOF> I would expect you to get the events through the normal input stack, because that's what load_device_evemu does.
[00:23] <bschaefer> hmm now i wonder why thats happening...
[00:23] <bschaefer> right it should be a real input device
[00:24] <RAOF> It creates a real* evdev device and makes it produce real* events.
[00:24] <RAOF> *For values of “real” which are provided by a LD_PRELOAD shim, but whatever ;)
[00:24] <bschaefer> did a break on:
[00:24] <bschaefer> mir::events::make_event(long, std::chrono::duration<long, std::ratio<1l, 1000000000l> >, unsigned long, unsigned int, MirPointerAction, unsigned int, float, float, float, float, float, float)
[00:25] <bschaefer> best part is i can see:
[00:25] <bschaefer> mir::events::make_event (device_id=0, timestamp=..., mac=0, modifiers=0, action=mir_pointer_action_motion, buttons_pressed=0, x_axis_value=99, y_axis_value=99,
[00:25] <bschaefer>     hscroll_value=0, vscroll_value=0, relative_x_value=99, relative_y_value=99)
[00:25] <bschaefer> soo mac = 0
[00:25] <RAOF> Why would that get hit at all? We're sending key events, not pointer events.
[00:25]  * bschaefer finds these functions to have a lot of arguments
[00:25] <bschaefer> o
[00:25] <RAOF> Yeah, not my favourite interfacae :)
[00:25] <bschaefer> i used the wrong one
[00:25] <bschaefer> RAOF, yeah i find that strange to be honest... as you did a keyboard recording...
[00:25] <bschaefer> where is the mouse event coming through?
[00:26] <bschaefer> events::make_event(long, std::chrono::duration<long, std::ratio<1l, 1000000000l> >, unsigned long, MirKeyboardAction, unsigned int, int, unsigned int)
[00:26] <bschaefer> the right one :)
[00:27] <bschaefer> RAOF, still coming through the fake input dev
[00:27] <bschaefer> RAOF, urrg
[00:27] <bschaefer> RAOF, ignore all of this
[00:27]  * bschaefer forgot to filter
[00:27] <bschaefer> and was hitting it on a random other test
[00:27] <RAOF> :)
[00:28] <bschaefer> now it makes sense why we hit the pointer break :)
[00:28] <RAOF> :)
[00:28] <bschaefer> RAOF, we never actually hit a make event
[00:28] <bschaefer> for a keyboard action
[00:29]  * bschaefer goes back to swapping 3 buffers and sleeping 1 second
[00:30] <RAOF> Run with MIR_CLIENT_INPUT_RECEIVER_REPORT=log and you'll see that you're really getting keyboard events.
[00:31] <bschaefer> RAOF, thanks gdb is not as friendly it would seem
[00:33] <bschaefer> strange but good news i think
[00:33] <bschaefer> SETTING MAC VALUE: 14215524572544855579
[00:33] <bschaefer> SETTING MAC VALUE: 0
[00:33] <bschaefer> both those come in at the same time
[00:34] <bschaefer> (for one DOWN event)
[00:34] <bschaefer> which; 14215524572544855579
[00:34] <bschaefer> is the expected value
[00:34] <bschaefer> soo now to figure out hwy...
[00:35] <RAOF> :)
[00:50]  * bschaefer fears its the android lexicon
[00:51] <bschaefer> RAOF, yes: SETTING MAC VALUE: 17 -- 1
[00:51] <bschaefer> RAOF, soo whats strange... why do we get a different make_event?
[00:51] <bschaefer> before the android lexicon?
[00:51]  * bschaefer needs to figure out the stack a bit better...
[00:51]  * bschaefer hard coded 17 to be set for the mac only in the android lexicon part
[00:52]  * RAOF admits that's a bit of the input stack he's not super familiar with.
[00:52] <bschaefer> RAOF, well sounds like a good part for me to get familiar with :)
[00:52] <RAOF> :)
[00:52] <bschaefer> RAOF, im starting to think ... the server generates an event and sends it to the android layer
[00:52] <bschaefer> which is ripped apart and sent to the client or something
[00:53] <RAOF> Correct.
[00:53] <bschaefer> the issue we cant preserve the mac with that...
[00:53] <bschaefer> since the android layer doesnt have any of that :(
[00:54] <bschaefer> RAOF, is this to avoid sending events over the wire?
[00:54]  * bschaefer also doenst really understand the 'wire' very well
[00:54] <RAOF> We actually have two entirely parallel wires.
[00:55] <bschaefer> wire being the rpc?
[00:55] <RAOF> Yeah.
[00:55] <RAOF> ‘The thing which ferries bits from the server to the client’
[00:55] <bschaefer> soo yeah that wont preserve a struct
[00:55] <bschaefer> that is opaque :(
[00:55] <RAOF> Yeah, you'll need to poke into the android layer.
[00:55] <bschaefer> yeah
[00:56] <bschaefer> RAOF, we cant change the android layer, but maybe theres some unused uint64 somewhere
[00:56] <RAOF> We've got the protobuf-speaking socket, and one Android socket per surface with input.
[00:56] <bschaefer> RAOF, we cant can we?
[00:56] <RAOF> Why can't we change the android layer?
[00:56] <bschaefer> i've no clue :)
[00:56] <bschaefer> since its 3rd party
[00:56] <RAOF> We can (and have) changed the android layer.
[00:56] <bschaefer> but im not sure how much its sync*
[00:56] <bschaefer> o cool, well then that makes thinks 100x easier
[00:56] <bschaefer> things*
[00:56] <RAOF> It's utterly out of sync; we're never going to try and merge any upstream changes into it.
[00:57] <bschaefer> RAOF, didnt know that :), cool yeah ill just fix up the android layer and get the client android lexicon accepting the new mac bits :)
[00:57]  * bschaefer guesses a day or so
[00:57] <bschaefer> RAOF, thanks for all the info!
[03:00] <RAOF> Mad c++ request: is it possible to template<class Obj, void (Obj::*mem_fn)(Args...)> ?
[03:00] <RAOF> THis seems like something that should be possible, but as far as I can tell isn't.
[03:03] <camako> Hmm calendar won't open... Can someone paste the link for 2/3rd?
[03:03] <RAOF> https://plus.google.com/hangouts/_/canonical.com/2-3-mir-meeting?authuser=1
[03:04] <RAOF> Maybe strip the authuser off.
[08:13] <anpok> RAOF: http://paste.ubuntu.com/12054177/ .. not very convenient..
[08:16] <RAOF> anpok: Yeah, that's roughly what I thought.
[08:16] <RAOF> Which is stupid, because this would actually be *really easy* for a compiler to infer.
[08:17] <RAOF> Anyway, EOD for me.
[08:17] <anpok> hm .. well rules.. and such..
[08:18] <anpok> the method ptr needs to be constant.. and the type parameters of it need to be known before .. it is trivial  if you use that as a function parameter though, but then you dont have compiletime method ptr address..
[08:19] <anpok> anyhow .. decltype constexpr and nested templates are a source of nice clang stack traces
[08:20] <RAOF> :)
[13:19] <alan_g> AlbertA: did I do something different than you meant? https://code.launchpad.net/~alan-griffiths/mir/make-mir_demo_server-dlopen-mir/+merge/267498
[14:13] <AlbertA> alan_g: umm yes. But now I did a clean build locally here...and it didn't help...ummm I wonder if I confused my binary names....
[14:15] <alan_g> AlbertA: OK. A pity though. Thanks
[14:18] <AlbertA> alan_g: ah I see... I changed the RTLD options... loading with just RTLD_LAZY made is actually what made it work....
[14:19]  * alan_g feels confused
[14:20] <AlbertA> alan_g: sorry :)
[14:21] <AlbertA> alan_g: it's just that when I see a GL crash I automatically suspect TLS issues...
[14:21] <alan_g> AlbertA: No, I'm wondering how that fixes anything.
[14:21] <alan_g> But I'll try it
[14:33] <AlbertA> alan_g:  I'll speculate and say maybe libhybris doesn't support libGLESv2.so being loaded with RTLD_NOW
[14:34] <alan_g> AlbertA: I'm not even going to think about what that imples.