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