[00:18] <racarr> Hello!
[00:19] <RAOF> No longer eating delicious desert?
[00:19] <racarr> Back home :D it will probably take a few days for the dust to fully leave my lungs though.
[00:27] <RAOF> Ooh. I *can* slot in a MockSurface. Yay!
[00:41] <RAOF> Oh, no.
[00:41] <RAOF> That's a lie.
[02:04] <smspillaz> racarr: !!
[02:14] <robert_ancell> RAOF, did you get anywhere with XMir+focus switching?
[02:15] <RAOF> robert_ancell: Yeah, I'm just preparing to propose a Mir branch to fix an annoyance there.
[02:15] <robert_ancell> RAOF, cool
[02:15] <robert_ancell> RAOF, also, do you think there's any version dependency that could help bug 1218932?
[02:16] <robert_ancell> The depends of u-s-c on xmir is a bit suspect already, not sure if there's any minimum version that makes sense
[02:16] <robert_ancell> actually, I guess that should be mir with a minimum version on a driver, though it should be a recommends I guess
[02:19] <RAOF> Yeah, I need to think about that a bit more.
[02:23] <racarr> smspillaz: !!?!!
[02:59] <RAOF> robert_ancell: https://code.launchpad.net/~raof/mir/unfocus-on-surface-destroy/+merge/183563 is available for your pleasure.
[02:59] <robert_ancell> RAOF, the name sounds like a useful feature :)
[03:01] <robert_ancell> RAOF, does the destroy event not get to the client?
[03:03] <RAOF> robert_ancell: It does, but you don't know whether the surface was focused or not.
[03:05] <robert_ancell> RAOF, would it be better just to add a mir_surface_get_has_focus()? This isn't like X - Mir will always notify if you get focus
[03:06] <robert_ancell> I'm just thinking that unfocus due to deletion is a slightly separate case to being unfocussed for a particular reason
[03:08] <RAOF> It is, yes. I could add has_focus(), but it would be a bit racy - you'd need to check it in the surface deletion callback to avoid possibble races (and that's non-obvious).
[03:10] <robert_ancell> RAOF, you say "We probably need to rethink focus entirely, but this is an incremental improvement that I need" - can't XMir track the focus itself?
[03:10] <RAOF> I could, yes.
[03:30] <RAOF> robert_ancell: Actually, I'm not sure whether I *could* do focus tracking in XMir. Aside from the locking being a huge pain in the arse, I'm not clear on what our message ordering guarantees are.
[03:30] <RAOF> I could do it with a mir_surface_get_has_focus(), though.
[03:30] <robert_ancell> RAOF, for input it doesn't matter about ordering right? You grab input devices when getting a focus event, and drop them when getting an unfocus or destroy
[03:31] <robert_ancell> RAOF, but with duflu's second opinion, I'm happy to approve the MP anyway
[03:31] <duflu> I think it's OK to say "we're not really sure what's focussed when" for now. The API is too racy (by design) to be sure.
[03:32] <RAOF> That branch guarantees that a released surface always ends up unfocused from the client API's perspective.
[03:32] <robert_ancell> RAOF, btw, I was thinking - do you think XMir will drop the input devices fast enough when switching to the second XMir? Could both XMirs get duplicate events during the changeover?
[03:32] <RAOF> Fair question; that's entirely possible.
[03:33] <duflu> robert_ancell: Even if you guaranteed ordering in the protocol, you can never guarantee when each XMir will be scheduled by the kernel and process the messages.
[03:33] <robert_ancell> duflu, correct
[03:34] <robert_ancell> duflu, but if XMir is being driven by the events, then the ordering isn't really relevant to it in this case
[03:34] <robert_ancell> RAOF, btw, did you see https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/
[03:34] <RAOF> robert_ancell: Yeah.
[03:34] <RAOF> I think I commented on that one?
[03:36] <RAOF> Yes :)
[03:37] <robert_ancell> ah, I didn't read the comments. Due to blog comments almost always being crap. I guess planet.freedesktop probably has more credibility here
[03:44] <RAOF> Heh.
[03:44] <RAOF> robert_ancell: So, probably the *correct* way to do this is a synchronous “please switch now” client API for xmir.
[03:45] <robert_ancell> RAOF, I was wondering if we are forced to do it the correct way or continue with our hack
[03:45] <RAOF> It depends on how fixed you want the bug.
[03:46] <robert_ancell> RAOF, fixed enought that it doesn't bite us in the arse later
[03:47] <RAOF> Without a request/ack style API there *will* be periods where both X servers are consuming events.
[03:48] <robert_ancell> RAOF, yeah, I think we just have to bite the bullet and do it properly via u-s-c. I don't really want to add it into the Mir protocol, but that would be the easiest and most reliable place to put it
[03:48] <RAOF> We don't have anywhere else to put it :/
[03:49] <robert_ancell> RAOF, well, if XMir could contact u-s-c via a different socket we could do something custom and temporary. But XMir doesn't really know u-s-c exists
[03:49] <RAOF> We could teach it.
[03:49] <RAOF> It'd not be super hard.
[03:50] <robert_ancell> RAOF, I suppose we could open a pipe and give you the fd in an env variable
[03:50] <RAOF> Or as another commandline option.
[03:51] <RAOF> Note: we are discussing the most terrible thing ever. ☺
[03:51] <robert_ancell> Yes, I feel dirty
[04:41]  * duflu goes to play in the rain, erm lunch
[05:55] <duflu> RAOF: Any idea why X is always slightly clumsy at changing modes? I always see flickering and sometimes briefly misplaced outputs while it reconfigures. This happens without X too. Plain Mir doesn't.
[05:56] <duflu> This happens *without* Mir too
[05:58] <duflu> Ugh. I mean the issue with X pre-dates Mir. A pure Mir environment seems to switch layouts much more cleanly. But I guess I haven't seen pure Mir switch modes yet
[06:08] <RAOF> duflu: I think XMir exposes a case where Mir does some unnecessary modesetting.
[06:08] <duflu> RAOF: No I mean X has always done this... without Mir
[06:08] <RAOF> But the X issue is bound up in X's "one framebuffer to rule them all"
[06:09] <RAOF> ie: you *can't* turn on a new monitor without touching the existing monitors.
[06:09] <duflu> Oh. Yes.
[06:09] <RAOF> Various drivers can do better and worse at mitigating that; Intel seems to make a fair amount of trouble to mitigate that (copying the contents of the previous framebuffer, etc)
[06:13] <duflu> RAOF: On an unrelated note, would intel's double/triple buffering in the DDX affect the generic logic of the xmir module?
[06:14] <RAOF> I don't believe so, no; from memory, those codepaths are in the drmmode bits, which we bypass.
[06:15] <RAOF> Bah! How do I get Jenkins to retry the flaky test?
[06:15] <duflu> RAOF: Click on the link. Or shout at it.
[06:16] <RAOF> What's the IP of s-jenkins?
[06:16] <RAOF> That's behind the VPN, right?
[06:16] <duflu> Think so
[06:22] <duflu> RAOF: Any tips for explorers wishing to dive into XMir's damage tracking?
[06:24] <RAOF> duflu: The main business is in xmir-window.c, where xmir_window_get_dirty maintains a circular list of damage regions in struct xmir_window.
[06:24] <duflu> RAOF: And xmir_window is effectively one Mir output?
[06:25] <RAOF> Right. We have one xmir_window per output (strictly speaking, one per CRTC)
[06:25] <RAOF> They're sitting in xmir_screen->root_window_fragments
[06:42] <hikiko> RAOF, should the multimonitor work in the lightdm screen?
[06:43] <hikiko> (before we start unity)
[06:44] <RAOF> hikiko: Yes, but you'll have mirrored displays because unity-greeter doesn't set anything different.
[06:44] <hikiko> mmm is there any setting in lightdm I should have or the defaults are fine?
[06:45] <RAOF> The defaults are fine.
[06:45] <hikiko> in an Intel 4000 I have multimonitor working on unity but not in lightdm
[06:45] <hikiko> which is very strange
[06:45] <RAOF> As in: your second display doesn't show anything?
[06:46] <hikiko> it shows a vertical purple line
[06:46] <hikiko> I ll upload a screenshot in a while
[06:52] <hikiko> RAOF: http://i.imgur.com/ulUN09l.jpg
[06:52] <hikiko> but as soon as I login everything is working fine
[06:52] <RAOF> Huh.
[06:52] <RAOF> Interesting.
[06:53] <RAOF> I wonder what it's doing?
[06:53] <hikiko> maybe there's something wrong in my system
[06:54] <hikiko> how can I check that lightdm uses xmir for sure?
[06:54] <RAOF> grep -i xmir /var/log/Xorg.${DISPLAY#:}.log
[06:55] <hikiko> also this occurs when I have the 2nd monitor plugged from the begining, I will check what happens if I start without the 2nd monitor plugged
[06:58] <hikiko> in Xorg.2.log I have this line:
[06:58] <hikiko> [  2356.280] xorg-server 2:1.13.3-0ubuntu6+xmir3 (For technical support please see http://www.ubuntu.com/support)
[06:58] <hikiko> am I using xmir?
[07:00] <dholbach> good morning
[07:00] <hikiko> good morning dholbach
[07:01] <hikiko> RAOF, ^ I think I use xmir... shall I fill a bug report?
[07:02] <RAOF> hikiko: That would suggest that you're *not* using mir
[07:02] <RAOF> Also, that you've got an old Xserver :)
[07:02] <hikiko> haha
[07:02] <hikiko> great
[07:03] <dholbach> hi hikiko
[07:03] <hikiko> so RAOF
[07:03] <hikiko> there must be a conf?
[07:04] <RAOF> hikiko: Do you have unity-system-compositor installed? It installs /etc/lightdm/lightdm.conf.d/10-unity-system-compositor, which enables usc and hence XMir.
[07:04] <hikiko> or installing xserver-xorg-mir is enough
[07:06] <hikiko> RAOF, if I run apt-get install there are extra packages :) it should be that
[07:06] <hikiko> (I mean apt-get install unity-system-compositor)
[07:06] <RAOF> Yeah, apt-get install unity-system-compositor should do it.
[07:07] <hikiko> ok I found what it was: when you upgrade unity-system-compositor with apt-get install there's a question
[07:08] <hikiko> install the package maintainer's version / keep your current etc and default == keep current
[07:08] <hikiko> let me try again
[07:09] <hikiko> fixed :D
[07:10] <hikiko> RAOF, now unity wallpaper
[07:10] <hikiko> has the size of the small monitor
[07:10] <RAOF> Yup, that sounds right.
[07:10] <hikiko> and the dash
[07:10] <RAOF> We clone by default.
[07:10] <hikiko> ok so I leave it like that?
[07:11] <RAOF> Oh, you probably want to set up a spanned desktop; the Displays capplet will let you do that.
[07:11] <RAOF> You can set it up just like you want.
[07:12] <hikiko> cool :)
[07:12] <hikiko> and RAOF another question (final)
[07:12] <hikiko> I want to test xmir for the first time
[07:13] <hikiko> I build and run ./mir_demo_server... --enable-xmir and that's all?
[07:13] <hikiko> what should I expect to see?
[07:16] <RAOF> hikiko: Once you've installed unity-system-compositor you'll be using xmir all the time.
[07:16] <hikiko> I mean the xmir I will build
[07:17] <hikiko> not the system's xmir
[07:17] <RAOF> Ah. In that case, run mir_demo_server_shell, and then on a different VT run “Xorg :33 -mir 1 -retro -verbose 7”
[07:17] <RAOF> (The :33 and 1 are just placeholder values; you can use whatever you want there)
[07:18] <RAOF> When you switch back to mir_demo_server_shell you'll see the delightful X root weave, which is the black and white crosshatch thingy.
[07:18] <hikiko> and then how do you stop it? just killing mir_demo_server_Shell?
[07:18] <RAOF> Ctrl-C works fine :)
[07:24] <duflu> hikiko: Ctrl+Alt+Backspace is how you get out of mir_demo_server_*
[07:25] <duflu> Ctrl+C was disabled a while back
[07:26] <hikiko> yes that's what I noticed :)
[07:26] <hikiko> thanks duflu and RAOF :D
[07:26] <RAOF> Oh, yeah. But Ctrl+C will kill Xorg.
[07:26] <RAOF> When you VT switch back to your Xorg-running VT.
[07:27] <hikiko> oh, I see
[07:28] <hikiko> and one more question to setup a spanned desktop do I need to do something on mir or I do it from unity settings?
[07:38] <hikiko> found
[08:31] <duflu> RAOF: Woo, no time-travelling frames any more
[08:32] <tvoss_> duflu \o/
[08:32] <duflu> Just need to *repeat* and verify. It's not a fix. Just a hack right now
[08:32] <tvoss_> duflu, what is the idea?
[08:33] <duflu> tvoss_: XMir seems to be reporting incorrect damage regions
[08:33] <tvoss_> duflu, ah
[08:34] <duflu> tvoss_: Still, somehow, affected by XMir's multimonitor logic
[08:34] <tvoss_> duflu, hmmm ... interesting
[08:34] <tvoss_> duflu, go ahead then ;)
[11:03] <hikiko> is there any way to temporarily disable xmir?
[14:26] <smspillaz> tvoss_: ^ interesting comment by duflu - do apps need to provide a damage region or is it just assumed to be sizeof(surface) on swap_buffers?
[14:26] <smspillaz> I didn't see anything in the mir api about it
[14:32] <tvoss_> smspillaz, no damage region, yet
[14:35] <smspillaz> tvoss_: ah okay. What was duflu's comment about damage regions about then?
[14:36] <tvoss_> smspillaz, duflu was talking about the xmir world, so mostly the x <-> mir integration parts over there
[14:37] <smspillaz> tvoss_: ah you mean xmir reporting incorrect damage regions to x clients?
[14:37]  * smspillaz thought that xdamage didn't live in the ddx
[14:37] <tvoss_> smspillaz, I would think vice-versa
[14:38] <tvoss_> smspillaz, let me check
[14:58] <sil2100> Hi everyone!
[14:59] <sil2100> Do you know if we still need to enable the Mir PPA for daily-releasing Mir?
[14:59] <sil2100> i.e. D09add_ppa~mir-team~staging ?
[14:59] <sil2100> Since I would prefer not to use non-standard PPAs when releasing stuff
[15:00] <sil2100> kgunn: ^ do you know?
[15:00]  * alan_g wishes he didn't need to learn so much about [E]GL
[15:00] <kgunn> sil2100: mir is in archive...no ppa needed
[15:00] <sil2100> Awesome
[15:01] <kgunn> at most, for those not already running xmir...just apt-get install unity-system-compositor
[15:01] <racarr> Morning!
[15:01] <kgunn> racarr: welcome back
[15:02] <kdub> good morning!
[15:02]  * kdub is back
[15:02] <racarr> kgunn: Thanks :)
[15:05] <alan_g> racarr: welcome back
[15:07] <racarr> alan_g: Thanks :)
[15:11] <kgunn> kdub: welcome back!!
[15:12] <kdub> thanks!
[15:14] <racarr> I keep on looking for some email titled like
[15:14] <racarr> Mirpocalypse
[15:14] <racarr> but havent found it yet. Seems like things are going pretty well?
[15:20] <alan_g> racarr: no dramatic failures
[15:21] <alan_g> but we've not been able to address the lack of a coherent data model and there are plenty of bugs and missing features
[15:57] <racarr> alan_g: :) Thanks.
[16:50] <racarr> Yay, email finished
[16:50] <racarr> I think I replied to all emails last week (except bugs + MRs) that warrant a response from me
[16:51] <racarr> so if you sent me an email last week and are waiting to hear back
[16:51] <racarr> please resend / ping me.
[17:33] <racarr> kgunn: Hey. I think I am keeping myself busy until lunch catching up on commit logs then bugs but can we schedule a sync for this afternoon maybe
[17:33] <racarr> So I can prioritize some tasks?
[17:33] <kgunn> racarr: sounds good
[17:34] <kgunn> i've got thing around 4pm my time...other than that i'm pretty open
[17:35] <racarr> kgunn: Ok how about in 2.5 hours (3 your time?)
[17:35] <kgunn> sounds good
[17:36] <racarr> Ok. Thanks :)
[17:52] <racarr|lunch> Back soon!
[20:23] <racarr> updating my phone image now
[20:23] <racarr> excited to see last weeks progress :)
[20:39] <kdub> racarr, once you've updated, could you try the acceptance tests? seeing some failures there on the phone
[20:43] <racarr> kdub: ok
[20:43] <racarr> updating my phone image earlier really meant charging my ultra dead neuxs 4 so it will be a bit stil
[20:47] <kdub> yeah, mine died a few times mid-update because it ran out of battery
[20:48] <racarr> its so obvious that comcast has been throttling me and is now rewarding me for not using any internet for a week -.-
[20:48] <racarr> Been getting like 3MBs all day
[21:00] <racarr> Phone looks pretty great :)
[22:03] <kgunn> racarr: on the phone...you notice the flicker yet ?...i'm wondering if that's z-order fighting
[22:13] <kgunn> kdub: ping
[22:13] <kdub> kgunn, pong
[22:14] <ricmm> racarr: ping
[22:16] <kgunn> kdub: hey...so i was trying to do mir logging on android...so i did stop unity8, then exported
[22:17] <kgunn> MIR_SERVER_MSG_PROCESSOR_REPORT=log
[22:17] <kgunn> MIR_SERVER_DISPLAY_REPORT
[22:17] <kgunn> =log
[22:17] <kgunn> MIR_SERVER_GLOG=1
[22:17] <kgunn> and MIR_SERVER_GLOG_LOG=/tmp/
[22:18] <kgunn> but...no luck
[22:18] <kgunn> did i miss something
[22:18] <kgunn> (obviously i restarted unity8 after all that)
[22:18] <kdub> hmm, seems like that should work
[22:19] <kgunn> kdub: is the log file names something funny (like j1jk2k3.something) or something obvious like (mir_glog.log)
[22:19] <kdub> MIR_SERVER_GLOG_LOG_DIR=/tmp
[22:24] <kdub> kgunn^^
[22:26] <kdub> the name should be... mir.hostname.user.loglevel.timestamp
[22:27] <racarr> ricmm: Pong!
[22:29] <racarr> kgunn: Yes! I saw it twice pretty quickly but then not again yet
[22:29] <racarr> kgunn: I dont think its that but would have to dig deeper
[22:30] <ricmm> kgunn: it doesnt inherit the environment from where you are restarting the job
[22:30] <ricmm> kgunn: you'd need to add that to the unity8.conf job
[22:33] <kgunn> ricmm: thanks for solving that mystery for me!