| RAOF | Grr. Do mir_demo_client* work for anyone else on the current staging PPA? | 00:40 |
|---|---|---|
| RAOF | They all fail for me in assert(mir_surface_is_valid()), and XMir also dies with a garbage MirBufferPackage | 00:42 |
| bryce | RAOF, I updated to the latest staging ppa on my intel box last Friday, but the screen was just static noise | 00:49 |
| bschaefer | RAOF, yeah, im getting the same thing :( | 00:51 |
| bschaefer | was working just before I pulled some new changes to lp:mir | 00:52 |
| bschaefer | RAOF, looks like rev 590 caused the issue for me | 00:56 |
| * kdub just merged lp:mir onto my working branch, looks like i see the same thing on android | 00:57 | |
| kdub | i'll try to confirm the rev590... | 00:57 |
| kdub | bschaefer, yep... something happened in 590 | 01:01 |
| bschaefer | kdub, its a large branch soo hopefully it'll be easy to track down | 01:02 |
| racarr | RAOF: Err. so I had garbage mir buffer package | 01:03 |
| racarr | but then I built mesa with usa-dma-buf which you still didn't merge to the main github branch | 01:03 |
| racarr | and it worked fine | 01:03 |
| racarr | oh 590 | 01:04 |
| RAOF | I actually reverse-merged that (ie: merged egl-platform-mir into -use-dma-buf), and the mesa packages in the PPA aren't built out of either of those branches anyway. | 01:04 |
| racarr | RAOF: New theory...something crazy due to a bug | 01:05 |
| racarr | try with --enable-input=true | 01:05 |
| racarr | the_input_focus_selector needs to | 01:05 |
| racarr | check the options and ahve a null implementaiton | 01:05 |
| racarr | like the input manager does | 01:05 |
| racarr | trunk right now with --enable-input=false (the default) is starting up a malformed input stack | 01:05 |
| racarr | and who knows what happens | 01:05 |
| racarr | um. | 01:05 |
| racarr | I'll propose a branch to fix it soon. I actually need to run and do some errands though | 01:06 |
| RAOF | racarr: Correct guess! | 01:07 |
| kdub | ok, trunk with --enable-input=true works for me too | 01:07 |
| racarr | ok | 01:07 |
| racarr | sorry about that | 01:07 |
| kdub | let's set the topic until its changed | 01:07 |
| racarr | I don't remember how to get my +o back | 01:07 |
| racarr | but! I really do want to run some errands because I need to be somewhere by 7 | 01:07 |
| racarr | ill be back later though, and even later for team meeting :) | 01:08 |
| racarr | Cheers! | 01:08 |
| kdub | well, until the proper fix for --enable-input=false is in | 01:09 |
| kdub | let's change the default | 01:10 |
| kdub | https://code.launchpad.net/~kdub/mir/server-startup-bandaid/+merge/159270 | 01:10 |
| kdub | bandaid branch^^ | 01:11 |
| bschaefer | kdub, I can approve that for you, if you don't mind | 01:13 |
| kdub | bschaefer, sure | 01:14 |
| * bschaefer isn't sure what the procedure for MPs are in lp:mir | 01:14 | |
| bschaefer | approved | 01:14 |
| kdub | bschaefer, one reviewer +1, plus no blocking comments | 01:14 |
| bschaefer | kdub, sounds about normal :) | 01:15 |
| kdub | bug report: https://bugs.launchpad.net/mir/+bug/1169781 | 01:16 |
| ubot5 | Launchpad bug 1169781 in Mir "mir after rev590 won't run without --enable-input=true" [Critical,Confirmed] | 01:16 |
| kdub | someone with ops set the /topic to mention to run with --enable-input=true in the meantime? | 01:22 |
| duflu | kdub: I always assumed it was 2+ reviewers? | 01:39 |
| duflu | No wonder my proposals linger :) | 01:40 |
| racarr | I think its understood as +2 for nontrivial proposals | 01:55 |
| racarr | but that's just how I have been thinking | 01:55 |
| duflu | Yeah, trivial or time-critical stuff would be only 1 | 01:58 |
| duflu | time-critical means when something is broken and it's holding us up | 01:58 |
| racarr | https://code.launchpad.net/~robertcarr/mir/fix-disabled-input/+merge/159277 | 02:05 |
| racarr | exists | 02:05 |
| RAOF | racarr: Code looks fine; checking that it actually works, too :) | 02:32 |
| robert_ancell | "Internal compiler error: Error reporting routines re-entered." | 02:44 |
| robert_ancell | seriously GCC? | 02:44 |
| duflu | Error during reporting of the first error? Nice | 02:45 |
| smspillaz | robert_ancell: std::make_shared ? | 02:58 |
| robert_ancell | smspillaz, it looks like it. I'm trying to reduce the program to create a test case | 02:59 |
| smspillaz | robert_ancell: known bug | 02:59 |
| smspillaz | https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1165732 | 02:59 |
| ubot5 | Launchpad bug 1165732 in gcc "GCC 4.7.3 internal compiler error when using std::make_shared" [Medium,Confirmed] | 02:59 |
| smspillaz | robert_ancell: if you have a class that would fail to have its constructor compiled (eg, because it was private or had pure virtual methods) then gcc freaks out when you get that inside of a template | 03:00 |
| robert_ancell | smspillaz, ah | 03:00 |
| smspillaz | robert_ancell: we should probably put that in the channel topic, I've seen four different people hit it and then start to write testcases :) | 03:00 |
| robert_ancell | ha! | 03:00 |
| RAOF | And, of course, the solution is to build with clang, which provides non-terrible error messages. :) | 03:01 |
| smspillaz | speaking of clang | 03:01 |
| smspillaz | duflu: needed to ask you something | 03:01 |
| smspillaz | duflu: remember when we made the templates extern for compiz plugins? | 03:01 |
| smspillaz | (eg PluginClassHandler, WrapableInterface etc) | 03:02 |
| racarr | RAOF: Thanks :) | 03:03 |
| racarr | robert_ancell: It's a known bug I believe that is fixed upstream according to some mailing list post I read or something | 03:03 |
| robert_ancell | racarr, yeah, the bug trail shows its a regression that's been fixed | 03:03 |
| RAOF | It's a regression from 4.6, and it's fixed in 4.8 apparently. | 03:03 |
| duflu | smspillaz: Yeah I remember | 03:04 |
| smspillaz | for some reason (dunno why yet) if you have liba.so which is linked to libb.so, both of them are not in the system library path, liba.so has a template definition that libb.so needs, if you dlopen libb.so but not liba.so it doesn't pull in the template | 03:04 |
| duflu | (sorry, am outside occasionally talking to painter) | 03:04 |
| smspillaz | no problem :) | 03:04 |
| smspillaz | duflu: any ideas ? | 03:04 |
| smspillaz | nm -S says its defined as "W" in liba.so | 03:04 |
| smspillaz | and U in libb.so | 03:05 |
| duflu | smspillaz: Yeah (W)eak symbol | 03:05 |
| smspillaz | cool, so what do I do in order to get a definition in libb.so ? | 03:05 |
| duflu | I don't follow the problem yet | 03:05 |
| duflu | Hang on | 03:05 |
| smspillaz | I'll try and write a simple testcase | 03:06 |
| smspillaz | (this is just my understanding of the problem by looking at compiz plugins) | 03:06 |
| smspillaz | ohhhh hmm | 03:07 |
| smspillaz | I wonder if the weak symbol is a template that never got defined | 03:07 |
| smspillaz | just declared as "yeah this exists" | 03:07 |
| duflu | smspillaz: I see. Yes. You don't want to accidentally pull in symbols from indirect libraries, for safety. I don't know how you would even if you wanted to. | 03:07 |
| smspillaz | and then the actual definition is some other symbol | 03:07 |
| duflu | (W)eak means defined, but can be rebound at runtime | 03:07 |
| duflu | smspillaz: Your problem might be less obvious. Only an explicit instantiation will create all methods for the class. Otherwise the default is to only create what you used the first time. External users might depend on some methods that do not exist | 03:09 |
| smspillaz | duflu: well, in this case they're directly linked | 03:09 |
| smspillaz | duflu: well, I don't know if its that. If for example, I dlopen both liba.so and libb.so then libb.so gets the definition | 03:10 |
| smspillaz | but its perplexing, because libb.so is definitely linked to liba.so, its just in a custom rpath (eg $prefix/lib/compiz) | 03:11 |
| duflu | smspillaz: Dependencies only go one way. If A links to (depends on) B, then dlopen(B) will indeed be missing everything that A provides | 03:11 |
| smspillaz | duflu: ah, sorry, B is linked to A | 03:11 |
| duflu | smspillaz: Yeah you need dlopen flag RTLD_GLOBAL (default is RTLD_LOCAL for safety) | 03:12 |
| duflu | You're usually meant to dlsym functions you need and not implicitly gain symbols from plugins loaded | 03:12 |
| smspillaz | duflu: hmm, what do you mean by "implicitly gain symbols from plugins loadeD" | 03:13 |
| smspillaz | *loaded | 03:13 |
| duflu | smspillaz: I recommend putting common template instantiations in a separate library, or duplicating them safely with -Bsymbolic | 03:14 |
| smspillaz | duflu: I was going to suggest that | 03:14 |
| duflu | smspillaz: Default is RTLD_LOCAL so you gain NO symbols from the load, unless you grab them explicitly (dlsym()) | 03:14 |
| smspillaz | duflu: so you'd suggest a libcompiz_opengl_interface.so in the $prefix/lib ? | 03:15 |
| duflu | RTLD_GLOBAL however means you get all symbols from the loaded library, which might be used in a later dlopen | 03:15 |
| smspillaz | duflu: I don't think the problem is that I'm trying to get symbols from a library that I've opened and have not dlsym'd yet, rather its getting symbols from a another library that the library I'm dlopening is linked to | 03:16 |
| smspillaz | (though maybe that's what you're referring to) | 03:16 |
| duflu | smspillaz: The big risk is: Load plugin A, load plugin B, unload plugin A. You could have B accidentally bound to symbols (no longer addressible) | 03:16 |
| duflu | .. bound to symbols from the unloaded A | 03:16 |
| smspillaz | duflu: I don't see why that would arise if B was linked explicitly to A | 03:17 |
| duflu | smspillaz: Because the dynamic loader only allows one copy of each symbol name. If one already exists from an earlier plugin then the later plugin binds to that copy | 03:17 |
| duflu | So you either need a universally unique library for common symbols, or build with -Bsymbolic to tell the dynamic loader that each plugin should get private copies | 03:18 |
| smspillaz | oh I see, so we initially get the symbols from loading A, then B, which is linked to A doesn't bring the symbols in, then A gets unloaded and the symbols are gone | 03:18 |
| smspillaz | duflu: iirc we had some trouble with -Bsymbolic. I'll try the separate library approach | 03:19 |
| duflu | smspillaz: -Bsymbolic is _only_ a problem if your classes have static members which are unsafe to have multiple copies of | 03:20 |
| duflu | It also causes code bloat, but maybe not so bad | 03:21 |
| duflu | smspillaz: On the other hand, explicit instantiation in a separate library means you instantiate all methods (most of which you never use). And that can cause worse code bloat | 03:21 |
| smspillaz | duflu: well, we definitely use all the methods | 03:22 |
| duflu | That's OK if it's your own template (not from the STL) | 03:22 |
| smspillaz | yep, its our own template | 03:23 |
| smspillaz | duflu: okay, I think I'll go with that then. | 03:27 |
| duflu | smspillaz: If it's all opengl-specific then you don't need a new library. Just instantiate it in the opengl plugin | 03:27 |
| smspillaz | been trying to fix this long-standing issue where loading plugins effectively causes other plugins to be implicitly loaded | 03:27 |
| smspillaz | duflu: well, see that's the thing. we do instantiate it in the opengl plugin | 03:27 |
| smspillaz | (or at least I think we do) | 03:27 |
| duflu | And remember to "extern" the template in public headers | 03:28 |
| duflu | Or else you'll have more copies | 03:28 |
| smspillaz | duflu: yeah, its already extern'd | 03:28 |
| duflu | smspillaz: I think implicit loading on dependent plugins is a good thing. You shouldn't have to know what A depends on if all you want to load is A | 03:29 |
| smspillaz | duflu: the problem is optional dependencies | 03:29 |
| duflu | Oh, the optional ones | 03:29 |
| smspillaz | eg, I need to be able to set up a test framework so that we load move, but move doesn't pull in opengl | 03:29 |
| smspillaz | but move implicitly does that because it checks if opengl is available | 03:30 |
| smspillaz | ... by pulling in opengl | 03:30 |
| smspillaz | which then causes opengl to be loaded | 03:30 |
| smspillaz | again implicitly | 03:30 |
| smspillaz | its a bit nasty | 03:30 |
| duflu | I would like to say it should be a simple flag in a simple loading call: CompizLoadPlugin(foo, NO_OPTIONALS) | 03:30 |
| duflu | But I remember it's not the simple | 03:30 |
| smspillaz | duflu: well, the way it works at the moment is that it calls PluginClassHandler <GLWindow, CompWindow>::get () | 03:31 |
| smspillaz | which *should* go to the vtable and then return null if it isn't loaded | 03:31 |
| duflu | Arg. I'm having terrible flashbacks | 03:31 |
| smspillaz | except that I fixed a problem several years ago which had the side effect of short-circuiting that | 03:32 |
| smspillaz | haha | 03:32 |
| smspillaz | anyways, maybe the problem is that we never really explicitly instantiated that template anywhere in opengl | 03:32 |
| duflu | In an ideal world, a plugin system should start with simple C functions which you look up by dysym. And then pretty quickly when all succeeds you can get a pointer/reference to higher-level objects | 03:33 |
| duflu | *dlsym | 03:33 |
| smspillaz | duflu: that's basically how it works right now | 03:33 |
| smspillaz | (or at least, that's the entry point from core) | 03:33 |
| duflu | Interesting trivia on the subject of bloat from template instantiation... quite often it is the symbol name itself that wastes the most space. Not the code. It's not uncommon for mangled template names to be hundreds of characters long. | 03:37 |
| duflu | Made worse by overuse of namespaces and default parameters like allocators | 03:38 |
| smspillaz | duflu: heh | 03:46 |
| smspillaz | _ZN5boost7variantIbifSsNS_17recursive_wrapperISt6vectorItSaItEEEENS1_I10CompActionEENS1_I9CompMatchEENS1_IS2_IN10CompOption5ValueESaISB_EEEENS_6detail7variant5void_ESH_SH_SH_SH_SH_SH_SH_SH_SH_SH_SH_E8assigner11assign_implIS5_EEvRKT_N4mpl_5bool_ILb0EEESQ_NSP_ILb1EEE.isra.230 | 03:46 |
| smspillaz | case in point | 03:46 |
| racarr | smspillaz: How did you guess my password | 03:47 |
| smspillaz | oh crap | 03:47 |
| duflu | Yes, and for some reason compilers need to emit that string _many_ times in a single object | 03:47 |
| smspillaz | I've been found out | 03:47 |
| smspillaz | racarr: ahaha, that'd be awesome "my password is a mangled template symbol" | 03:47 |
| smspillaz | -EUNGUESSABLE | 03:48 |
| * duflu wonders what _SH_SH_SH_SH translates to | 03:48 | |
| smspillaz | the compiler freaking out | 03:49 |
| smspillaz | duflu: I feel like lots of these problems could be solved by having a binary format specifically designed to handle C++ | 03:50 |
| smspillaz | like, for once, being able to have aliases for template parameters | 03:50 |
| duflu | smspillaz: Kinda. It still needs to be copy and pasteable sometimes | 03:50 |
| smspillaz | like 43d452 = int, string, char, bool | 03:51 |
| * smspillaz notes that the majority of C++'s problems come from trying to be bolted on top of a C-like infrastructure | 03:51 | |
| smspillaz | the solution is clearly to abolish C *waits for pitchforks to arrive at door* | 03:52 |
| duflu | More generally a lot of problems would be solved by well-defined symbol/linkage rules in the language definition. Some languages do that | 03:52 |
| smspillaz | you mean Go, right ? :p | 03:53 |
| duflu | Java, mostly | 03:54 |
| duflu | And probably Go | 03:54 |
| racarr | I heard all the cool kids were using rust last week | 03:55 |
| smspillaz | duflu: so I'm still wondering, even if I explicitly instantiate the template in liba, have it declared extern, then link libb to liba, I don't get the definition on dlopening libb | 03:56 |
| duflu | smspillaz: You may not "get the symbol" if it wasn't already in use at run-time before the dlopen | 03:57 |
| duflu | Hmm | 03:57 |
| duflu | smspillaz: As always, link with -zdefs (CFLAG -Wl,-zdefs) to tell you what you've forgotten at build time | 03:58 |
| duflu | Things will be clearer if the linker is giving you errors and no binary | 03:59 |
| smspillaz | duflu: doesn't seem to be complaining :/ | 04:17 |
| duflu | smspillaz: That's extra weird. It means the linker has found all symbols resolved at build time. And yet some are missing at run time? | 04:18 |
| smspillaz | yeah | 04:18 |
| smspillaz | duflu: also I wrote a testcase without rpath and it works fine | 04:18 |
| duflu | smspillaz: Whatever is missing symbols needs to be linked with -zdefs | 04:18 |
| smspillaz | I'm going to try "installing" the testcase and installing the plugins somewhere unconventional | 04:18 |
| smspillaz | so that we'll have to use rpath | 04:18 |
| smspillaz | curious, that works the way you'd expect too | 04:25 |
| robert_ancell | racarr, around? | 04:33 |
| duflu | smspillaz: Remember make install with CMake actually strips rpaths :P | 04:37 |
| smspillaz | I know, I'm asking it not to in the testcase :) | 04:37 |
| smspillaz | though I still can't reproduce this problem :( | 04:38 |
| smspillaz | and there's nothing in the link flags that stands out | 04:38 |
| racarr | robert_ancell: Halfway | 05:02 |
| racarr | will be around and focused at meeting time :) | 05:02 |
| racarr | around but surrounded by noise atm | 05:02 |
| robert_ancell | argh, we have shell sessions and frontend sessions. Very confusing | 05:44 |
| robert_ancell | racarr, should SessionContainer contain shell:Sessions not frontend::Sessions? | 05:49 |
| robert_ancell | I need to focus a session by name for the system compositor (removing the hacky lightdm code) but it seems really hard to iterate over the current shell sessions | 05:49 |
| robert_ancell | racarr, and SessionContainer has virtual methods for insert and remove, but it's a concrete class - what is the point of the virtual methods? | 05:50 |
| racarr | robert_ancell: Yes it should contain shell::Sessions I think | 06:00 |
| racarr | it's a little difficult to do without dynamic casts somewhere :) there is one now...it could move and you could have shell::Sessions everywhere | 06:00 |
| racarr | I think the point of the virtual methods is for mocking | 06:00 |
| robert_ancell | duflu, alf_, meeting | 06:03 |
| smspillaz | duflu: ah frick, I think I've found the problem | 06:38 |
| duflu | smspillaz: OTP | 06:39 |
| smspillaz | np | 06:39 |
| smspillaz | its being linked to the wrong library, rpath madness it seems | 06:39 |
| smspillaz | fixable | 06:39 |
| smspillaz | \o/ | 06:39 |
| duflu | kdub: Done now?... [kdub] transition android build to raring: TODO | 06:42 |
| duflu | Oh, no kdub | 06:42 |
| kdub | in progress | 06:43 |
| duflu | smspillaz: Cool. A simple answer | 06:43 |
| smspillaz | duflu: though its scary. for some reason if you build with rpaths cmake will put $prefix/lib into your rpath as well as any INSTALL_RPATH hint you add | 06:44 |
| smspillaz | and considering the plugin names are quite generic, there's a real risk of accidentally pulling in a library we didn't intend to | 06:45 |
| smspillaz | anyways, -EWRONGCHAN :p | 06:45 |
| RAOF | Wheee! We should run the glmark2-mir benchmarks on my radeon system - it's happy to do 10FPS on the terrain bench, for example :) | 06:51 |
| duflu | RAOF: Yeah that's the only one I got less than 60 FPS. Twas 59 | 06:53 |
| RAOF | The trick is asking a 2-gen-old low-power card to render at 1920x1200 :) | 06:54 |
| RAOF | Woot! I win the "it-doesn't-work-if-you-try-and-dereference-an-fd-as-a-pointer" award! | 07:08 |
| mlankhorst | :X | 07:18 |
| duflu | tvoss: mir_connection_create_surface ? mir_create_surface? mir_connection_createsurface :) | 07:19 |
| tvoss | RAOF, \o/ | 07:19 |
| tvoss | duflu, put my vote in for mir_connection_create_surface | 07:19 |
| tvoss | duflu, it's verbose but clear | 07:19 |
| duflu | I thought as much | 07:19 |
| RAOF | In my defence, passing fds as "void *handle" is unnecessarily obscure. | 07:20 |
| duflu | I'm trying to think if there are any single verbs to describe a surface being created :) | 07:20 |
| tvoss | RAOF, it forces the API user to really know what's going on ... which might be considered a good thing | 07:20 |
| alf_ | RAOF: which branch from mesa-mir (github) is the latest? egl-platform-mir-use-dma-buf ? | 07:21 |
| tvoss | duflu, genesis ... not a verb, but shiny nevertheless :) | 07:21 |
| RAOF | alf_: Yes. The PPA is built from mir-ppa on github, though. | 07:21 |
| duflu | tvoss: Yeah you catch my drift | 07:22 |
| alf_ | RAOF: hmm, I think egl-platform-mir-use-dma-buf is missing a commit (the last from branch egl-platform-mir) | 07:22 |
| RAOF | alf_: Quite true; you'll find them there now. | 07:24 |
| alf_ | RAOF: excellent, thanks! | 07:24 |
| alan_g | tvoss: I was wondering if the guidelines you adopted from mir were online and came across something subtly different: http://unity.ubuntu.com/wp-content/uploads/2012/03/cppguide.html - is there a plan for convergence? | 08:31 |
| * alf_ notices that the input components in mir are very chatty... | 08:31 | |
| tvoss | alan_g, those are the old ones, good catch | 08:35 |
| tvoss | alan_g, will check how to update those guidelines | 08:35 |
| alan_g | tvoss: you're welcome. (I followed a link from https://wiki.ubuntu.com/Unity/CodingStyle which might also need maintenance) | 08:38 |
| alf_ | duflu: alan_g: tvoss: Any objection to changing mir_socket to be 777, so that other users can connect? | 08:44 |
| duflu | alf_: I was thinking that. It would be useful now, but creates security problems later | 08:44 |
| alf_ | duflu: what security problems? | 08:45 |
| tvoss | alf_, fine with me | 08:45 |
| duflu | alf_: Any remotely logged in user can start a client and it renders on your desktop | 08:45 |
| duflu | ... or any daemon (non-root) can spawn surfaces on your desktop | 08:45 |
| alf_ | duflu: hmm... | 08:46 |
| duflu | alf_: And later... any daemon could screen-scrape (if clients are given such power in future) | 08:46 |
| alan_g | alf_: Is this something that would need to differ between session and system compositing? | 08:48 |
| duflu | alf_: Looks like the Ubuntu/Linux approach is to limit access to group "video" which I suspect you become a member of on login (?) | 08:48 |
| alan_g | I.e. should it be configurable? | 08:48 |
| duflu | alan_g: Probably configurable eventually. But right now we just don't want any gaping security holes to forget about | 08:48 |
| alf_ | duflu: the "video" approach is sensible | 08:49 |
| duflu | alf_: Seems to be how /dev/dri/* works | 08:50 |
| alf_ | alan_g: we probably want only the user owning a session to be able to render to it, whereas the system compositor needs to accept connections from various users (from their session compositor) | 08:52 |
| alan_g | alf_: so "video" makes sense for system compositing, what we have now for session? | 08:52 |
| alf_ | alan_g: that sounds right | 08:53 |
| alf_ | duflu: do you get video permissions only when you log in locally? | 08:53 |
| duflu | alf_: Hmm, actually I'm not in group video. That might not work | 08:53 |
| * duflu looks at X | 08:54 | |
| alf_ | alan_g: duflu: perhaps we should just ask the security team or the X team, I am sure they have this figured out | 08:55 |
| alan_g | alf_: adding oneself to "video" was a hack you gave me to get mir working in the early days. It isn't a default. | 08:55 |
| alf_ | alan_g: right | 08:56 |
| duflu | alf_: X seems to chmod 777 and implements its own security... | 08:56 |
| duflu | srwxrwxrwx 1 root root 0 Apr 16 09:04 /tmp/.X11-unix/X0 | 08:56 |
| alf_ | duflu: right, with xhosts etc | 08:56 |
| duflu | Yep | 08:57 |
| duflu | That's annoying. I was sure some groups were assign dynamically and video was included | 08:57 |
| duflu | +ed | 08:57 |
| alf_ | duflu: alan_g: tvoss: I leave the mir_socket as it is for now, until we discuss a bit more and get some feedback from the security team | 09:01 |
| tvoss | alf_, do you take care of reaching out to the security team? | 09:01 |
| tvoss | RAOF, still around? | 09:02 |
| alf_ | tvoss: I am not sure who they are, so I was planning on letting Robert A. know and handling this | 09:03 |
| tvoss | alf_, yup, fine with me | 09:03 |
| AlanBell | is there some documentation on what Mir will be able to do from a user perspective? | 09:06 |
| AlanBell | I can see lots of stuff about the low level detail of how it works, but will it do stuff like full screen zoom, text tracking zoom, multiple desktops on a cube or anything like that? | 09:07 |
| AlanBell | all I can see in the documentation is that it will do drop shadows on windows | 09:07 |
| duflu | AlanBell: Mir is no yet complete enough to answer those questions, or to be interesting at all for "users" | 09:07 |
| AlanBell | sure, but are these things going to be what it is for? | 09:08 |
| duflu | AlanBell: Yes, that kind of thing. But it's a long way from having such special effects yet. In the mean time we have Compiz | 09:09 |
| AlanBell | how about colour management, is that in the plans? | 09:12 |
| RAOF | tvoss: Yes. | 09:12 |
| RAOF | AlanBell: I'd like to make colour management happen, yes. | 09:13 |
| RAOF | alf_: The system compositor never accepts any sessions from anything but the display manager (in this case, LightDM)R | 09:14 |
| RAOF | alf_: Once Robert's got the LightDM bits hooked up, the system compositor will no longer have a listening socket on the filesystem at all. | 09:14 |
| alf_ | RAOF: interesting | 09:15 |
| tvoss | AlanBell, anything you are especially interested in for ColorManagement? | 09:15 |
| duflu | alf_: To avoid duplication, look and comment here (I have added more): https://bugs.launchpad.net/mir/+bug/1169075 | 09:15 |
| ubot5 | Launchpad bug 1169075 in Mir "Mir server running as root does not accept connections from non-root clients" [Medium,New] | 09:15 |
| AlanBell | tvoss: well interested in whether Mir is the layer in which that is planned to be done | 09:15 |
| alf_ | duflu: ok | 09:16 |
| tvoss | AlanBell, cool | 09:16 |
| AlanBell | I know Mir is planned to be lighter than wayland, and wayland has text tracking zoom and just got colour management | 09:16 |
| tvoss | AlanBell, ack | 09:16 |
| AlanBell | I was just concerned that if these were not in scope for Mir they probably won't get done at any other level because they are in Wayland | 09:16 |
| RAOF | AlanBell: Mir needs to be involved in colour management, yes, because Mir is in control of the CRTCs which is where you do the monitor response curve calibration. | 09:17 |
| alan_g | AlanBell: mir currently has a design that allows rendering "effects" to be added by other code in the server process. Our priority will be the effects needed by unity - but that isn't a technical limitation. | 09:18 |
| AlanBell | yeah, and unity doesn't need desktop switching any more | 09:19 |
| RAOF | alf_: Yeah. Basically what you end up with is: the DM spawns the SC (or visa versa), handing it an open fd to communicate over. The DM then spawns the sessions, handing *them* one end of an open fd and the SC the other end. | 09:21 |
| alan_g | AlanBell: *I* need desktop switching - and I'm sure other developers here do too. ;) | 09:21 |
| RAOF | alf_: That simplifies security to "I need to trust that the DM only spawns sensible sessions" | 09:22 |
| AlanBell | alan_g: ah, that is encouraging ;) | 09:23 |
| alf_ | RAOF: it's unfortunate that both "system compositor" and "session compositor" have the same initials "SC" :) | 09:23 |
| RAOF | alf_: This is true :) | 09:23 |
| RAOF | I think we could potentially do a similar thing in the session compositor, too. | 09:24 |
| alan_g | alf_: "global compositor"? ;) | 09:25 |
| RAOF | I'm not sure if we need to have *any* sockets on the filesystem anywhere. Except for testing purposes. | 09:25 |
| alf_ | RAOF: how do clients connect to the session compositor? | 09:26 |
| RAOF | They get spawned by a client connected to the session compositor. | 09:28 |
| RAOF | Well, most will be spawned by the session compositor itself, of course. | 09:29 |
| RAOF | I'm not sure if this is practical, but it's something we *could* do :) | 09:30 |
| alf_ | RAOF: yes, I am not sure how well this would work. Imagine I have a terminal (in a mir session) and start another client from there. How would the terminal know that this is a mir client and that it expects the fd to be passed in a certain way? | 09:32 |
| RAOF | It'd leave a mir fd open for *all* the clients it spawns. It doesn't need to know that it's a mir client that its spawning. | 09:32 |
| RAOF | Nothing relies on the first free fd being 3, right? | 09:33 |
| RAOF | ☺ | 09:33 |
| alf_ | RAOF: ok, how would you start something from an ssh session? :) | 09:34 |
| RAOF | You wouldn't :) | 09:35 |
| RAOF | Actually, that's not strictly true. You'd write an upstart conf file and get the session upstart to start it :) | 09:36 |
| RAOF | Or have a client already spawned that provides an interface to spawn further clients, or whatever. | 09:38 |
| RAOF | Woot! We now have daily packages for xf86-video-{ati,intel,nouveau} with XMir support. | 10:00 |
| RAOF | HUZZAH | 10:00 |
| duflu | Excellent-ness | 10:06 |
| tvoss | RAOF, \o/ | 10:08 |
| alan_g | That's working packages? | 10:14 |
| RAOF | alan_g: Should be - I haven't tested nouveau, but mlankhorst assures me that works :) | 10:34 |
| mlankhorst | RAOF: I only tested with the kernel changes patched in, though | 10:34 |
| alan_g | RAOF: excellent. (Of course we *should* have automated tests to guarantee it all works.) | 10:35 |
| RAOF | We should indeed, but probably once the lightdm bits are in place. | 10:36 |
| hikiko__ | hi, is there a hangout right now? | 12:15 |
| hikiko__ | ah am :p ignore | 12:19 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| thiagoandrade | I finally managed to build Mir and run it without errors, but in the Mir demos are all appearing glitchy when I run then. For instance the mir_egltriangle is nowhere near a triangle, it's a bunch of little white squares. Is there something I'm missing? | 14:57 |
| alan_g | thiagoandrade: yes (although its hard to guess what without more context) | 15:12 |
| thiagoandrade | alan_g, I believe the problem is my video driver. I tried to install fglrx but it wouldn't work as my video card is a little old (Radeon HD 4200). I don know if I have a driver installed or if that matters, but "lsmod | grep drm" returns me the drm module. Should I install the driver available on the ATI website? | 15:16 |
| alan_g | thiagoandrade: that sounds plausible but is a bit outside my knowledge. | 15:18 |
| alan_g | alf_ ^ - any thoughts? | 15:18 |
| alf_ | thiagoandrade: It sounds like a tiling issue. Do you see the squares changing or is it just a static image? | 15:20 |
| thiagoandrade | alf_, static image. | 15:21 |
| alf_ | thiagoandrade: hmm, are you using the mesa from the mir-team staging PPA? | 15:21 |
| thiagoandrade | yes | 15:21 |
| alf_ | thiagoandrade: ok, can you please try build/bin/render_surfaces (on its own, without a mir server) | 15:22 |
| thiagoandrade | alf_, ok. | 15:23 |
| thiagoandrade | alf_, it works. | 15:23 |
| alf_ | thiagoandrade: ok, now please try running the mir_demo_client_unaccelerated with a mir server, you should see a rectangle flashing between two colors | 15:25 |
| thiagoandrade | alf_, no. Purple glitchy square. | 15:26 |
| alf_ | thiagoandrade: what bzr version of mir are you using, and what mesa version (dpkg -s libegl1-mesa) | 15:29 |
| thiagoandrade | alf_, libegl1-mesa version is 9.2~git20130402.b2eee086-0ubuntu0+mir6-jenkins69. bzr version of Mir I don how to see, but updated yesterday. | 15:33 |
| alf_ | thiagoandrade: please try the latest version of mir (bzr pull), there was a fix yesterday for a similar problem with clients | 15:38 |
| thiagoandrade | alf_, Updated. Now it's on version 597, gonna try again. By the way, just for curiosity. How one sees the current version of the branch with bzr? | 15:39 |
| alf_ | thiagoandrade: to get the mir bzr version -> "bzr revno" | 15:39 |
| thiagoandrade | alf_, Ok now I get the flashing screen with mir_demo_client_unaccelerated | 15:44 |
| thiagoandrade | Guess it's working. | 15:44 |
| thiagoandrade | alf_, Thanks. | 15:44 |
| alf_ | thiagoandrade: try the mir_egltriangle, too (which is accelerated), just to make sure | 15:45 |
| thiagoandrade | alf_, Working. :D | 15:46 |
| alf_ | thiagoandrade: great :) | 15:47 |
| thiagoandrade | alf_, Now I can play around with Mir. Thanks. | 15:47 |
| alf_ | thiagoandrade: np | 15:47 |
| === thiagoandrade is now known as thiagoandrade|lu | ||
| === thiagoandrade|lu is now known as thiago_da|lunch | ||
| kdub | alf_, updated server-render-window (if the review is still fresh in your mind) | 15:50 |
| alf_ | kdub: looking | 15:51 |
| alf_ | kdub: I guess I shouldn't take it as a sign that the update revision is revision 666 ;) | 15:52 |
| kdub | haha! i thought the same thing :P | 15:52 |
| === alan_g is now known as alan_g|afk | ||
| alf_ | kdub: hmm, return -1 is still there ? | 16:05 |
| kdub | shouldn't be... | 16:05 |
| kdub | oh, that's a different return -1 | 16:05 |
| kdub | i should change that too! | 16:05 |
| kdub | alf_, ok, removed. now the commit number is much nicer too! | 16:07 |
| alf_ | kdub: ok, approved | 16:07 |
| kdub | cool, thanks | 16:07 |
| === alan_g|afk is now known as alan_g | ||
| === olli_ is now known as olli | ||
| kgunn | kdub: hell yeah! fb native window! | 19:32 |
| kdub | kgunn, yay! now android graphics doesnt have to depend on android glue | 19:36 |
| kdub | working on rooting out that glue now... | 19:36 |
| * kdub -> eye dr | 21:10 | |
| robert_ancell | thomi, will https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 autoland? Or is both CI and autolanding disabled for MPs not proposed by someone in the whitelist | 21:26 |
| thomi | robert_ancell: will find out, one minute | 21:27 |
| robert_ancell | thomi, ta | 21:27 |
| thomi | robert_ancell: autolanding will work, as long as the MP approver is on the whitelist. CI won't trigger however | 21:31 |
| robert_ancell | thomi, ok good. Has anyone considered starting CI if someone on the whitelist gives the MP an 'approve' review? I can live with the autolanding testing, but it would be nicer if CI would start once I'd checked the merge was good | 21:32 |
| thomi | robert_ancell: in fact, it's running now: http://10.97.2.10:8080/job/lightdm-raring-amd64-autolanding/12/console | 21:32 |
| robert_ancell | thomi, also nice would be in Jenkins would comment on the MP that it was building it with the link - the delay can be confusing | 21:33 |
| robert_ancell | thomi, is there a bug tracker I can file against or do I just keep bugging you? :) | 21:33 |
| thomi | robert_ancell: I don't believe we have, I'll file a feature request on your behalf if you like | 21:33 |
| robert_ancell | please do | 21:34 |
| thomi | robert_ancell: I'm happy to be bugged about this stuff, but FYI the project responsible is https://launchpad.net/jenkins-launchpad-plugin | 21:35 |
| robert_ancell | thomi, ok, cool I can file bugs there. The second issue is probably bug 1134328 | 21:36 |
| ubot5 | bug 1134328 in jenkins-launchpad-plugin "not enough feedback from autolanding jobs" [Undecided,New] https://launchpad.net/bugs/1134328 | 21:36 |
| robert_ancell | thomi, and the first issue is bug 1157855 :) | 21:38 |
| ubot5 | bug 1157855 in jenkins-launchpad-plugin "allow triggering of CI jobs when somebody trusted Approved the MP" [Undecided,New] https://launchpad.net/bugs/1157855 | 21:38 |
| thomi | dammit, I'll stop typing then :) | 21:38 |
| thomi | robert_ancell: if you want attention on a particular bug for that project you're probably best emailing Martin :) | 21:39 |
| robert_ancell | thomi, he created those bugs so I'll assume he'll get emailed when I comment on them | 21:40 |
| thomi | good point | 21:40 |
| thomi | robert_ancell: I just noticed that on https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 there's a CI approve vote | 22:01 |
| thomi | robert_ancell: so... apparently it already does what we want!? | 22:01 |
| thomi | robert_ancell: either that, or someone fixed it *really* fast :P | 22:01 |
| robert_ancell | thomi, I think it did it when it did the autolang | 22:40 |
| robert_ancell | autoland | 22:40 |
| thomi | that's a bit odd | 22:40 |
| thomi | once it's landed there's not much point running CI | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!