[00:23] H [00:23] Dear armhf: really? === renato_ is now known as Guest30310 [03:38] Hmm, did some pipe specific to Canonical just go down? [03:43] Dunno. What are you trying to resolve? [03:44] RAOF: Canonical mail, Launchpad and IRC all went quiet for a while. [03:44] Now they're back [06:31] duflu: Is there any particular reason not to _catch_ the exceptions in the compositing thread? [06:32] RAOF: Because we don't know how to recover from them, and the act of catching trashes the stack trace [06:32] Is there another solution? [06:37] Hm. I think we actually _do_ know how to recover from them; try again next frame. [06:37] That'll work for some of the errors. [06:37] Well, some classes of failure. [06:38] RAOF: Recovery would be excellent if it was reliable. If there's a risk of looping then it's safer to get a nice bug report. [06:38] We'd need to try for 5 or so frames, then bail. [06:38] But still, I'd prefer to debate the recoverability of each scenario separately [06:39] Yeah. That'd require us to have an actual exception hierarchy. And to proxy said things to the main thread, I think. [06:39] Which is indeed a post-RTM thing. [06:39] RAOF: Yes, actual exceptions with actual catching [06:40] Although if the recovery is near the ioctls then maybe not even exceptions are required [06:42] How useful were the cores generated when these exceptions _were_ generating cores? [06:43] Because looking through the code it looks like a lot of the error state has dropped out of the stack before the exception is thrown. [06:45] RAOF: Very, for a brief while between the first fix and when it regressed. [06:45] Unfortunately the first fix occurred after the first flood of bug reports [06:45] * RAOF is quite surprised [06:45] we could assemble additional error information with boost exception while unwinding [06:45] * duflu offers anpok the wear jar [06:45] *swear jar [06:46] anpok: You know what we should do? Rather than use enable_error_info on std::runtime_errors, we should just throw std::system_errors. [06:46] Throwing anything you don't know how to catch and recover from is the problem [06:47] duflu: Not really, because we're a library. [06:47] RAOF: well .. if there is relevant information in the stack itself [06:47] But throwing something we don't handle in a thread of our creation is indeed a problem. [06:47] but yes system_error looks more like the right type [06:47] * RAOF queues up a “replace everything with system_error” branch. [06:49] RAOF: Unless it includes full catching and recovery it's a step backwards... we really need to deal with each throw separately [06:49] It's a long path [06:57] It's not a step backwards. At worse it's a step sideways. It gets us a better exception message if nothing else. [06:57] It's also just the sort of mechanical transformation that I feel I'm about capable of doing at the moment :/ [06:58] RAOF: I know how that feels. However using any exceptions without full recover implemented will fail to solve the bug [06:59] recovery even [06:59] That is correct. [06:59] RAOF: OK then, no problem. Please don't create conflicts for me though :) [07:10] Oh Compiz/Unity7 I won't miss you... just as soon as we have the replacement ready [07:11] * duflu has the tiny phantom window problem. They sporadically appear and disappear [07:24] camako: Still showing 0.1.9 is the latest download. Don't forget https://launchpad.net/mir Development focus = 0.5 [07:26] duflu... Weird... I coulda sworn I saw 0.4.0... lemme check again [07:26] camako: Should be Development focus = 0.5, but is presently utopic (which is obsolete) [07:27] You have to configure the Mir project page [07:30] Sorry I can't give more details. I don't administer any projects any more. I can't see a project details page to cite for an example [07:36] camako: You should have a "Change project details" option (or similar) on https://launchpad.net/mir [07:36] ... which I don't [07:38] Oh and the trusty (and earlier) series possibly should still be visible. Because it's theoretically possible for them to get fixes backported, although highly unlikely [07:39] duflu still looking [07:41] camako: https://answers.launchpad.net/launchpad/+question/82049 [07:43] duflu .. "change details" doesn't exist for me [07:43] camako: Oh. You aren't a project admin either [07:43] I wonder who it [07:43] is [07:44] duflu... guess not [07:44] Thomas? [07:45] didrocks, sil2100, Saviq: Can anyone add camako to pspmteam? [07:47] Or Mirv? ^ [07:48] The Mir Tech Lead has no permissions to administer the Mir project :) [07:49] duflu.. I was able to change status for 0.3, 0.4 as I was the "release manager" on lp... [07:49] for 0.5, you are the release manager since you created it [07:49] camako: Yeah I can do that too on the series I created. But you need top-level access to admin the Mir project. That's owned by https://launchpad.net/~pspmteam [07:50] right [07:50] camako: popey is also an admin. Ask him when he comes online [07:51] duflu... ok [07:51] It's really annoying then the button you need is hidden [07:52] duflu, camako looks like dbarth or popey can add people there [07:52] Yep. And David's not online yet either [07:52] ogra_.. ok thanks [08:00] alf_: You around? [08:00] duflu: yes [08:01] alf_: Are you familiar with any changes that happened in June around buffer ownership? Looks like the new behaviour is that a client can own _all_ the buffers until/unless a compositor needs one. [08:01] Sounds like a bug but may be a feature [08:02] duflu: I don't remember of an explicit change, but it sounds like something that may have changed by Alberto's work on the BufferQueue? [08:04] alf_: It seems to work but in theory shouldn't. If a client is allowed to have all the buffers on startup then compositors get what? [08:04] I guess I'll keep trying to write more tests till I can prove something is amiss [08:06] Soooooo. [08:06] duflu: Perhaps it works currently because the clients get one buffer at a time? [08:06] Why does armhf seem to receive fewer fds than sent? [08:07] RAOF: sizeof() silliness? [08:07] Hm. [08:07] But AFAIK sizeof all the important bits is the same as desktop [08:07] I shall come back to this later. [08:08] But I *send* 2 fds, and cmsg->cmsg_len on the receiving end is 16. [08:08] Which is *not* CMSG_LEN(2 * sizeof(int)) [08:08] Anyway, later. [08:08] RAOF: Oh. I don't understand the cmsg stuff but remember everyone was suspicious of recent changes to it === chihchun_afk is now known as chihchun [08:56] someone ping me? [08:56] camako, duflu ^^^^ [08:56] popey, hey [08:56] popey: Yeah can you add camako to pspmteam? [08:56] ogra_.. thanks [08:57] ;) [08:57] We presently have no one able to administer the Mir project :) [08:57] * popey looks [08:57] "lol" [08:57] I think kgunn is part of the pspm team [08:58] but yea.. I should be as well [08:58] done [08:58] popey: Ta [08:58] popey thanks [08:59] duflu... done... looks good now? [09:00] camako: Ah cool yes [09:00] np [09:01] camako: For cleanliness we could rename "trusty" to "0.1" and "saucy" to "0.0" [09:01] I think that's possible [09:02] duflu... sure [09:03] duflu.. done! Looks all neat :-) [09:04] camako: Cool again. Also looks better here now: https://launchpad.net/ubuntu/+source/mir [09:04] yep [09:05] camako: I think we need a new plan to reduce branching. Somehow we need to avoid branching until after the server ABI has changed [09:06] duflu.. yea I agree [09:06] Perhaps explicitly targeting lp:mir/0.N (where N is "next") would work [09:07] then we don't need to call anything "devel" [09:07] but that increases the risk of proposals targeting the wrong one [09:08] Whatever the approach it should be possible to release 0.5.1, 0.5.2 ... before ever needing to branch a 0.6 for example [09:08] yea currently it's a presumptive approach [09:17] duflu: instead of changing targets can we just rename devel and create a new one each release [09:18] alan_g: You mean use "devel" as a series? I think that would look confusing in Bugs that are targeted [09:18] Better to have a number [09:19] Or just keep the development branch as it is and tag 0.5.x on devel _until_ an ABI break happens [09:19] Then branch [09:20] But that requires a "freeze" period for each point release. Same old problem === chihchun is now known as chihchun_afk [09:47] duflu: got time to review this before you go? https://code.launchpad.net/~alan-griffiths/mir/fix-1300653/+merge/225692 [09:47] alan_g: Maybe :) Hang on [09:53] duflu: thanks [09:54] np === MacSlow is now known as MacSlow|lunch === chihchun_afk is now known as chihchun === MacSlow|lunch is now known as MacSlow === Trevinho_ is now known as Trevinho [12:54] hey all === renato_ is now known as renato__ [13:01] anpok: hey, I'd need some help with touch input events. [13:01] would you have a bit of time for that? === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === doko_ is now known as doko [14:58] mterry: Hi! I am working on refactoring USC. Do we have a document (or even better tests) describing the expected behavior for session switching and spinner display when we get DM events? [14:59] alf_, no, but I could try to put together a quick explanation [14:59] mzanetti: meeting is in a minutes [14:59] -s [14:59] right after that [15:00] mterry: That would be useful, thanks. Based on that I can write some tests you can then review for expected behavior. [15:03] mterry: could you please also briefly describe in the explanation what exactly "next" and "active" mean for the DM [15:03] alf_, yup [15:03] writing that now in fact :) [15:04] mterry: thank you :) === chihchun is now known as chihchun_afk [15:24] alf_, sent email. Let me know if you have questions [15:24] mterry: great, thanks === chihchun_afk is now known as chihchun [15:41] camako: Sorry, hangouts crashed computer [16:21] alf_: hey just to tell you, the issues I was having on Friday last week (the GL/GLES conflict) I resolved. I needed to call eglBindAPI before mir created a context. However I had made a typo: EGL_OPENGL_BIT instead of EGL_OPENGL_API [16:21] so no need for an immediate mir change [16:22] greyback: Interesting that this works, since Mir sets eglBindAPI() to ES2 when creating a context [16:23] greyback: this for the desktop, IIRC? [16:23] alf_: really? Heh, then I'm confused :) Yes desktop [16:41] dednick: had a look at this yet? https://code.launchpad.net/~alan-griffiths/mir/spike-trusted-helper-socket/+merge/225677 [16:41] alan_g: eh. no, i haven't had a chance yet. [16:41] alan_g: sorry. i will try to get it in tomorrow morning. Just busy trying to get somethings to land [16:43] dednick: np. (Until kgunn asks why it didn't land.) ;) === alan_g is now known as alan_g|EOD [18:07] so, for example, a game for example metro,... will be compatible in ubuntu mir? [18:08] i think no [18:08] PreSSion, not enough info.... mir can run games [18:09] yes, i know, but i want buy metro for linux [18:09] but idk because i don't know if in the future i will can play in ubuntu with mir [18:10] sorry for my "engrish" [18:10] so, I want to buy a game, its ok, i know now i can play in ubuntu [18:11] but i don't know if in the future i will can play in the future ubuntu versions with mir [18:11] we should have backwards compatibility with xmir [18:12] oh nice, so i will play for example metro in ubuntu phone [18:12] posible right= [18:13] i mean when i put the dock station with the monitor [18:14] well most phones are arm not x86 [18:14] so no binary compatibility [18:15] yes, but ubuntu said his phone will have full convergence [18:15] so, ubuntu will sell some phone with x86 processor? [18:21] nice, i see one of the ubuntu phone have got an intel atom processor, so that phone will be full convergence and play games as metro right? [18:21] with xmir ofc [18:37] allllmost done with my foray in to surface attributes [18:38] I instantiated 4 common tests over all of them 1.Default value. 2. Notifies observer on change 3.Doesntnotify observer on default change [18:38] * greyback raises an eyebrow [18:38] err on no change [18:38] 4. Throws on invalid value [18:39] and only about half pass... [18:39] and then DPI uses invalid value to mean "Query" [18:40] greyback: ? [18:41] racarr: just curious [18:41] racarr: thought you were adding more surface attributes or something [18:42] haha not yet [18:43] racarr: would be nice if we could have a protobuf style way of defining properties on surfaces, just a text file which defines type and range could do a lot [18:44] * greyback wakes from dream world and goes back to work [18:44] haha [18:44] im not sure about that far [18:44] but ultimately I would like the attribute system to be more generic... [18:44] i.e. cursor setting should be an attribute... [18:44] its not clear that size isnt an attribute [18:44] etc [18:45] it was one reason I wanted the custom protobuf stuff, so we could rapidly iterate on surface attributes. Sadly that wasn't possible with protobuf [18:49] * kdub_ sorta likes that idea [18:49] s/sorta// [18:55] :) [18:55] all im doingh now...is ensuring consistent semantics on all of them [18:55] and also making them [18:55] sent on surface creation [18:55] so that the client can always query them with a non blocking getter [18:55] currently we are missing getters for 2 [18:55] and one has a blocking getter [18:55] (dpi) [19:00] i've been thinking that some sort of generic/extensible compositor data system would be a win too [19:01] mm [19:02] like... [19:02] visibility === josharenson1 is now known as josharenson [19:05] or animation... the compositor should be able to tag the surfaces with data [19:05] and the data can be generic to libmirserver [19:05] and every individual compositor keeps the concept of what data they're tagging with [19:05] * kdub_ ends musing [19:27] Lunnch === renato_ is now known as Guest32432 === Guest32432 is now known as renato__ [22:04] hey guys, anyone run xmir with nouveau recently? I'm just seeing a black screen for USC [22:06] bregma: hey, I'm having trouble testing unity8-mir on my desktop (well having trouble with USC) - could I ask you to do a quick test of ppa:unity-team/phone-right-edge to see if unity8-mir comes up or not? === w00t_ is now known as w00t [22:18] ok so working with mterry a bit, he think it's more XMir issue than USC. [22:18] let me recap: [22:19] I have ubuntu-desktop-mir & USC installed [22:20] When I startup, after plymouth, I just get a black screen [22:20] I see that USC is running though. Also appears to be an X server running [22:22] here's useful log-files http://pastebin.ubuntu.com/7762355/ [22:22] mterry sees from the USC log file that USC never sees a client session - i.e. the xmir greeter session [22:23] running mir 0.4.0 [22:33] greyback: no ideas on my end sorry... [22:33] you can start xmir with Xorg :1 -mi r [22:34] -mir [22:34] and make sure it doesnt segfault [22:34] even Xorg :1 -mir 0 -retro [22:34] to get the crosshatch so there will be something [22:34] on screen lol [22:34] racarr, you don't need -mirSocket? [22:34] oh [22:34] maybe [22:34] I think you can use [22:34] MIR_SOCKET [22:34] env [22:34] oo right yeah you can [22:50] racarr: thanks for suggestion, doing that leaves me with a hanging process http://pastebin.ubuntu.com/7762468/ [22:51] greyback, i was running into that earlier attempt to do xmir ... let me try on a mir server [22:52] bschaefer: thanks :) [22:52] np! [22:53] greyback, X seems to start up for me [22:53] greyback, this is just a mir_demo_server though, + xmir [22:54] bschaefer: ok, I'll try that, just to see [22:54] wouldn't hurt to try that out [22:56] huh, I get a "Connection refused" error. [22:56] but I can run a mir demo client ok [22:56] greyback, chmod 777 /tmp/mir_socket? [22:56] o [22:56] hmm [22:56] greyback, is it trying forever to attempt to connect to the xserver? [22:56] bschaefer: nope [22:56] bschaefer: nope, it terminates [22:57] greyback, whats your MIR_SOCKET? [22:57] err well a demo works... [22:57] http://pastebin.ubuntu.com/7762489/ [22:57] why does a demo work... [22:57] /run/mir_socket [22:57] oh oh oh [22:57] greyback, mir_demo_server_* puts the socket in /run for you? [22:58] /tmp/mir_socket [22:58] yeah [22:58] that'll be the issue :) [22:58] Loading extension GLX [22:58] Driver needs flags 0, incompatible with nested, deleting. [22:58] Driver needs flags 0, incompatible with nested, deleting. [22:58] Driver needs flags 1, incompatible with nested, deleting. [22:58] thats normal, at lease i hit those [22:58] ok [22:58] then the background loads, and you get a nice x cursor [23:01] bschaefer: kinda, I just saw the screen flash black/grey/black/grey/black and I'm back to a black screen [23:02] greyback, o, that doesn't sound good. I get the flashing for a second, then it loads [23:02] maybe the xorg log offers some info? [23:05] bschaefer: nothing I can see as obvious anyway: http://pastebin.ubuntu.com/7762506/ [23:05] greyback, im also using intel [23:05] which could explain some things... [23:05] bschaefer: indeed [23:05] but this did used to work [23:06] well it's late here, think I'll give up for the night, [23:06] interesting... [23:07] bschaefer: thanks for the help so far [23:07] greyback, its only mid afternoon here :) [23:07] greyback, hopefully you can figure out some more info! Have a good night! [23:07] bschaefer: ah you folk in your sunny climes [23:07] haha [23:07] o/ [23:48] RAOF: Ping? [23:48] racarr: Pong! [23:48] RAOF: The import of xcursor.c has lead to mass abstention [23:48] on cursor spike phase 6 [23:48] can you weigh in? [23:49] I mean not urgently or anything just at some point [23:51] racarr: Sure, queued up. [23:51] thanks