| === racarr|desert is now known as racarr | ||
| racarr | Hello! | 00:18 |
|---|---|---|
| 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:19 |
| RAOF | Ooh. I *can* slot in a MockSurface. Yay! | 00:27 |
| RAOF | Oh, no. | 00:41 |
| RAOF | That's a lie. | 00:41 |
| smspillaz | racarr: !! | 02:04 |
| robert_ancell | RAOF, did you get anywhere with XMir+focus switching? | 02:14 |
| 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:15 |
| ubot5 | bug 1218932 in Unity System Compositor "unity-system-compositor should depend on >= version of xserver-xorg-video-<driver> (intel|nouveau|radeon) that works with it." [Undecided,Confirmed] https://launchpad.net/bugs/1218932 | 02:15 |
| 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:16 |
| RAOF | Yeah, I need to think about that a bit more. | 02:19 |
| racarr | smspillaz: !!?!! | 02:23 |
| 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 :) | 02:59 |
| robert_ancell | RAOF, does the destroy event not get to the client? | 03:01 |
| RAOF | robert_ancell: It does, but you don't know whether the surface was focused or not. | 03:03 |
| 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:05 |
| robert_ancell | I'm just thinking that unfocus due to deletion is a slightly separate case to being unfocussed for a particular reason | 03:06 |
| 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:08 |
| 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:10 |
| 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 |
| === chihchun_afk is now known as chihchun | ||
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| RAOF | Yes :) | 03:36 |
| 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:37 |
| 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:44 |
| 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:45 |
| robert_ancell | RAOF, fixed enought that it doesn't bite us in the arse later | 03:46 |
| RAOF | Without a request/ack style API there *will* be periods where both X servers are consuming events. | 03:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| RAOF | Note: we are discussing the most terrible thing ever. ☺ | 03:51 |
| robert_ancell | Yes, I feel dirty | 03:51 |
| * duflu goes to play in the rain, erm lunch | 04:41 | |
| 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:55 |
| duflu | This happens *without* Mir too | 05:56 |
| 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 | 05:58 |
| 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:08 |
| 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:09 |
| duflu | RAOF: On an unrelated note, would intel's double/triple buffering in the DDX affect the generic logic of the xmir module? | 06:13 |
| RAOF | I don't believe so, no; from memory, those codepaths are in the drmmode bits, which we bypass. | 06:14 |
| 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:15 |
| RAOF | What's the IP of s-jenkins? | 06:16 |
| RAOF | That's behind the VPN, right? | 06:16 |
| duflu | Think so | 06:16 |
| duflu | RAOF: Any tips for explorers wishing to dive into XMir's damage tracking? | 06:22 |
| 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:24 |
| 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:25 |
| hikiko | RAOF, should the multimonitor work in the lightdm screen? | 06:42 |
| hikiko | (before we start unity) | 06:43 |
| 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:44 |
| 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:45 |
| hikiko | it shows a vertical purple line | 06:46 |
| hikiko | I ll upload a screenshot in a while | 06:46 |
| 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:52 |
| RAOF | I wonder what it's doing? | 06:53 |
| hikiko | maybe there's something wrong in my system | 06:53 |
| hikiko | how can I check that lightdm uses xmir for sure? | 06:54 |
| RAOF | grep -i xmir /var/log/Xorg.${DISPLAY#:}.log | 06:54 |
| 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:55 |
| 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? | 06:58 |
| dholbach | good morning | 07:00 |
| hikiko | good morning dholbach | 07:00 |
| hikiko | RAOF, ^ I think I use xmir... shall I fill a bug report? | 07:01 |
| 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:02 |
| dholbach | hi hikiko | 07:03 |
| hikiko | so RAOF | 07:03 |
| hikiko | there must be a conf? | 07:03 |
| 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:04 |
| 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:06 |
| hikiko | ok I found what it was: when you upgrade unity-system-compositor with apt-get install there's a question | 07:07 |
| hikiko | install the package maintainer's version / keep your current etc and default == keep current | 07:08 |
| hikiko | let me try again | 07:08 |
| hikiko | fixed :D | 07:09 |
| 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:10 |
| 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:11 |
| hikiko | cool :) | 07:12 |
| hikiko | and RAOF another question (final) | 07:12 |
| hikiko | I want to test xmir for the first time | 07:12 |
| hikiko | I build and run ./mir_demo_server... --enable-xmir and that's all? | 07:13 |
| hikiko | what should I expect to see? | 07:13 |
| 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:16 |
| 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:17 |
| 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:18 |
| duflu | hikiko: Ctrl+Alt+Backspace is how you get out of mir_demo_server_* | 07:24 |
| duflu | Ctrl+C was disabled a while back | 07:25 |
| 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:26 |
| hikiko | oh, I see | 07:27 |
| 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:28 |
| hikiko | found | 07:38 |
| duflu | RAOF: Woo, no time-travelling frames any more | 08:31 |
| 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:32 |
| duflu | tvoss_: XMir seems to be reporting incorrect damage regions | 08:33 |
| tvoss_ | duflu, ah | 08:33 |
| duflu | tvoss_: Still, somehow, affected by XMir's multimonitor logic | 08:34 |
| tvoss_ | duflu, hmmm ... interesting | 08:34 |
| tvoss_ | duflu, go ahead then ;) | 08:34 |
| === dholbach_ is now known as dholbach | ||
| hikiko | is there any way to temporarily disable xmir? | 11:03 |
| === 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 | ||
| 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:26 |
| tvoss_ | smspillaz, no damage region, yet | 14:32 |
| smspillaz | tvoss_: ah okay. What was duflu's comment about damage regions about then? | 14:35 |
| tvoss_ | smspillaz, duflu was talking about the xmir world, so mostly the x <-> mir integration parts over there | 14:36 |
| 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:37 |
| tvoss_ | smspillaz, let me check | 14:38 |
| sil2100 | Hi everyone! | 14:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 |
| kdub | good morning! | 15:02 |
| * kdub is back | 15:02 | |
| racarr | kgunn: Thanks :) | 15:02 |
| alan_g | racarr: welcome back | 15:05 |
| racarr | alan_g: Thanks :) | 15:07 |
| kgunn | kdub: welcome back!! | 15:11 |
| === chihchun is now known as chihchun_afk | ||
| kdub | thanks! | 15:12 |
| 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:14 |
| alan_g | racarr: no dramatic failures | 15:20 |
| 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:21 |
| === om26er is now known as om26e | ||
| === om26e is now known as om26er | ||
| racarr | alan_g: :) Thanks. | 15:57 |
| === michae___ is now known as T0Z | ||
| 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:50 |
| racarr | so if you sent me an email last week and are waiting to hear back | 16:51 |
| racarr | please resend / ping me. | 16:51 |
| 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:33 |
| kgunn | i've got thing around 4pm my time...other than that i'm pretty open | 17:34 |
| racarr | kgunn: Ok how about in 2.5 hours (3 your time?) | 17:35 |
| kgunn | sounds good | 17:35 |
| racarr | Ok. Thanks :) | 17:36 |
| === racarr is now known as racarr|lunch | ||
| racarr|lunch | Back soon! | 17:52 |
| === racarr|lunch is now known as racarr | ||
| racarr | updating my phone image now | 20:23 |
| racarr | excited to see last weeks progress :) | 20:23 |
| kdub | racarr, once you've updated, could you try the acceptance tests? seeing some failures there on the phone | 20:39 |
| 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:43 |
| kdub | yeah, mine died a few times mid-update because it ran out of battery | 20:47 |
| 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 | 20:48 |
| racarr | Phone looks pretty great :) | 21:00 |
| kgunn | racarr: on the phone...you notice the flicker yet ?...i'm wondering if that's z-order fighting | 22:03 |
| kgunn | kdub: ping | 22:13 |
| kdub | kgunn, pong | 22:13 |
| ricmm | racarr: ping | 22:14 |
| kgunn | kdub: hey...so i was trying to do mir logging on android...so i did stop unity8, then exported | 22:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| kdub | kgunn^^ | 22:24 |
| kdub | the name should be... mir.hostname.user.loglevel.timestamp | 22:26 |
| racarr | ricmm: Pong! | 22:27 |
| 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:29 |
| 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:30 |
| kgunn | ricmm: thanks for solving that mystery for me! | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
