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