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