| bschaefer | RAOF, hmm the only thing i can do with a surface event is: MirSurfaceAttrib mir_surface_event_get_attribute(MirSurfaceEvent const* ev); | 00:01 |
|---|---|---|
| * 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:02 |
| 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:03 |
| RAOF | bschaefer: Hah! | 00:04 |
| bschaefer | RAOF, ? | 00:04 |
| 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:05 |
| * 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:06 |
| 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:07 |
| * bschaefer doesnt remember where that print statement even is | 00:08 | |
| 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:09 | |
| 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:10 |
| bschaefer | RAOF, just do a LD_LIBRARY_PATH to where they are built? | 00:11 |
| 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:12 |
| 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:13 |
| bschaefer | as your verify uses the cookie timestamp to get a mac | 00:14 |
| RAOF | That would be right? | 00:15 |
| bschaefer | yeah it is .. im just wondering whats going on with my mac | 00:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| bschaefer | with a random uint64 | 00:21 |
| RAOF | :) | 00:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| * bschaefer goes back to swapping 3 buffers and sleeping 1 second | 00:29 | |
| RAOF | Run with MIR_CLIENT_INPUT_RECEIVER_REPORT=log and you'll see that you're really getting keyboard events. | 00:30 |
| bschaefer | RAOF, thanks gdb is not as friendly it would seem | 00:31 |
| 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:33 |
| 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:34 |
| RAOF | :) | 00:35 |
| * bschaefer fears its the android lexicon | 00:50 | |
| 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:51 | |
| * 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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! | 00:57 |
| 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:00 |
| 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:03 |
| RAOF | Maybe strip the authuser off. | 03:04 |
| === chihchun_afk is now known as chihchun | ||
| anpok | RAOF: http://paste.ubuntu.com/12054177/ .. not very convenient.. | 08:13 |
| 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:16 |
| RAOF | Anyway, EOD for me. | 08:17 |
| anpok | hm .. well rules.. and such.. | 08:17 |
| 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:18 |
| anpok | anyhow .. decltype constexpr and nested templates are a source of nice clang stack traces | 08:19 |
| RAOF | :) | 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 | ||
| 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 | 13:19 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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:13 |
| alan_g | AlbertA: OK. A pity though. Thanks | 14:15 |
| AlbertA | alan_g: ah I see... I changed the RTLD options... loading with just RTLD_LAZY made is actually what made it work.... | 14:18 |
| * alan_g feels confused | 14:19 | |
| AlbertA | alan_g: sorry :) | 14:20 |
| 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:21 |
| AlbertA | alan_g: I'll speculate and say maybe libhybris doesn't support libGLESv2.so being loaded with RTLD_NOW | 14:33 |
| alan_g | AlbertA: I'm not even going to think about what that imples. | 14:34 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!