[00:26] robert_ancell: If you'd like to test, the ubuntu branch of github.com/RAOF/xserver.git should work for you. [00:26] RAOF, awesome, thanks [00:26] that has packaging right? [00:27] Yup. [00:27] It's a simple "DEB_BUILD_OPTIONS=parallel=9" debuild -i -I -us -uc away! [00:39] tvoss_: Around? [00:56] RAOF: you know he's in asia right? [01:01] kgunn: Yes, which is why he might be around :) [01:07] RAOF, yup [01:07] * robert_ancell ->lunch [01:08] tvoss_: So, I'd like to raise https://code.launchpad.net/~raof/mir/prebump-abi-for-lifecycle-cookie/+merge/184703 and the associated platform-api change http://bazaar.launchpad.net/~raof/platform-api/update-for-lifecycle-cookie/revision/149 again :) [01:09] duflu: Good morning! [01:10] RAOF: Morning; goodish [01:20] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1218815 this bug needs triage. [01:20] Launchpad bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Triaged] [01:23] robotfuel: It is triaged already. What are you aiming for? :) [01:24] having it assigned to someone. [01:24] duflu: [01:24] ^ [01:25] robotfuel: Ah, yes. I think RAOF thinks he knows the answer. Although a proper fix might require enhancements to Mir first [01:25] Yeah, throw it here. [01:27] duflu: if it was medium or high I could see it not being assigned while there are critical bugs. but all critical bugs should have someone assigned to it, even if it's just the project lead. :) [01:27] robotfuel: I disagree. Too often bugs are assigned to people who have other things on their plate. The bug never gets started or taken up by anyone else because it looks like it belongs to someone already [01:29] RAOF: Are you _sure_ you need a scanout flag for that? [01:29] duflu: To do it correctly, yes. [01:30] duflu: That flag doesn't need to be a *guarantee* that it'll be scanned out, but it does need to indicate that this buffer needs to be treated as if it could be scanned out. [01:30] We really need the same for intel, it's just that intel can make a reasonable guess as to whether it might be scanned out or not. Radeon can't. [01:30] RAOF: Yeah. So why/how is the stride info we have wrong? Why wouldn't we just fix that? [01:30] Because it's not stride. [01:30] Umm, pitch [01:31] ? [01:31] It's not pitch, either. It's bound up with how the tiling is arranged. [01:31] Ugh [01:31] Right [01:31] Damn DDXs [01:31] duflu: that's what the in progress flag is for in status, if your team wants to do differently then I am okay with that. [01:32] Radeon *is* a bit of a fan of crazily duplicating code and hoping that everyone's using the same stuff. [01:32] But, as we found, it's the same for Intel - scanout needs to be handled a bit specially. [01:33] RAOF: When I started (and finished) bypass support, I had no idea the DDXen would play with the hardware this much :P [01:33] I thought I knew what a "client" was. But that's not true for XMir [01:34] I suspect we'll need to do similar things in the Mir EGL platform; we might just not have hit the problems yet. [01:36] Less likely. I actually tested it all with EGL on intel + radeon + nouveau [01:59] * RAOF could really do with a working second monitor [02:05] Admittedly, I have never needed two. Just happened to buy one for the old office, and brought it home when I left [02:24] Urgh, wow. This is messed up on radeon. [02:25] But, of course, I can't reproduce the graphical glitches. [02:25] Because that would make things too easy. [02:39] duflu: The environment variable to disable bypass was MIR_BYPASS=0, right? [02:39] RAOF: Yes. Just need to make sure the variable makes it though to the USC process :) [02:40] *through [02:45] Ok, so radeon exhibits damage problems in multihead. [02:46] And also exhibits that "you need to VT switch to get Mir to send new buffers with bypass" problem that we had earlier. [02:57] RAOF: I noticed bypass did make bug 1211700 worse. But the bug itself existed before bypass [02:58] bug 1211700 in Mir "[radeon] [nouveau] Unthrottled EGL clients cause Mir to slow, sometimes to a halt" [High,New] https://launchpad.net/bugs/1211700 [02:58] That wouldn't be exposed by XMir; XMir *is* throttled. [02:58] Well, ish. [02:59] Although XMir is kinda unthrottled, that bug would not be what's affecting XMir, because XMir is idle, waiting in select() when you gdb into it. [03:00] RAOF: I had some ideas on how to relieve the problem a while back. And I have nouveau hardware that reproduces it easily. Just wasn't a priority compared to the other issues [03:00] Yeah. [03:01] Although, to some extent, it's a combination of correct behaviour and insufficient kernel smarts. [03:06] Yeah Maarten started talking about GPU threads and scheduling on the GPU. It's a whole new world [03:08] Basically what we want is a deadline scheduler for the GPU. [03:09] RAOF: Extending MirBufferPackage.... that shouldn't break any ABIs right? [03:10] Correct. [03:10] As far as I can tell. [03:10] We get it by pointer [03:10] which is good [03:10] Because we allocate them ourselves. [03:10] Except that we return the pointer by parameter from a function with returns void. Which is weird [03:10] Yeah, because reasons. [03:11] Actually, why do we have that idiom? [03:12] RAOF: I think it was a mistake which we overlooked at the time. Returning a pointer as the function result would have been slightly nicer [03:12] duflu: RAOF: isn't MirBufferPackage allocated by the client? [03:12] or am I thinking of something else [03:12] smspillaz: Not anymore [03:12] It was [03:12] smspillaz: How? It's returned as "type **x" [03:12] RAOF: does this mean I have to change all my code again ? :( [03:12] smspillaz: It's not changing [03:12] smspillaz: A little bit, yes. [03:13] RAOF: when did this change happen? [03:13] duflu: At one point it was a client-allocated MirBufferPackage * that got passed in. [03:13] Oh [03:13] Umm, then Sam's client code shouldn't build so long as warnings are errors... ? [03:14] MirBufferPackage *surface_buffer; [03:14] mir_surface_get_current_buffer (impl->surface, &surface_buffer); [03:14] looks like I wrote the gtk+ stuff after that change :) [03:14] :) [03:15] Cool [03:24] Yay kernel builtin edids! [03:24] yay! [04:17] RAOF, I can confirm the input works switching between two sessions - just need to get it switched up to VT switching away from all sessions [04:30] robert_ancell: That just requires hooking up in unity-system-compositor, right? [05:00] RAOF, mostly exposing it from Mir [05:00] Right, as expected. [05:36] Oooh. [05:36] Interesting. [05:37] *that's* definitely racy... [05:37] Should be pretty difficult to hit, though? [05:47] ?? [05:48] duflu: Hey, we're always going to be triple buffering, right? [05:48] RAOF: Nope. That's kind of a bug. We will and should switch to double when possible [05:48] At the *moment* we always triple buffer, yes? [05:48] I'm just doing a by-hand verification of my damage tracking logic. [05:49] RAOF: Yes, kind of... If the client is slow enough then SwitchingBundle might only hand out 2 [05:49] RAOF: BTW, I removed all the damage and age tracking and that bug remained. It's not in the damage tracking AFAIK [05:50] duflu: Oh, we get the damage_for_current_buffer *after* we submit the previous buffer. So, in the unlikely event that X gets preempted and the swap completes before the next line we'll clear the damage from the wrong place. [05:52] RAOF: Sounds similar to my first theory. I now forget why I stopped believing it [05:52] Because you removed all the damage tracking and the bug remained? :) [05:52] RAOF: Maybe... [05:53] RAOF: I mean I got rid of age tracking and set the dirty region to the whole xmir_win (or empty) [05:53] Then the bug remains. But if you never allow dirty to be empty then the bug will be hidden [05:54] Right. Because you just continually render [05:55] RAOF: Boo... Mesa requires MirBufferPackage never grows: [05:55] mir_advance_colour_buffer(struct dri2_egl_surface *surf) [05:55] { [05:55] MirBufferPackage buffer_package; [05:55] if(!surf->mir_surf->surface_advance_buffer(surf->mir_surf, &buffer_package)) [05:56] I can work around it I think [05:56] duflu: Oh. Yay for having two distinct APIs for exactly the same thing [05:59] duflu, racarr, kdub, alf_ hikiko - meeting [05:59] kgunn too [05:59] :) === chihchun_afk is now known as chihchun [06:01] it seems i am alone in the hangout :) rejoining [06:01] hikiko, we're there! [06:24] question: :) [06:24] is magic sysrq disabled on kernel? [06:24] hikiko, it works for me [06:24] Good question. It never works for me. But I likely get it wrong [06:24] I use it frequently when the VTs break [06:25] robert_ancell, how did you enable it? in /proc/sysrq? [06:25] for me: hold down alt+PrintScr, then s-u-b [06:25] hikiko, I don't think I've done anything to enable it [06:25] yes, I know but it's a laptop here and sysrq doesnt work so I was wondering if I have to do something:/ [06:26] oh no :D it worked now :D thanks robert_ancell [06:27] hikiko, np [06:27] I was trying with s u g/h :) [06:27] hikiko, you can check in dmesg if any SysReq events have occurred [06:28] bye all [06:29] Ha. Works now :) === duflu_ is now known as duflu [06:29] RAOF: what's the process for getting Mesa updates in the archive? Are they picked up automatically from your github branches? [06:30] \m/ [06:38] alf_: No, I do that manually. === alf_ is now known as alf|xmir_devel [07:06] alf|xmir_devel: ping [07:35] mlankhorst: pong [07:39] alf|xmir_devel: can you help me reproduce the issue? what branches etc do I need [07:50] mlankhorst: follow the instructions from https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html [07:50] mlankhorst: for mesa you can use the https://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment branch [07:50] ok [07:51] mlankhorst: for mir use lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack as noted in the mail, I have updated it remove the stray dup() [07:52] mlankhorst: the mesa branch contains the i965 changes which you may want to remove or change, and also in platform_mir.c don't forget to set USE_DUP and USE_PRIME to the values you want [07:54] alf|xmir_devel: oh using drm bus id is a bad idea, best to open dev directly, but unrelated to your issue :P [08:09] RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=60182 with fix it seems :p [08:09] Freedesktop bug 60182 in DRM/Radeon "X.Org Server terminate when I close video player" [Critical,New] [08:15] alf|xmir_devel: oh btw test seems to fail when I try building mir there.. [08:16] The following tests FAILED: [08:16] 10 - acceptance-tests.TestNestedMir.* (Failed) [08:16] 55 - unit-tests.GBMGraphicBufferBasic.* (Failed) [08:16] mlankhorst: yes, don't worry, it's because I have updated/hacked the code without updating the tests [08:16] ok [08:22] alf|xmir_devel: @"mlankhorst: I actually see a dup() in NestedMir... I will get rid of this and check what is going on" - the frontend code closes FDs after sending them to the client to avoid resource leaks. [08:23] alan_g: then why is that dup needed at all? [08:24] alan_g: right, the point is that we should be opening a new drm fd instance, not duping the drm fd we use in the platform [08:24] pretty much [08:24] alan_g: I have hacked a fix in lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack for testing purposes, but we need to find a better way to do it. [08:26] alf|xmir_devel: Shall I leave you to it? Or get involved? [08:30] alan_g: If you can take a look at the latest commit in lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack, and come up with a better design for it, it would be great. Right now I am passing an auth_magic std::function to NativePlatform::initialize which is platform-specific in the sense that it is only needed on GBM. [08:33] alan_g: (but it is not urgent, we first need to solve the egl image problem before any of this is usable on trunk) [08:33] ok I've merged the branch against 9.2 and built the packages :P [08:35] alf|xmir_devel: OK, I was going to look at tidying some of the "nested" code that has landed, and then look at the differences between what kdub landed on trunk for android and what we had on the gbm spike. [08:35] This fits into the latter category [08:35] alan_g: sounds good === alf|xmir_devel is now known as alf|probable_pow === alf|probable_pow is now known as alf|power_outage [08:37] * alan_g wonders: "Prisoner Of War" [08:43] compositor wars... [08:51] alf|power_outage: fwiw, nested mir works for me on nouveau, I'll try on intel.. [09:02] ok crash, weeeee [09:06] question: [09:06] 131 [ 473.381] (==) Depth 24 pixmap format is 32 bpp [09:06] 132 [ 474.356] (==) FBDEV(0): Backing store disabled [09:06] 133 [ 474.358] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument [09:06] I get this failsafe log [09:06] when xmir crashes [09:08] and i wonder if someone knows what it means (I find different explanations here and there) + I am trying to understand if this caused the crash or it is a result of the crash or irrelevant [09:14] hikiko: That'd just be the failsafe X log. That gets started if X crashes on startup for some reason. [09:14] so, it's totally irrelevant [09:14] isn't it? [09:15] Yeah. [09:15] hikiko: fbdev is the fallback driver of last resort. It does not support Mir (yet) and means the real driver failed to start USC [09:15] cool :) [09:15] That'll only happen *after* you crash the original X :) [09:15] So long as fbdev isn't crashing too [09:15] it isnt [09:17] and another question: sometimes I restart lightdm and instead of starting X with xmir it starts X [09:17] if I restart many times [09:19] and I have no clue why I dont get a crash at that point [09:19] hikiko: In theory, X is meant to start in legacy mode *every time* Mir (unity-system-compositor) fails to start [09:19] if I just run restart lightdm too many times at somepoint X starts instead of X -mir [09:20] oh [09:20] hikiko: We always (1) Try Mir and if that fails (2) Start legacy X [09:20] If (2) fails then that's a new bug [09:20] but if 2 fails then [09:20] we start Mir or X? [09:21] hikiko: If (2) fails then that's a new bug no one has logged yet. Sounds important :) [09:21] what happens is: [09:21] (in some cases) [09:21] I run restart lightdm many times and mir restarts ok with no crash [09:22] at some point I restart and X starts [09:22] (no crash) [09:22] and then if I restart lightdm [09:22] Mir will start and crash [09:23] hikiko: If Mir crashes then look in /var/log/lightdm/unity-system-compositor.log for the cause. Hopefully it's a bug we already know about [09:23] ok :) [09:24] thanks duflu RAOF [09:24] No problem [09:42] alf|power_outage: does the nested mir server only use a single drm fd? [09:47] screw it, I'm going to make the kernel tell me why ENOENT happens [09:50] [ 105.467925] [drm] unknown target object for relocation 7 [09:51] 2: 2 (batchbuffer)@0x000000e0 -> 7 (region)@0x00000000 + 0x00000000 [09:52] odd [09:53] which is from intelAllocateBuffer [09:53] mlankhorst: the nested mir uses a drm fd for two things: to init gbm and to send to clients that init gbm. I got the second from the first using dup() because FD sent to clients get closed automatically), but IIUC alf|power_outage changed that... [09:54] ====== Created gbm_bo 0x7f2e340026f0 0x7f2e340026f0 with image 0x7f2e34002740 handle: 7 screen: 0x72d390 ====== [09:54] which no longer exists, it seems.. [09:54] alan_g: yes, and each client needs their own instance of the drm fd [09:54] else really really bad things(TM) will happen [09:55] * alan_g already knows he got it wrong [09:58] alan_g: the question is.. does non-nested mir share its own drm fd too? [09:59] mlankhorst: no, it uses drmOpen() [10:00] ok good.. still things are messing up somewhere :P [10:02] mlankhorst: if it helps the host mir uses int mggh::DRMHelper::get_authenticated_fd() to get the FD it passes out. (I've not yet looked at alf|power_outage nested code) [10:06] hm in this case it seem likely isolated to the nested server only now for sure [10:06] alan_g: it's almost the same code, with the difference that we need to ask the host mir server to auth the magic cookie (since the nested mir is non DRM master) [10:06] mlankhorst: ^^ === alf|power_outage is now known as alf_ [10:08] * duflu goes to create some culinary splendour [10:11] * alan_g goes to make some tea [10:11] * RAOF decides that his manual review of the XMir damage logic suggests that it's sound, and EODs. [10:17] alf_: my only conclusion is that nested mir and master mir share the drm fd.. [10:18] and I'm damned sure that's the case [10:19] see http://paste.debian.net/38295/ [10:19] Linux kernel complains relocation target 7 no longer exists.. [10:21] oh no, in this case it was 6 [10:21] hm damn wtf is going on :P [10:22] mlankhorst: that is what I have been wondering for a few days now :) [10:30] ok so intel does enable bo re-use.. [10:31] meh lets kill that off first [10:34] oh i see [10:34] probably intel bug.. [10:34] ====== platform_mir: dri2 swap buffers: before flush ====== [10:34] 0: 8 (prime) [10:34] 1: 9 (vb) [10:34] 2: 2 (batchbuffer)@0x00000010 -> 8 (prime)@0x00000000 + 0x00000000 [10:34] 2: 2 (batchbuffer)@0x00000094 -> 8 (prime)@0x00000000 + 0x00000000 [10:34] 2: 2 (batchbuffer)@0x000000e0 -> 6 (region)@0x00000000 + 0x00000000 [10:35] 2: 2 (batchbuffer)@0x00000174 -> 9 (vb)@0x00000000 + 0x00000000 [10:35] there is a relocation for 6, but that bo is not mentioned on the validation list [10:35] it's still a valid bo, afaict [10:39] so now to figure out why relocation is failing like that :P === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [11:22] alf_: ah, intel has an internal cache that gets re-used for flink.. [11:36] alf_: what's the state of the art branch for nested/gbm? [11:36] lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack? [11:37] alan_g: ~afrantzis/mir/spike-nested-gbm-egl-image-hack yes [11:39] alf_: OK to top-approve lp:~alan-griffiths/mir/cleanup-NativeAndroidPlatform? [11:40] alan_g: I am OK, although I haven't tested it on an Android device, but it seems harmless. === alf_ is now known as alf|xmir-devel === alan_g is now known as alan_g|lunch [12:01] alf|xmir-devel: definitely some memory corruption going on, no idea what exactly though === hikiko is now known as hikiko|lunch === chihchun is now known as chihchun_afk === alan_g|lunch is now known as alan_g [12:46] huh wtf [12:51] mlankhorst: ? [12:55] alf|xmir-devel: hitting some very weird bug, it's probably in intel but I don't see why it's doing whatever it is it's doing.. [13:00] oh finally some sense.. [13:01] (gdb) print bo->bufmgr [13:01] $6 = (drm_intel_bufmgr *) 0x6580d0 [13:01] (gdb) print bo->bufmgr [13:01] $5 = (drm_intel_bufmgr *) 0x636280 [13:01] why are there 2 drm_intel_bufmgrs ? [13:03] seriously.. [13:07] gbm can create a screen, egl probably creates a separate screen or something [13:08] #7 0x00007ffff3d821be in gbm_create_device (fd=16) at ../../../../src/gbm/main/gbm.c:156 [13:08] #8 0x00007ffff61d3dea in eglInitialize (dpy=0x64e3b0, major=0x7fffffffe1f8, minor=0x7fffffffe1fc) at ../../../../../src/egl/main/eglapi.c:317 [13:08] so eglInitialize and gbm_create_device [13:15] mlankhorst: perhaps that's why dupImage doesn't work at all, and we need to create a new image for the Mir EGL screen (USE_DUP=0)? [13:16] alf|xmir-devel: no you really need to get rid of the separate copy [13:16] RAOF wrote the code, he may know how to do that.. [13:17] mlankhorst: which code? [13:18] the 'screen' comes from mir [13:19] but you're creating the gbm without any knowledge of it [13:20] mlankhorst: I guess we could go the other way too, as I think platform_drm does... use the dri2 info from GBM to set up the EGL dri2. [13:20] that's the thing you should do [13:20] does that kill off the platform_mir by any chance? :P [13:22] probably not, but in any case mir probably needs to know about the gbm screen and use it [13:22] mlankhorst: no, we have our own native display and window types [13:23] specifically [13:23] if (!dri2_create_screen(disp)) [13:23] goto cleanup_dpy; [13:23] that line is wrong === hikiko|lunch is now known as hikiko [13:24] please don't make such hard to debug problems in the future [13:24] :P [13:27] (and I checked git blame, so I know it was you) [13:28] mlankhorst: I need to talk to RAOF tomorrow, to see how we can move ahead with this, since I think that it involves some significant changes in platform mir and the information we pass to platform mir from mir (right now it is just the drm fd) [13:28] sure [13:29] and you're welcome, please try to give me easier problems next time ;) [13:29] mlankhorst: thank you :) I really appreciate your time and effort! [13:31] after that dupimage will work correctly and flink vs w/e doesn't matter [13:32] is there anything else using gbm? :P [13:34] mlankhorst: the display subsystem is using gbm internally, but that's using platform_drm so no problems there [13:34] mlankhorst: (in host mir) [13:37] alf|xmir-devel: it sounds like you understand the problem (if not the solution)? [13:38] well there were 2 problems, but seems so :p [13:40] other problem was sharing drm fd [13:50] mlankhorst: \o/ [13:53] kgunn: hi! [13:53] kgunn: we have a critical bug in Mir related to intel (most probably) - could you guys take a look at that and check if it's indeed a Mir issue? Or maybe something wrong with the intel driver? [13:53] kgunn: https://bugs.launchpad.net/mir/+bug/1223889 [13:53] Launchpad bug 1223889 in Mir "Mir crashing on Intel drivers - memory corruption in /usr/bin/X" [Critical,New] [13:54] * kgunn looks === chihchun_afk is now known as chihchun [13:55] kgunn: if you need some more logs besides lightdm.log, x.log and unity-system-compositor.log then this is the last chance ;p Since I need to restart the container, as it's dead [13:55] sil2100: go ahead [13:56] sil2100: so this is effectively the ppa from daily-build ?? [13:56] just curious how we potentially bisect === dandrader is now known as dandrader|afk [13:57] ....and ironically mlankhorst was working on intel mem corruption a moment ago....same thing ? [13:57] kgunn: yes, this is using the current daily-build PPA contents, at least for the mir parts [13:57] kgunn: only affected nesting [13:57] afaik xorg-server doesn't use gbm [13:57] mlankhorst: was worth a hope :) [13:58] alf|xmir-devel: ...i don't want wreck your train of thot, but could you take a closer look at https://bugs.launchpad.net/mir/+bug/1223889 [13:58] Launchpad bug 1223889 in Mir "Mir crashing on Intel drivers - memory corruption in /usr/bin/X" [Critical,New] [13:59] since RAOF & duflu are sleeping [13:59] sil2100: i assume this means usc/mir/xmir are held up [14:00] alan_g: mlankhorst: yes (more or less), but I am not clear of the details of the solution yet... it is complicated because we need to pass to the "client" version of EGL platform mir information that only a server has (e.g. gbm_device*) [14:00] kgunn: well, yes, and it's also a bit inconvinient as because it causes an X crash, it breaks our intel machine, so it blocks up the whole release queue - since the broken, X-less intel machine is hanged until timeout or until someone notices to abort manually... [14:01] alf|xmir-devel: not really.. server doesn't need egl platform mir. Only nested client does. :P [14:01] kgunn: so essentially this problem breaks and slightly blocks all other packages, because it's breaking our test architecture [14:02] sil2100: is there a simple way to roll back the ppa to be based on the "previous" version of u-s-c/mir/xserver-xorg-video-intel that was working for you [14:02] mlankhorst: that's what I mean, a client (nested mir) needs to pass information to Mesa that is server related (gbm_device*) [14:03] mlankhorst: remember we are doing server buffer allocation [14:04] kgunn: sadly not really... we would have to know what revision caused the failure, revert, rebuilt etc. - worse if the intel upload causes the problems [14:08] kgunn, didrocks: if you don't mind, I'll skip mirslave release this tick [14:09] kgunn, didrocks: we know it's broken and at least it won't break all other stacks :) We can run it later [14:10] sil2100: so you're saying that standalone X intel is fine with this xserver-xorg-video-intel...right ? [14:11] kgunn: yes, it's only happening when mir is used apparently [14:11] Would have to see locally on my machine if the crash is happening, but there's so many things pending... [14:11] sil2100: just for bisecting...we know that yesterday, had no problems....and this morning...we have problems right ? [14:12] meaning...we must have pushed something in xmir/mir/xserver-xorg-video-intel w/in last 24 hours that caused this [14:12] kgunn: let me check that, since we had some 'other' problems yesterday, but I'll check - from what I know it only happened today [14:13] sil2100: that would be really helpful to know....when the last good combo was [14:14] kgunn: bad news is... we didn't have a successful run yesterday as well, but not because of an X crash [14:15] kgunn: we DNS-resolve problems, so no release happened [14:15] ok but maybe last friday was ok? [14:15] sil2100: ^ [14:15] kgunn: the last successful run was on the 6th, then the infra errors started happening [14:16] kgunn: yes, it seems we didn't have a successful run since libmirclient3 was introduced ;p [14:16] I mean, just today seems to be the first time the tests are actually ran [14:17] sil2100: hmmm....could be [14:17] but the build order took care of that sort of thing i thot === dandrader|afk is now known as dandrader [14:22] kgunn: please just valgrind ;P [14:22] it's there for a reason! :D [14:22] make /etc/X11/X2 with these contents: #!/bin/bash [14:23] exec /usr/bin/valgrind --show-reachable=yes --track-fds=yes --leak-check=full --error-limit=no --freelist-vol=500000000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -core -verbose 10 &>>/var/log/valgrind.log [14:26] and install xserver.*dbg [14:27] symlink /etc/X11/X to it, /etc/X11/X must stay a symlink :p [14:29] kgunn: I will try to reproduce/investigate a bit later [14:31] alf|xmir-devel: i assume you understand 'how to' what mlankhorst just said :) [14:39] Morning! [14:41] mornin' === alan_g is now known as alan_g|tea === 3JTAAEL6B is now known as tvoss [14:48] hey guys :) === jono is now known as Guest91193 [14:51] sil2100: ack [14:53] hey tvoss :) [14:53] racarr, o/ [14:56] tvoss: Will you be in Lexington? [14:56] racarr, nope, unfortunately not :/ [14:58] Aww [14:58] racarr: ping [14:58] racarr: how are we doing with the DPMS-android stuff [14:58] is there an API in place in Mir yet or not? if not, I'll need some of your aid to reach the hwcomposer hal directly from powerd [14:58] :) [14:59] ricmm, kdub might be able to help, too [14:59] right just wondering as we had this discussion last week and there was a quick testing that was gonna happen [14:59] so, if it hasnt happened then I'll make the call of doing direct powerd->hal access for the screen control [15:00] until theres a problem the_shell_display_power_controller() or whatever under android, heh [15:00] an interface, not a problem, sorry [15:00] ricmm: Pong! [15:00] ricmm: There is an API in place [15:00] racarr: awesome [15:00] which one is it? got a landing rev? sorry [15:00] ricmm: Part of the display configuration API [15:00] no worries! lemme find it [15:01] also standup? No one else is there [15:01] darn that one is complicated [15:01] i am racarr [15:01] but i see nobody else :p [15:01] let me relogin again === alan_g|tea is now known as alan_g [15:01] 1054 [15:01] racarr, still alone :) [15:01] I see no-one too [15:02] i see alan [15:02] I see kgunn [15:02] ricmm: 1054 [15:02] ricmm: The impl isn't landed due to a series of issues with doing it over IPC [15:02] racarr, we are all at the same hangout! [15:02] s/landed/proposed [15:02] hikiko: Can you give me the link? [15:02] yea thats what im just seeing [15:02] CAlendar link isn't working for me [15:02] if theres no impl then I cannot use it [15:03] racarr: can you point me to the HAL interface you were planning to use? [15:03] ricmm: hwcomposer.h blank/unblank [15:03] ricmm: It all works actually for android, I can propose the android impl asap [15:04] gbm is the one thats broken? [15:04] well to be fair I might do the direct powerd access as theres no short-term plan for the shell policy enacter [15:04] so it will still have to be powerd [15:05]