bschaeferRAOF, 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 around00:02
bschaeferthough: mir_surface_attrib_focus should be set00:02
RAOFYou 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
RAOFbschaefer: Hah!00:04
bschaeferRAOF, ?00:04
RAOFFun fact: load_device_evemu doesn't wait for the device replay to finish before returning.00:05
RAOFWhich is sensible.00:05
bschaeferRAOF, so the test is finishing before the events get through?00:05
RAOFSo what's happening is that the test is quitting before the device replay starts.00:05
bschaeferdang, i like... thought about that00:05
bschaeferlast week and ended up looking at the udev source code00:05
RAOFIf you put a sleep after load_device_evemu you get events.00:05
bschaeferbut stopped00:05
* bschaefer was getting focused events00:06
RAOFSo the right thing to do will be to block the test until an input event is received.00:06
bschaeferRAOF, is there a reasonable way to get when the replay starts?00:06
bschaefero right thats better00:06
bschaefersad face its failing00:07
* bschaefer wonders what he did wrong00:07
bschaeferHERE WE ARE: 1439251644004809000 - 1463174340001603012300:07
bschaeferits close ...00:07
* bschaefer doesnt remember where that print statement even is00:08
bschaeferwhats weird is that print statement isnt even there any more ... hmm why didnt that get recompiled out of there00:09
* bschaefer most likley forgot to install the changes00:09
RAOFYou can run out of the build tree easily.00:10
bschaefero really?00:10
bschaeferi just usually run off staging00:10
bschaeferRAOF, just do a LD_LIBRARY_PATH to where they are built?00:11
RAOFEverything's built with a wrapper that sets the right variables.00:12
bschaeferRAOF, o so just use that wrapping in bin?00:12
RAOFYou should be able to do build/bin/mir_unit_tests and have it all run correctly.00:12
bschaeferwell that makes things easier00:12
bschaeferRAOF, i think whats happening is your tests runs off the android lexicon00:12
bschaeferwhich is set to 000:12
bschaeferfor the timestamp00:12
bschaeferT: (18954176 + 12574245) 7571075335272719900 which is00:13
bschaefercookie.timestamp, cookie.mac == calculated mac00:13
bschaeferhmm somethings is off somewhere00:13
bschaeferas your verify uses the cookie timestamp to get a mac00:14
RAOFThat would be right?00:15
bschaeferyeah it is .. im just wondering whats going on with my mac00:15
bschaeferie. 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
bschaeferso it seems i've either missed a spot, or am doing something wrong :)00:16
RAOFIs it just random stack garbage?00:16
RAOFIf 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
bschaeferRAOF, right which means i've missed a location00:17
bschaefer(in where an event is created)00:18
bschaeferwhich 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:24600:18
bschaeferRAOF, the thing is i already came through here and gave all the mac values a 000:19
bschaeferas it wouldnt have compiled otherwise00:19
RAOFAh, this isn't a fake input device.00:19
RAOFThis is a fully armed and operational input device.00:20
bschaeferRAOF, hmm this is where the code path is coming from for a make event00:20
bschaeferon a mir key event00:20
bschaeferbut still, i set the mac to 0 :)00:20
bschaeferunless i just miss placed the mac ...00:20
bschaeferwith a random uint6400:21
bschaeferbut i did it after the timestamp, and thats what i did in the fake inptu device00:23
bschaeferRAOF, are you saying that we shouldnt be getting the events through the fake input stack?00:23
RAOFI would expect you to get the events through the normal input stack, because that's what load_device_evemu does.00:23
bschaeferhmm now i wonder why thats happening...00:23
bschaeferright it should be a real input device00:23
RAOFIt 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
bschaeferdid a break on:00:24
bschaefermir::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
bschaeferbest part is i can see:00:25
bschaefermir::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
bschaefersoo mac = 000:25
RAOFWhy 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 arguments00:25
RAOFYeah, not my favourite interfacae :)00:25
bschaeferi used the wrong one00:25
bschaeferRAOF, yeah i find that strange to be honest... as you did a keyboard recording...00:25
bschaeferwhere is the mouse event coming through?00:25
bschaeferevents::make_event(long, std::chrono::duration<long, std::ratio<1l, 1000000000l> >, unsigned long, MirKeyboardAction, unsigned int, int, unsigned int)00:26
bschaeferthe right one :)00:26
bschaeferRAOF, still coming through the fake input dev00:27
bschaeferRAOF, urrg00:27
bschaeferRAOF, ignore all of this00:27
* bschaefer forgot to filter00:27
bschaeferand was hitting it on a random other test00:27
bschaefernow it makes sense why we hit the pointer break :)00:28
bschaeferRAOF, we never actually hit a make event00:28
bschaeferfor a keyboard action00:28
* bschaefer goes back to swapping 3 buffers and sleeping 1 second00:29
RAOFRun with MIR_CLIENT_INPUT_RECEIVER_REPORT=log and you'll see that you're really getting keyboard events.00:30
bschaeferRAOF, thanks gdb is not as friendly it would seem00:31
bschaeferstrange but good news i think00:33
bschaeferSETTING MAC VALUE: 1421552457254485557900:33
bschaeferSETTING MAC VALUE: 000:33
bschaeferboth those come in at the same time00:33
bschaefer(for one DOWN event)00:34
bschaeferwhich; 1421552457254485557900:34
bschaeferis the expected value00:34
bschaefersoo now to figure out hwy...00:34
* bschaefer fears its the android lexicon00:50
bschaeferRAOF, yes: SETTING MAC VALUE: 17 -- 100:51
bschaeferRAOF, soo whats strange... why do we get a different make_event?00:51
bschaeferbefore 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 part00:51
* RAOF admits that's a bit of the input stack he's not super familiar with.00:52
bschaeferRAOF, well sounds like a good part for me to get familiar with :)00:52
bschaeferRAOF, im starting to think ... the server generates an event and sends it to the android layer00:52
bschaeferwhich is ripped apart and sent to the client or something00:52
bschaeferthe issue we cant preserve the mac with that...00:53
bschaefersince the android layer doesnt have any of that :(00:53
bschaeferRAOF, is this to avoid sending events over the wire?00:54
* bschaefer also doenst really understand the 'wire' very well00:54
RAOFWe actually have two entirely parallel wires.00:54
bschaeferwire being the rpc?00:55
RAOF‘The thing which ferries bits from the server to the client’00:55
bschaefersoo yeah that wont preserve a struct00:55
bschaeferthat is opaque :(00:55
RAOFYeah, you'll need to poke into the android layer.00:55
bschaeferRAOF, we cant change the android layer, but maybe theres some unused uint64 somewhere00:56
RAOFWe've got the protobuf-speaking socket, and one Android socket per surface with input.00:56
bschaeferRAOF, we cant can we?00:56
RAOFWhy can't we change the android layer?00:56
bschaeferi've no clue :)00:56
bschaefersince its 3rd party00:56
RAOFWe can (and have) changed the android layer.00:56
bschaeferbut im not sure how much its sync*00:56
bschaefero cool, well then that makes thinks 100x easier00:56
RAOFIt's utterly out of sync; we're never going to try and merge any upstream changes into it.00:56
bschaeferRAOF, 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 so00:57
bschaeferRAOF, thanks for all the info!00:57
RAOFMad c++ request: is it possible to template<class Obj, void (Obj::*mem_fn)(Args...)> ?03:00
RAOFTHis seems like something that should be possible, but as far as I can tell isn't.03:00
camakoHmm calendar won't open... Can someone paste the link for 2/3rd?03:03
RAOFMaybe strip the authuser off.03:04
=== chihchun_afk is now known as chihchun
anpokRAOF: http://paste.ubuntu.com/12054177/ .. not very convenient..08:13
RAOFanpok: Yeah, that's roughly what I thought.08:16
RAOFWhich is stupid, because this would actually be *really easy* for a compiler to infer.08:16
RAOFAnyway, EOD for me.08:17
anpokhm .. well rules.. and such..08:17
anpokthe 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
anpokanyhow .. decltype constexpr and nested templates are a source of nice clang stack traces08:19
=== 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_gAlbertA: did I do something different than you meant? https://code.launchpad.net/~alan-griffiths/mir/make-mir_demo_server-dlopen-mir/+merge/26749813:19
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
AlbertAalan_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_gAlbertA: OK. A pity though. Thanks14:15
AlbertAalan_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 confused14:19
AlbertAalan_g: sorry :)14:20
AlbertAalan_g: it's just that when I see a GL crash I automatically suspect TLS issues...14:21
alan_gAlbertA: No, I'm wondering how that fixes anything.14:21
alan_gBut I'll try it14:21
AlbertAalan_g:  I'll speculate and say maybe libhybris doesn't support libGLESv2.so being loaded with RTLD_NOW14:33
alan_gAlbertA: 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!