[00:07] <RAOF> racarr: Your mesa fails to build against trunk; but for an obvious reason that I'll just fix up.
[00:12] <racarr> RAOF: thanks...sorry I have mild
[00:12] <racarr> branches inside branches schizophrenia the last 2 weeks
[00:13] <racarr> *motions to chalkboard filled with diagrams*
[00:13] <racarr> It's all wheels inside wheels...ive seen it....*twitch*
[00:25] <RAOF> racarr: Good, that (finally) works. Thanks!
[00:25]  * RAOF has a pleasing, but somewhat banded, plasma flying across his display.
[00:31]  * kdub noticed the bandedness too
[00:33] <RAOF> My guess is that it's not using a full 8-bit colour range, but whatever.
[00:56] <racarr> RAOF: If you merge receive-input-in-client you can quit the plasma with the q key!
[00:56] <racarr> its a revolution in user interaction
[00:56] <racarr> ;)
[00:56] <racarr> thanks for testing and fixing :)
[00:58] <RAOF> Should land in the PPA next time jenkins scans the branches.
[01:01] <RAOF> racarr: Got any idea how you'll handle keymaps? :)
[01:14] <RAOF> racarr: Do we have to poll() every 10ms for input?
[01:16]  * duflu hopes that's a joke
[01:16]  * duflu afk
[01:16] <racarr> RAOF: No there should be a comment there...
[01:16] <racarr> maybe I didn't push everything yet
[01:17] <racarr> there just needs to be a way to interrupt it so we can use a longer poll time without making shutdown slow (or the test times become huge)
[01:17] <racarr> i.e. a wake fd
[01:17] <racarr> it might that a droidinput::Looper should be used but
[01:17] <racarr> need to sync up with Alan on that in the morning...
[01:17] <RAOF> If you expected there to be a comment about the poll(), then you haven't pushed everything :)
[01:18] <racarr> RAOF: As for keymaps, currently it is using the android keymap files+format
[01:18] <racarr> though only Generic is available :)
[01:18] <racarr> I think we will replace it
[01:18] <racarr> with libxkb
[01:18] <racarr> its pretty well abstracted, in that its just part of the InputReaderPolicy
[01:18] <racarr> pushed more changes :) but probably just containing that comment that I just explained
[02:57] <robert_ancell> RAOF, I'm thinking that that Mir on X wont be ready by 13.05. Does that sounds right to you (you have a bp item though eleni is working on it right?)?
[02:59] <RAOF> robert_ancell: Correct, eleni is working on it.
[02:59] <RAOF> I think it could be ready for 13.05 if it's a priority.
[02:59] <robert_ancell> RAOF, I'll reassign the item then
[03:00] <robert_ancell> It's a very nice to have, but not essential
[03:01] <robert_ancell> RAOF, there are two items right, SDL on Mir then X on SDL on Mir right?
[03:01] <RAOF> No, just Mir on SDL.
[03:02]  * robert_ancell gets confused with order
[03:02] <robert_ancell> yep, that sounds more like it
[03:02] <robert_ancell> RAOF, so we already have SDL on X, so mir on sdl = mir on X?
[03:02] <RAOF> Correct.
[03:02] <robert_ancell> and that was easier than mir on X?
[03:02] <RAOF> Eleni's just using SDL as the toolkit for Mir-on-X
[03:03] <duflu> It should be equally easy to make Mir on native X after that. The boiler-plate for an X Window and GLX setup isn't that big.
[03:11] <duflu> smspillaz: Bored with uni already?
[06:12] <tvoss> RAOF, ping
[06:12] <RAOF> tvoss: Yo!
[06:14] <tvoss> RAOF, ninjaaron asked about libxkb yesterday, too. Will ping him today, he seemed to know a lot about it
[06:14] <tvoss> RAOF, perhaps we can get some help
[06:14] <RAOF> tvoss: I presume everyone's referring to libxkbcommon?
[06:14] <RAOF> Which we should totally use.
[06:15] <tvoss> RAOF, yup :) libxkbcommon it is
[06:15]  * tvoss is too lazy to type common, no tab completion :)
[06:24] <RAOF> Grr, GMock.
[06:25] <tvoss> RAOF, what did you do? can I help? :)
[06:25] <RAOF> Verifying that a destructor is called is unnecessarily annoying.
[06:26] <RAOF> Or: verifying that a destructor is called in a couple of tests, and not caring in most of them, is unnecessarily annoying.
[06:26] <tvoss> RAOF, okay
[06:26] <tvoss> RAOF, an existing test?
[06:27] <RAOF> tvoss: Cleaning up in https://code.launchpad.net/~raof/mir/buffer-age-misc-cleanups/+merge/155164
[06:29] <tvoss> RAOF, looking
[06:32] <duflu> Hmm, I hope we don't end up with XKB (extension) semantics in using libxbkcommon. That was a major problem for Compiz and not something I'd like to see happen in Mir
[06:33] <tvoss> duflu, the general idea is that we reuse the existing keymapping solution without pulling in all of the atom handling
[06:33] <RAOF> duflu: I don't believe it mandates xkb
[06:34]  * RAOF -> baby
[06:34] <duflu> tvoss: Twas only the grab behaviour that was wrong I think. And we're trying to avoid that right now AFAIK
[06:34] <tvoss> duflu, yup
[06:38]  * duflu wonders how many times the words "Android" and "#include <X11/" need to appear in the Mir source before it's "too much"
[06:55] <duflu> tvoss: Can you point me to the design principle/reasoning/rationale for separating the protobuf from protobuf.wire?
[06:56] <duflu> or /pattern
[06:56] <tvoss> duflu, not sure what you mean?
[06:56] <duflu> tvoss: There are two layers of protocol. There must be a good reason why it's done that way
[06:59] <tvoss> duflu, from what I see on trunk, the wire protocol deals with the actual rpc, while the protobuf definition defines the actual types and services that we expose
[06:59] <RAOF> duflu: AFAIK "#include <X11/" is nowhere in the Mir source?
[07:00] <duflu> tvoss: Yeah I can see that. But I don't yet understand why we need to abstract an abstraction (wrap protobuf in protobuf). I need to understand more of the "why"
[07:00] <duflu> RAOF: Not yet, but potentially when we use libxkbcommon :)
[07:00] <duflu> -need + want
[07:01] <tvoss> duflu, can you check with alan_g please? I remember there was a reason ... but I'm otp right now :)
[07:01] <duflu> Kay
[07:06] <RAOF> duflu: There's no X11/ in libxkbcommon :)
[07:10] <duflu> Whee, small win
[07:17]  * duflu thinks this looks like a hack: /usr/include/xkbcommon/xkbcommon.h
[07:17] <duflu> One designed for Weston?
[07:20] <tvoss> duflu, hack in what respect?
[07:21] <duflu> tvoss: The name "xkb..." and yet it has no dependency on *XKB* stuff under X11/. Seems a bit backwards. Thought that could be resolved simply with better naming
[07:22] <tvoss> duflu, that's a good point actually. While reading through the library I though about a name along the lines of libkeymap :)
[08:13] <RAOF> Wooo!
[08:13] <RAOF> I win the “work around annoying bits of gmock” award.
[08:36] <tvoss> RAOF, \o/
[09:17] <duflu> Argh. I hate it when Europe wakes up. No offence :)
[11:24] <smspillaz> RAOF: the re-entrancy rule strikes again ?
[15:05] <kdub> morning
[15:06] <tvoss> kdub, good morning :)
[15:07] <UbuPhillup> hi
[15:14] <kgunn> kdub: ping
[15:15] <racarr_> Morning
[15:17] <tvoss> racarr_, good morning :)
[15:20] <kdub> kgunn, pong
[15:27] <alan_g> racarr_: Morning. Looking into the Looper thing. Is definitely a difference in behaviour, not worked out why yet.
[15:27] <racarr_> alan_g: Thanks :)
[15:27] <racarr_> I am wondering, how it was supposed to work as it stands, as it seems like the deadline timer is unused?
[15:28] <racarr_> (Wondering if there is some bit of boost asio I do not understand)
[15:29] <alan_g> racarr_: is all asio magic to me - tvoss seems to understand (or have a bit more experience of) this stuff
[15:29] <tvoss> alan_g, racarr_ can you point me to the bit that is not working?
[15:31] <alan_g> tvoss: the bit racarr_ is referring to is Looper::pollOnce(int timeoutMillis) with timeoutMillis > 0
[15:32] <racarr_> tvoss: It works with the android::Looper implementation but not with our boost::asio based implementation :)
[15:32] <racarr_> it's all described in here https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
[15:32] <racarr_> "Currently this is failing to work with MIR_INPUT_USE_ANDROID_TYPES=false ...."
[15:32] <tvoss> alan_g, racarr_ looking ...
[15:52] <racarr_> three items I could take up
[15:53] <tvoss> racarr_, on the Looper issue
[15:53] <racarr_> 1. SW cursor (seems hard to land)/pointer input 2. Back to inprocess EGL 3. Clean up qtubuntu mir branch
[15:53] <racarr_> tvoss: Oh?!
[15:54] <tvoss> racarr_, at your items: I would focus on inprocess EGL
[15:56] <racarr_> Ok. makes sense
[15:57] <racarr_> actually depending on how it is structured that might all live in Qt ubuntu now that prepare-for-inprocess-egl has landed
[15:59] <tvoss> racarr_, what's the magic cmake option to enable compiling the Looper relying on boost?
[15:59] <racarr_> tvoss: MIR_INPUT_USE_ANDROID_TYPES=false
[15:59] <racarr_> which is the default
[16:00] <racarr_> should use the looper coming from 3rd-party/android-deps/bla/bla (with the boost implementation in header file)
[16:00] <tvoss> racarr_, ack
[16:13]  * alf_ is starting to get really tired of gcc ICEs
[16:13] <racarr_> alf_: I know what you mean...
[16:13] <tvoss> racarr_, can you give http://pastebin.ubuntu.com/5649723/
[16:13] <tvoss> a spin?
[16:14] <racarr_> alf_: At some point last week I wrote like 900 lines of new code...then -> ICE....I wanted to cry!
[16:14] <racarr_> alf_: SOme bug report implied it may be fixed upstream I am thinking of building my own G++
[16:16] <racarr_> tvoss: Trying :)
[16:16] <tvoss> racarr_, cool
[16:16] <racarr_> tvoss: alan_g: It's strange...changes to Looper.h wont actually trigger
[16:16] <alf_> racarr_: my current methodology is to build with clang, so I can get an idea of what the problem is
[16:16] <racarr_> recompile of android-input
[16:16] <racarr_> always have to make clean
[16:16] <racarr_> alf_: Ah...that's a better idea than crying
[16:17] <alf_> racarr_: :)
[16:17] <alan_g> racarr_: that's because CMake's dependency tracing doesn't track #include MACRO
[16:17] <racarr_> tvoss: Still the same.
[16:17] <racarr_> alan_g: ah....
[16:18] <alan_g> Just delete a few files in 3rd_party/...
[16:18] <tvoss> racarr_, then I need to look a bit deeper
[16:18] <racarr_> tvoss: googling around people kind of implied
[16:19] <racarr_> the only way to do this with asio is in the timer callback
[16:19] <racarr_> you have to cancel the work.
[16:19] <racarr_> then there is going about resetting the io service and
[16:19] <racarr_> readding the async_read...and I dunno
[16:19] <racarr_> not sure asio is the right fit here
[16:21] <racarr_> tvoss: A thought..."woken" needs to be reset right
[16:21] <racarr_> i.e. around l585 if (woken.load())
[16:23] <alan_g> racarr_: it doesn't seem at all easy. Am proposing a fix branch
[16:23] <kdub> alf_, could you give another look? https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762
[16:23] <racarr_> it doesn't help though
[16:23] <alf_> kdub: sure
[16:23] <racarr_> alan_g: Yeah...it's really complex to how it should be :/
[16:23] <racarr_> I think run_one should take a timeout ;)
[16:24] <alan_g> racarr_: Agreed
[16:25] <alan_g> racarr_: https://code.launchpad.net/~alan-griffiths/mir/receive-input-in-client-patch/+merge/155549
[16:26] <alf_> kdub: @l.78, the line is not wrapped. Other than that looks good.
[16:27] <racarr_> alan_g: It looks like there is some confusion in this branch? extra changes etc
[16:27] <alan_g> Bugger - that has some trunc changes tpp
[16:27] <alan_g> Bugger - that has some trunc changes too
[16:27] <racarr_> :)
[16:28] <kdub> alf_, sorry, got lost in some merges... fixed now
[16:29] <alf_> kdub: also, is lp:~kdub/mir/ndk-rewrite the best place to get information from for creating a chroot, or is lp:mir enough now?
[16:30] <kdub> alf_, after that branch, just lp:mir
[16:30] <kdub> i'll delete that branch, and send out a mail on the mailing list
[16:30] <alf_> kdub: so, we should update at l.65 ?
[16:31] <kdub> alf_, yes :/ i corrected that, but that got lost in my merge mixup too
[16:31] <kdub> fixed
[16:32] <alan_g> racarr_: I hope that fixes it
[16:34] <alan_g> (At least it looks like I intended)
[16:34] <racarr_> alan_g: Oh good idea at line 310
[16:34] <racarr_> (test name change)
[16:35] <alan_g> racarr_: np
[16:35] <alf_> kdub: thanks, approved
[16:35] <racarr_> testing now
[16:36] <racarr_> alan_g: All works
[16:37] <racarr_> going to merge your branch in to mine and push
[16:37] <racarr_> alan_g: tvoss: Thanks both :)
[16:39] <racarr_> I wonder if the InputReceiverThread on the client side should be/use an android::Looper
[16:39] <alan_g> racarr_: hopefully we'll soon be confident to delete the ANDROID_TYPES=on option (and the code to support it)
[16:39] <racarr_> Mm
[16:39] <racarr_> Currently it is using a little mini select loop but it needs optimization (diff l598)
[16:49] <racarr_> *really happy to finally being close to landing an end to end test for input*
[16:50] <racarr_> it's easy to move fast there now :)
[16:50] <tvoss> racarr_, yup, great work :)
[16:50] <racarr_> aww merge conflicts
[16:51] <racarr_> tvoss: Oh while you are around i wanted to ask you...was trying to find a good input demo
[16:51] <racarr_> but nothing qwidget based works on qtubuntu for me
[16:51] <racarr_> expected/known?
[16:51] <racarr_> (Not many QML demos that work with no cursor ;))
[16:51] <tvoss> racarr_, mostly known I would say. I would think that the qml examples should work, though
[16:52] <racarr_> at least precanned ones in /opt/qt5/examples
[16:52] <racarr_> yeah
[16:52] <racarr_> there is just only one that will accept keyboard input before mouse input
[16:52] <racarr_> and it makes a pretty lame video XD (qtdeclarative/quick/keynavigation)
[16:53] <tvoss> racarr_, ack, @cursor: is there a way to get a cursor rendering easily? IIRC you can provide the InputReader with a cursor handler
[16:53] <racarr_> tvoss: We have a cursor handler in trunk
[16:53] <tvoss> racarr_, is that one actually rendering?
[16:53] <racarr_> and InputManager takes a CursorListener object, which would be the place to put a renderer
[16:53] <racarr_> but the CursorListener is null atm
[16:54] <racarr_> not sure how to render it
[16:54] <racarr_> at least in a way that will land :)
[16:55] <tvoss> racarr_, yeah, so let's postpone a cool video until we have a way to expose the hw cursor, if that's fine with you
[16:56] <racarr_> Yeah :)
[16:56] <racarr_> I amw ondering if I should try and work on that now...I dunno its probably not that difficult I just can't figure out the interfaces in mir...
[16:58] <racarr_> the thing is the cursor listener shouldn't speak directly to the compositor or if it does
[16:58] <racarr_> that's a pretty big change!
[16:58] <racarr_> because it makes lines that cross surface stack where there were none
[16:58] <tvoss> racarr_, hw cursor support is more likely to end up somehwere in graphics
[16:58] <racarr_> but surface stack isn't really prepared to
[16:58] <racarr_> represent a cursor
[16:58] <tvoss> racarr_, yup
[16:59] <tvoss> racarr_, so focus on in_process_egl
[17:00] <racarr_> ok
[17:00] <racarr_> tvoss: The way I was handling that in the iteration-1 branch was
[17:01] <racarr_> using almost unmodified qtubuntu backend, and ubuntu_platform_api backed by libmirserver
[17:01] <racarr_> does that still make sense? I am not sure exactly what the status of ubuntu_* API is
[17:02] <racarr_> I have this thought that we don't really need "qmir" just qtubuntu, a nd ubuntu-application-api-mirclient and ubuntu-application-api-mirserver
[17:04] <tvoss> racarr_, that's a difficult one. Need to give it some thought
[17:05] <racarr_> tvoss: ok
[17:05] <racarr_> tvoss: It's a convenient way to proceed ;) that ends with little code duplication
[17:05] <racarr_> but I am not entirely sure it makes sense
[17:06] <racarr_> i.e. why is the launcher an indirect consumer of ubuntu-application-api
[17:07] <racarr_> seems weird.
[17:10] <racarr_> ill delay it a day and at least get the inserver EGL display and a demo inprocess app proposed today :)
[17:10] <tvoss> racarr, that sounds like a good idea :)
[17:26] <alf_> status: working on compositing-on-demand, reviewing, fighting with gcc ICEs
[17:27] <racarr> it's a shame too that its not easy to downgrade to 4.6 now because of the override use (which I quite like actually)
[17:27] <racarr> its just like it's some sort of cruel joke being played on us XD
[17:44] <racarr> hmm issues with the new test_client_mir_surface tests when merging trunk in to receive-input
[17:53] <alf_> racarr: alan_g: Do we need SurfaceStack::raise_to_top()? No one is using it, and it has memory problems (it uses a potentially invalidated iterator).
[17:54] <alan_g> alf_: dead code? Delete it!
[17:58] <racarr> alf_: Apparently not!
[17:58] <racarr> I think it was used in an early version of sessions/ in copenhagen ;)
[17:59] <racarr> then we decided restacking the surfaces was silly when all we need is visibility
[17:59] <alf_> racarr: alan_g: preparing an MP
[17:59] <racarr> obviously we will need something like it one day. but lets just drop it and
[17:59] <racarr> readd it working correctly when we do :)
[18:00] <racarr> hmm
[18:00] <racarr> where does the server MesaNativeDisplay implementation go :)
[18:01] <racarr> mir::graphics::EGL::?
[18:41] <kgunn> racarr: ping
[18:49] <kgunn> alf_: hey, can you change https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 to have the drafter set to mir-team ?
[18:51] <racarr> kgunn: Pongalong!
[19:43] <racarr> I think I need to make
[19:43] <racarr> mir::DisplayServer mockable but its not clear what the interface is
[19:44] <racarr> the EGLNativeDisplay constructor (well or more likely factory function)
[19:45] <racarr> wants to take mir::DisplayServer I think
[19:46] <racarr> becuase the thing is, think of the code paths in unity. Unity starts up, initializes a server configuration, and then calls off to mir::run_mir(Configuration)
[19:46] <racarr> at which point control goes to Mir
[19:46] <racarr> but unity needs a time to start, threads
[19:47] <racarr> and get some reference to the display server instance (after it is prepared)
[19:47] <racarr> so I think we need some callback, the display server instance invokes inbetween starting and entering the main loop
[19:48] <racarr> to give unity a time to say, start a thread which creates a surface and starts rendering.
[19:49] <racarr> even simpler just imagine we are talking about a simple EGL demo app instead of unity. What does it need? It needs the display to get the platform package to initialize the egl context, and it needs a surface controller
[19:49] <racarr> to create a surface.
[19:50] <racarr> so it seems like maybe mir::DisplayServer should provide these
[19:50] <racarr> through a...<NAME GOES HERE> interface
[19:51] <racarr> first thought is mir::ServerInstance but actually this interface
[19:52] <racarr> doesn't need start/stop like mir::DisplayServer does (and you would guess a ServerInstance would)
[19:52] <racarr> so maybe it's more like mir::ServerComponents is the interface with (.shell_surface_controller(), .display(), etc...)
[19:52] <racarr> and mir::DisplayServer implements
[19:53] <racarr> or maybe mir::ServerInstance is the concrete implementation containing start/stop and the .display(), etc...
[19:53] <racarr> and mir::DisplayServer becomes the interface with just
[19:53] <racarr> the component access
[19:55] <racarr> I think that makes sense. a mir::DisplayServer has a bunch of components that make up the interface mir::* exposes to the shell. a server instance is a display server with API for execution
[19:56] <racarr> *shrug*
[19:56] <racarr> Sorry sounds kind of pedantic but I think it's important to think about this interface because we need to make sure Unity and Mir are cleanly mockable from eachother.
[19:58] <kgunn> kdub: quick one i think
[19:59] <kgunn> what exactly did "display integration" mean ?...i mean  you already go hwc vsync working for nexus4 (not nec'lly landed...but)
[20:00] <racarr> Lunch!
[20:00] <kdub> kgunn, making sure that all the pieces fit together (integration test)
[20:01] <kgunn> kdub: thanks...it was marked as todo...but i suppose that will hinge on some mp's to say done...
[21:04] <kgunn> robert_ancell: would you mind making mir-team drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-nexus4
[21:04] <robert_ancell> kgunn, done
[21:04] <kgunn> thank you!