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