[00:03] tvoss, robotfuel openarena working on ati as well [00:03] bschaefer, ack and thx [00:03] * bschaefer checks the lightdm logs [00:03] np [00:04] robotfuel, I don [00:04] dont see any problems in any logs :( [00:04] things seem to have started correctly [00:04] https://bugs.launchpad.net/xmir/+bug/1206732 has logs [00:04] Launchpad bug 1206732 in XMir "compiz crashed with latest s-c-t ppa on nvidia gt640 " [Undecided,New] [00:05] robotfuel, actually: http://paste.ubuntu.com/5930923/ [00:05] so you are not getting any input device set correctly? [00:05] * bschaefer checks his own logs [00:05] it sounds like a permission issue possibly.... [00:06] bschaefer: it's the same preseed and files that worked for intel and ati [00:06] bschaefer: I think it's the compiz crash [00:06] robotfuel, yeah, there use to be a permissions problem when running mir from the tty but that wouldn't make sense there... [00:06] robotfuel, that would make sense :) [00:06] but you should still be able to run open areana even if its crashed [00:06] as long as it didn't bring X down [00:08] robotfuel, o dammit, sorry, i missed this line: tvoss: it ran ok on intel and radeon, on nvidia I get: ret = 0 for buffer 26 [00:08] I read it as all 3 were failing! [00:08] ah okay [00:08] falling asleep now :) grab you guys later [00:09] tvoss, have a good night! [00:09] bschaefer, thx and bye [00:13] bschaefer: I am re-running the test to see if it's reproducible [00:13] robotfuel, thanks! [00:13] I just needed to grab all the logs first ;) [00:14] I'll check back after I commute home [00:14] alright, are you a bit past your EOD? [01:14] bschaefer: I got the same result, but without the compiz crash [01:14] bschaefer: have you seen the ret = 0 for buffer 26 ret = 0 for buffer 18 before in the xorg.0.log? [01:14] robotfuel, :(, whats strange is i just ran pts/gaming-free [01:14] and I get sent back to lightdm [01:14] * bschaefer double checks [01:15] bschaefer: with the s-c-t ppa? [01:16] s-c-t? [01:16] u-s-c? [01:16] * bschaefer is using the u-s-c tesitng ppa [01:16] testing* [01:17] and I don't see anything in my xorg.0.log about buffers ret = 0 [01:18] robotfuel, where did you see the greeter crash info at? [01:19] bschaefer: it was this bug https://bugs.launchpad.net/xmir/+bug/1206508 [01:19] Launchpad bug 1206508 in XMir "Xorg crash on xmir punts user back out to greeter" [High,Triaged] [01:20] * bschaefer looks [01:21] bschaefer: it looks like that bug covers 2 different scenarios [01:21] bschaefer: if you read the last comment [01:21] robotfuel, well im getting kicked to the greeter when trying to run this pts/gaming-free test [01:21] for the phoronics test suite [01:21] bschaefer: what happens when you run glxinfo? [01:22] * bschaefer install it [01:22] bschaefer: maybe with export DISPLAY=:0 or export DISPLAY=:0.0 [01:22] bschaefer: install mesa tools to run it [01:22] yeah, hmm just a bunch of info :) [01:23] robotfuel, it doesn't crash if thats what you're wondering :) [01:24] and glxgears works as well, and openarena works [01:24] bschaefer: that would be good to add to a bug [01:24] im just not sure why gaming-free causes me pain [01:24] I haven't tried games [01:25] robotfuel, could you run this on a machine: run pts/gaming-free? [01:25] err, it adds a lot of games though... [01:25] bschaefer: I can't openbenchmarking.org is blocked from the lab. that's where it downloads from [01:26] bschaefer: I'll download it now and try when I get in work tomorrow [01:26] i see, hmm well Ill have to look at this tomorrow! [01:26] robotfuel, well that could work, i should go eat some dinner .. [01:26] robotfuel, thanks for the help today! [01:28] what's this new package? xserver-xorg-xmir ? [01:33] also, seem like the arrow at the top-left corner is gone, right? [01:51] I think the testing instructions need to be modified, had to manually pull in unity-system-compositor. [01:55] RAOF: Are you familiar with undefined symbol xorgMir? (https://bugs.launchpad.net/bugs/1205822) [01:55] Launchpad bug 1205822 in XMir "Software rendering fallback in use instead of intel driver: (EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xorgMir" [Undecided,New] [02:21] it seem like Mir or XMir has some memory leak. I might be wrong, but it feels like it starts up super fast, but gets slower as times goes by. [03:00] duflu: That's failure to run against an XMir-enabled server. [03:02] RAOF: I feel you're just restating the problem. I'm still confused. But so long as you're aware of it... [03:03] duflu: Specifically, it's failure to follow the instructions to pin the PPA ☺ [03:03] But I can make that failure more obvious, so shall. [03:06] RAOF, is the arrow at the top-left corner gone? [03:06] chjunior: Yes [03:06] Now the only way to tell is (a) by checking logs, or (b) hitting Ctrl-C :) [03:07] haha, that's the reason for the question [03:07] RAOF, what ctrl-c should do? Nothing happened here [03:07] Oh, has that fix propagated? Yay! [03:08] chjunior: It would have killed mir [03:08] I guess it's fixed then :P [03:08] which logs should I look at? R [03:08] RAOF, [03:09] chjunior: /var/log/Xorg.0.log, or you can run ‘xrandr -q’ and check for XMir Mode Of Death! [03:10] I'm going to be sad when we have actual xrandr support and I can no longer call it the Mode Of Death. [03:10] :) That's a good name [03:10] There is always something new that you can declare "of death!" [03:12] But probably not in a user-visible string [03:12] ☺ [03:14] RAOF, is stuff still going to the output buffer? like password and everything I type [03:14] I'm not sure. I think the fix for ctrl-C should have also fixed that, but I've not tested it. [03:15] You still can't user-switch, though. [03:15] Which reminds me - racarr! [03:15] racarr: How goes notify-on-focus? ☺ [03:17] Sweet! I win the ‘able to get dma-buf size out of the kernel’ award! [03:22] RAOF, and I win the "Trying things someone waned were buggy just to see the world burn" [03:23] had to restart after user-switch [03:23] do you think XMir will be ready for 13.04 performance-wise ? [03:27] * duflu wonders how long is too long for stress testing to run on armhf [03:45] chjunior: 13.04? A bit late for that :) [03:45] wow, sorry, messed up with numbers [03:46] chjunior: 13.10? Yes; there's some subtlety in GLX bypass that needs to be worked out, but we should be able to get approximately 0% performance penalty on composited desktops. [03:46] * duflu cancels all real-life for the next few weeks to make that happen :/ [03:47] I thank you all duflu, RAOF and others for that [03:51] duflu: Indeed, got some time to talk composite-bypass? [03:52] RAOF: Depends how far down the rabbit hole you want to go :) [03:52] Just a high-level discussion of how composite bypass interacts with nested compositors [03:52] (Of which XMir is one) [03:53] Because currently the answer to that appears to be ‘badly’ [03:53] RAOF: I will need to refresh my memory of the bypass work done so far [03:54] Because for nested compositors, composite bypass means “hand out the buffer we received from our server to a client”, and that has a bunch of failure modes. [03:54] RAOF: No, that's the "old" method I'm not using any more [03:55] duflu: Right - but you're not doing a nested compositor. [03:55] RAOF: You're right. That issue needs to be solved/avoided in the nesting logic. I found it problematic so didn't do that [03:55] duflu: Since you're running on the hardware you *can* choose to allocate scanout-ready buffers. [03:56] RAOF: Yes, the conditional-ness of that is TODO :) [03:56] Presently everything can be scan-out [03:57] So, do you have any thoughts about solutions for nestedness? [03:58] RAOF: It actually makes very little sense to pass any buffers from the Display classes down to the client. Because the buffer allocator can of course make a scanout capable buffer without Display* getting involved [03:58] Not to mention you can't trust clients... [03:59] RAOF: My present approach accepts *any* scanout capable buffer, which can come from the client or can come from the Display (default compositing) [03:59] But, on the other hand, nested bypass *requires* that you send the buffer you receive to the client. [04:00] RAOF: Why? that's got high risk of the client misbehaving and breaking the server, surely? [04:00] How do you bypass if the client isn't rendering to a buffer acquired by the nested server? [04:01] ie: The nested server needs to call mir_surface_swap_buffers() on something. What is that something? [04:02] RAOF: Bypass doesn't care which server created the buffer. It still works [04:02] With obvious memory management trickery [04:02] How does the buffer get from the nested compositor to the display? [04:03] It *sounds* like you're talking about client-allocated buffers, which would indeed work fabulously for this. [04:03] RAOF: Yes I was thinking that [04:03] Just doesn't work with mirserver's memory management yet [04:04] Because the client (which is a server) is the one allocating the buffer [04:04] Indeed. [04:05] If we can do *that* then bypass is easy, and xmir is easier. [04:05] It was my understanding that this was not on the table. [04:05] Sounds like a job for Afternoon Team Meeting™! [04:06] Oh. Is that going to occur with everyone in IOM? [04:10] Maybe... ? [05:20] Are we having the weekly this weeting? [05:20] Oh that's what was just being discussed :) Hi [05:20] RAOF: client-focus-notifications...I dunno [05:20] I feel as if the branch is unpopular in a profound way :p it needs more review [05:21] and maybe better ideas [05:21] I kind of feel like it's done [05:50] RAOF: I kept thinking about it over lunch... [05:50] duflu: Oh, and? [05:50] and I don't think there are any fundamental conflicts between nesting and bypass... [05:50] ... just that both at once will require more work so as to not negate bypass benefits [05:51] ... which should be a simple matter of implementing my DisplayBuffer changes [05:51] I mean, any "NestedDisplayBuffer" should be enhanced to implement bypass like GBM does now [05:52] It should all just work so long as both servers use the same logic and enable bypass at the same time [05:52] I still don't see how? [05:53] I mean, you can *certainly* handle bypass on the outer compositor; that works regardless of the client. [05:54] RAOF: And once implemented in the inner compositor (implemented for NestedDisplayBuffer or whatever), then why wouldn't it work? [05:54] What do you mean by "implemented" in this case? [05:55] RAOF: It's a new function I've added to the DisplayBuffer interface. You can safely stub it or implement for bypass support [05:55] * RAOF looks at the DisplayBuffer interface [05:55] Though I may be relying on memory too much [05:56] I think the fundamental problem is that for bypass the inner compositor *is not* allocating a DisplayBuffer [05:56] RAOF: It has to... for N-buffering and to ensure you're not trusting clients [05:57] Which turns around our buffer allocation strategy. [05:57] You are asserting that server-allocated buffers are incompatible with bypass. [05:57] RAOF, duflu, kdub, racarr, hikiko, alf__, thomi, meeting.. [05:58] RAOF: Only what you're proposing nesting should do turns things around. And in an unsafe way [05:58] Not sure how the WiFi will hold up here though [05:58] duflu: Actually, I think with triple buffering *and* 2 buffers available client-side it can be safe. [05:59] Hm, maybe. [05:59] RAOF: On the other hand, I will be free to fully discuss bypass in about 24 hours :) [06:00] morning [06:00] RAOF, kdub, racarr... [06:00] robert_ancell: Logging in to a session with webcam. [06:00] RAOF, ack [06:09] Am I appearing in the hangout? [06:09] I see a bunch of people, but no audio or video. [06:10] RAOF, you show a photo [06:48] abnormally interested in buffers today [06:48] still thinking about bypass [06:48] Please do. [06:49] There's also the extra special case of XMir DRI2 bypass to consider, which has the extra frission of not allowing protocol changes! [06:50] There is? -.- [06:50] (Although the DRI2Invalidate event will be useful there) [06:50] racarr: Well, the case we're aiming for with XMir is to have Unity fullscreen, drawing directly on the framebuffer, for ~0% XMir overhead. Same for fullscreen GL games. [06:52] RAOF: Actually, I think we can afford to enforce the extra restrictions on clients when the client is a nested server (hence very few of them, and controlled by us) [06:52] But generalized bypass does not have that luxury [06:52] duflu: With the unfortunate DRI2 case above :) [06:53] * duflu has no idea what the DRI2 issue is still [06:53] If we want ~0 performance regression on fullscreen games, which we obviously do, then we need to give the DRI2 client (ie: the fullscreen game) a framebuffer to render on. [06:54] RAOF: Ok yes [06:54] I was thinking of that [06:55] as the case [06:55] This means we need to hand out something that will become the framebuffer in response to DRI2BufferBackLeft [06:55] I cannot comment further outside of pure speculation :) [06:55] * duflu goes to find coffee [07:07] Hmm, at what point does the stack depth affect performance?... I keep seeing large stacks in mirserver up to 72 frames deep... [07:08] good morning [07:08] Morning dholbach [07:08] hey duflu [07:12] racarr: Careful with asking community contributors to "fill in testing". Sometimes that can scare people off, or at least make them lost interest to the point of never completing the work. It's a fine line. [07:12] -lost +lose [07:14] ... but it's good and right to ask at least once, I guess. The question then becomes "is the work important enough to us that we fill in the testing ourselves?" [07:38] good morning :) [07:39] Eeeloe, [07:43] duflu, ping [07:43] tvoss_, pong [07:45] RAOF, ping [07:45] tvoss__, pong? [07:45] tvoss__: pong [07:45] tvoss__: 17:43 Got a kernel patch to work, fixing up some xserver packaging, the ppa doesn't seem to have caught fire... [07:46] RAOF, ah cool, what does the kernel patch do? [07:47] Add enough llseek support to dma-buf to let us get the size of one [07:47] ack [07:48] Which was blocking radeon support for egl-platform-mir upstream\ [07:48] RAOF, awesome [07:54] RAOF, want me to give the intel driver update a spin? [07:55] The shiny shiny ickle one? I haven't pushed that anywhere yet. [07:56] I need to go and make dinner; I'll be on later. [07:56] RAOF, yup [07:56] RAOF, I was talking about http://bazaar.launchpad.net/~mir-team/mir/xf86-video-ati-vladmir/revision/2539 [07:56] RAOF, can I just compile it against the testing ppa? [08:11] duflu, so when using the switch branch with system-comp-testing, the usc just crashes [08:12] RAOF, ^ could you quickly verify? [08:12] That's different [08:12] tvoss_: Oh, I noticed yesterday I had changed the ABI without bumping the soname. Make sure *everything* is rebuilt [08:12] ... of libmirserver that is [08:14] tvoss_: Me forgetting to bump the soname means it's possible to accidentally forget to rebuild everything that uses libmirserver [08:18] duflu, that is, I need to rebuild usc, right? [08:19] tvoss_: Yes anything that uses libmirserver. It should have given you a runtime error (missing library) but won't because I forgot to bump the soname/ABI [08:20] tvoss_: I wasted hours last night for the same reason. tests crashing inexplicably [08:20] I'll fix it today... [08:20] duflu, cool, let me know when I can take a look [08:21] tvoss_: No need to wait for me. You can rebuild everything now [08:21] duflu, ack [08:21] * duflu is waiting on cross-compiles [08:24] robert_ancell: At what point can we not bump the server ABI any more? Seems like we have several activities in progress that will do so [08:24] -will +should [08:25] duflu, we'll need to be ABI stable at release, but I think long term we'll just bump the soname every time we make a non-additive change and recompile u-s-c and unity-mir each time that happens [08:25] robert_ancell: Cool [08:25] I don't think we need to worry too much about changing the ABI as long as we bump soname given the small number of libmirserver consumers [08:26] robert_ancell: Yes I forgot to bump and it's caused several people to forget to rebuild [08:26] duflu, right now, we don't need to bump it - the system-compositor-testing PPA is manually kept in a safe state [08:27] once u-s-c hits universe then we're solving that in jenkins with a dependency done by didrocks [08:27] Long term, we'll rely on sonmae [08:27] robert_ancell: PPA rules don't help me while people keep playing with pre-release branches :) [08:27] Just don't want to slow things down too much requiring the soname bumps and associated changes in debian/* [08:28] duflu, who's doing that / what? [08:28] robert_ancell: I mean WIP branches (switch) [08:28] i.e. running u-s-c from the PPA with a locally built version on Mir? [08:29] robert_ancell: kgunn: btw, the ppa worked on ati and intel [08:29] let me retry another run in a few [08:30] didrocks: \o/ hells yeah [08:30] let's cross fingers ;) [08:30] and retry [08:30] sure [08:31] * duflu suspects people are messaging each other from within the same physical room [08:31] * duflu thinks that's strange [08:48] duflu: we don't want to interrupt the meeting [08:48] duflu: but you are not that far from truth :) === dholbach_ is now known as dholbach [08:55] http://paste.debian.net/hidden/f5f6260b/ does this look ok? untested though [08:57] oops, looks like it's wrong :p [09:01] oh correct after all, weee [09:16] alan_g, ping [09:16] hikiko: hi [09:16] hi :) [09:16] How is it going? [09:16] mmm fine in general but I have a question [09:17] I tried to replace the create_nested_platform with the NestedPlatform constructor [09:17] in the_graphics_platform() [09:17] Yes [09:18] but it seems that the lambda cannot return a deduced type [09:19] You need to specify the return type explicitly [09:20] See mir::DefaultServerConfiguration::the_input_report() for an example [09:20] let me check it :) [09:21] oh so you use []()->Type [09:22] but this will cause a problem when I call create_platform isn't it? [09:22] because I have a condition [09:22] in non nested mode I return mg::Platform in nested mgn::NestedPlatform [09:23] or I can use []()->mg::Platform [09:23] hikiko: you must return shared_ptr [09:23] ah the abstract type [09:23] ok :) [09:23] And NestedPlatform must extend Platform [09:24] (sorry I am not so familiar with lambdas) [09:24] See mir::DefaultServerConfiguration::the_input_report() for an example [09:24] yes that's done :) [09:24] ok [09:24] thanks a lot === alan_g is now known as alan_g|tea [09:32] kgunn: been working on it, but tests were failing since they didn't handle the extra ops :P [09:33] mlankhorst: thanks! === alan_g|tea is now known as alan_g [09:45] http://paste.debian.net/hidden/2d845546/ can you test that one? :P [09:55] alf__, alan_g, tvoss_, can you add some info to bug 1203590 if you know what we need from lttng/systemtap [09:55] bug 1203590 in systemtap (Ubuntu) "[MIR] systemtap" [Undecided,New] https://launchpad.net/bugs/1203590 [10:01] duflu, re: bug #1206633 [10:01] bug 1206633 in Mir "mir doesn't start "Error opening DRM device" on nVidia" [Undecided,New] https://launchpad.net/bugs/1206633 [10:01] duflu, I was running as root [10:02] Saviq: OK. Just means it's not a trivial mistake :) [10:04] bah one unfortunate side effect is that VT switching no longer seems to work.. [10:06] duflu, yeah, I had robert_ancell next to me for immediate help, but we didn't get anywhere, hence the bug [10:07] alf__, [10:07] alf__: in multimonitor-gbm-cursor should I be seeing any difference in behaviour? Or does that need other changes? [10:08] ^ that was my question :D [10:08] alan_g: What's the recommended way to ignore uninteresting calls, in tests which really should have no expectation of them? [10:09] duflu: to stub the calls, not mock them [10:09] alan_g: Mixed stub methods in a mock class? [10:10] Problem is I have two test cases which needs it mocked. The rest of the tests shouldn't care ("not interested") [10:10] -needs +need [10:11] duflu: you could, e.g. derive a mock class for the test from a shared stub class. [10:12] Sounds like overkill but would work I guess [10:12] duflu: there's also NiceMock (which IMO is overused in our code) [10:12] meh w/e, this fixes control-C at least.. [10:13] alan_g: Wait, no. I need the mock class in every test. Just one method I wish to ignore in most (it's called during destruction) [10:14] duflu: Then it's probably easier to have the one class and set expect AnyNumber in the constructor [10:15] alan_g: I thought I similar in SetUp and got bogus failures. Maybe the constructor is indeed a better idea [10:15] I thought I *tried* [10:16] That should work too [10:24] hikiko: you have review comments - mir.nested-platform-constructor [10:26] thanks alan_g let me see :) === alan_g is now known as alan_g|afk [10:28] does mir disable xserver vt switches? [10:30] mlankhorst: w/o you proposed change in http://paste.debian.net/hidden/2d845546/ [10:30] i had the vt problem already [10:31] looks like strictly speaking xserver should be spawned with -sharevts -keeptty :P [10:34] considering at this point xserver no longer controls the server === alan_g|afk is now known as alan_g [10:39] So close to finishing, but out of time [10:50] https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800 try 2 [10:57] kgunn: do you know on which part of boost you build-dep on? [10:57] kgunn: because right now the package deps on libboost-all-dev which is now in universe [10:57] and there is a discussion on #ubuntu-devel to only deps on what it's needed [10:58] i see that from linking it's: libboost-program-options-dev libboost-system-dev but there might be other header/template only portions of boost used. [10:59] -lboost_chrono -lboost_date_time -lboost_filesystem -lboost_system -lboost_thread -lboost_program_options -lboost_regex [11:03] robert_ancell: hey [11:03] didrocks, hello [11:04] robert_ancell: so I don't see libboost-all-dev in the MIR [11:04] https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207 [11:04] Launchpad bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,New] [11:04] and Mir depends on it [11:04] the discussion we just had on #ubuntu-devel is that we should of course only build-dep on what we rely on [11:04] 11:58:43 xnox | i see that from linking it's: libboost-program-options-dev libboost-system-dev but there might be [11:04] | other header/template only portions of boost used. [11:04] 11:59:06 xnox | -lboost_chrono -lboost_date_time -lboost_filesystem -lboost_system -lboost_thread [11:04] | -lboost_program_options -lboost_regex [11:04] didrocks, ok, we can switch to that [11:04] * xnox is doing a test build with ^ [11:05] xnox: thanks man :) [11:05] \o/ [11:05] robert_ancell: if so, we'll probably have to update the MIR as well (eventually) [11:05] IIRC filesystem wasn't in main last time I checked [11:06] hm, interesting though - libboost-all-dev had to be in universe like, since longer? [11:08] a long time ago mpi was not wanted in main, so because of that -mpi- portion is split into universe, the rest source packages are in main (if there are rdepends) some of the binary packages might be in universe if there are no rdepends. [11:08] if archive reorg ever happens, this mess with two source packages for default boost will go away. [11:09] so build passes & all unit tests pass (build-time tests) \o/ [11:11] Yeaaa [11:12] robert_ancell: anyway, strange thing that it wasn't noticed earlier that libboost-all-dev is in universe - I didn't see it mentioned in the MIR too! [11:12] sil2100, yeah, I think it was missed because the source package is in main, but not all the binaries [11:15] mlankhorst: i was going to try your mp...but now we got an issue with the boost version in main :-/ [11:18] robert_ancell: https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804 [11:19] xnox, awesome, thanks! [11:19] sil2100: robert_ancell: so chrono & regex will be "rescued" from universe -> main. but that's ok, cause the source package they are build from is in main already. All others are in main already. No M.I.R. is needed for those [11:19] xnox, just added the note how we don't need the debian/changelog entry. Otherwise looks good [11:23] robert_ancell: well the daily landing should be able to use it correctly..... unless you are not using daily landing =) [11:30] robert_ancell: dropped changelog entry. [11:37] mlankhorst, I fixed that MP you made - it is rebuilding [11:46] ok [11:47] for some reason I cant trigger a jenkins rebuild [11:48] did anyone else have the same problem? [11:52] hikiko: Not logged in over VPN? [11:52] no [11:52] I tried from the web interface [11:52] do I need a Canonical's IP for this? [11:53] You need to log into the web interface via the VPN [11:54] I see === alan_g is now known as alan_g|lunch === hikiko is now known as hikiko|lunch === hikiko|lunch is now known as hikiko === alan_g|lunch is now known as alan_g [13:19] hikiko: Do you have a plan for what to do next? [13:20] alan_g, I was about to push the fix and ask you [13:20] shall I continue the nested platform or do the native one first? [13:22] hikiko: I'd imagine that writing the nested one would identify the functions needed from the native one. [13:25] alan_g, alf__ suggested that the nested platform will keep a pointer to the underlying native platform (mg::Platform => either GBM or Android) and call the native funct when necessary, I guess your idea is that I will add a fill_ipc, get_ipc, create_buffer_alloc... etc in the NativePlatform class and call these? [13:26] sorry :s/NativePlatform class/native platform interface [13:26] hikiko: Yes. (If we end up with NativePlatform being identical to Platform we can merge them.) [13:26] the native platform interface will end up to call the GBM/Android functions? [13:27] oh, ok :) [13:27] hikiko: alan_g: I think that the NativePlatform interface will turn out to be very close to mg::Platform, since we mostly want to relay requests [13:27] hikiko: alan_g: but we can decide later, as Alan suggests [13:28] yes, maybe I could just keep the create_native_platform and create a 2nd constructor for each platform [13:28] ok we ll see [13:30] hikiko: I'm assuming your earlier spike gives you enough to write a first draft of the nested code. [13:31] yes, although in the previous branch I used to keep a ptr to the native mg::Platform [13:31] there was no NativePlatform interface [13:31] but it's not a big deal to add the methods to the native platform class [14:26] mlankhorst: @setsid, does the change also affect vt switching combinations (Alt+F*) or only Ctrl-*? [14:35] it ignores all keyboard input in mir, would need to actually handle input for it to be useful [14:35] I don't know what the previous behavior was, though.. === alan_g is now known as alan_g|tea [14:39] xorg seems to generate XF86Switch_VT_1 etc, but I have no idea why it does, and not simply change to the appropriate vt === alan_g|tea is now known as alan_g [14:43] mlankhorst: ok, so we need to be able to handle at least VT switching key combinations ourselves before this lands, and also add a kill Mir key combination, otherwise development will become painful [14:48] ... while you still run with --disable-input ? [14:49] with openarena benchmarks xmir is faster than x on intel now [14:58] yeah but getting 400 fps on glxgears, so dno how reliable that is :p [16:11] MORNING [16:11] too early for shouting :) === kubuntu is now known as Guest40281 [18:57] Lunch break :) will be a little long (~1 hour) little sister is off exploring down town SF and got a little spooked so I am going to go meet up with her :) [20:49] Back [21:02] just installed daily and added ppa for mir. did apt-get update, reboot etc. Is there anything I should do in order to verify it's using mir? [21:05] crippledmonk, if you want to verify tou are using xmir do: ps aux | grep mir [21:05] s/tou/you [21:10] ps -ef | grep unity-system-compositor [21:13] bschaefer: I got this todd 4166 0.0 0.0 4444 824 pts/0 S+ 14:11 0:00 grep --color=auto mir [21:14] crippledmonk, nothing else? [21:14] crippledmonk, make sure you have unity-system-compositor installed [21:14] just a sudo apt-get unity-system...... in term [21:15] yup! [21:15] you can also check by doing apt-cache policy unity-system-compositor [21:16] it gave me errors...unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130730bzr898saucy0) but 0.0.8+13.10.20130731.2-0ubuntu1 is to be installed [21:16]