[04:44] <robert_ancell> RAOF, was / is there an XMir git branch (i.e. with the actual changes on git master and not with a debian/ dir like fdo:~mlankhorst/xserver
[04:44] <robert_ancell> Trying to work out correct attribution for xmir.patch
[04:45] <RAOF> robert_ancell: I presume Maarten has a branch somewhere, but I've only got https://github.com/raof/xserver
[04:45] <RAOF> Which isn't the one that you're after.
[04:48] <RAOF> robert_ancell: Some quick searching shows up http://cgit.freedesktop.org/~mlankhorst/xserver/
[04:48] <robert_ancell> RAOF, that just has debian/ added and everything in the patch file
[04:49] <RAOF> Yeah, dunno, sorry.
[04:49] <robert_ancell> np
[04:49] <RAOF> He presumably had a git tree to develop in, though.
[04:51] <robert_ancell> Presumably
[04:51] <duflu> robert_ancell: It's documented in the obvious place :)
[04:52] <duflu> robert_ancell: https://code.launchpad.net/xmir
[04:52] <duflu> But yeah we definitely need to move it
[04:53] <robert_ancell> duflu, again, that's pointing at a branch containing debian/patches, i.e. not a branch based off master with the changes done inline
[04:53] <robert_ancell> duflu, I am moving it now
[04:53] <robert_ancell> And without the original branch we're going to lose attribution. But it's probably not a big deal.
[04:53] <duflu> robert_ancell: I know it's ugly. I doubt Maarten did maintain anything inline. He was always patches
[04:54] <robert_ancell> I'm going to split up the changes anyway so we can get them upstream at some point
[04:54] <duflu> robert_ancell: I never did figure out how to build in manually too... Only got a successful build from debuild
[04:54] <duflu> (strange compiler errors otherwise)
[04:59] <duflu> Obviously the secret sauce is in debian/
[04:59]  * duflu goes to get some sunlight
[06:26] <duflu> Man touchscreen hardware really sucks. Even when you eliminate all the graphics lag, touchscreens are still slow. Plugging a mouse into the same device is dramatically more responsive.
[08:25] <alan_g> alf_: have you had a chance to look at the power off/on/off/on/... crash?
[08:27] <alf_> alan_g: yes, the crash happens in a GL call, I am trying to figure out why...
[08:28] <alan_g> alf_: ack. I'll leave you to it. :)
[08:28]  * alan_g goes to port glmark2-mir to contemporary API
[08:32] <duflu> alan_g: You'll also want to wait till the client ABI bump before updating glmark2-mir in wily. Or else we'll have to do it twice
[08:33] <alan_g> duflu: we need to decide how to work around https://code.launchpad.net/~alan-griffiths/mir/bump-client-ABI/+merge/258769/comments/646197
[08:33] <alan_g> But at least I can get the code ready
[08:36] <duflu> alan_g: Take it out of CI temporarily I guess. BTW that is https://bugs.launchpad.net/mir/+bug/1341490
[09:10] <alf_> alan_g: @glmark2, I already have an upstream branch for the update
[09:11] <alan_g> alf_: ok, I'll drop mine then
[09:11] <alf_> alan_g: but we will need to update the ubuntu packages
[10:05] <duflu> alf_: Booo.... requires ES3 - https://www.khronos.org/opengles/sdk/docs/man3/html/glReadBuffer.xhtml
[10:05] <duflu> Sigh
[10:05] <duflu> And even then still not FRONT
[10:06] <duflu> ES is surprisingly limited, again
[10:17]  * alan_g does a clean build from trunk and gets "ClientSurfaceEvents.surface_receives_state_events...Segmentation fault (core dumped)"
[10:32]  * alan_g realise he did something stupid
[11:17] <alf_> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1454201-usc-crash-for-0.13/+merge/258863
[11:17] <alan_g> alf_: thanks!
[11:18] <alf_> alan_g: More investigation is needed to figure out why the workaround is needed (and if it's really our fault or the driver's), but this should be enough to unblock the release
[11:18] <alan_g> understood
[11:41] <alan_g> alf_: any ideas? https://code.launchpad.net/~afrantzis/mir/fix-1454201-usc-crash-for-0.13/+merge/258863/comments/646452
[11:46] <alan_g> The test diagnostic is rather unhelpful. :(
[11:47] <alf_> alan_g: I knew I was forgetting something (to check the tests!)
[11:48] <alf_> alan_g: I will fix and update the branch
[11:50] <alan_g> alf_: thanks. [Non-urgent: does the diagnostic need to be so far removed from the actual problem?]
[11:56] <davmor2> alan_g: the issue you spotted yesterday in silo21 did you resolve it at all?
[11:59] <alan_g> davmor2: we're (well alf_) closing on it. I expect to rebuild and test after lunch.
[11:59]  * alan_g goes to lunch while alf_  does the work.
[11:59] <davmor2> alan_g: that's great just remembered about it so thought I'd ask while it was in my head :)
[13:23] <dandrader> I've mir_proving_server running on my laptop as root. Is it possible to run mir clients without being root?
[13:24] <dandrader> I did "sudo chmod a+rwx mir_socket" but trying mir_demo_client_egltriangle without root still gives me "Can't get connection"
[13:25] <dandrader> ok, manually pointing out the location of the mir_socket did the trick: "/tmp$ mir_demo_client_egltriangle -m mir_socket"
[13:26] <dandrader> wonder why I don't have to do so when I run the client as root
[13:27] <alan_g> dandrader: the socket location depends on some environment variables that are set differently
[13:29] <dandrader> alan_g, where/how can I find a list of env vars that mir looks for?
[13:30] <alan_g> mir_proving_server --help ... "Socket filename [string:default=$XDG_RUNTIME_DIR/mir_socket or  /tmp/mir_socket]"
[13:32] <dandrader> alan_g, so this translates to having a MIR_SERVER_HOST_SOCKET in the environment of the client app?
[13:33] <greyback_> dandrader: I usually set MIR_SOCKET=/tmp/mir_socket
[13:33] <alan_g> If you run as root then $XDG_RUNTIME_DIR isn't set so server and client look at /tmp/mir_socket
[13:33] <alan_g> If you run as non-root then it is usually set
[13:35] <dandrader> alan_g, I got it from the help text. but what's the name of the env var I should use for the client?
[13:36] <dandrader> alan_g, it says nothing aboutn the existence of the MIR_SOCKET env var
[13:36] <dandrader> greyback_, thanks!
[13:42] <racarr> So...autolanding is down I guess?
[13:59] <greyback_> alan_g: fyi, qtmir had some landings. I'm working on fixing up qtmir/devel-mir-next to suit
[13:59] <alan_g> greyback_: Oh. I'll need to roll that into silo 021
[14:00] <greyback_> alan_g: yep, exactly why I'm doing it
[14:00] <alan_g> Thanks. Is it a long job?
[14:00] <greyback_> alan_g: nah, almost there, just 2 new tests I'm being careful with
[14:01] <alan_g> Excellent (rebuild of mir will be finished shortly)
[14:02] <greyback_> alan_g: in the CI Dashboard, your silo21 is for "vivid primary" - I didn't think we could land there any more
[14:02] <greyback_> tho I see plenty of other silos with the same
[14:03] <greyback_> my qtmir landing was in vivid+stable-overlay
[14:03] <alan_g> I don't know why not. So long as we don't break ABI
[14:04] <greyback_> things are unclear
[14:05] <alan_g> They certainly are
[14:06] <alan_g> I thought "overlay" was a temporary substitute until wily was usable. But it got hijacked
[14:28] <racarr> Planning to rework the event representation today (mostly to line up to input_event.cpp/the C API)
[14:28] <racarr> starting to realize there may  be some advantage to
[14:28] <racarr> deunionizing the event...
[14:29] <racarr> I was thinking about the playground shell and the big if statement for handling
[14:29] <racarr> keybindings there and realized what you want is probably some sort of
[14:29] <kdub> I feel like I've never had the genuine thought 'awesome, its a union'
[14:29] <racarr> kdub: not since I was 12 or so here :p
[14:30] <racarr> haha uh but you want
[14:30] <racarr> some sort of Keybinder interface
[14:30] <racarr> but then I realized keybinding description is
[14:30] <racarr> the same signature as "MirKeyboardEvent" - "MirInputEvent"
[14:30] <racarr> (Minus MirInputEvent that is)
[14:30] <racarr> so if you could construct a MirKeyboardEvent without constructing the enclosing
[14:30] <racarr> MirInputEvent
[14:30] <racarr> MirKeyboardEvent could be the
[14:30] <racarr> authorative uh
[14:30] <racarr> key type
[14:30] <racarr> lol
[14:31] <racarr> and avoid this android input mess of
[14:31] <racarr> MotionEvent v. NotifyMotionArgs (partially constructed MOtionEvent basically)
[14:33] <racarr> in other news I literally forgot to drink coffee
[14:33] <racarr> this morning
[14:33] <racarr> this is unprecedented
[14:41] <racarr> Hmm
[14:42] <racarr> I've been thinking of promoting (Keyboard/Touch/Pointer)Event::Modifiers to InputEvent
[14:42] <racarr> but the above thought suggests otherwise
[14:47] <anpok_> and then do things like comparing events..
[14:47] <anpok_> but does it matter that there is a union?
[14:48] <racarr> anpok_: Well the thing is if
[14:48] <racarr> its a union then they all need to contain
[14:48] <racarr> timestamp
[14:48] <racarr> which ISNT part
[14:48] <racarr> of a keybinding
[14:48] <racarr> description
[14:48] <racarr> and
[14:48] <racarr> device_id
[14:48] <racarr> which...could be
[14:48] <racarr> lol
[14:48] <racarr> ugh
[14:49] <racarr> I guess thats suggesting the time is the unique member
[14:49] <racarr> yeah because its like
[14:49] <racarr> a Keyboard state
[14:49] <racarr>  + a time
[14:49] <racarr>  = an event
[14:50] <anpok_> or + occurence
[14:50] <racarr> what do you mean?
[14:50] <anpok_> if you leave the device id out of the keyboard stae
[14:50] <anpok_> *state
[14:50] <racarr> ah, yes.
[14:50] <anpok_> where and when
[14:53] <racarr> hmm
[14:53] <racarr> so if not a union...C++ inheritance?
[14:53] <racarr> Rust traits + FFI
[14:54] <racarr> ...focus focus
[15:01] <kdub> how did we end up with so much 'required' in protobuf :/
[15:05] <camako> kdub, standup
[15:05] <kdub> ah, coming
[15:38] <dandrader> I run mir_proving_server on my laptop. run a client in from another ssh terminal. then in the client's terminal I do ctrl+c. mir_proving_server frezes for good, getting defunct and impossible to kill. is that a know issue?
[15:41] <alan_g> dandrader: I'm not aware of that happening.
[15:41] <alan_g> alf_: silo 021 has your fix and is working for me on mako. Wanna try it?
[15:43] <alan_g> greyback_: are we there yet?
[16:07] <dandrader> some how building mir_proving_server myself, with debug config, and running it under gdb made it behave....
[16:14] <alf_> alan_g: all good on krillin
[16:15] <alan_g> \o/
[18:33] <racarr> Does anyone know how to GDB mir_unit_tests/
[18:34] <racarr> if I run gdb on mir_unit_tests GDB silently detaches
[18:34] <racarr> (no kidding...)
[18:34] <racarr> if I run it on .uninstalled
[18:34] <racarr> Bus error
[18:34] <racarr> its been happening for about 2 weeks now...
[18:35] <racarr> also has anyone experienced problems with system headers getting mixed in to local compilation...
[18:38] <anpok_> hm that did not happen for me
[18:40] <racarr> anpok_: Ok I guess ill just quit programming and get a job in the farm.
[18:40] <racarr> ...printf debugging and dist upgrade it s
[18:40] <racarr> is
[18:42] <racarr> ahaha
[18:42] <racarr> I mismatched an int32_t and an int64_t in a union
[18:42] <racarr> making it look as if another enum value (preceeeding it in the union)
[18:42] <racarr> was overwritten with the value which it would have had if
[18:42] <racarr> parts were compiled with system headers instead of the modified local headers
[18:42] <racarr> WHEEEE
[19:29]  * kdub has gotten that gdb error
[19:29] <kdub> on the unit tests
[19:42] <SturmFlut> Mir and Unity8 on BayTrail: http://sturmflut.github.io/ubuntu/baytrail/2015/05/12/ubuntu-15-10-and-desktop-next-on-a-baytrail-tablet/
[19:42] <SturmFlut> The external HDMI port even works in theory
[20:05] <greyback_> kdub: I have a question on android multimonitor. I know how there is a DisplaySyncGroup, which is a collection of DisplayBuffers which are all swapped at once
[20:05] <kdub> greyback_, right
[20:05] <greyback_> kdub: say only 1 DisplayBuffer needs a redraw. Does the android MM stuff require the other one to also be redrawn too?
[20:06] <greyback_> i.e. we get fresh DisplayBuffers back for all displays after a swap
[20:07] <kdub> greyback_, so, the updated DisplayBuffer will get a swap, and the not-updated one won't
[20:07] <kdub> and both will be 'reposted'
[20:07] <greyback_> ahh
[20:07] <greyback_> swap != post
[20:08] <kdub> right, I had to tease that out because hwc doesn't give me a way to just update one
[20:09] <kdub> so the DisplayBuffer is back to the original idea of just being the content on screen (2d stuff or overlays), and the DisplaySyncGroup does the posting
[20:09] <greyback_> kdub: that's ok. The above scenario had me confused, but as swap != post, it's ok