RAOFGrr. Do mir_demo_client* work for anyone else on the current staging PPA?00:40
RAOFThey all fail for me in assert(mir_surface_is_valid()), and XMir also dies with a garbage MirBufferPackage00:42
bryceRAOF, I updated to the latest staging ppa on my intel box last Friday, but the screen was just static noise00:49
bschaeferRAOF, yeah, im getting the same thing :(00:51
bschaeferwas working just before I pulled some new changes to lp:mir00:52
bschaeferRAOF, looks like rev 590 caused the issue for me00:56
* kdub just merged lp:mir onto my working branch, looks like i see the same thing on android00:57
kdubi'll try to confirm the rev590...00:57
kdubbschaefer,  yep... something happened in 59001:01
bschaeferkdub, its a large branch soo hopefully it'll be easy to track down01:02
racarrRAOF: Err.  so I had garbage mir buffer package01:03
racarrbut then I built mesa with usa-dma-buf which you still didn't merge to the main github branch01:03
racarrand it worked fine01:03
racarroh 59001:04
RAOFI 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
racarrRAOF: New theory...something crazy due to a bug01:05
racarrtry with --enable-input=true01:05
racarrthe_input_focus_selector needs to01:05
racarrcheck the options and ahve a null implementaiton01:05
racarrlike the input manager does01:05
racarrtrunk right now with --enable-input=false (the default) is starting up a malformed input stack01:05
racarrand who knows what happens01:05
racarrI'll propose a branch to fix it soon. I actually need to run and do some errands though01:06
RAOFracarr: Correct guess!01:07
kdubok, trunk with --enable-input=true works for me too01:07
racarrsorry about that01:07
kdublet's set the topic until its changed01:07
racarrI don't remember how to get my +o back01:07
racarrbut! I really do want to run some errands because I need to be somewhere by 701:07
racarrill be back later though, and even later for team meeting :)01:08
kdubwell, until the proper fix for --enable-input=false is in01:09
kdublet's change the default01:10
kdubbandaid branch^^01:11
bschaeferkdub, I can approve that for you, if you don't mind01:13
kdubbschaefer, sure01:14
* bschaefer isn't sure what the procedure for MPs are in lp:mir01:14
kdubbschaefer, one reviewer +1, plus no blocking comments01:14
bschaeferkdub, sounds about normal :)01:15
kdubbug report: https://bugs.launchpad.net/mir/+bug/116978101:16
ubot5Launchpad bug 1169781 in Mir "mir after rev590 won't run without --enable-input=true" [Critical,Confirmed]01:16
kdubsomeone with ops set the /topic to mention to run with --enable-input=true in the meantime?01:22
duflukdub: I always assumed it was 2+ reviewers?01:39
dufluNo wonder my proposals linger :)01:40
racarrI think its understood as +2 for nontrivial proposals01:55
racarrbut that's just how I have been thinking01:55
dufluYeah, trivial or time-critical stuff would be only 101:58
duflutime-critical means when something is broken and it's holding us up01:58
RAOFracarr: Code looks fine; checking that it actually works, too :)02:32
robert_ancell"Internal compiler error: Error reporting routines re-entered."02:44
robert_ancellseriously GCC?02:44
dufluError during reporting of the first error? Nice02:45
smspillazrobert_ancell: std::make_shared ?02:58
robert_ancellsmspillaz, it looks like it. I'm trying to reduce the program to create a test case02:59
smspillazrobert_ancell: known bug02:59
ubot5Launchpad bug 1165732 in gcc "GCC 4.7.3 internal compiler error when using std::make_shared" [Medium,Confirmed]02:59
smspillazrobert_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 template03:00
robert_ancellsmspillaz, ah03:00
smspillazrobert_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
RAOFAnd, of course, the solution is to build with clang, which provides non-terrible error messages. :)03:01
smspillazspeaking of clang03:01
smspillazduflu: needed to ask you something03:01
smspillazduflu: remember when we made the templates extern for compiz plugins?03:01
smspillaz(eg PluginClassHandler, WrapableInterface etc)03:02
racarrRAOF: Thanks :)03:03
racarrrobert_ancell: It's a known bug I believe that is fixed upstream according to some mailing list post I read or something03:03
robert_ancellracarr, yeah, the bug trail shows its a regression that's been fixed03:03
RAOFIt's a regression from 4.6, and it's fixed in 4.8 apparently.03:03
duflusmspillaz: Yeah I remember03:04
smspillazfor 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 template03:04
duflu(sorry, am outside occasionally talking to painter)03:04
smspillazno problem :)03:04
smspillazduflu: any ideas ?03:04
smspillaznm -S says its defined as "W" in liba.so03:04
smspillazand U in libb.so03:05
duflusmspillaz: Yeah (W)eak symbol03:05
smspillazcool, so what do I do in order to get a definition in libb.so ?03:05
dufluI don't follow the problem yet03:05
dufluHang on03:05
smspillazI'll try and write a simple testcase03:06
smspillaz(this is just my understanding of the problem by looking at compiz plugins)03:06
smspillazohhhh hmm03:07
smspillazI wonder if the weak symbol is a template that never got defined03:07
smspillazjust declared as "yeah this exists"03:07
duflusmspillaz: 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
smspillazand then the actual definition is some other symbol03:07
duflu(W)eak means defined, but can be rebound at runtime03:07
duflusmspillaz: 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 exist03:09
smspillazduflu: well, in this case they're directly linked03:09
smspillazduflu: well, I don't know if its that. If for example, I dlopen both liba.so and libb.so then libb.so gets the definition03:10
smspillazbut its perplexing, because libb.so is definitely linked to liba.so, its just in a custom rpath (eg $prefix/lib/compiz)03:11
duflusmspillaz: Dependencies only go one way. If A links to (depends on) B, then dlopen(B) will indeed be missing everything that A provides03:11
smspillazduflu: ah, sorry, B is linked to A03:11
duflusmspillaz: Yeah you need dlopen flag RTLD_GLOBAL (default is RTLD_LOCAL for safety)03:12
dufluYou're usually meant to dlsym functions you need and not implicitly gain symbols from plugins loaded03:12
smspillazduflu: hmm, what do you mean by "implicitly gain symbols from plugins loadeD"03:13
duflusmspillaz: I recommend putting common template instantiations in a separate library, or duplicating them safely with -Bsymbolic03:14
smspillazduflu: I was going to suggest that03:14
duflusmspillaz: Default is RTLD_LOCAL so you gain NO symbols from the load, unless you grab them explicitly (dlsym())03:14
smspillazduflu: so you'd suggest a libcompiz_opengl_interface.so in the $prefix/lib ?03:15
dufluRTLD_GLOBAL however means you get all symbols from the loaded library, which might be used in a later dlopen03:15
smspillazduflu: 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 to03:16
smspillaz(though maybe that's what you're referring to)03:16
duflusmspillaz: 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 A03:16
smspillazduflu: I don't see why that would arise if B was linked explicitly to A03:17
duflusmspillaz: 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 copy03:17
dufluSo 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 copies03:18
smspillazoh 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 gone03:18
smspillazduflu: iirc we had some trouble with -Bsymbolic. I'll try the separate library approach03:19
duflusmspillaz: -Bsymbolic is _only_ a problem if your classes have static members which are unsafe to have multiple copies of03:20
dufluIt also causes code bloat, but maybe not so bad03:21
duflusmspillaz: 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 bloat03:21
smspillazduflu: well, we definitely use all the methods03:22
dufluThat's OK if it's your own template (not from the STL)03:22
smspillazyep, its our own template03:23
smspillazduflu: okay, I think I'll go with that then.03:27
duflusmspillaz: If it's all opengl-specific then you don't need a new library. Just instantiate it in the opengl plugin03:27
smspillazbeen trying to fix this long-standing issue where loading plugins effectively causes other plugins to be implicitly loaded03:27
smspillazduflu: well, see that's the thing. we do instantiate it in the opengl plugin03:27
smspillaz(or at least I think we do)03:27
dufluAnd remember to "extern" the template in public headers03:28
dufluOr else you'll have more copies03:28
smspillazduflu: yeah, its already extern'd03:28
duflusmspillaz: 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 A03:29
smspillazduflu: the problem is optional dependencies03:29
dufluOh, the optional ones03:29
smspillazeg, I need to be able to set up a test framework so that we load move, but move doesn't pull in opengl03:29
smspillazbut move implicitly does that because it checks if opengl is available03:30
smspillaz... by pulling in opengl03:30
smspillazwhich then causes opengl to be loaded03:30
smspillazagain implicitly03:30
smspillazits a bit nasty03:30
dufluI would like to say it should be a simple flag in a simple loading call: CompizLoadPlugin(foo, NO_OPTIONALS)03:30
dufluBut I remember it's not the simple03:30
smspillazduflu: well, the way it works at the moment is that it calls PluginClassHandler <GLWindow, CompWindow>::get ()03:31
smspillazwhich *should* go to the vtable and then return null if it isn't loaded03:31
dufluArg. I'm having terrible flashbacks03:31
smspillazexcept that I fixed a problem several years ago which had the side effect of short-circuiting that03:32
smspillazanyways, maybe the problem is that we never really explicitly instantiated that template anywhere in opengl03:32
dufluIn 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 objects03:33
smspillazduflu: that's basically how it works right now03:33
smspillaz(or at least, that's the entry point from core)03:33
dufluInteresting 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
dufluMade worse by overuse of namespaces and default parameters like allocators03:38
smspillazduflu: heh03:46
smspillazcase in point03:46
racarrsmspillaz: How did you guess my password03:47
smspillazoh crap03:47
dufluYes, and for some reason compilers need to emit that string _many_ times in a single object03:47
smspillazI've been found out03:47
smspillazracarr: ahaha, that'd be awesome "my password is a mangled template symbol"03:47
* duflu wonders what _SH_SH_SH_SH translates to03:48
smspillazthe compiler freaking out03:49
smspillazduflu: I feel like lots of these problems could be solved by having a binary format specifically designed to handle C++03:50
smspillazlike, for once, being able to have aliases for template parameters03:50
duflusmspillaz: Kinda. It still needs to be copy and pasteable sometimes03:50
smspillazlike 43d452 = int, string, char, bool03:51
* smspillaz notes that the majority of C++'s problems come from trying to be bolted on top of a C-like infrastructure03:51
smspillazthe solution is clearly to abolish C *waits for pitchforks to arrive at door*03:52
dufluMore generally a lot of problems would be solved by well-defined symbol/linkage rules in the language definition. Some languages do that03:52
smspillazyou mean Go, right ? :p03:53
dufluJava, mostly03:54
dufluAnd probably Go03:54
racarrI heard all the cool kids were using rust last week03:55
smspillazduflu: 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 libb03:56
duflusmspillaz: You may not "get the symbol" if it wasn't already in use at run-time before the dlopen03:57
duflusmspillaz: As always, link with -zdefs (CFLAG -Wl,-zdefs) to tell you what you've forgotten at build time03:58
dufluThings will be clearer if the linker is giving you errors and no binary03:59
smspillazduflu: doesn't seem to be complaining :/04:17
duflusmspillaz: 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
smspillazduflu: also I wrote a testcase without rpath and it works fine04:18
duflusmspillaz: Whatever is missing symbols needs to be linked with -zdefs04:18
smspillazI'm going to try "installing" the testcase and installing the plugins somewhere unconventional04:18
smspillazso that we'll have to use rpath04:18
smspillazcurious, that works the way you'd expect too04:25
robert_ancellracarr, around?04:33
duflusmspillaz: Remember make install with CMake actually strips rpaths :P04:37
smspillazI know, I'm asking it not to in the testcase :)04:37
smspillazthough I still can't reproduce this problem :(04:38
smspillazand there's nothing in the link flags that stands out04:38
racarrrobert_ancell: Halfway05:02
racarrwill be around and focused at meeting time :)05:02
racarraround but surrounded by noise atm05:02
robert_ancellargh, we have shell sessions and frontend sessions. Very confusing05:44
robert_ancellracarr, should SessionContainer contain shell:Sessions not frontend::Sessions?05:49
robert_ancellI 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 sessions05:49
robert_ancellracarr, 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
racarrrobert_ancell: Yes it should contain shell::Sessions I think06:00
racarrit's a little difficult to do without dynamic casts somewhere :) there is one now...it could move and you could have shell::Sessions everywhere06:00
racarrI think the point of the virtual methods is for mocking06:00
robert_ancellduflu, alf_, meeting06:03
smspillazduflu: ah frick, I think I've found the problem06:38
duflusmspillaz: OTP06:39
smspillazits being linked to the wrong library, rpath madness it seems06:39
duflukdub: Done now?... [kdub] transition android build to raring: TODO06:42
dufluOh, no kdub06:42
kdubin progress06:43
duflusmspillaz: Cool. A simple answer06:43
smspillazduflu: 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 add06:44
smspillazand considering the plugin names are quite generic, there's a real risk of accidentally pulling in a library we didn't intend to06:45
smspillazanyways, -EWRONGCHAN :p06:45
RAOFWheee! 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
dufluRAOF: Yeah that's the only one I got less than 60 FPS. Twas 5906:53
RAOFThe trick is asking a 2-gen-old low-power card to render at 1920x1200 :)06:54
RAOFWoot! I win the "it-doesn't-work-if-you-try-and-dereference-an-fd-as-a-pointer" award!07:08
duflutvoss: mir_connection_create_surface ? mir_create_surface? mir_connection_createsurface :)07:19
tvossRAOF, \o/07:19
tvossduflu, put my vote in for mir_connection_create_surface07:19
tvossduflu, it's verbose but clear07:19
dufluI thought as much07:19
RAOFIn my defence, passing fds as "void *handle" is unnecessarily obscure.07:20
dufluI'm trying to think if there are any single verbs to describe a surface being created :)07:20
tvossRAOF, it forces the API user to really know what's going on ... which might be considered a good thing07:20
alf_RAOF: which branch from mesa-mir (github) is the latest? egl-platform-mir-use-dma-buf ?07:21
tvossduflu, genesis ... not a verb, but shiny nevertheless :)07:21
RAOFalf_: Yes. The PPA is built from mir-ppa on github, though.07:21
duflutvoss: Yeah you catch my drift07: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
RAOFalf_: Quite true; you'll find them there now.07:24
alf_RAOF: excellent, thanks!07:24
alan_gtvoss: 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
tvossalan_g, those are the old ones, good catch08:35
tvossalan_g, will check how to update those guidelines08:35
alan_gtvoss: 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
duflualf_: I was thinking that. It would be useful now, but creates security problems later08:44
alf_duflu: what security problems?08:45
tvossalf_, fine with me08:45
duflualf_: Any remotely logged in user can start a client and it renders on your desktop08:45
duflu... or any daemon (non-root) can spawn surfaces on your desktop08:45
alf_duflu: hmm...08:46
duflualf_: And later... any daemon could screen-scrape (if clients are given such power in future)08:46
alan_galf_: Is this something that would need to differ between session and system compositing?08:48
duflualf_: 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_gI.e. should it be configurable?08:48
duflualan_g: Probably configurable eventually. But right now we just don't want any gaping security holes to forget about08:48
alf_duflu: the "video" approach is sensible08:49
duflualf_: Seems to be how /dev/dri/* works08: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_galf_: so "video" makes sense for system compositing, what we have now for session?08:52
alf_alan_g: that sounds right08:53
alf_duflu: do you get video permissions only when you log in locally?08:53
duflualf_: Hmm, actually I'm not in group video. That might not work08:53
* duflu looks at X08:54
alf_alan_g: duflu: perhaps we should just ask the security team or the X team, I am sure they have this figured out08:55
alan_galf_: 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: right08:56
duflualf_: X seems to chmod 777 and implements its own security...08:56
duflusrwxrwxrwx 1 root root 0 Apr 16 09:04 /tmp/.X11-unix/X008:56
alf_duflu: right, with xhosts etc08:56
dufluThat's annoying. I was sure some groups were assign dynamically and video was included08: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 team09:01
tvossalf_, do you take care of reaching out to the security team?09:01
tvossRAOF, still around?09:02
alf_tvoss: I am not sure who they are, so I was planning on letting Robert A. know and handling this09:03
tvossalf_, yup, fine with me09:03
AlanBellis there some documentation on what Mir will be able to do from a user perspective?09:06
AlanBellI 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
AlanBellall I can see in the documentation is that it will do drop shadows on windows09:07
dufluAlanBell: Mir is no yet complete enough to answer those questions, or to be interesting at all for "users"09:07
AlanBellsure, but are these things going to be what it is for?09:08
dufluAlanBell: Yes, that kind of thing. But it's a long way from having such special effects yet. In the mean time we have Compiz09:09
AlanBellhow about colour management, is that in the plans?09:12
RAOFtvoss: Yes.09:12
RAOFAlanBell: I'd like to make colour management happen, yes.09:13
RAOFalf_: The system compositor never accepts any sessions from anything but the display manager (in this case, LightDM)R09:14
RAOFalf_: 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: interesting09:15
tvossAlanBell, anything you are especially interested in for ColorManagement?09:15
duflualf_: To avoid duplication, look and comment here (I have added more): https://bugs.launchpad.net/mir/+bug/116907509:15
ubot5Launchpad bug 1169075 in Mir "Mir server running as root does not accept connections from non-root clients" [Medium,New]09:15
AlanBelltvoss: well interested in whether Mir is the layer in which that is planned to be done09:15
alf_duflu: ok09:16
tvossAlanBell, cool09:16
AlanBellI know Mir is planned to be lighter than wayland, and wayland has text tracking zoom and just got colour management09:16
tvossAlanBell, ack09:16
AlanBellI 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 Wayland09:16
RAOFAlanBell: 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_gAlanBell: 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
AlanBellyeah, and unity doesn't need desktop switching any more09:19
RAOFalf_: 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_gAlanBell: *I* need desktop switching - and I'm sure other developers here do too. ;)09:21
RAOFalf_: That simplifies security to "I need to trust that the DM only spawns sensible sessions"09:22
AlanBellalan_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
RAOFalf_: This is true :)09:23
RAOFI think we could potentially do a similar thing in the session compositor, too.09:24
alan_galf_: "global compositor"? ;)09:25
RAOFI'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
RAOFThey get spawned by a client connected to the session compositor.09:28
RAOFWell, most will be spawned by the session compositor itself, of course.09:29
RAOFI'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
RAOFIt'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
RAOFNothing relies on the first free fd being 3, right?09:33
alf_RAOF: ok, how would you start something from an ssh session? :)09:34
RAOFYou wouldn't :)09:35
RAOFActually, that's not strictly true. You'd write an upstart conf file and get the session upstart to start it :)09:36
RAOFOr have a client already spawned that provides an interface to spawn further clients, or whatever.09:38
RAOFWoot! We now have daily packages for xf86-video-{ati,intel,nouveau} with XMir support.10:00
tvossRAOF, \o/10:08
alan_gThat's working packages?10:14
RAOFalan_g: Should be - I haven't tested nouveau, but mlankhorst assures me that works :)10:34
mlankhorstRAOF: I only tested with the kernel changes patched in, though10:34
alan_gRAOF: excellent. (Of course we *should* have automated tests to guarantee it all works.)10:35
RAOFWe 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 ignore12: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
thiagoandradeI 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_gthiagoandrade: yes (although its hard to guess what without more context)15:12
thiagoandradealan_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_gthiagoandrade: that sounds plausible but is a bit outside my knowledge.15:18
alan_galf_ ^ - 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
thiagoandradealf_, static image.15:21
alf_thiagoandrade: hmm, are you using the mesa from the mir-team staging PPA?15:21
alf_thiagoandrade: ok, can you please try build/bin/render_surfaces (on its own, without a mir server)15:22
thiagoandradealf_, ok.15:23
thiagoandradealf_, 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 colors15:25
thiagoandradealf_, 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
thiagoandradealf_, 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 clients15:38
thiagoandradealf_, 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
thiagoandradealf_, Ok now I get the flashing screen with mir_demo_client_unaccelerated15:44
thiagoandradeGuess it's working.15:44
thiagoandradealf_, Thanks.15:44
alf_thiagoandrade: try the mir_egltriangle, too (which is accelerated), just to make sure15:45
thiagoandradealf_, Working. :D15:46
alf_thiagoandrade: great :)15:47
thiagoandradealf_,  Now I can play around with Mir. Thanks.15:47
alf_thiagoandrade: np15:47
=== thiagoandrade is now known as thiagoandrade|lu
=== thiagoandrade|lu is now known as thiago_da|lunch
kdubalf_, updated server-render-window (if the review is still fresh in your mind)15:50
alf_kdub: looking15:51
alf_kdub: I guess I shouldn't take it as a sign that the update revision is revision 666 ;)15:52
kdubhaha! i thought the same thing :P15:52
=== alan_g is now known as alan_g|afk
alf_kdub: hmm, return -1 is still there ?16:05
kdubshouldn't be...16:05
kduboh, that's a different return -116:05
kdubi should change that too!16:05
kdubalf_, ok, removed. now the commit number is much nicer too!16:07
alf_kdub: ok, approved16:07
kdubcool, thanks16:07
=== alan_g|afk is now known as alan_g
=== olli_ is now known as olli
kgunnkdub: hell yeah! fb native window!19:32
kdubkgunn, yay! now android graphics doesnt have to depend on android glue19:36
kdubworking on rooting out that glue now...19:36
* kdub -> eye dr21:10
robert_ancellthomi, 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 whitelist21:26
thomirobert_ancell: will find out, one minute21:27
robert_ancellthomi, ta21:27
thomirobert_ancell: autolanding will work, as long as the MP approver is on the whitelist. CI won't trigger however21:31
robert_ancellthomi, 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 good21:32
thomirobert_ancell: in fact, it's running now:
robert_ancellthomi, also nice would be in Jenkins would comment on the MP that it was building it with the link - the delay can be confusing21:33
robert_ancellthomi, is there a bug tracker I can file against or do I just keep bugging you? :)21:33
thomirobert_ancell: I don't believe we have, I'll file a feature request on your behalf if you like21:33
robert_ancellplease do21:34
thomirobert_ancell: I'm happy to be bugged about this stuff, but FYI the project responsible is https://launchpad.net/jenkins-launchpad-plugin21:35
robert_ancellthomi, ok, cool I can file bugs there. The second issue is probably bug 113432821:36
ubot5bug 1134328 in jenkins-launchpad-plugin "not enough feedback from autolanding jobs" [Undecided,New] https://launchpad.net/bugs/113432821:36
robert_ancellthomi, and the first issue is bug 1157855 :)21:38
ubot5bug 1157855 in jenkins-launchpad-plugin "allow triggering of CI jobs when somebody trusted Approved the MP" [Undecided,New] https://launchpad.net/bugs/115785521:38
thomidammit, I'll stop typing then :)21:38
thomirobert_ancell: if you want attention on a particular bug for that project you're probably best emailing Martin :)21:39
robert_ancellthomi, he created those bugs so I'll assume he'll get emailed when I comment on them21:40
thomigood point21:40
thomirobert_ancell: I just noticed that on https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 there's a CI approve vote22:01
thomirobert_ancell: so... apparently it already does what we want!?22:01
thomirobert_ancell: either that, or someone fixed it *really* fast :P22:01
robert_ancellthomi, I think it did it when it did the autolang22:40
thomithat's a bit odd22:40
thomionce it's landed there's not much point running CI22:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!