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