[00:01] namespace mgeglm = mir::graphics::egl::mesa? [00:01] I just wanted to share how happy I was to type mgeglm [00:17] ??? [00:43] RAOF: I just think it's a funny combination of letters [00:43] ignore me... [00:43] No, that just seems like a surprisingly nested namespace. [00:58] racarr: hmm, this could get fun [00:59] smspillaz: What are you up to? :) [00:59] namespace compiz::objects::central::keyboard [00:59] I don't get it ;) [00:59] :P [01:00] RAOF: me? mostly eating popcorn [01:29] robert_ancell: We have logs if you're interested :) https://bugs.launchpad.net/mir/+bug/1109957 [01:29] Launchpad bug 1109957 in Mir "lightdm with type=mir causes raring to freeze on boot. plymouth stuck at 100% progress." [Critical,New] [01:31] duflu, ta [01:36] Wow, seems Alexandros likes to finish things without any fanfare. This is now DONE(!): https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 [01:36] Except that we can't get any useful numbers out of it till we fix Mir's eglSwapInterval(0) [02:32] duflu, can you look out for a notification for "TEST BUG" against Mir? [02:32] robert_ancell: Could you please update the subscription to ensure mir-team gets bug comments too? [02:32] duflu, did that before this [02:32] comments? [02:32] I think people should opt-in for comments [02:33] robert_ancell: I disagree. Someone has to answer comments. And if the dev team has not subscribed then that will usually be no one [02:34] no, that's just spamming people. If you want to do that then subscribe yourself. Otherwise people should only subscribe to bugs that are relevant to them [02:35] robert_ancell: Umm, Mir bugs are relevant to Mir developers. More generally developers need a kick in the pants to pay more attention to their own bugs [02:35] duflu, you are automatically subscribed to your own bugs, and you can subscribe people to bugs you think they should look at [02:36] robert_ancell: "own bugs" means bugs you caused, not logged [02:36] duflu, then subscribe them when you read it [02:36] duflu, bugs can easily become a distraction from actual work - the goal is not to empty the bug tracker [02:37] robert_ancell: True, but you can't release anything if you have a pile of High's and Criticals [02:37] you can === jono is now known as Guest2834 [02:37] * duflu is scared at that prospect [02:39] duflu, it depends who set them to high and critical - we have an open tracker [02:42] robert_ancell: It's not meant to be a matter of opinion. There are clear definitions of the severities here: https://wiki.ubuntu.com/Bugs/Importance [02:42] Though that's not to say those are followed accurately [02:44] duflu, bingo [02:53] robert_ancell: I get the impression that this page is good for determining bug severity if you're a kernel [02:53] it would be good to have bug guidelines per-project [02:53] It's hard enough having one standard. I'm not sure we want multiple standards [02:54] sure, its just that the examples are not very applicable to some projects [02:54] "causes data corruption" <- let me know when that happens in a display server [02:55] We can *totally* do that. [02:55] RAOF: was that a challenge accepted ? [02:55] We just need to set up the GPU memory maps appropriately :) [02:55] RAOF: I think that's fudging with the definition of "data" [02:56] Surely you can mmap some memory to an important file [02:56] right, I just didn't think that fell within the usecase of a display server [02:56] Set the GPU memory maps appropriately so that they overlap with the kernel's VFS cache. [02:56] RAOF: oh, heh [02:56] Evil [02:57] RAOF: does mir run as root ? [02:57] I don't think we know. [02:57] (its a stupid question, I've not run it in months) [02:57] haha [02:57] yikes [02:57] smspillaz: Not normally, but it can [02:57] The system-compositor probably will, but the sessions won't. [02:57] you guys are going to have lots of fun [02:58] Of course! [03:22] duflu, you had a branch that was going to add a mircommon-dev right? What happened to that? [03:22] robert_ancell: It landed. And I see it in the PPA already [03:22] duflu, oh right, I hadn't updated [03:31] robert_ancell: Is it bad for lightdm that mir has no upstart config? [03:32] duflu, mir is started by lightdm so upstart is not involved [03:32] robert_ancell: Fair enough. But there is often a small delay in the socket becoming available. Does lightdm sleep a little before looking for it? [03:33] Or poll for it and eventually time out? [03:33] duflu, yeah, there's a hack currently but we will need the system compositor to notify lightdm when the socket is ready [03:33] poll [03:33] Damn. No easy explanations [03:34] You and your forethought [03:34] the way X does this is using a unix signal. We can easily pick that up, though it's a bit yuck. The cleaner way is to pass a fd to the compositor and have it write to it when ready [03:34] robert_ancell: Signals sound might simpler. Why yuck? [03:35] -might +much [03:35] duflu, because they're kind of hard to handle in the receiver. But we have all the work for X done so we can live with it [03:35] also potentially we want more information than a signal can provide [03:36] I guess a signal necessitates knowing a process ID to send to :( [03:36] duflu, children can emit a signal on themselves and the parent picks it up [03:37] We want to pass an fd from lightdm to the system-compositor *anyway*; we might as well signal readiness on it. [06:03] RAOF, ping [06:03] tvoss: Pong. [06:04] RAOF, good afternoon :) quick question about hw cursors: do we have a work item for that? [06:04] Hm. I suspect that we might want a parallel server-side buffer age so we can optimise out sending buffers we know the client has. [06:05] tvoss: Heh. Yes, someone set alf_ as owning that work item today. [06:05] client-1303-mir-converged [06:05] RAOF, cool, we have the first iteration of input mostly landed, and rendering a cursor might prove helpful :) [06:06] We don't have keyboard input landed at all, right? [06:06] RAOF, an english keyboard should work :) [06:07] RAOF, ah, just observing your comments on receive-input-in-client [06:07] What about https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 [06:08] RAOF, that's what I was referring to, I thought it had landed yesterday [06:08] :) [06:11] RAOF, anyway, once that lands, generic keyboard support is there. Then keymapping is the next topic [06:11] Cool. [06:12] daniels will be interested to hear where libkeymap fails to support our needs :) [06:14] RAOF, I guess not at all :) we just need to take a look at it [06:14] RAOF, got a link for me? [06:16] It's libxkbcommon :) [06:16] RAOF, I'm confused now :) [06:16] He was just complaining that he mis-named it, and it should really be called libkeymap. [06:16] RAOF, I guess I'm all in for that [06:38] mmrazik, I was wondering if there is any documentation on fence_cdu [06:39] tvoss: do you have account on magners? [06:39] mmrazik, not sure :) [06:39] tvoss: let me pastebin --help [06:39] I don't think there is much more than that. Maybe something on wiki.canonical.com [06:39] mmrazik, ack [06:40] tvoss: http://pastebin.ubuntu.com/5651494/ [06:40] tvoss: its a python script so I guess we can modify if need something [06:41] mmrazik, ack [06:41] and I _think_ (didn't check) its using ssh to access the power strips [06:41] mmrazik, I was thinking about writing a google test fixture for setting up the multi-monitor setup [06:48] Huh. GTest really does call *0 = 1; to die in this case. [06:55] Grr. What the hell, gdb? [06:56] RAOF, what's up? [06:57] My changes to not leak fds in GBMClientBuffer have broken the acceptance-tests; a couple of them now segfault. [06:58] However, for some reason gdb doesn't seem to find DefaultDisplayServerTestFixture_client_library_accesses_and_advances_buffers::TestBody(), so I can't attach gdb at the right place. [06:59] Because obviously I need to be tracing the _child_, which means I need to set follow-fork-mode just before it forks. [06:59] RAOF: gdb doesn't find it cos it's in a child process. You need to enable tracing into childten [06:59] *children [06:59] Yeah what you said [07:00] * RAOF → Zoë bath; back later to be annoyed at gdb further. [07:00] * duflu reverts the day's work and starts again. Lost in class dependency spaghetti [07:55] Hah. Don't accidentally recurse infinitely. [07:59] Hm, no, that's not going to work. Looks like I really do need to make the server not uselessly send buffers the client already has. [08:09] kdub: Hey, you send fds for buffers out over the wire - how come android clients don't crash after not very long for exhausting their fd space? [08:11] RAOF: I believe it's past 1am for kdub [08:12] Yeah, that would be right. [08:12] He's on in our *morning* :) [08:12] * RAOF suspects the answer to his question is ‘if we had any non-trivial demo clients, they *would* crash after not very long by exhausting their fd space’ [08:13] Heh [08:13] In time === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [10:47] Night all === mmrazik is now known as mmrazik|afk [12:38] alan_g: @composite-on-demand, what do you think about on_change_call(...) instead of e.g. set_change_callback(...) [12:38] alan_g: or on_changed_call() [12:40] alf_: this is actually a case where I tend like "set" - largely because it isn't otherwise clear that it overwrites any existing callback (as opposed to "add...") [12:41] alf_: but I think any of the above would be an improvement [12:42] alan_g: ok [12:43] alf_: there's also "on_change_invoke()" [12:53] install_change_callback () is another potential one I guess [12:54] alan_g: smspillaz: I like how render_view.on_change_invoke(...) reads, but I will go with set_change_callback() since its semantics are clearer [12:54] +1 [12:55] smspillaz: I think install_change_callback() suffers from the same problem (as discussed above) [12:56] yeah I was thinking that too === alan_g is now known as alan_g|lunch [13:24] alf_: are the gl bench #s being dumped somewhere to show a trend chart? or are they individually buried in jenkins test results? [13:36] kgunn: I don't think there is a job for running glmark2 on mir, just on a traditional ubuntu system, but I don't know where the results end up. === alan_g|lunch is now known as alan_g [15:07] morning [15:09] Hello! [15:11] status, working on integrating hwc device, hit a snag where (i think) the gpu clocks are not turned on all the way [15:13] status: got run_mir working properly, MP's a better MessageProcessorReport, and started wondering about glog again [15:14] alan_g, yeah, waiting to clear that needs fixing on the scripts change :/ [15:15] * alan_g nags kdub [15:23] status: Amending composite-on-demand MP, started investigating mir shutdown regression (i.e. we don't return to a properly configured console sometimes) === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [15:47] What is the status of the input subsystem? I read in the commit logs that input events are now passed down to the client, but how much of the whole system is implemented? Would it be possible to write a demo client which accepts keyboard/mouse events? [15:50] sturmflut: ask racarr when he wakes up [15:50] sturmflut: we're getting closer - racarr is the one to ask [15:50] smspillaz, alan_g: Okay [15:50] racarr: wake up! [15:51] haha [15:51] he'll probably be around in 10 minutes :) [15:52] sturmflut: if I end up moving to SFO later this year for a possible internship I'll make sure to knock on his door [15:54] sturmflut, once the last branch lands: yes, you could start writing a client. racarr actually planned something cool :) [15:54] sturmflut, but best talk to him [15:55] I also noticed that my minimal client has to #include but the /usr/include/mir/client/mir_toolkit/mir_client_library.h header file provided by the PPA packages tries to #include "mir_toolkit/c_types.h" which does not work. Is this because the Header files are still being shuffled around? [16:00] sturmflut, I'm pretty sure that is the reason, yes [16:00] alan_g, can you look into what sturmflut just mentioned? [16:00] sturmflut: I too am a bit confused about what's happening there. (It isn't what I expect.) Can you temporarily add [/usr/include/]mir/client to your project include path. [16:01] tvoss: I discussed it with robert_ansell yesterday and was assured it does work. But it seems I'm not the only one of a different opinion. [16:02] alan_g, ack. sturmflut can you file a bug please? [16:02] alan_g: If i add it to my include path it works, as one would expect. [16:03] sturmflut: use that as a workaround. (But please raise the bug.) [16:03] alan_g: Will do [16:08] kdub: tvoss kgunn (anyone interested) I'm creating a canonical [no pun intended] example of a useful logging reporter. I'd appreciate comments on https://code.launchpad.net/~alan-griffiths/mir/improved-MessageProcessorReport/+merge/155746 === alan_g is now known as alan_g|vt === alan_g|vt is now known as alan_g [16:45] I exist [16:45] smspillaz: :) [16:46] sturmflut: It's possible to write a demo client which receives keyboard events using the outstanding event ~robertcarr/mir/receive-input-in-client [16:46] your guess of the status in trunk so far is good though, input is sent up to clients [16:46] but not all received yet [16:46] (and pointer input isnt finished) [16:58] hi racarr [16:59] Hi katie [16:59] how's things? want to have a catch up? [17:00] things are good, not sure I have anything [17:00] me neither [17:02] katie: Ok let's skip this week then [17:02] racarr: great [17:03] i mean, i love our meetings, but good to have some time back :) [17:03] katie: I feel the same :) [17:04] actually right now I feel very little other than disdain for android::Looper but if I had normal feelings that would be it [17:05] status: Iterating on receive-input-in-client...tried to port the client side input machinery to android::Looper to get rid of the short timeouts [17:05] (plus fixing RAOF's other comments) [17:05] got it "working" but acceptance tests fails intermittently with the looper on the client side [17:05] drivers work better when they don't load their firmware all the time [17:05] then back to finishing off inprocess EGL branch from yesterday [17:05] racarr, can you put a fixme there that notes down that we ideally want to associate it to the same event loop [17:06] kdub, ? :) [17:06] kdub: Actually mythbusters did a show on that, drivers work best when loading their firmware all the time! [17:06] :p [17:06] tvoss: What do you mean? [17:06] i.e. assosciate all input and everything else to the same event loop? [17:08] tvoss, just a fun bug i caused during hwc development [17:08] kdub, ah :) [17:09] racarr, we have a looper in the client api anyway, it's an io_service. We might want to reuse that for the input channel, too [17:10] tvoss: Boost::asio is not a good replacement for epoll I think as we saw in [17:10] Looper.h [17:10] well [17:11] I dunno it can be adapted of course [17:11] racarr, I do disagree, I think it's a very sane replacement, it just does not fit the Looper model or we haven't looked into it deeply enough [17:11] racarr, just leave a note in the code :) [17:14] RAOF, to answer the backscroll... we don't exhaust the fd space because the kernel keeps a mapping of pid's to fd's and pops the same one out on the client side on every message [17:29] so weird...the android::Looper version of the client, sometimes it indefinitely hangs in pollOnce in the acceptance test [17:29] if I add the fd to the looper in the first call to next_event instead of in the constructor [17:29] it never fails (well, out of 1000 runs, whereas the other failed ~1/10) [17:30] what is happening...-.- [17:31] racarr: when things don't make sense it is time to look at something else for 20min [17:41] alan_g: You mean instead of continuing to blunder around in nonsense? Novel idea. [17:42] I mean that breaking focus helps see what you missed [17:42] racarr: ^ === alan_g is now known as alan_g|life [18:08] alan_g|life: Hehe I know what you mean :) [18:51] alan_g|life: https://bugs.launchpad.net/mir/+bug/1161064 [18:51] Launchpad bug 1161064 in Mir "Mir client header files seem to be incorrect" [Undecided,New] [18:58] sturmflut: Thanks! I am about to go on lunch [18:58] but I will process that later today...I think you are right! [18:58] racarr: Input processing on the server side currently concentrates on Android, am I right? Or is there a branch which handles other platforms [18:58] so we should just land a fix asap [18:58] sturmflut: No it works on desktop [18:58] some of the naming is misleading because it uses [18:58] large pieces of the android input stack :) [18:58] ah [18:59] so the mir::input::android namespace is the android-input based implementation of mir::input but not the android...platform? [18:59] confusing...need better names :) [19:00] sturmflut: https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 if you look aronud l363 you can see an example using it :) [19:24] got distracted by finishing inprocess egl XD...just need to find the right abstraction for the display validation now and should be good to go [19:24] but now lunch for real === racarr is now known as racarr|lunch [20:02] tvoss, hello [20:02] robert_ancell, hey there :) [20:02] robert_ancell, wanna sync up? I have got nothing urgent on my side [20:02] tvoss, yeah, just a quick one [20:02] ack, gimme two :) === ernsthaft_ is now known as sturmlfut === sturmlfut is now known as sturmflut [21:02] meeting "mir team 2"? [21:02] Yeah, for those of us for whom “mir team 1’ was stupid'o'clock. [21:04] kdub: RAOF :) happening now [21:48] kdub: Is that pid→fd mapping an android-specific thing? Because when *I* send fds over the pipe I get a shiny new one each time at the client. [21:49] might be, surfaceflinger does the same thing with its binder transactions [21:50] i can look into it, maybe its an android kernel thing [21:50] Eh. [21:51] I'm going to fix things up so we don't send needless fds, so it doesn't really matter. [21:51] that would be better [22:30] RAOF, how are you for pkg-config/include directories? [22:32] robert_ancell: You mean, would I like to weigh in on the include-directory-structure thread, or do I have enough headers? [22:32] RAOF, I just need a second opinion on https://code.launchpad.net/~robert-ancell/mir/mir-common-headers/+merge/155660 - This is just standard stuff to me or is it confusing? [23:11] CMake Error at cmake_install.cmake:44 (FILE): [23:11] file INSTALL cannot find "/mnt/datengrab/mir/build/doc/html". [23:11] What the heck [23:18] As of lately all accelerated clients segfault in XGetXCBConnection () from /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 . I tried it with the packages from the PPA and by building Mir manually. Happens with the included examples and glmark2. The unaccelerated demo client still works. [23:29] sturmflut: You need to have doxygen installed for make install to work. [23:30] sturmflut: We should probably fix that :) [23:30] RAOF: doxygen is installed [23:30] Hm. Was it installed when you first ran cmake? [23:30] Oh, you might *also* have to specifically enable docs. [23:30] RAOF: Yes, I even wiped the whole build/ folder and ran cmake again [23:31] sturmflut: Segfault in XGetXCBConnection means that Mesa hasn't detected the right EGL platform, and has uselessly defaulted to X11 which segfaults if you're not *in* X11. [23:31] sturmflut: We've recently gone through a transition for mesa which would have caused that, but the mesa in github (and I hope the PPA by now) should work with Mir trunk. [23:32] RAOF: On the doc issue: I had to manually set BUILD_DOXYGEN to ON, then it worked [23:32] Dunno why it was off in the first place [23:33] Because we hate you, I think :) [23:33] Thank you, sir, I will remember that [23:33] We should really fix that. [23:33] To either (a) turn on the docs automatically when doxygen is installed, or (b) not fail to install when the docs haven't been built. [23:33] Or possibly even (c) both of the above. [23:34] Equally, Mesa defaulting to the X11 EGL platform is stupid and should be fixed. [23:36] How do I find out if my Mesa package is on par with the github version? Seems like most of my Mesa packages are version 9.1~rc2-0ubuntu0+mir2-jenkins17 [23:36] sturmflut: Hm. Mesa in the PPA hasn't been rebuilt since the changes landed in github, so it won't work. [23:37] thomi: How do we prod jenkins to build & upload a new mesa? [23:37] RAOF: to a PPA you mean? It should happen automatically as part of the autolanding process [23:38] * thomi investigates [23:38] thomi: mesa isn't autolanded. [23:38] ahh, in that case, It's probably as simple as rebuilding a jenkins job [23:39] RAOF: http://10.97.0.6:8080/job/mesa-egl-platform-mir-raring-dput/ was last run 20 days ago - does that sound about right? [23:39] That'd match the timestamp in the PPA; there are new changes in the git branch though that'll make sturmflut's mesa actually work, though. [23:40] ahh, I see the git polling script is throwing an error, I'll rebuild it manually for now, and look in to why it's failing [23:40] Now this is what I call Platinum Support [23:43] gource visualization of Mir codebase: http://youtu.be/7grEFrTBzus [23:45] RAOF: OK, the problem is that the git plugin we're using in jenkins is rather old, and requires a workspace on the slave (which isn't available). I'll file and RT to upgrade the plugin to a newer version, where this issue is fixed [23:47] cgoldberg: Looks nice [23:47] Yeah, very puurdy. [23:48] sturmflut, i love making visualizations when I'm bored... just popped in to have a look at Mir :) [23:51] cool cgoldberg [23:56] thomi: Is it safe to build my own Mesa from github? Or should I wait for the packages [23:57] sturmflut: I don't know about "safe", sorry. those packages have been dput'ed, so they shouldn't be too far away [23:58] sturmflut: you can see the build progress here: https://launchpad.net/~mir-team/+archive/staging/+packages