| RAOF | robert_ancell: Good morning. Or afternoon, depending. | 00:55 |
|---|---|---|
| robert_ancell | RAOF, hello | 00:55 |
| RAOF | Does lightdm have a tool to parse/modify lightdm.conf? | 00:56 |
| robert_ancell | RAOF, /usr/lib/lightdm/lightdm-set-defaults | 00:57 |
| RAOF | Sweet, thanks. | 01:00 |
| RAOF | Hm. Presumably that could be trivially extended to support changing the session type, right? | 01:01 |
| robert_ancell | RAOF, yes | 01:01 |
| RAOF | Excellent. | 01:04 |
| RAOF | Hurray for awesome upstreams. | 01:05 |
| thomi | RAOF: hey - it sounds like maybe no decision was reached last night regarding the client API fd issue? | 01:59 |
| thomi | at least, no message to the ML or merges to change anything. | 01:59 |
| RAOF | thomi: Oh, I'll prepare a merge nom | 02:04 |
| thomi | RAOF: cool - I wasn't sure what the final consensus was | 02:05 |
| thomi | RAOF: all I know is that IMO we're currently violating the "make it hard to use incorrectly" tenet of API design. | 02:05 |
| RAOF | Indeed. | 02:05 |
| * thomi likes being the bumbling idiot to find all the problems your *real* users will find in the future | 02:05 | |
| thomi | robert_ancell: so, are you back at work, or just lurking? | 02:08 |
| thomi | just lurking I guess :) | 02:13 |
| thomi | RAOF: in the mean time, do you know off the top of your head what I need to do to close that FD? | 02:16 |
| RAOF | thomi: close(platform_package.fd[0]) should do it. | 02:16 |
| thomi | RAOF: I'd need to call mir_connection_get_platform(my_connection, &my_platform_package) first, to populate those FDs, right? | 02:18 |
| RAOF | Right | 02:18 |
| robert_ancell | thomi, back to work | 02:18 |
| robert_ancell | (I am) | 02:18 |
| thomi | robert_ancell: cool! | 02:18 |
| thomi | RAOF: what's the name members used for in MirSurfaceParameters? | 04:20 |
| thomi | does it have to be the same as the name passed to mir_connect? | 04:20 |
| RAOF | ... | 04:20 |
| thomi | and if so, why can't it just be copied from the connection? | 04:20 |
| RAOF | I was going to say the application's ID, but that's clearly not right :) | 04:20 |
| thomi | the examples just use the same string as the application name | 04:21 |
| thomi | (i.e.- __PRETTY_FUNCTION__) | 04:21 |
| RAOF | So, there's good reason to name surfaces; for example, the title bar. | 04:21 |
| RAOF | I don't know of anything that's using that information right now, though. | 04:22 |
| thomi | ok | 04:23 |
| thomi | RAOF: I think something useful I could be doing is adding to the doxygen documentation of these types, but I wonder if anyone would object? | 04:23 |
| RAOF | Why? | 04:23 |
| thomi | dunno - I assumed they were undocumented for a reason | 04:24 |
| RAOF | The reason is almost certainly “no one bothered documenting it” | 04:24 |
| thomi | ok, I might start documenting things as I go | 04:26 |
| thomi | hmmm, I seem to have broken something, such that now mir_connect_sync hangs forever | 04:43 |
| thomi | even after restarting mir_demo_server O.0 | 04:43 |
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| hikiko | alf_, are you busy? | 07:30 |
| alf_ | hikiko: hi, what's up? | 07:31 |
| hikiko | I can't find the EGLNativeWindowType anywhere and I wonder what is it... I guess something like the EGLNativeDisplay, but I wonder why we use it | 07:34 |
| hikiko | (client/gbm/gbm_platform.h/cpp) | 07:35 |
| alf_ | hikiko: EGLNativeWindowType is an EGL type. It is an opaque handle for the native window type. | 07:37 |
| alf_ | hikiko: we give it to the client so they can use EGL functions to set up the rendering context | 07:39 |
| hikiko | which is the context we created in the server? | 07:40 |
| === alan_g is now known as alan_g|afk | ||
| alf_ | hikiko: no, a new rendering context they can use to draw on a MirSurface | 07:42 |
| hikiko | so this is a context created in the client | 07:43 |
| hikiko | by the client* | 07:43 |
| hikiko | and the NativeWindow is the pc/android window that the client "sees" in his screen? | 07:44 |
| hikiko | or something else? | 07:44 |
| hikiko | I am trying to understand if I need to create another context using sdl or I can use the egl functions as they are, but I am not sure I understood 100% what's going on in the client platform :S | 07:46 |
| alf_ | hikiko: yes, window == visible surface (whatever that may mean for each windowing system) | 07:46 |
| hikiko | ok, so I forget about all this and I create an sdl window again in the platform part... | 07:47 |
| alf_ | hikiko: no, when using mirclient, the native window is a MirSurface | 07:47 |
| alf_ | hikiko: or to be more exact some representation of MirSurfaces that the EGL system can use | 07:49 |
| alf_ | hikiko: why can't you just compile with the gbm backend for now, until the server part is finished, and then move to the client part? | 07:50 |
| hikiko | because | 07:50 |
| hikiko | you can't use the gbm as it is | 07:50 |
| hikiko | one sec I ll show you | 07:51 |
| hikiko | irPlatformType mclg::GBMClientPlatform::platform_type() const | 07:51 |
| hikiko | { | 07:51 |
| hikiko | return mir_platform_type_gbm; | 07:51 |
| hikiko | } | 07:51 |
| hikiko | each client platform | 07:51 |
| hikiko | has this function | 07:51 |
| hikiko | android returns android, gbm returns gbm, I have to return sdl | 07:51 |
| hikiko | mmm | 07:52 |
| hikiko | if i use gbm as it is | 07:52 |
| alf_ | hikiko: It doesn't matter for now, the first step is to get the server-side examples working. Sure, the client side won't work, but we can fix this later. | 07:52 |
| hikiko | yes that's what I am trying to do :s ok let me try something.. bbl (+thanks!) | 07:53 |
| hikiko | btw alf_ is there any way to exclude gmock... of the build? | 07:59 |
| hikiko | I get tones of errors there | 07:59 |
| tvoss | hikiko, what kinds of erros? | 08:01 |
| hikiko | tvoss, about wrong declarations, syntax errors in templates and I end up with: | 08:02 |
| hikiko | fatal error: too many errors emitted, stopping now [-ferror-limit=] | 08:02 |
| tvoss | hikiko, then it's highly likely that you have an error somewhere in your header files. GMock compiles just fine in general | 08:02 |
| * tvoss notes that almost always one's own code is wrong :) | 08:03 | |
| hikiko | tvoss, I was getting errors even when I was compiling the trunk | 08:03 |
| hikiko | just now they become fatal | 08:03 |
| hikiko | so, it's not only my header files | 08:03 |
| tvoss | hikiko, compilation works fine in CI and autolanding | 08:03 |
| hikiko | ok, then I ll change my compile params... | 08:03 |
| hikiko | :D | 08:04 |
| tvoss | hikiko, why do you have custom compile params? | 08:04 |
| hikiko | well, I use clang because each time I have an error like: forgot to include a header file, I trigger a gcc internal compiler error | 08:05 |
| hikiko | it was faster to change the env var and use clang | 08:05 |
| hikiko | than compile the next gcc versions | 08:05 |
| tvoss | hikiko, which gcc version are you using? | 08:05 |
| === alan_g|afk is now known as alan_g | ||
| tvoss | hikiko, saucy has gcc 4.8 | 08:05 |
| hikiko | gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) | 08:05 |
| hikiko | I am still using raring tvoss | 08:06 |
| hikiko | do you think I have to upgrade? | 08:06 |
| tvoss | hikiko, not sure, but gcc 4.7.3 is quite stable for me | 08:06 |
| hikiko | well in my case it was crashing all the time with internal compiler error and no clue about the problem it triggered it | 08:07 |
| hikiko | so I gave up and replaced it | 08:07 |
| alan_g | tvoss: ping | 08:09 |
| tvoss | hikiko, at any rate, you should not need to compile a toolchain on your own: see https://launchpad.net/~ubuntu-toolchain-r/+archive/test | 08:09 |
| tvoss | alan_g, pong | 08:09 |
| alan_g | tvoss: did you see RAOF's email "Mir in Ubuntu"? IMO it raises some architectural issues... | 08:10 |
| tvoss | alan_g, yup, have seen it ... what are those issues? | 08:11 |
| alan_g | tvoss: we should have a plan for stabilizing ABI and comms protocol | 08:11 |
| tvoss | alan_g, yup, agreed | 08:11 |
| alan_g | Because it is starting to impact other components | 08:11 |
| alan_g | tvoss: is that something you should be driving? Or who? | 08:12 |
| tvoss | alan_g, I would think that the ABI stability is a requirements towards Mir and the team should just pick it up. But I'm happy to trigger the discussion | 08:12 |
| RAOF | I don't think comms protocol is particularly important to stabilise at this point - although backwards compatibility in comms protocol might be soon. | 08:14 |
| RAOF | But needing to rebuild unity-system-compositor for each Mir commit clearly won't scale to the distro. | 08:14 |
| tvoss | RAOF, fully agreed | 08:15 |
| alan_g | RAOF: ack (although I think we should prepare the way by adding version info to the protocol - even if we ignore it) | 08:15 |
| RAOF | alan_g: +1 | 08:16 |
| RAOF | We should at least be able to return a sensible "whoops, this won't work" error. | 08:16 |
| alan_g | RAOF: We can return an error string containing "whoops, this won't work" - does that count? ;) | 08:20 |
| RAOF | alan_g: As long as it can be translated ☺ | 08:20 |
| === pete-woods1 is now known as pete-woods | ||
| hikiko | alf_, what happened to the drm authenticator? | 09:35 |
| alf_ | hikiko: it was removed, but it seems that we will need to reinstate it after all | 09:36 |
| hikiko | :S | 09:36 |
| hikiko | well without it my branch doesn't compile anymore | 09:36 |
| hikiko | I use the authenticator to register my drm device fd | 09:37 |
| alf_ | hikiko: Why do you need to register a drm device fd? | 09:48 |
| hikiko | actually I have to tell the xserver | 09:49 |
| hikiko | which is my drm fd | 09:49 |
| alan_g | alf_: I'm not sure I've used it since rebuilding my system - is s-jenkins working for you? | 09:49 |
| tvoss | alan_g, it's down | 09:49 |
| alan_g | tvoss: ta | 09:50 |
| alf_ | hikiko: Why is this needed for the SDLDisplay? | 09:51 |
| hikiko | if you want to create a gbm buffer | 09:51 |
| hikiko | you need the drm fd | 09:51 |
| hikiko | there's no other way | 09:51 |
| hikiko | but if you open a drm fd | 09:52 |
| hikiko | you need to authenticate | 09:52 |
| hikiko | tell the xserver that you will use this device | 09:52 |
| hikiko | otherwise you wont have permissions to do anything | 09:52 |
| alf_ | hikiko: right, but my question still stands: why do you need to create a gbm buffer for the SDLDisplay (I mean that class in particular, not the sdl backend in general). | 09:53 |
| hikiko | because you use the gbm buffers in the ipc mechanism | 09:54 |
| hikiko | and you told me that there's no point to create my own type of buffers | 09:54 |
| hikiko | last month :s | 09:54 |
| hikiko | +the gbm buffer allocator is part of the gbm platform which is used in the display | 09:55 |
| hikiko | sorry | 09:55 |
| hikiko | you asked for the display ^^ | 09:55 |
| alf_ | hikiko: That's true, you don't need gbm buffers in the SDLDisplay class, you need them in the buffer allocator. My proposal for step 1 is to get SDLDisplay + render_to_fb to work, which doesn't involve the buffer allocator or any IPC/client code. I think that's the easiest way (step by step) to move forward, otherwise there are just too many things to take care of at once. | 09:58 |
| alf_ | hikiko: then step 2 is getting the buffer allocator + render_surfaces to work, step 3 is IPC/client side rendering. | 09:59 |
| alf_ | hikiko: that is, for step 1 you just need an SDLPlatform that returns a proper SDLDisplay and stub implementations for everything else | 10:05 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === alan_g is now known as alan_g|lunch | ||
| racarr | Good morning! | 12:55 |
| === mmrazik is now known as mmrazik|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === mzanetti is now known as mzanetti|lunch | ||
| === mmrazik|afk is now known as mmrazik | ||
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| kgunn | racarr mornin' | 13:26 |
| kgunn | awfully early | 13:26 |
| alan_g | kgunn: racarr afternoon (not very early) | 13:27 |
| racarr | Morning all :) | 13:27 |
| kgunn | afternoon alan_g | 13:27 |
| === mzanetti|lunch is now known as mzanetti | ||
| racarr | alan_g: Can I explain "friend class SessionManager" from rebuild input targets | 13:33 |
| racarr | Am having trouble coming up with a better solution | 13:33 |
| alan_g | racarr: I guess you have the right. ;) (Although I've not tried for a deep understanding yet.) | 13:35 |
| racarr | I just meant I am asking for help :) | 13:36 |
| racarr | basically the problem is, now that ms::Surface is the input target | 13:36 |
| racarr | how can the shell with an msh::Surface give it keyboard focus (through the InputTargeter) | 13:36 |
| racarr | so I added msh::Surface::internal_surface, protected, and let the SessionManager use it -.- | 13:37 |
| racarr | it could also be InputTargeter instead of session manager. | 13:38 |
| racarr | or the even the InputRegistrar, could be the only one to use internal_surface, and it exposes like handle_for_surface(std::shared_ptr<msh::Surface>...) which the targeter uses | 13:38 |
| racarr | but I don't know. none of these (including friending the SessionManager) | 13:38 |
| racarr | are particularly compelling | 13:39 |
| alan_g | racarr: I've a feeling that the relationship between ms::Surface and msh::Surface is wrong. (And that things being modelled as attributes should be associations) Maybe this is part of the same issue. | 13:41 |
| racarr | alan_g: Hmm I think it is part of the same stickiness...what do you mean by attributes vs assosciations though? | 13:42 |
| alan_g | racarr: Let me try an example... | 13:44 |
| alan_g | A board game piece could have a "black" or "white" color attribute | 13:45 |
| alan_g | Or it could associated (e.g. in a set of) with "black pieces" or a with "white pieces" | 13:46 |
| racarr | vs some sort of external assosciation? | 13:46 |
| racarr | mm | 13:46 |
| racarr | I see | 13:46 |
| racarr | So you mean ::type/::state | 13:47 |
| racarr | give msh::Surface dual roles? | 13:47 |
| racarr | because without that it's just a resource managing class | 13:47 |
| racarr | (input did too, but now input is moved down) | 13:47 |
| alan_g | racarr: that's what I mean. Not sure my "unease" actually points to a solution. | 13:49 |
| racarr | alan_g: Hmm. | 13:53 |
| racarr | alan_g: Maybe the "solution" is to remove the friend/protected | 13:53 |
| racarr | resource managing classes typically expose something like that | 13:53 |
| racarr | and then aim at moving the state somewhere else | 13:53 |
| alan_g | racarr: certainly adding a friend to access a *protected* member seems odd | 13:55 |
| alan_g | racarr: and does internal_surface() need to be virtual? | 13:56 |
| racarr | No definitely not | 13:56 |
| racarr | it should probably return | 13:57 |
| racarr | weak_ptr? | 13:57 |
| racarr | as well | 13:57 |
| racarr | or throw an exception | 13:58 |
| alan_g | racarr: Possibly - or check the lock succeeds | 13:58 |
| racarr | alan_g: My current leading theory is remove the protected and friend class, remove the virtual, add an exception + tests for internal_surface | 13:59 |
| === francisco is now known as Guest51059 | ||
| alan_g | racarr: actually, looking at where internal_surface() is used - could it be replaced by update_input_focus(InputTargetListener&) ? | 14:01 |
| racarr | It could. | 14:02 |
| racarr | hmm | 14:02 |
| racarr | well | 14:03 |
| racarr | except then InputTargetListener wants shared_ptr, which is maybe another bug? | 14:03 |
| racarr | I'm not sure that isn't more coupled though...im trying to think about how the tests would look | 14:03 |
| alan_g | racarr: is it more coupled? Then session manager doesn't need to know how the input target is moved (it doesn't need to get a ms::Surface from one place and pass it to another. | 14:06 |
| racarr | but the same way msh::Surface doesn't need to know about an InputTargetListener | 14:07 |
| racarr | / how it receives focus | 14:07 |
| racarr | right now it doesnt even need to know if it has focus but eventually it will | 14:07 |
| racarr | I can see the appeal of update_input_focus | 14:10 |
| alan_g | "tell don't ask" ;) | 14:11 |
| racarr | it makes me uneasy though because I dont | 14:11 |
| racarr | think of focus as an attribute | 14:11 |
| racarr | of the surface. | 14:11 |
| racarr | though I guess it' clear with the InputTargetListener... | 14:12 |
| alan_g | "attribute" or "association"? | 14:12 |
| racarr | its | 14:12 |
| racarr | an assosciation | 14:12 |
| racarr | focus is assosciated with the surface (in the InputDispatcher as it stands) | 14:13 |
| racarr | but the surface isn't told, hey you got focus, hey you lost focus, etc. | 14:13 |
| alan_g | but that "surface" is the ms::Surface, not the msh::Surface | 14:13 |
| racarr | mm | 14:14 |
| racarr | Ugh | 14:14 |
| racarr | the reference issues | 14:14 |
| racarr | are difficult to solve :p | 14:14 |
| racarr | if you want to do it this way then InputTargetListener has to take | 14:14 |
| alan_g | a weak_ptr - or a proxy | 14:15 |
| alan_g | yep | 14:15 |
| racarr | ms::Surface&, so then the window handle repository has to take ms::Surface& | 14:15 |
| racarr | and | 14:15 |
| racarr | and so the surface stack :p | 14:15 |
| racarr | or a weak_ptr perhaps...? | 14:15 |
| racarr | thinkthink* | 14:15 |
| racarr | it's not that bad either way | 14:16 |
| alan_g | racarr: what isn't clear to me is what should happen to input if the focussed surface is zapped. (But I'll leave that as an exercise..." | 14:19 |
| alan_g | s/"/) | 14:19 |
| racarr | alan_g: Another possible way to solve this is with operator== overload | 14:19 |
| racarr | but it's kind of hairy | 14:20 |
| * alan_g headdesk | 14:20 | |
| racarr | hmm, if the focused surface is zapped, then the InputDispatcher | 14:20 |
| racarr | will fail to promote the focused window handle | 14:20 |
| alan_g | http://arstechnica.com/information-technology/2013/05/why-arent-user-defined-operators-more-common/ | 14:20 |
| racarr | and clear its focus | 14:20 |
| racarr | I know :p this seems like a pretty clear overload though | 14:21 |
| alan_g | racarr: that enough help for now? | 14:22 |
| racarr | Yes thanks. :) | 14:22 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| racarr | coffee shop be back for meeting! | 14:49 |
| kdub | hello again folks, status, working on a swapping algorithm switcher | 15:01 |
| racarr | status: Updating rebuild-input-targeting. Then going to work on some lttng tracing for inpu | 15:10 |
| racarr | t | 15:10 |
| alan_g | racarr: you've a couple of other MPs in need of attention | 15:15 |
| racarr | alan_g: I will reject disable-sequences until later | 15:17 |
| racarr | alan_g: I can update depthify-stack but there is no point to land it without rebuild-input-targeting as input wont work in stacked scenarios | 15:17 |
| racarr | so have been waiting | 15:18 |
| alan_g | racarr: ok | 15:29 |
| racarr | oh wow... | 15:32 |
| racarr | alan_g: In that whole discusion before...I was wondering, how does msh::Surface then go on and pass itself to the InputTargeter from take_input_focus | 15:33 |
| racarr | now looking at the code...it needs to pass ms::Surface and it's all very obvious :p | 15:33 |
| racarr | I think I got crosswired because I am used to thinking that InputTarget=shell::Surface | 15:33 |
| alan_g | racarr: how very confusing | 15:34 |
| racarr | the msh::Surface/mf::Surface<->ms::Surface is so frustrating | 15:35 |
| racarr | maybe I will try and find a "once and for all" solution this week...I think its worth some thought | 15:35 |
| alan_g | racarr: good luck! (I keep being distracted by more urgent work.) | 15:38 |
| racarr | :) | 15:38 |
| alf_ | status: BufferSwapperSpin and client::RpcReport MPs, with the next step being an lttng RpcReport implementation (and perhaps related client side improvements) | 15:39 |
| racarr | How come bypass comp? | 15:39 |
| alan_g | racarr: it is a maze of twisty little objects - I know what I want to happen, but untangling the bits I want to change is frustratingly slow. | 15:40 |
| racarr | mm :) | 15:40 |
| kdub | alan_g, anything I could help with? | 15:41 |
| alan_g | kdub: not right now, but once I get this first spike running I'll be grabbing you. (Hopefully tomorrow) | 15:42 |
| racarr | alan_g: Pushed updates to rebuild-input-targeting | 15:46 |
| racarr | let me know if I can help fit things together on review, etc...feel bad about dumping such a large branch but couldn't find any sensible way to split it up | 15:46 |
| alan_g | racarr: ack | 15:47 |
| racarr | I Guess I will write some doxygen too | 15:47 |
| racarr | alf_: I am looking at adding LTTNG for some interesting input statistics (just a few to start, such as received event from kernel, dispatched event, etc...) | 16:01 |
| racarr | alf_: Just want to make sure I have the idea right... | 16:01 |
| racarr | make a new report interface. Then provide lttng/logger implementations? | 16:02 |
| racarr | or are there other ways to use it | 16:02 |
| alf_ | racarr: that's the recommended way, look at message_processor_report* in server/lttng/ as a template of how to do it | 16:04 |
| alf_ | racarr: let me know if you have any questions | 16:08 |
| racarr | alf_: I think it makes sense. Thanks :) | 16:08 |
| alf_ | racarr: yw | 16:08 |
| racarr | what I am wrestling with in my head...is...I guess I want a less explicit interface but | 16:08 |
| racarr | it's probably wrong? | 16:08 |
| racarr | the thing is. the way I imagine wanting to use tracing (espescially in parts like input) is to have...lots of trace points! | 16:09 |
| racarr | But if they are done through a report rather than explicitly they have a real cost | 16:09 |
| racarr | both runtime, and interface bloat | 16:10 |
| alf_ | racarr: runtime=cost when using a null report? | 16:10 |
| alan_g | racarr: you were at the London sprint. We discussed the difference between reporting and tracing there | 16:10 |
| racarr | what you get through the report, is explicitness, and a contract. | 16:11 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | alan_g: Mm | 16:12 |
| racarr | alf_: Well, it's still a virtual method invocation right. It's a hugely low cost I guess. | 16:12 |
| alan_g | racarr: is this the same discussion revisited? | 16:12 |
| racarr | mostly about interface bloat. | 16:13 |
| racarr | alan_g: sort of.. | 16:13 |
| alf_ | alan_g: racarr: hangout? | 16:13 |
| racarr | It's just there are some type of events...like say | 16:13 |
| racarr | "Couldn't load input device configuration file so falling back to generic" | 16:13 |
| racarr | that I am not sure are ever interesting as part of a report | 16:13 |
| racarr | and are so large | 16:13 |
| racarr | err, the space of possible events | 16:14 |
| racarr | but you would love to see them in a trace | 16:14 |
| racarr | *shrug* | 16:14 |
| racarr | alf_: We can. I don't want to distract everyone too much though | 16:14 |
| racarr | because I haven't spent much time thinking about this yet | 16:14 |
| alf_ | racarr: ok | 16:14 |
| racarr | I think maybe I am getting ahead of myself anyway | 16:15 |
| racarr | as my initial goal was just to add tracing for a few interesting | 16:15 |
| racarr | occurences | 16:15 |
| racarr | not everything XD | 16:15 |
| racarr | lol at comments in android input stack | 16:16 |
| racarr | We hold a wake lock at all times except during epoll_wait(). This works due to some // subtle choreography | 16:16 |
| racarr | "Subtle choreography" | 16:17 |
| === greyback is now known as greyback|food | ||
| alan_g | racarr: alf_ - do we want to hangout now? Or after racarr has spent a day implementing something? | 16:23 |
| alf_ | alan_g: racarr: let's leave it for after | 16:25 |
| racarr | I agree. I just got ahead of myself. The current interfaces are fine for all I want to do now. | 16:25 |
| racarr | in the past. I've found really detailed tracing as a more useful way to debug | 16:26 |
| racarr | multithreaded/multiprocess systems | 16:26 |
| racarr | and might want to enable that one day? | 16:26 |
| racarr | but. ONE STEP AT A TIME *hits self on head with one step at a time stick* | 16:26 |
| alf_ | kdub: how about BufferSwapperSync, BufferSwapperAsync ? | 16:27 |
| alan_g | racarr: ok, but it is good to share ideas about the overall shape of things too. ;) | 16:28 |
| alf_ | kdub: hmm, Async doesn't really tell the whole story | 16:28 |
| kdub | alf_, yeah, "synced to what?" was my first thought | 16:28 |
| racarr | alan_g: The one thing I do have open for this first step is | 16:29 |
| racarr | the existing "InputReport" stuff to redirect the android logging | 16:29 |
| racarr | is conflicting in name because I can't provide an LTTNG backing for that really | 16:29 |
| racarr | at least, the command line option is conflicting ;) | 16:31 |
| alan_g | racarr: you'd like to rename it "LegacyInputReport"? Fine by me - I just stopped it spewing over the console | 16:31 |
| racarr | Ok | 16:31 |
| racarr | yes. Much appreciated :) | 16:31 |
| alan_g | racarr: one day we can get rid of the legacy. ;) | 16:31 |
| kdub | alf_, maybe FrameDroppingSwapper and VsyncSwapper? | 16:32 |
| kdub | sort of tough to convey all the nuances of a buffer swapper in class name ;-) | 16:33 |
| === alan_g is now known as alan_g|life | ||
| === jono is now known as Guest93857 | ||
| === greyback|food is now known as greyback | ||
| racarr | so how do I use lttng -.- | 18:31 |
| racarr | hmm neither my new lttng or the old lttng following alfs instructions | 18:42 |
| racarr | works for me | 18:42 |
| racarr | Lunccccch! | 18:50 |
| === mmrazik|afk is now known as mmrazik | ||
| === greyback is now known as greyback|away | ||
| greyback|away | racarr: small patch for lp:~robertcarr/platform-api/mir branch so it builds against latest mir: http://pastebin.ubuntu.com/5711198/ | 19:13 |
| greyback|away | after merging trunk ofc | 19:14 |
| racarr | annd back | 19:24 |
| racarr | greyback|away: Ah! thanks will merge | 19:25 |
| kdub | swapperswappers are tricky | 20:07 |
| racarr | :( | 20:17 |
| thomi | morning folks | 21:15 |
| robert_ancell | thomi, hello | 21:24 |
| robert_ancell | thomi, hey, any update on autorebuilding lightdm against libmirserver? | 21:24 |
| thomi | robert_ancell: should be working now | 21:24 |
| robert_ancell | \o/ | 21:24 |
| robert_ancell | thomi, also, we need to enable lightdm building on saucy | 21:24 |
| thomi | might be done already, let me check | 21:25 |
| robert_ancell | thomi, https://launchpad.net/~mir-team/+archive/staging/+packages shows lightdm being rebuilt 2 May - so it doesn't appear to be working? | 21:25 |
| thomi | robert_ancell: ok, saucy is already enabled. I have a call with francis in 4 minutes, so I'll ask him about it then | 21:26 |
| robert_ancell | ok, ta | 21:26 |
| thomi | robert_ancell: also, I have a 50 line c++ program that reliably hangs the mir server :( | 21:27 |
| thomi | about to file a bug... | 21:27 |
| robert_ancell | :( | 21:27 |
| thomi | I'm really glad we're doing these stress tests, we seem to be fixing a lot of problems | 21:27 |
| thomi | well, when I say "we"... I'm not fixing anything :P | 21:27 |
| kgunn | thomi: hey...somebody's gotta break it before you can fix it | 21:29 |
| thomi | I'm the annoying guy who comes along and pokes holes in your nice shiny new code :) | 21:30 |
| kgunn | i'm grateful...good stuff! | 21:31 |
| robotfuel | I get the following error message when trying to run mir_demo_server on the phone: http://pastebin.ubuntu.com/5711560/ has anyone else run across this? | 21:43 |
| greyback|away | robotfuel: I find a reboot can help that. I sometimes get it after a package update | 21:44 |
| greyback|away | robotfuel: oh actually, are you running on your desktop? | 21:44 |
| robotfuel | greyback|away: no the ubuntu-touch image on a galaxy nexus | 21:45 |
| thomi | robert_ancell: got a moment for a quick hangout with francis to discuss the lightdm issue? | 21:46 |
| greyback|away | robotfuel: ah, I see. You need to run it via "adb shell" - not as the root user | 21:46 |
| robert_ancell | thomi, sure | 21:46 |
| robotfuel | greyback|away: I am running it in the ubuntu_chroot | 21:46 |
| robotfuel | via adb shell | 21:46 |
| robert_ancell | thomi, what is the issue? | 21:46 |
| thomi | robert_ancell: just the lightdm being rebuilt after every mir | 21:47 |
| robert_ancell | ack | 21:47 |
| thomi | robert_ancell: actually, don't worry | 21:47 |
| robert_ancell | even better :) | 21:47 |
| thomi | I'll manage, and pull you in if needed | 21:47 |
| greyback|away | robotfuel: ok good. Did you stop surfaceflinger? | 21:47 |
| greyback|away | robotfuel: you can do this while not in the chroot, by running simply "stop" | 21:48 |
| robotfuel | greyback|away: yes I ran stop && ubuntu_chroot shell | 21:48 |
| greyback|away | robotfuel: in that case, I'm running low on ideas. What device have you? | 21:48 |
| greyback|away | oh oyu said, galaxy nexus | 21:49 |
| robotfuel | greyback|away: yes a gnex | 21:49 |
| thomi | robert_ancell: you want lp:~mir-team/lightdm/unity rebuilt, right? not lp:lightdm | 21:50 |
| robert_ancell | thomi, correct | 21:50 |
| greyback|away | robotfuel: give me a minute, I'll try it on mine | 21:50 |
| === greyback|away is now known as greyback | ||
| robotfuel | I have jenkins running a glmark job on the desktop, but it should be more interesting on a phone, because fps isn't tied to the refresh rate of the monitor | 21:50 |
| thomi | robert_ancell: ok, we had enabled the autorebuild for unity-system-compositor, but not for lightdm, that's being done now | 21:51 |
| kgunn | robotfuel: on a phone you're still going to be tied to vsync | 21:51 |
| kgunn | unless you do something to unhinge it | 21:51 |
| robert_ancell | thomi, so U-S-C shows it is 19 days old | 21:52 |
| robert_ancell | thomi, oh duh. I was getting mixed up. I think technically we don't need to rebuild lightdm on libmirserver changes, but it is a nice to have anyway | 21:52 |
| thomi | robert_ancell: ok, well.. that's going in now anyway :-/ | 21:53 |
| robert_ancell | we do need lightdm on saucy though | 21:53 |
| thomi | everything should be being built on saucy already | 21:53 |
| robert_ancell | thomi, it might actually need to be rebuilt when u-s-c changes in the future, but I'll bug you then if it's a problem | 21:53 |
| * robert_ancell takes a week off and forgets everything | 21:54 | |
| fginther | yo | 21:54 |
| thomi | robert_ancell: so after the rebuild the packages should be pushed to ppa:mir-team/staging, ight? | 21:54 |
| robert_ancell | thomi, yes | 21:54 |
| thomi | fginther: can we do that easily? | 21:55 |
| robert_ancell | thomi, how do you version them? | 21:55 |
| fginther | robert_ancell, we can do that.. | 21:55 |
| robert_ancell | fginther, so it just overwrites the existing one? | 21:55 |
| fginther | the packages can be versioned with a monotonically increasing version number | 21:55 |
| fginther | yes, it will overwrite the last one | 21:55 |
| robert_ancell | fginther, will a user upgrade from version X to X (i.e. if the binary has changed)? | 21:56 |
| thomi | presumably the version number will be X -> X+1 or X.1 | 21:56 |
| robert_ancell | I was hoping we could have 0.0.1brz25.3 for the third rebuild of bzr version 25 | 21:56 |
| greyback | robotfuel: ok I got it working here. I made sure everything was up to date. Then reboot, adb root, adb shell, stop, ubuntu_chroot, mir_demo_server&, mir_demo_client_accelerated | 21:57 |
| fginther | robert_ancell, if the user does a dist-upgrade, they will get the lastest, but if a user does a install of just mir, it will not pull in the lightdm-mir | 21:57 |
| robotfuel | greyback: thanks, I didn't try the client part | 21:57 |
| greyback | robotfuel: if the server returns that error message you got, then the client will fail. Server needs to be running | 21:58 |
| greyback | before client can show anything | 21:58 |
| thomi | robert_ancell: latest mir bug I've found is posted at: https://bugs.launchpad.net/mir/+bug/1185183 | 21:58 |
| ubot5 | Launchpad bug 1185183 in Mir "mir_demo_server hangs" [Undecided,New] | 21:58 |
| kdub | i can try on my phone... see what happens | 21:59 |
| robotfuel | I am using image 132, maybe that image has an issue. | 21:59 |
| greyback | robotfuel: perhaps, that I cannot say. apt-get dist-upgrade all up to date? | 22:00 |
| fginther | robert_ancell, it is very difficult to get the version numbers to 'reset', so what happens is, you'll see a version ending in '0' when the package is built due to a source change, othewise, the version will end in X, where X is always greater then the last X | 22:00 |
| robert_ancell | fginther, ok | 22:01 |
| robotfuel | greyback: distupgrade fixed the issue, thanks! | 22:20 |
| racarr | earrrly in. early out! | 22:20 |
| greyback | robotfuel: glad to hear it. | 22:20 |
| kgunn | cya racarr | 22:30 |
| thomi | robert_ancell: got a second? | 22:50 |
| robert_ancell | thomi, sure | 22:50 |
| thomi | robert_ancell: so the bug I reported above is blocking the stress tests moving much further. I wonder who I should bug about this? Or should I just leave it with you and work on something else today? | 22:51 |
| robert_ancell | thomi, I'll have a look at it | 22:52 |
| thomi | robert_ancell: thanks | 22:53 |
| robert_ancell | thomi, always exactly after 500 times? | 22:58 |
| thomi | robert_ancell: 501 actually, yeah | 22:58 |
| robert_ancell | weird | 22:58 |
| thomi | yeah. I wondered if the sevrer was leaking 2 file handle per connection | 22:59 |
| thomi | just a guess | 22:59 |
| robert_ancell | thomi, why does it close the fd? | 22:59 |
| thomi | robert_ancell: otherwise the client leaks them. see mail to ML | 22:59 |
| robert_ancell | ok, that's just a workaround | 22:59 |
| thomi | RAOF was going to fix that in the client API | 22:59 |
| thomi | yeah | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!