[00:01] <racarr> namespace mgeglm = mir::graphics::egl::mesa?
[00:01] <racarr> I just wanted to share how happy I was to type mgeglm
[00:17] <RAOF> ???
[00:43] <racarr> RAOF: I just think it's a funny combination of letters
[00:43] <racarr> ignore me...
[00:43] <RAOF> No, that just seems like a surprisingly nested namespace.
[00:58] <smspillaz> racarr: hmm, this could get fun
[00:59] <RAOF> smspillaz: What are you up to? :)
[00:59] <smspillaz> namespace compiz::objects::central::keyboard
[00:59] <racarr> I don't get it ;)
[00:59] <RAOF> :P
[01:00] <smspillaz> RAOF: me? mostly eating popcorn
[01:29] <duflu> robert_ancell: We have logs if you're interested :)  https://bugs.launchpad.net/mir/+bug/1109957
[01:31] <robert_ancell> duflu, ta
[01:36] <duflu> 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] <duflu> Except that we can't get any useful numbers out of it till we fix Mir's eglSwapInterval(0)
[02:32] <robert_ancell> duflu, can you look out for a notification for "TEST BUG" against Mir?
[02:32] <duflu> robert_ancell: Could you please update the subscription to ensure mir-team gets bug comments too?
[02:32] <robert_ancell> duflu, did that before this
[02:32] <robert_ancell> comments?
[02:32] <robert_ancell> I think people should opt-in for comments
[02:33] <duflu> 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] <robert_ancell> 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] <duflu> 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] <robert_ancell> duflu, you are automatically subscribed to your own bugs, and you can subscribe people to bugs you think they should look at
[02:36] <duflu> robert_ancell: "own bugs" means bugs you caused, not logged
[02:36] <robert_ancell> duflu, then subscribe them when you read it
[02:36] <robert_ancell> duflu, bugs can easily become a distraction from actual work - the goal is not to empty the bug tracker
[02:37] <duflu> robert_ancell: True, but you can't release anything if you have a pile of High's and Criticals
[02:37] <robert_ancell> you can
[02:37]  * duflu is scared at that prospect
[02:39] <robert_ancell> duflu, it depends who set them to high and critical - we have an open tracker
[02:42] <duflu> 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] <duflu> Though that's not to say those are followed accurately
[02:44] <robert_ancell> duflu, bingo
[02:53] <smspillaz> robert_ancell: I get the impression that this page is good for determining bug severity if you're a kernel
[02:53] <smspillaz> it would be good to have bug guidelines per-project
[02:53] <duflu> It's hard enough having one standard. I'm not sure we want multiple standards
[02:54] <smspillaz> sure, its just that the examples are not very applicable to some projects
[02:54] <smspillaz> "causes data corruption" <- let me know when that happens in a display server
[02:55] <RAOF> We can *totally* do that.
[02:55] <smspillaz> RAOF: was that a challenge accepted ?
[02:55] <RAOF> We just need to set up the GPU memory maps appropriately :)
[02:55] <smspillaz> RAOF: I think that's fudging with the definition of "data"
[02:56] <duflu> Surely you can mmap some memory to an important file
[02:56] <smspillaz> right, I just didn't think that fell within the usecase of a display server
[02:56] <RAOF> Set the GPU memory maps appropriately so that they overlap with the kernel's VFS cache.
[02:56] <smspillaz> RAOF: oh, heh
[02:56] <duflu> Evil
[02:57] <smspillaz> RAOF: does mir run as root ?
[02:57] <RAOF> I don't think we know.
[02:57] <smspillaz> (its a stupid question, I've not run it in months)
[02:57] <smspillaz> haha
[02:57] <smspillaz> yikes
[02:57] <duflu> smspillaz: Not normally, but it can
[02:57] <RAOF> The system-compositor probably will, but the sessions won't.
[02:57] <smspillaz> you guys are going to have lots of fun
[02:58] <RAOF> Of course!
[03:22] <robert_ancell> duflu, you had a branch that was going to add a mircommon-dev right? What happened to that?
[03:22] <duflu> robert_ancell: It landed. And I see it in the PPA already
[03:22] <robert_ancell> duflu, oh right, I hadn't updated
[03:31] <duflu> robert_ancell: Is it bad for lightdm that mir has no upstart config?
[03:32] <robert_ancell> duflu, mir is started by lightdm so upstart is not involved
[03:32] <duflu> 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] <duflu> Or poll for it and eventually time out?
[03:33] <robert_ancell> duflu, yeah, there's a hack currently but we will need the system compositor to notify lightdm when the socket is ready
[03:33] <robert_ancell> poll
[03:33] <duflu> Damn. No easy explanations
[03:34] <duflu> You and your forethought
[03:34] <robert_ancell> 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] <duflu> robert_ancell: Signals sound might simpler. Why yuck?
[03:35] <duflu> -might +much
[03:35] <robert_ancell> 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] <robert_ancell> also potentially we want more information than a signal can provide
[03:36] <duflu> I guess a signal necessitates knowing a process ID to send to :(
[03:36] <robert_ancell> duflu, children can emit a signal on themselves and the parent picks it up
[03:37] <RAOF> We want to pass an fd from lightdm to the system-compositor *anyway*; we might as well signal readiness on it.
[06:03] <tvoss> RAOF, ping
[06:03] <RAOF> tvoss: Pong.
[06:04] <tvoss> RAOF, good afternoon :) quick question about hw cursors: do we have a work item for that?
[06:04] <RAOF> 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] <RAOF> tvoss: Heh. Yes, someone set alf_ as owning that work item today.
[06:05] <RAOF> client-1303-mir-converged
[06:05] <tvoss> RAOF, cool, we have the first iteration of input mostly landed, and rendering a cursor might prove helpful :)
[06:06] <RAOF> We don't have keyboard input landed at all, right?
[06:06] <tvoss> RAOF, an english keyboard should work :)
[06:07] <tvoss> RAOF, ah, just observing your comments on receive-input-in-client
[06:07] <RAOF> What about https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
[06:08] <tvoss> RAOF, that's what I was referring to, I thought it had landed yesterday
[06:08] <RAOF> :)
[06:11] <tvoss> RAOF, anyway, once that lands, generic keyboard support is there. Then keymapping is the next topic
[06:11] <RAOF> Cool.
[06:12] <RAOF> daniels will be interested to hear where libkeymap fails to support our needs :)
[06:14] <tvoss> RAOF, I guess not at all :) we just need to take a look at it
[06:14] <tvoss> RAOF, got a link for me?
[06:16] <RAOF> It's libxkbcommon :)
[06:16] <tvoss> RAOF, I'm confused now :)
[06:16] <RAOF> He was just complaining that he mis-named it, and it should really be called libkeymap.
[06:16] <tvoss> RAOF, I guess I'm all in for that
[06:38] <tvoss> mmrazik, I was wondering if there is any documentation on fence_cdu
[06:39] <mmrazik> tvoss: do you have account on magners?
[06:39] <tvoss> mmrazik, not sure :)
[06:39] <mmrazik> tvoss: let me pastebin --help
[06:39] <mmrazik> I don't think there is much more than that. Maybe something on wiki.canonical.com
[06:39] <tvoss> mmrazik, ack
[06:40] <mmrazik> tvoss: http://pastebin.ubuntu.com/5651494/
[06:40] <mmrazik> tvoss: its a python script so I guess we can modify if need something
[06:41] <tvoss> mmrazik, ack
[06:41] <mmrazik> and I _think_ (didn't check) its using ssh to access the power strips
[06:41] <tvoss> mmrazik, I was thinking about writing a google test fixture for setting up the multi-monitor setup
[06:48] <RAOF> Huh. GTest really does call *0 = 1; to die in this case.
[06:55] <RAOF> Grr. What the hell, gdb?
[06:56] <tvoss> RAOF, what's up?
[06:57] <RAOF> My changes to not leak fds in GBMClientBuffer have broken the acceptance-tests; a couple of them now segfault.
[06:58] <RAOF> 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] <RAOF> Because obviously I need to be tracing the _child_, which means I need to set follow-fork-mode just before it forks.
[06:59] <duflu> RAOF: gdb doesn't find it cos it's in a child process. You need to enable tracing into childten
[06:59] <duflu> *children
[06:59] <duflu> 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] <RAOF> Hah. Don't accidentally recurse infinitely.
[07:59] <RAOF> 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] <RAOF> 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] <duflu> RAOF: I believe it's past 1am for kdub
[08:12] <RAOF> Yeah, that would be right.
[08:12] <RAOF> 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] <duflu> Heh
[08:13] <duflu> In time
[10:47] <duflu> Night all
[12:38] <alf_> alan_g: @composite-on-demand, what do you think about on_change_call(...) instead of e.g. set_change_callback(...)
[12:38] <alf_> alan_g: or on_changed_call()
[12:40] <alan_g> 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] <alan_g> alf_: but I think any of the above would be an improvement
[12:42] <alf_> alan_g: ok
[12:43] <alan_g> alf_: there's also "on_change_invoke()"
[12:53] <smspillaz> install_change_callback () is another potential one I guess
[12:54] <alf_> 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] <smspillaz> +1
[12:55] <alf_> smspillaz: I think install_change_callback() suffers from the same problem (as discussed above)
[12:56] <smspillaz> yeah I was thinking that too
[13:24] <kgunn> 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] <alf_> 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.
[15:07] <kdub> morning
[15:09] <alan_g> Hello!
[15:11] <kdub> status, working on integrating hwc device, hit a snag where (i think) the gpu clocks are not turned on all the way
[15:13] <alan_g> status: got run_mir working properly, MP's a better MessageProcessorReport, and started wondering about glog again
[15:14] <kdub> alan_g, yeah, waiting to clear that needs fixing on the scripts change :/
[15:15]  * alan_g nags kdub 
[15:23] <alf_> status: Amending composite-on-demand MP, started investigating mir shutdown regression (i.e. we don't return to a properly configured console sometimes)
[15:47] <sturmflut> 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] <smspillaz> sturmflut: ask racarr when he wakes up
[15:50] <alan_g> sturmflut: we're getting closer - racarr is the one to ask
[15:50] <sturmflut> smspillaz, alan_g: Okay
[15:50] <smspillaz> racarr: wake up!
[15:51] <sturmflut> haha
[15:51] <smspillaz> he'll probably be around in 10 minutes :)
[15:52] <smspillaz> 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] <tvoss> sturmflut, once the last branch lands: yes, you could start writing a client. racarr actually planned something cool :)
[15:54] <tvoss> sturmflut, but best talk to him
[15:55] <sturmflut> I also noticed that my minimal client has to #include <mir/client/mir_toolkit/mir_client_library.h> 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] <tvoss> sturmflut, I'm pretty sure that is the reason, yes
[16:00] <tvoss> alan_g, can you look into what sturmflut just mentioned?
[16:00] <alan_g> 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] <alan_g> 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] <tvoss> alan_g, ack. sturmflut can you file a bug please?
[16:02] <sturmflut> alan_g: If i add it to my include path it works, as one would expect.
[16:03] <alan_g> sturmflut: use that as a workaround. (But please raise the bug.)
[16:03] <sturmflut> alan_g: Will do
[16:08] <alan_g> 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
[16:45] <racarr> I exist
[16:45] <racarr> smspillaz: :)
[16:46] <racarr> 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] <racarr> your guess of the status in trunk so far is good though, input is sent up to clients
[16:46] <racarr> but not all received yet
[16:46] <racarr> (and pointer input isnt finished)
[16:58] <katie> hi racarr
[16:59] <racarr> Hi katie
[16:59] <katie> how's things? want to have a catch up?
[17:00] <racarr> things are good, not sure I have anything
[17:00] <katie> me neither
[17:02] <racarr> katie: Ok let's skip this week then
[17:02] <katie> racarr: great
[17:03] <katie> i mean, i love our meetings, but good to have some time back :)
[17:03] <racarr> katie: I feel the same :)
[17:04] <racarr> 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] <racarr> 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] <racarr> (plus fixing RAOF's other comments)
[17:05] <racarr> got it "working" but acceptance tests fails intermittently with the looper on the client side
[17:05] <kdub> drivers work better when they don't load their firmware all the time
[17:05] <racarr> then back to finishing off inprocess EGL branch from yesterday
[17:05] <tvoss> racarr, can you put a fixme there that notes down that we ideally want to associate it to the same event loop
[17:06] <tvoss> kdub, ? :)
[17:06] <racarr> kdub: Actually mythbusters did a show on that, drivers work best when loading their firmware all the time!
[17:06] <racarr> :p
[17:06] <racarr> tvoss: What do you mean?
[17:06] <racarr> i.e. assosciate all input and everything else to the same event loop?
[17:08] <kdub> tvoss, just a fun bug i caused during hwc development
[17:08] <tvoss> kdub, ah :)
[17:09] <tvoss> 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] <racarr> tvoss: Boost::asio is not a good replacement for epoll I think as we saw in
[17:10] <racarr> Looper.h
[17:10] <racarr> well
[17:11] <racarr> I dunno it can be adapted of course
[17:11] <tvoss> 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] <tvoss> racarr, just leave a note in the code :)
[17:14] <kdub> 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] <racarr> so weird...the android::Looper version of the client, sometimes it indefinitely hangs in pollOnce in the acceptance test
[17:29] <racarr> if I add the fd to the looper in the first call to next_event instead of in the constructor
[17:29] <racarr> it never fails (well, out of 1000 runs, whereas the other failed ~1/10)
[17:30] <racarr> what is happening...-.-
[17:31] <alan_g> racarr: when things don't make sense it is time to look at something else for 20min
[17:41] <racarr> alan_g: You mean instead of continuing to blunder around in nonsense? Novel idea.
[17:42] <alan_g> I mean that breaking focus helps see what you missed
[17:42] <alan_g> racarr: ^
[18:08] <racarr> alan_g|life: Hehe I know what you mean :)
[18:51] <sturmflut> alan_g|life: https://bugs.launchpad.net/mir/+bug/1161064
[18:58] <racarr> sturmflut: Thanks! I am about to go on lunch
[18:58] <racarr> but I will process that later today...I think you are right!
[18:58] <sturmflut> 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] <racarr> so we should just land a fix asap
[18:58] <racarr> sturmflut: No it works on desktop
[18:58] <racarr> some of the naming is misleading because it uses
[18:58] <racarr> large pieces of the android input stack :)
[18:58] <sturmflut> ah
[18:59] <racarr> so the mir::input::android namespace is the android-input based implementation of mir::input but not the android...platform?
[18:59] <racarr> confusing...need better names :)
[19:00] <racarr> 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] <racarr> 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] <racarr> but now lunch for real
[20:02] <robert_ancell> tvoss, hello
[20:02] <tvoss> robert_ancell, hey there :)
[20:02] <tvoss> robert_ancell, wanna sync up? I have got nothing urgent on my side
[20:02] <robert_ancell> tvoss, yeah, just a quick one
[20:02] <tvoss> ack, gimme two :)
[21:02] <kdub> meeting "mir team 2"?
[21:02] <RAOF> Yeah, for those of us for whom “mir team 1’ was stupid'o'clock.
[21:04] <kgunn> kdub: RAOF :) happening now
[21:48] <RAOF> 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] <kdub> might be, surfaceflinger does the same thing with its binder transactions
[21:50] <kdub> i can look into it, maybe its an android kernel thing
[21:50] <RAOF> Eh.
[21:51] <RAOF> I'm going to fix things up so we don't send needless fds, so it doesn't really matter.
[21:51] <kdub> that would be better
[22:30] <robert_ancell> RAOF, how are you for pkg-config/include directories?
[22:32] <RAOF> robert_ancell: You mean, would I like to weigh in on the include-directory-structure thread, or do I have enough headers?
[22:32] <robert_ancell> 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] <sturmflut> CMake Error at cmake_install.cmake:44 (FILE):
[23:11] <sturmflut>   file INSTALL cannot find "/mnt/datengrab/mir/build/doc/html".
[23:11] <sturmflut> What the heck
[23:18] <sturmflut> 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] <RAOF> sturmflut: You need to have doxygen installed for make install to work.
[23:30] <RAOF> sturmflut: We should probably fix that :)
[23:30] <sturmflut> RAOF: doxygen is installed
[23:30] <RAOF> Hm. Was it installed when you first ran cmake?
[23:30] <RAOF> Oh, you might *also* have to specifically enable docs.
[23:30] <sturmflut> RAOF: Yes, I even wiped the whole build/ folder and ran cmake again
[23:31] <RAOF> 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] <RAOF> 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] <sturmflut> RAOF: On the doc issue: I had to manually set BUILD_DOXYGEN to ON, then it worked
[23:32] <sturmflut> Dunno why it was off in the first place
[23:33] <RAOF> Because we hate you, I think :)
[23:33] <sturmflut> Thank you, sir, I will remember that
[23:33] <RAOF> We should really fix that.
[23:33] <RAOF> 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] <RAOF> Or possibly even (c) both of the above.
[23:34] <RAOF> Equally, Mesa defaulting to the X11 EGL platform is stupid and should be fixed.
[23:36] <sturmflut> 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] <RAOF> sturmflut: Hm. Mesa in the PPA hasn't been rebuilt since the changes landed in github, so it won't work.
[23:37] <RAOF> thomi: How do we prod jenkins to build & upload a new mesa?
[23:37] <thomi> RAOF: to a PPA you mean? It should happen automatically as part of the autolanding process
[23:38]  * thomi investigates
[23:38] <RAOF> thomi: mesa isn't autolanded.
[23:38] <thomi> ahh, in that case, It's probably as simple as rebuilding a jenkins job
[23:39] <thomi> 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] <RAOF> 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] <thomi> 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] <sturmflut> Now this is what I call Platinum Support
[23:43] <cgoldberg> gource visualization of Mir codebase:  http://youtu.be/7grEFrTBzus
[23:45] <thomi> 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] <sturmflut> cgoldberg: Looks nice
[23:47] <RAOF> Yeah, very puurdy.
[23:48] <cgoldberg> sturmflut, i love making visualizations when I'm bored... just popped in to have a look at Mir :)
[23:51] <kdub> cool cgoldberg
[23:56] <sturmflut> thomi: Is it safe to build my own Mesa from github? Or should I wait for the packages
[23:57] <thomi> sturmflut: I don't know about "safe", sorry. those packages have been dput'ed, so they shouldn't be too far away
[23:58] <thomi> sturmflut: you can see the build progress here: https://launchpad.net/~mir-team/+archive/staging/+packages