| RAOF | robert_ancell: If you'd like to test, the ubuntu branch of github.com/RAOF/xserver.git should work for you. | 00:26 |
|---|---|---|
| robert_ancell | RAOF, awesome, thanks | 00:26 |
| robert_ancell | that has packaging right? | 00:26 |
| RAOF | Yup. | 00:27 |
| RAOF | It's a simple "DEB_BUILD_OPTIONS=parallel=9" debuild -i -I -us -uc away! | 00:27 |
| RAOF | tvoss_: Around? | 00:39 |
| kgunn | RAOF: you know he's in asia right? | 00:56 |
| RAOF | kgunn: Yes, which is why he might be around :) | 01:01 |
| tvoss_ | RAOF, yup | 01:07 |
| * robert_ancell ->lunch | 01:07 | |
| RAOF | 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:08 |
| RAOF | duflu: Good morning! | 01:09 |
| duflu | RAOF: Morning; goodish | 01:10 |
| robotfuel | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1218815 this bug needs triage. | 01:20 |
| ubot5 | Launchpad bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Triaged] | 01:20 |
| duflu | robotfuel: It is triaged already. What are you aiming for? :) | 01:23 |
| robotfuel | having it assigned to someone. | 01:24 |
| robotfuel | duflu: | 01:24 |
| robotfuel | ^ | 01:24 |
| duflu | robotfuel: Ah, yes. I think RAOF thinks he knows the answer. Although a proper fix might require enhancements to Mir first | 01:25 |
| RAOF | Yeah, throw it here. | 01:25 |
| robotfuel | 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 |
| duflu | 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:27 |
| duflu | RAOF: Are you _sure_ you need a scanout flag for that? | 01:29 |
| RAOF | duflu: To do it correctly, yes. | 01:29 |
| RAOF | 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 |
| RAOF | 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 |
| duflu | RAOF: Yeah. So why/how is the stride info we have wrong? Why wouldn't we just fix that? | 01:30 |
| RAOF | Because it's not stride. | 01:30 |
| duflu | Umm, pitch | 01:30 |
| duflu | ? | 01:31 |
| RAOF | It's not pitch, either. It's bound up with how the tiling is arranged. | 01:31 |
| duflu | Ugh | 01:31 |
| RAOF | Right | 01:31 |
| duflu | Damn DDXs | 01:31 |
| robotfuel | 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:31 |
| RAOF | Radeon *is* a bit of a fan of crazily duplicating code and hoping that everyone's using the same stuff. | 01:32 |
| RAOF | But, as we found, it's the same for Intel - scanout needs to be handled a bit specially. | 01:32 |
| duflu | RAOF: When I started (and finished) bypass support, I had no idea the DDXen would play with the hardware this much :P | 01:33 |
| duflu | I thought I knew what a "client" was. But that's not true for XMir | 01:33 |
| RAOF | I suspect we'll need to do similar things in the Mir EGL platform; we might just not have hit the problems yet. | 01:34 |
| duflu | Less likely. I actually tested it all with EGL on intel + radeon + nouveau | 01:36 |
| * RAOF could really do with a working second monitor | 01:59 | |
| duflu | Admittedly, I have never needed two. Just happened to buy one for the old office, and brought it home when I left | 02:05 |
| RAOF | Urgh, wow. This is messed up on radeon. | 02:24 |
| RAOF | But, of course, I can't reproduce the graphical glitches. | 02:25 |
| RAOF | Because that would make things too easy. | 02:25 |
| RAOF | duflu: The environment variable to disable bypass was MIR_BYPASS=0, right? | 02:39 |
| duflu | RAOF: Yes. Just need to make sure the variable makes it though to the USC process :) | 02:39 |
| duflu | *through | 02:40 |
| RAOF | Ok, so radeon exhibits damage problems in multihead. | 02:45 |
| RAOF | And also exhibits that "you need to VT switch to get Mir to send new buffers with bypass" problem that we had earlier. | 02:46 |
| duflu | RAOF: I noticed bypass did make bug 1211700 worse. But the bug itself existed before bypass | 02:57 |
| ubot5 | 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 |
| RAOF | That wouldn't be exposed by XMir; XMir *is* throttled. | 02:58 |
| RAOF | Well, ish. | 02:58 |
| RAOF | 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. | 02:59 |
| duflu | 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 |
| RAOF | Yeah. | 03:00 |
| RAOF | Although, to some extent, it's a combination of correct behaviour and insufficient kernel smarts. | 03:01 |
| duflu | Yeah Maarten started talking about GPU threads and scheduling on the GPU. It's a whole new world | 03:06 |
| RAOF | Basically what we want is a deadline scheduler for the GPU. | 03:08 |
| duflu | RAOF: Extending MirBufferPackage.... that shouldn't break any ABIs right? | 03:09 |
| RAOF | Correct. | 03:10 |
| RAOF | As far as I can tell. | 03:10 |
| duflu | We get it by pointer | 03:10 |
| duflu | which is good | 03:10 |
| RAOF | Because we allocate them ourselves. | 03:10 |
| duflu | Except that we return the pointer by parameter from a function with returns void. Which is weird | 03:10 |
| RAOF | Yeah, because reasons. | 03:10 |
| RAOF | Actually, why do we have that idiom? | 03:11 |
| duflu | 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 |
| smspillaz | duflu: RAOF: isn't MirBufferPackage allocated by the client? | 03:12 |
| smspillaz | or am I thinking of something else | 03:12 |
| RAOF | smspillaz: Not anymore | 03:12 |
| RAOF | It was | 03:12 |
| duflu | smspillaz: How? It's returned as "type **x" | 03:12 |
| smspillaz | RAOF: does this mean I have to change all my code again ? :( | 03:12 |
| duflu | smspillaz: It's not changing | 03:12 |
| RAOF | smspillaz: A little bit, yes. | 03:12 |
| smspillaz | RAOF: when did this change happen? | 03:13 |
| RAOF | duflu: At one point it was a client-allocated MirBufferPackage * that got passed in. | 03:13 |
| duflu | Oh | 03:13 |
| duflu | Umm, then Sam's client code shouldn't build so long as warnings are errors... ? | 03:13 |
| smspillaz | MirBufferPackage *surface_buffer; | 03:14 |
| smspillaz | mir_surface_get_current_buffer (impl->surface, &surface_buffer); | 03:14 |
| smspillaz | looks like I wrote the gtk+ stuff after that change :) | 03:14 |
| RAOF | :) | 03:14 |
| duflu | Cool | 03:15 |
| RAOF | Yay kernel builtin edids! | 03:24 |
| jrr | yay! | 03:24 |
| robert_ancell | 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:17 |
| RAOF | robert_ancell: That just requires hooking up in unity-system-compositor, right? | 04:30 |
| robert_ancell | RAOF, mostly exposing it from Mir | 05:00 |
| RAOF | Right, as expected. | 05:00 |
| RAOF | Oooh. | 05:36 |
| RAOF | Interesting. | 05:36 |
| RAOF | *that's* definitely racy... | 05:37 |
| RAOF | Should be pretty difficult to hit, though? | 05:37 |
| duflu | ?? | 05:47 |
| RAOF | duflu: Hey, we're always going to be triple buffering, right? | 05:48 |
| duflu | RAOF: Nope. That's kind of a bug. We will and should switch to double when possible | 05:48 |
| RAOF | At the *moment* we always triple buffer, yes? | 05:48 |
| RAOF | I'm just doing a by-hand verification of my damage tracking logic. | 05:48 |
| duflu | RAOF: Yes, kind of... If the client is slow enough then SwitchingBundle might only hand out 2 | 05:49 |
| duflu | RAOF: BTW, I removed all the damage and age tracking and that bug remained. It's not in the damage tracking AFAIK | 05:49 |
| RAOF | 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:50 |
| duflu | RAOF: Sounds similar to my first theory. I now forget why I stopped believing it | 05:52 |
| RAOF | Because you removed all the damage tracking and the bug remained? :) | 05:52 |
| duflu | RAOF: Maybe... | 05:52 |
| duflu | RAOF: I mean I got rid of age tracking and set the dirty region to the whole xmir_win (or empty) | 05:53 |
| duflu | Then the bug remains. But if you never allow dirty to be empty then the bug will be hidden | 05:53 |
| RAOF | Right. Because you just continually render | 05:54 |
| duflu | RAOF: Boo... Mesa requires MirBufferPackage never grows: | 05:55 |
| duflu | mir_advance_colour_buffer(struct dri2_egl_surface *surf) | 05:55 |
| duflu | { | 05:55 |
| duflu | MirBufferPackage buffer_package; | 05:55 |
| duflu | if(!surf->mir_surf->surface_advance_buffer(surf->mir_surf, &buffer_package)) | 05:55 |
| duflu | I can work around it I think | 05:56 |
| RAOF | duflu: Oh. Yay for having two distinct APIs for exactly the same thing | 05:56 |
| robert_ancell | duflu, racarr, kdub, alf_ hikiko - meeting | 05:59 |
| robert_ancell | kgunn too | 05:59 |
| kgunn | :) | 05:59 |
| === chihchun_afk is now known as chihchun | ||
| hikiko | it seems i am alone in the hangout :) rejoining | 06:01 |
| robert_ancell | hikiko, we're there! | 06:01 |
| hikiko | question: :) | 06:24 |
| hikiko | is magic sysrq disabled on kernel? | 06:24 |
| robert_ancell | hikiko, it works for me | 06:24 |
| duflu | Good question. It never works for me. But I likely get it wrong | 06:24 |
| robert_ancell | I use it frequently when the VTs break | 06:24 |
| hikiko | robert_ancell, how did you enable it? in /proc/sysrq? | 06:25 |
| robert_ancell | for me: hold down alt+PrintScr, then s-u-b | 06:25 |
| robert_ancell | hikiko, I don't think I've done anything to enable it | 06:25 |
| hikiko | yes, I know but it's a laptop here and sysrq doesnt work so I was wondering if I have to do something:/ | 06:25 |
| hikiko | oh no :D it worked now :D thanks robert_ancell | 06:26 |
| robert_ancell | hikiko, np | 06:27 |
| hikiko | I was trying with s u g/h :) | 06:27 |
| robert_ancell | hikiko, you can check in dmesg if any SysReq events have occurred | 06:27 |
| robert_ancell | bye all | 06:28 |
| duflu_ | Ha. Works now :) | 06:29 |
| === duflu_ is now known as duflu | ||
| alf_ | RAOF: what's the process for getting Mesa updates in the archive? Are they picked up automatically from your github branches? | 06:29 |
| hikiko | \m/ | 06:30 |
| RAOF | alf_: No, I do that manually. | 06:38 |
| === alf_ is now known as alf|xmir_devel | ||
| mlankhorst | alf|xmir_devel: ping | 07:06 |
| alf|xmir_devel | mlankhorst: pong | 07:35 |
| mlankhorst | alf|xmir_devel: can you help me reproduce the issue? what branches etc do I need | 07:39 |
| alf|xmir_devel | mlankhorst: follow the instructions from https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html | 07:50 |
| alf|xmir_devel | mlankhorst: for mesa you can use the https://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment branch | 07:50 |
| mlankhorst | ok | 07:50 |
| alf|xmir_devel | 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:51 |
| alf|xmir_devel | 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:52 |
| mlankhorst | alf|xmir_devel: oh using drm bus id is a bad idea, best to open dev directly, but unrelated to your issue :P | 07:54 |
| mlankhorst | RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=60182 with fix it seems :p | 08:09 |
| ubot5 | Freedesktop bug 60182 in DRM/Radeon "X.Org Server terminate when I close video player" [Critical,New] | 08:09 |
| mlankhorst | alf|xmir_devel: oh btw test seems to fail when I try building mir there.. | 08:15 |
| mlankhorst | The following tests FAILED: | 08:16 |
| mlankhorst | 10 - acceptance-tests.TestNestedMir.* (Failed) | 08:16 |
| mlankhorst | 55 - unit-tests.GBMGraphicBufferBasic.* (Failed) | 08:16 |
| alf|xmir_devel | mlankhorst: yes, don't worry, it's because I have updated/hacked the code without updating the tests | 08:16 |
| mlankhorst | ok | 08:16 |
| alan_g | 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:22 |
| mlankhorst | alan_g: then why is that dup needed at all? | 08:23 |
| alf|xmir_devel | 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 |
| mlankhorst | pretty much | 08:24 |
| alf|xmir_devel | 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:24 |
| alan_g | alf|xmir_devel: Shall I leave you to it? Or get involved? | 08:26 |
| alf|xmir_devel | 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:30 |
| alf|xmir_devel | 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 |
| mlankhorst | ok I've merged the branch against 9.2 and built the packages :P | 08:33 |
| alan_g | 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 |
| alan_g | This fits into the latter category | 08:35 |
| alf|xmir_devel | alan_g: sounds good | 08:35 |
| === alf|xmir_devel is now known as alf|probable_pow | ||
| === alf|probable_pow is now known as alf|power_outage | ||
| * alan_g wonders: "Prisoner Of War" | 08:37 | |
| olli | compositor wars... | 08:43 |
| mlankhorst | alf|power_outage: fwiw, nested mir works for me on nouveau, I'll try on intel.. | 08:51 |
| mlankhorst | ok crash, weeeee | 09:02 |
| hikiko | question: | 09:06 |
| hikiko | 131 [ 473.381] (==) Depth 24 pixmap format is 32 bpp | 09:06 |
| hikiko | 132 [ 474.356] (==) FBDEV(0): Backing store disabled | 09:06 |
| hikiko | 133 [ 474.358] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument | 09:06 |
| hikiko | I get this failsafe log | 09:06 |
| hikiko | when xmir crashes | 09:06 |
| hikiko | 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:08 |
| RAOF | hikiko: That'd just be the failsafe X log. That gets started if X crashes on startup for some reason. | 09:14 |
| hikiko | so, it's totally irrelevant | 09:14 |
| hikiko | isn't it? | 09:14 |
| RAOF | Yeah. | 09:15 |
| duflu | 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 |
| hikiko | cool :) | 09:15 |
| RAOF | That'll only happen *after* you crash the original X :) | 09:15 |
| duflu | So long as fbdev isn't crashing too | 09:15 |
| hikiko | it isnt | 09:15 |
| hikiko | and another question: sometimes I restart lightdm and instead of starting X with xmir it starts X | 09:17 |
| hikiko | if I restart many times | 09:17 |
| hikiko | and I have no clue why I dont get a crash at that point | 09:19 |
| duflu | hikiko: In theory, X is meant to start in legacy mode *every time* Mir (unity-system-compositor) fails to start | 09:19 |
| hikiko | if I just run restart lightdm too many times at somepoint X starts instead of X -mir | 09:19 |
| hikiko | oh | 09:20 |
| duflu | hikiko: We always (1) Try Mir and if that fails (2) Start legacy X | 09:20 |
| duflu | If (2) fails then that's a new bug | 09:20 |
| hikiko | but if 2 fails then | 09:20 |
| hikiko | we start Mir or X? | 09:20 |
| duflu | hikiko: If (2) fails then that's a new bug no one has logged yet. Sounds important :) | 09:21 |
| hikiko | what happens is: | 09:21 |
| hikiko | (in some cases) | 09:21 |
| hikiko | I run restart lightdm many times and mir restarts ok with no crash | 09:21 |
| hikiko | at some point I restart and X starts | 09:22 |
| hikiko | (no crash) | 09:22 |
| hikiko | and then if I restart lightdm | 09:22 |
| hikiko | Mir will start and crash | 09:22 |
| duflu | 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 |
| hikiko | ok :) | 09:23 |
| hikiko | thanks duflu RAOF | 09:24 |
| duflu | No problem | 09:24 |
| mlankhorst | alf|power_outage: does the nested mir server only use a single drm fd? | 09:42 |
| mlankhorst | screw it, I'm going to make the kernel tell me why ENOENT happens | 09:47 |
| mlankhorst | [ 105.467925] [drm] unknown target object for relocation 7 | 09:50 |
| mlankhorst | 2: 2 (batchbuffer)@0x000000e0 -> 7 (region)@0x00000000 + 0x00000000 | 09:51 |
| mlankhorst | odd | 09:52 |
| mlankhorst | which is from intelAllocateBuffer | 09:53 |
| alan_g | 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:53 |
| mlankhorst | ====== Created gbm_bo 0x7f2e340026f0 0x7f2e340026f0 with image 0x7f2e34002740 handle: 7 screen: 0x72d390 ====== | 09:54 |
| mlankhorst | which no longer exists, it seems.. | 09:54 |
| mlankhorst | alan_g: yes, and each client needs their own instance of the drm fd | 09:54 |
| mlankhorst | else really really bad things(TM) will happen | 09:54 |
| * alan_g already knows he got it wrong | 09:55 | |
| mlankhorst | alan_g: the question is.. does non-nested mir share its own drm fd too? | 09:58 |
| alan_g | mlankhorst: no, it uses drmOpen() | 09:59 |
| mlankhorst | ok good.. still things are messing up somewhere :P | 10:00 |
| alan_g | 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:02 |
| mlankhorst | hm in this case it seem likely isolated to the nested server only now for sure | 10:06 |
| alf|power_outage | 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 |
| alf|power_outage | mlankhorst: ^^ | 10:06 |
| === alf|power_outage is now known as alf_ | ||
| * duflu goes to create some culinary splendour | 10:08 | |
| * 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:11 | |
| mlankhorst | alf_: my only conclusion is that nested mir and master mir share the drm fd.. | 10:17 |
| mlankhorst | and I'm damned sure that's the case | 10:18 |
| mlankhorst | see http://paste.debian.net/38295/ | 10:19 |
| mlankhorst | Linux kernel complains relocation target 7 no longer exists.. | 10:19 |
| mlankhorst | oh no, in this case it was 6 | 10:21 |
| mlankhorst | hm damn wtf is going on :P | 10:21 |
| alf_ | mlankhorst: that is what I have been wondering for a few days now :) | 10:22 |
| mlankhorst | ok so intel does enable bo re-use.. | 10:30 |
| mlankhorst | meh lets kill that off first | 10:31 |
| mlankhorst | oh i see | 10:34 |
| mlankhorst | probably intel bug.. | 10:34 |
| mlankhorst | ====== platform_mir: dri2 swap buffers: before flush ====== | 10:34 |
| mlankhorst | 0: 8 (prime) | 10:34 |
| mlankhorst | 1: 9 (vb) | 10:34 |
| mlankhorst | 2: 2 (batchbuffer)@0x00000010 -> 8 (prime)@0x00000000 + 0x00000000 | 10:34 |
| mlankhorst | 2: 2 (batchbuffer)@0x00000094 -> 8 (prime)@0x00000000 + 0x00000000 | 10:34 |
| mlankhorst | 2: 2 (batchbuffer)@0x000000e0 -> 6 (region)@0x00000000 + 0x00000000 | 10:34 |
| mlankhorst | 2: 2 (batchbuffer)@0x00000174 -> 9 (vb)@0x00000000 + 0x00000000 | 10:35 |
| mlankhorst | there is a relocation for 6, but that bo is not mentioned on the validation list | 10:35 |
| mlankhorst | it's still a valid bo, afaict | 10:35 |
| mlankhorst | so now to figure out why relocation is failing like that :P | 10:39 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| mlankhorst | alf_: ah, intel has an internal cache that gets re-used for flink.. | 11:22 |
| alan_g | alf_: what's the state of the art branch for nested/gbm? | 11:36 |
| alan_g | lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack? | 11:36 |
| alf_ | alan_g: ~afrantzis/mir/spike-nested-gbm-egl-image-hack yes | 11:37 |
| alan_g | alf_: OK to top-approve lp:~alan-griffiths/mir/cleanup-NativeAndroidPlatform? | 11:39 |
| alf_ | alan_g: I am OK, although I haven't tested it on an Android device, but it seems harmless. | 11:40 |
| === alf_ is now known as alf|xmir-devel | ||
| === alan_g is now known as alan_g|lunch | ||
| mlankhorst | alf|xmir-devel: definitely some memory corruption going on, no idea what exactly though | 12:01 |
| === hikiko is now known as hikiko|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| mlankhorst | huh wtf | 12:46 |
| alf|xmir-devel | mlankhorst: ? | 12:51 |
| mlankhorst | 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.. | 12:55 |
| mlankhorst | oh finally some sense.. | 13:00 |
| mlankhorst | (gdb) print bo->bufmgr | 13:01 |
| mlankhorst | $6 = (drm_intel_bufmgr *) 0x6580d0 | 13:01 |
| mlankhorst | (gdb) print bo->bufmgr | 13:01 |
| mlankhorst | $5 = (drm_intel_bufmgr *) 0x636280 | 13:01 |
| mlankhorst | why are there 2 drm_intel_bufmgrs ? | 13:01 |
| mlankhorst | seriously.. | 13:03 |
| mlankhorst | gbm can create a screen, egl probably creates a separate screen or something | 13:07 |
| mlankhorst | #7 0x00007ffff3d821be in gbm_create_device (fd=16) at ../../../../src/gbm/main/gbm.c:156 | 13:08 |
| mlankhorst | #8 0x00007ffff61d3dea in eglInitialize (dpy=0x64e3b0, major=0x7fffffffe1f8, minor=0x7fffffffe1fc) at ../../../../../src/egl/main/eglapi.c:317 | 13:08 |
| mlankhorst | so eglInitialize and gbm_create_device | 13:08 |
| alf|xmir-devel | 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:15 |
| mlankhorst | alf|xmir-devel: no you really need to get rid of the separate copy | 13:16 |
| mlankhorst | RAOF wrote the code, he may know how to do that.. | 13:16 |
| alf|xmir-devel | mlankhorst: which code? | 13:17 |
| mlankhorst | the 'screen' comes from mir | 13:18 |
| mlankhorst | but you're creating the gbm without any knowledge of it | 13:19 |
| alf|xmir-devel | 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 |
| mlankhorst | that's the thing you should do | 13:20 |
| mlankhorst | does that kill off the platform_mir by any chance? :P | 13:20 |
| mlankhorst | probably not, but in any case mir probably needs to know about the gbm screen and use it | 13:22 |
| alf|xmir-devel | mlankhorst: no, we have our own native display and window types | 13:22 |
| mlankhorst | specifically | 13:23 |
| mlankhorst | if (!dri2_create_screen(disp)) | 13:23 |
| mlankhorst | goto cleanup_dpy; | 13:23 |
| mlankhorst | that line is wrong | 13:23 |
| === hikiko|lunch is now known as hikiko | ||
| mlankhorst | please don't make such hard to debug problems in the future | 13:24 |
| mlankhorst | :P | 13:24 |
| mlankhorst | (and I checked git blame, so I know it was you) | 13:27 |
| alf|xmir-devel | 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 |
| mlankhorst | sure | 13:28 |
| mlankhorst | and you're welcome, please try to give me easier problems next time ;) | 13:29 |
| alf|xmir-devel | mlankhorst: thank you :) I really appreciate your time and effort! | 13:29 |
| mlankhorst | after that dupimage will work correctly and flink vs w/e doesn't matter | 13:31 |
| mlankhorst | is there anything else using gbm? :P | 13:32 |
| alf|xmir-devel | mlankhorst: the display subsystem is using gbm internally, but that's using platform_drm so no problems there | 13:34 |
| alf|xmir-devel | mlankhorst: (in host mir) | 13:34 |
| alan_g | alf|xmir-devel: it sounds like you understand the problem (if not the solution)? | 13:37 |
| mlankhorst | well there were 2 problems, but seems so :p | 13:38 |
| mlankhorst | other problem was sharing drm fd | 13:40 |
| kgunn | mlankhorst: \o/ | 13:50 |
| sil2100 | kgunn: hi! | 13:53 |
| sil2100 | 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 |
| sil2100 | kgunn: https://bugs.launchpad.net/mir/+bug/1223889 | 13:53 |
| ubot5 | Launchpad bug 1223889 in Mir "Mir crashing on Intel drivers - memory corruption in /usr/bin/X" [Critical,New] | 13:53 |
| * kgunn looks | 13:54 | |
| === chihchun_afk is now known as chihchun | ||
| sil2100 | 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 |
| kgunn | sil2100: go ahead | 13:55 |
| kgunn | sil2100: so this is effectively the ppa from daily-build ?? | 13:56 |
| kgunn | just curious how we potentially bisect | 13:56 |
| === dandrader is now known as dandrader|afk | ||
| kgunn | ....and ironically mlankhorst was working on intel mem corruption a moment ago....same thing ? | 13:57 |
| sil2100 | kgunn: yes, this is using the current daily-build PPA contents, at least for the mir parts | 13:57 |
| mlankhorst | kgunn: only affected nesting | 13:57 |
| mlankhorst | afaik xorg-server doesn't use gbm | 13:57 |
| kgunn | mlankhorst: was worth a hope :) | 13:57 |
| kgunn | 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 |
| ubot5 | Launchpad bug 1223889 in Mir "Mir crashing on Intel drivers - memory corruption in /usr/bin/X" [Critical,New] | 13:58 |
| kgunn | since RAOF & duflu are sleeping | 13:59 |
| kgunn | sil2100: i assume this means usc/mir/xmir are held up | 13:59 |
| alf|xmir-devel | 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 |
| sil2100 | 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:00 |
| mlankhorst | alf|xmir-devel: not really.. server doesn't need egl platform mir. Only nested client does. :P | 14:01 |
| sil2100 | kgunn: so essentially this problem breaks and slightly blocks all other packages, because it's breaking our test architecture | 14:01 |
| kgunn | 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 |
| alf|xmir-devel | mlankhorst: that's what I mean, a client (nested mir) needs to pass information to Mesa that is server related (gbm_device*) | 14:02 |
| alf|xmir-devel | mlankhorst: remember we are doing server buffer allocation | 14:03 |
| sil2100 | 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:04 |
| sil2100 | kgunn, didrocks: if you don't mind, I'll skip mirslave release this tick | 14:08 |
| sil2100 | kgunn, didrocks: we know it's broken and at least it won't break all other stacks :) We can run it later | 14:09 |
| kgunn | sil2100: so you're saying that standalone X intel is fine with this xserver-xorg-video-intel...right ? | 14:10 |
| sil2100 | kgunn: yes, it's only happening when mir is used apparently | 14:11 |
| sil2100 | Would have to see locally on my machine if the crash is happening, but there's so many things pending... | 14:11 |
| kgunn | sil2100: just for bisecting...we know that yesterday, had no problems....and this morning...we have problems right ? | 14:11 |
| kgunn | meaning...we must have pushed something in xmir/mir/xserver-xorg-video-intel w/in last 24 hours that caused this | 14:12 |
| sil2100 | 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:12 |
| kgunn | sil2100: that would be really helpful to know....when the last good combo was | 14:13 |
| sil2100 | kgunn: bad news is... we didn't have a successful run yesterday as well, but not because of an X crash | 14:14 |
| sil2100 | kgunn: we DNS-resolve problems, so no release happened | 14:15 |
| kgunn | ok but maybe last friday was ok? | 14:15 |
| kgunn | sil2100: ^ | 14:15 |
| sil2100 | kgunn: the last successful run was on the 6th, then the infra errors started happening | 14:15 |
| sil2100 | kgunn: yes, it seems we didn't have a successful run since libmirclient3 was introduced ;p | 14:16 |
| sil2100 | I mean, just today seems to be the first time the tests are actually ran | 14:16 |
| kgunn | sil2100: hmmm....could be | 14:17 |
| kgunn | but the build order took care of that sort of thing i thot | 14:17 |
| === dandrader|afk is now known as dandrader | ||
| mlankhorst | kgunn: please just valgrind ;P | 14:22 |
| mlankhorst | it's there for a reason! :D | 14:22 |
| mlankhorst | make /etc/X11/X2 with these contents: #!/bin/bash | 14:22 |
| mlankhorst | 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:23 |
| mlankhorst | and install xserver.*dbg | 14:26 |
| mlankhorst | symlink /etc/X11/X to it, /etc/X11/X must stay a symlink :p | 14:27 |
| alf|xmir-devel | kgunn: I will try to reproduce/investigate a bit later | 14:29 |
| kgunn | alf|xmir-devel: i assume you understand 'how to' what mlankhorst just said :) | 14:31 |
| racarr | Morning! | 14:39 |
| kgunn | mornin' | 14:41 |
| === alan_g is now known as alan_g|tea | ||
| === 3JTAAEL6B is now known as tvoss | ||
| tvoss | hey guys :) | 14:48 |
| === jono is now known as Guest91193 | ||
| didrocks | sil2100: ack | 14:51 |
| racarr | hey tvoss :) | 14:53 |
| tvoss | racarr, o/ | 14:53 |
| racarr | tvoss: Will you be in Lexington? | 14:56 |
| tvoss | racarr, nope, unfortunately not :/ | 14:56 |
| racarr | Aww | 14:58 |
| ricmm | racarr: ping | 14:58 |
| ricmm | racarr: how are we doing with the DPMS-android stuff | 14:58 |
| ricmm | 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 |
| ricmm | :) | 14:58 |
| tvoss | ricmm, kdub might be able to help, too | 14:59 |
| ricmm | right just wondering as we had this discussion last week and there was a quick testing that was gonna happen | 14:59 |
| ricmm | so, if it hasnt happened then I'll make the call of doing direct powerd->hal access for the screen control | 14:59 |
| ricmm | until theres a problem the_shell_display_power_controller() or whatever under android, heh | 15:00 |
| ricmm | an interface, not a problem, sorry | 15:00 |
| racarr | ricmm: Pong! | 15:00 |
| racarr | ricmm: There is an API in place | 15:00 |
| ricmm | racarr: awesome | 15:00 |
| ricmm | which one is it? got a landing rev? sorry | 15:00 |
| racarr | ricmm: Part of the display configuration API | 15:00 |
| racarr | no worries! lemme find it | 15:00 |
| racarr | also standup? No one else is there | 15:01 |
| ricmm | darn that one is complicated | 15:01 |
| hikiko | i am racarr | 15:01 |
| hikiko | but i see nobody else :p | 15:01 |
| hikiko | let me relogin again | 15:01 |
| === alan_g|tea is now known as alan_g | ||
| ricmm | 1054 | 15:01 |
| hikiko | racarr, still alone :) | 15:01 |
| alan_g | I see no-one too | 15:01 |
| kgunn | i see alan | 15:02 |
| alan_g | I see kgunn | 15:02 |
| racarr | ricmm: 1054 | 15:02 |
| racarr | ricmm: The impl isn't landed due to a series of issues with doing it over IPC | 15:02 |
| hikiko | racarr, we are all at the same hangout! | 15:02 |
| racarr | s/landed/proposed | 15:02 |
| racarr | hikiko: Can you give me the link? | 15:02 |
| ricmm | yea thats what im just seeing | 15:02 |
| racarr | CAlendar link isn't working for me | 15:02 |
| ricmm | if theres no impl then I cannot use it | 15:02 |
| ricmm | racarr: can you point me to the HAL interface you were planning to use? | 15:03 |
| racarr | ricmm: hwcomposer.h blank/unblank | 15:03 |
| racarr | ricmm: It all works actually for android, I can propose the android impl asap | 15:03 |
| ricmm | gbm is the one thats broken? | 15:04 |
| ricmm | well to be fair I might do the direct powerd access as theres no short-term plan for the shell policy enacter | 15:04 |
| ricmm | so it will still have to be powerd | 15:04 |
| ricmm | simpler to do powerd -> hal instead of powerd -> dbus -> shell -> hal | 15:05 |
| racarr | Mir has to know to stop rendering, etc though, and dieally wouldn't report this as errors | 15:05 |
| racarr | actually I can sort of make | 15:05 |
| racarr | GBM work the problem is it's over | 15:05 |
| racarr | well let me explain in just a few minutes | 15:05 |
| racarr | standup :) | 15:05 |
| ricmm | ok | 15:06 |
| === chihchun is now known as chihchun_afk | ||
| kgunn | alf|xmir-devel: i was just wondering aloud to robert if this https://code.launchpad.net/~robertcarr/mir/dpms-support-api/+merge/181884 might have been the issue | 15:11 |
| kgunn | but....the build stacks should'be taken care of it | 15:11 |
| kgunn | new api, but no new impl....should'be just rebuilt | 15:11 |
| kgunn | alan_g: assume you had a problem....can you rejoin hangout? | 15:19 |
| kgunn | alan_g: racarr wanted to chat about ipc wrt dpms | 15:19 |
| alan_g | kgunn: no - just no interest in the followup conversation | 15:19 |
| ricmm | racarr: ping, got a minute now then? | 15:38 |
| ricmm | kgunn: does that mean that the discussion didnt happen? :) | 15:39 |
| kgunn | ricmm: we're discussing mir ipc wrt dpms atm on a hangout | 15:39 |
| ricmm | awesome | 15:39 |
| didrocks | kgunn: hey! yesterday I asked to not migrate the libmirclient ABI | 15:42 |
| didrocks | as asac and I are trying to get the unity8 on Mir | 15:42 |
| didrocks | and once again, the transition was done… | 15:42 |
| didrocks | it's the 3rd time that happens from the Mir team that we ask to not do risky things and this happen | 15:43 |
| kgunn | didrocks: who did you ask? | 15:43 |
| didrocks | now all dailies are busted | 15:43 |
| didrocks | can check the logs | 15:43 |
| ricmm | didrocks: it was bumped? | 15:43 |
| didrocks | kgunn: the last 2 times, you were in the loop IIRC | 15:43 |
| didrocks | ricmm: to libmirclient3 | 15:43 |
| ricmm | darn | 15:43 |
| didrocks | let me check for that one | 15:43 |
| didrocks | kgunn: robert_ancell | 15:44 |
| didrocks | 2013-09-10 17:33:56 robert_ancell_ didrocks, the mirclient3 transition? | 15:44 |
| didrocks | 2013-09-10 17:45:52 didrocks robert_ancell: urgh, transition? | 15:44 |
| didrocks | 2013-09-10 17:45:58 didrocks robert_ancell: no transition right now please | 15:44 |
| didrocks | 2013-09-10 17:46:09 didrocks asac tries to get unity-mir on | 15:44 |
| kgunn | didrocks: ok | 15:44 |
| ricmm | didrocks: unity-mir doesnt depend on libmirclient3, only qtubuntu/platform-api -> apps | 15:44 |
| didrocks | it's the 3 times on 3 when we ask the Mir team to be cautious and it seems we are unheard | 15:44 |
| ricmm | err, mirclient in general | 15:45 |
| didrocks | I'm *really* unimpressed | 15:45 |
| ricmm | didrocks: what room are you in? | 15:45 |
| kgunn | didrocks: ....cause we did screw up on libmirclient2...no mir-devel mail (someone screamed)... | 15:45 |
| kgunn | didrocks: then...we did diligence https://lists.ubuntu.com/archives/mir-devel/2013-September/000373.html | 15:45 |
| didrocks | ricmm: right, but the drivers are depending on it | 15:45 |
| kgunn | didrocks: but no one replied on mir-devel | 15:45 |
| didrocks | kgunn: you know, we deliver in ubuntu | 15:45 |
| didrocks | kgunn: ubuntu-devel would be the first step | 15:45 |
| didrocks | and checking with the integration team would have been great | 15:45 |
| didrocks | and when the integration team tells "please no", listening to them would be good | 15:46 |
| kgunn | didrocks: i thot agreement was mir-devel | 15:46 |
| didrocks | kgunn: I'm not on that last | 15:46 |
| didrocks | kgunn: I can't be on all upstream ML | 15:46 |
| didrocks | list* | 15:46 |
| kgunn | didrocks: yes...chatting with robert A on irc...i would've thot would take care | 15:46 |
| kgunn | didrocks: ok...so now, ubuntu-dev....if we mail out a warning on that...that is where you want to see it ?....is there another mail for "integration team" | 15:47 |
| kgunn | ? | 15:47 |
| didrocks | kgunn: it's the main ubuntu ML | 15:47 |
| didrocks | so everyone is supposed to read it | 15:47 |
| kgunn | didrocks: ok, just trying to make sure...when libmirclient4 happens we dont f up again....so ubuntu-dev...right? | 15:48 |
| didrocks | kgunn: right ubuntu-dev, and as it's a packaging change, pinging the integration team | 15:48 |
| didrocks | so that they can review it | 15:49 |
| kgunn | didrocks: integration team being you, mirv, sil ? anyone else? | 15:49 |
| didrocks | kgunn: ~ubuntu-unity as per https://wiki.ubuntu.com/DailyRelease/FAQ#What.27s_needed_to_be_done_when_proposing_a_branch_or_reviewing.3F | 15:50 |
| kgunn | https://launchpad.net/~ubuntu-unity <- didrocks | 15:51 |
| didrocks | kgunn: right | 15:52 |
| racarr | ricmm: Ok so the DPMS issue is the IPC API doesn't work but that';s only for xmir | 15:54 |
| racarr | so if you want I can try and propose an android impl soon (should take like 2-3 hours of work to finish it off) | 15:55 |
| racarr | that will work via in server APIs | 15:55 |
| didrocks | kgunn: discussing with asac | 15:55 |
| didrocks | we revert the change now | 15:56 |
| kgunn | didrocks: ack...compiling note to the team for permanence....sorry it happened | 15:57 |
| === tkamppeter_ is now known as tkamppeter | ||
| didrocks | kgunn: thanks | 16:03 |
| === dandrader is now known as dandrader|lunch | ||
| sil2100 | kgunn: is the revert taking place now? If not, I'll revert it myself if needed, as we want to have this resolved ASAP | 16:17 |
| ricmm | racarr: please do, but that wont really land anytime soon into a released image | 16:18 |
| ricmm | racarr: but we need it in there one way or another :) will ping you in a couple hours to see how we are doing | 16:19 |
| didrocks | sil2100: ok, it seems kgunn isn't available, we already agree on the revert, please do | 16:24 |
| sil2100 | ACK | 16:25 |
| kgunn | didrocks: can we still help win you time ? | 16:32 |
| didrocks | sil2100: did you do it? ^ | 16:33 |
| kgunn | racarr: can we back out the libmirclient3 change ? | 16:33 |
| didrocks | kgunn: only backing out that one before next tick (so in the next 10 minutes) will help | 16:33 |
| kgunn | didrocks: sil2100 ...this is the correct one right ? | 16:35 |
| kgunn | https://code.launchpad.net/~robertcarr/mir/dpms-support-api/+merge/181884 | 16:35 |
| sil2100 | didrocks: compiling | 16:35 |
| kgunn | sil2100: thanks | 16:35 |
| sil2100 | I need to test build my revert | 16:35 |
| sil2100 | kgunn: yeah, that's the one, I made a revert and checking if it builds | 16:36 |
| kgunn | sil2100: thanks...i was going to pull & update myself if needed... | 16:36 |
| didrocks | thanks kgunn and sil2100 | 16:36 |
| * didrocks continues on unity8/unity-mir meanwhile | 16:37 | |
| kgunn | always a bit dangerous to have managers touching code | 16:37 |
| didrocks | heh | 16:38 |
| sil2100 | Build already daaamn! *hastes his bzr bd* | 16:40 |
| jono_ | kgunn, hey | 16:44 |
| jono_ | when do we plan on switching on Mir by default in 13.10? | 16:44 |
| kgunn | our goal is next week sept 19, we have key bugs to address next week we have | 16:45 |
| kgunn | a sprint in lexington | 16:45 |
| kgunn | to try to kill off the ones we consider "make xmir default" blockers | 16:46 |
| kgunn | jono_: ^ | 16:46 |
| jono_ | kgunn, perfect | 16:47 |
| jono_ | thanks :-) | 16:47 |
| jono_ | kgunn, how is everything going? | 16:47 |
| jono_ | frantic I assume :-) | 16:47 |
| kgunn | jono_: yeah...frantic is a decent description (w/o swear words that is) | 16:48 |
| jono_ | lol | 16:48 |
| jono_ | :-) | 16:48 |
| kgunn | sil2100: gotta mp yet ? lemme know i'll top approve | 17:05 |
| sil2100 | kgunn: I have it up, but it's not building correctly on my system - I have some unresolved symbol, need to check if it's a result of the changes or not | 17:05 |
| sil2100 | kgunn: https://code.launchpad.net/~sil2100/mir/revert_libmirclient3/+merge/185110 | 17:05 |
| sil2100 | kgunn: could you maybe try? | 17:05 |
| kgunn | sil2100: will do (switching machines) | 17:06 |
| kgunn | racarr: ^ mind being a savvy set of mir-team eyes on this one https://code.launchpad.net/~sil2100/mir/revert_libmirclient3/+merge/185110 | 17:06 |
| === alan_g is now known as alan_g|EOD | ||
| sil2100 | racarr: I'm gettin the following error: /opt/tmp/canonical/stacks/tmp/build-area/mir-0.0.10+13.10.20130904/obj-x86_64-linux-gnu/bin/unit-tests: symbol lookup error: /opt/tmp/canonical/stacks/tmp/build-area/mir-0.0.10+13.10.20130904/obj-x86_64-linux-gnu/bin/unit-tests: undefined symbol: eglCreateImageKHR | 17:07 |
| sil2100 | racarr: you know if this could be caused by the revert? | 17:08 |
| sil2100 | racarr: or is there something just wrong on my system | 17:08 |
| kgunn | sil2100: are you building for arm or amd64 ? | 17:10 |
| kgunn | oh sorry...i see x86_64 | 17:10 |
| sil2100 | Yes, building locally, since cross-building would take even more time | 17:11 |
| kgunn | sil2100: right...but target build is amd64....not arm right ? | 17:11 |
| kgunn | sil2100: is mesa & xserver-xorg-video-intel driver up to date | 17:12 |
| sil2100 | kgunn: that's why I wanted you to try and build it locally on your machine just in case ;) I'm building lp:mir right now, if that fails as well then it's not the revert's fault | 17:13 |
| kgunn | sil2100: i suspect its unrelated...no gl code touched in that libmirclient3 code change | 17:14 |
| bschaefer | sil2100, mines defined here: | 17:16 |
| bschaefer | eglext.h:84:EGLAPI EGLImageKHR EGLAPIENTRY eglCreateImageKHR (EGLDisplay dpy, EGLContext ctx, EGLenum target, EGLClientBuffer buffer, const EGLint *attrib_list); | 17:16 |
| bschaefer | possibly missing an update to egl :) | 17:16 |
| sil2100 | bschaefer: right, lp:mir failed as well here ;) | 17:18 |
| bschaefer | :), sorry, just saw the undefined symbol and looked it up | 17:19 |
| sil2100 | bschaefer: but interesting, my libegl1-mesa is up-to-date! | 17:20 |
| sil2100 | And libegl1-mesa-dev as well ;p | 17:21 |
| bschaefer | Installed: 9.2-1ubuntu1? | 17:21 |
| sil2100 | 9.2-1ubuntu1, yes | 17:21 |
| bschaefer | sil2100, hmm it should be dpkg -L libegl1-mesa-dev | 17:22 |
| bschaefer | installing it... | 17:22 |
| sil2100 | I have eglCreateImageKHR in the header as well, but hmmm | 17:22 |
| bschaefer | o...then that is indeed strange | 17:22 |
| sil2100 | I wonder what's up ;) bschaefer does lp:mir build for you normally? | 17:22 |
| sil2100 | kgunn: but anyway, if it builds for you, let's approve it | 17:23 |
| bschaefer | sil2100, let me check! | 17:23 |
| sil2100 | CI will build it as well and only merge if it's ok | 17:23 |
| * bschaefer can also check libmesa to see if that function is defined or not... | 17:23 | |
| sil2100 | bschaefer: thanks! | 17:23 |
| sil2100 | Maybe EGL_EGLEXT_PROTOTYPES is undefined on my system ;p | 17:23 |
| bschaefer | possibly! Its just having problems linking right? Sooo it must not be finding where its defined...strangly | 17:24 |
| bschaefer | sil2100, mine compiles fine | 17:26 |
| * bschaefer does a complete rebuild | 17:26 | |
| kdub | i can check too | 17:26 |
| bschaefer | sil2100, I also just did a dist-upgrade a bit ago | 17:26 |
| kgunn | building... | 17:28 |
| bschaefer | sil2100, possibly trying a --reinstall on libegl1-mesa-dev? | 17:28 |
| sil2100 | Could you guys also check if https://code.launchpad.net/~sil2100/mir/revert_libmirclient3 is fine? | 17:28 |
| sil2100 | bschaefer: will try, strange thing! | 17:29 |
| sil2100 | But I got used to my system having build problems | 17:29 |
| kdub | sil2100, looking it over | 17:29 |
| sil2100 | kdub: thanks ;) | 17:29 |
| bschaefer | np, I can merge it in with trunk mir and build it to check as well | 17:29 |
| sil2100 | There's a merge, if anyone can help kgunn reviewing that and approving - we need to revert that as per didrocks decision (and the many many problems we have because of that) | 17:29 |
| kgunn | damn slow machine....50% thru | 17:33 |
| kdub | sil2100, i approved it, small comment | 17:33 |
| kgunn | sil2100: if i build ok, i'll run a client demo for sanity...if all ok, i'll top aprove | 17:34 |
| kgunn | 80%... | 17:39 |
| kgunn | like watching paint dry | 17:39 |
| bschaefer | my branch compiled, i can run some demos for sanity as well | 17:40 |
| kgunn | bschaefer: you so speedy...please do | 17:40 |
| bschaefer | :) | 17:41 |
| kgunn | bschaefer: you must be on an i7 | 17:41 |
| sil2100 | :) | 17:42 |
| bschaefer | kgunn, nope an i5, but seems to work well :) | 17:42 |
| bschaefer | i wish! | 17:42 |
| bschaefer | kgunn, demos are working fine! (also forgot about the flashing one...) | 17:42 |
| kgunn | linking...drumroll please | 17:43 |
| * bschaefer doesn't know how to express that in IRC | 17:44 | |
| kgunn | all done | 17:44 |
| kgunn | bschaefer: i know...i miss noise making in office | 17:44 |
| bschaefer | kgunn, well i've never worked in an office, but I can imagine its a bit easier :) | 17:45 |
| sil2100 | kdub: approved the code perspective | 17:48 |
| sil2100 | bschaefer: does the branch I pointed work for you? | 17:48 |
| bschaefer | sil2100, yup! | 17:48 |
| kgunn | sil2100: bschaefer kdub racarr ...built, and worked for demos...i feel good | 17:48 |
| kgunn | ready for me to approve | 17:48 |
| sil2100 | kgunn: could you top-approve? Thanks! | 17:48 |
| kgunn | sil2100: roger that | 17:49 |
| sil2100 | Thanks guys! | 17:49 |
| kgunn | sil2100: done...and no thank you...sorry for the poop-storm | 17:50 |
| kgunn | sil2100: gonna go eat & exercise... bschaefer & kdub got your back if you need it i'm sure... | 17:56 |
| * bschaefer will be around for a while... | 18:01 | |
| racarr | I am trying to understand this libmirclient3 stuff | 18:18 |
| racarr | 1. How can I not fuck things up in the future. | 18:18 |
| racarr | 2. What is meant by problems and how is it expected that this will fix them? | 18:18 |
| === dandrader|lunch is now known as dandrader | ||
| racarr | Lunch | 18:43 |
| racarr | back | 19:26 |
| kgunn | bschaefer: everything ok? verizon decided i shouldn't have interenet for the last little while | 19:33 |
| ricmm | racarr: ping | 19:33 |
| * kgunn hears verison | 19:33 | |
| * kgunn hearts verizon even | 19:34 | |
| bschaefer | kgunn, everythings been quite | 19:34 |
| kgunn | except ricmm pining...we ok ricmm ? | 19:34 |
| ricmm | we ok, just reaching out to robert | 19:34 |
| bschaefer | hopefully everything is :) | 19:34 |
| ricmm | see if he has had any progress on the DPMS for android impl | 19:34 |
| ricmm | as he had said 2-3 hours | 19:34 |
| ricmm | a few hours back | 19:34 |
| ricmm | its the last piece of the puzzle from your team, so far | 19:35 |
| ricmm | ;) | 19:35 |
| kgunn | ah yes... | 19:38 |
| kgunn | mmm.... racarr might be lunching | 19:39 |
| racarr | ricmm: Pong | 19:43 |
| racarr | ricmm: Ok great, so yes I am working on it now half done but there is a problem! which I was waiting to ask kgunn about | 19:44 |
| racarr | The API got reverted. | 19:44 |
| racarr | kgunn: I don't understand what happened. | 19:44 |
| racarr | kgunn: I don't understand what happened. 1. How do I not mess it up in the future. 2. What were the problems? 3. How is this supposed to fix them | 19:45 |
| kgunn | racarr: not your fault | 19:45 |
| kgunn | racarr: #1 - see the email i sent to team | 19:45 |
| racarr | whoops had some up arrow = repeating myself XD | 19:46 |
| racarr | I'm not actually THAT confused :) | 19:46 |
| kgunn | #2 - didrocks asac and ricmm asked for libmirclient3 not to land until unity-mir was in... | 19:46 |
| racarr | oh I missed that...I was waiting on it earlier | 19:46 |
| racarr | Oh. I see now | 19:46 |
| kgunn | #3....i honestly didnt get it either...i think cause they were using daily-build ppa's somehow ? | 19:46 |
| kgunn | if total rebuild...it should be ok...but maybe they weren't doing that | 19:47 |
| racarr | Ok. I understand more now :) sorry about missing the email. | 19:47 |
| racarr | the MR to revert it cites issues on intel on the desktop, etc | 19:47 |
| racarr | which really sounds like we have some sort of | 19:47 |
| racarr | infrastructure or roll out error | 19:47 |
| racarr | because I dont think the change can break anything besides through ABI | 19:48 |
| kgunn | racarr: agreed | 19:48 |
| kgunn | again...you did nothing wrong....and followed what i thot was the right way (email on mir-devel)... | 19:48 |
| kgunn | no worries.... | 19:48 |
| kgunn | we'll get it right on libmirclient4 | 19:48 |
| kgunn | :) | 19:48 |
| racarr | :D thanks | 19:49 |
| === dandrader is now known as dandrader|afk | ||
| racarr | I feel like it's worth trying to figure out what happened though with things being broken on the desktop | 19:49 |
| racarr | More of a thought than a feeling I guess :p | 19:49 |
| kgunn | me & bschaefer built locally....then sil2100 could not...something about not finding eglCreateImageKHR | 19:51 |
| kdub | nothing should really link directly to that function | 19:51 |
| racarr | hmm...now I am remembering I saw that once in the last few weeks | 19:51 |
| racarr | how did I resolve it | 19:51 |
| kgunn | racarr: so i think....when didrocks & ricmm say they have a green image w/o libmirclient3....you could then push the dpms + libmirclient3 to provide the fix | 19:52 |
| racarr | I think I dist upgraded | 19:52 |
| racarr | How will we get a green image without screen blanking -.- | 19:52 |
| kgunn | everything else minus screen blanking | 19:52 |
| ricmm | racarr: the green image is not feature-complete Mir | 19:52 |
| racarr | ok | 19:52 |
| kgunn | i would guess | 19:52 |
| ricmm | its just SF with all the Mir stuffed landed but not enabled | 19:52 |
| racarr | oh. good idea | 19:52 |
| kgunn | ricmm: but don't we want some level of sanity test result of the mir-enabled in the same image as well ? | 19:53 |
| ricmm | so whatever you need to depend on for DPMS, use it | 19:53 |
| racarr | I didn't understand that :) | 19:53 |
| ricmm | plus, its a server API, no? | 19:53 |
| ricmm | shouldnt impact mirclient | 19:53 |
| racarr | ehhh | 19:53 |
| ricmm | not that I mind about mirclient, the problem with that one was desktop-related | 19:53 |
| ricmm | but it held up the whole pipeline | 19:53 |
| racarr | I guess it could be masked from mirclient | 19:53 |
| racarr | its a client API too (for xmir) | 19:53 |
| ricmm | that sounds wrong | 19:54 |
| kgunn | mmm right...thanks ricmm forget touch will be sever side | 19:54 |
| racarr | ! that's the bit I don't understand how did it trigger | 19:54 |
| ubot5 | racarr: I am only a bot, please don't think I'm intelligent :) | 19:54 |
| racarr | problems on the desktop? | 19:54 |
| racarr | ...no worries ubot5 | 19:54 |
| kgunn | ricmm: xmir is a native client | 19:54 |
| ricmm | mirclient was bumped but that required a rebuild of everything and its mom | 19:54 |
| ricmm | which caused problems as we had the pipeline stalled for the unity stuff | 19:55 |
| kgunn | ricmm: did we rebuild for its dog & brother too ? | 19:55 |
| racarr | oh | 19:55 |
| ricmm | cousins too | 19:55 |
| kgunn | :) | 19:55 |
| ricmm | again, im not that familiar with the mirclient blockage, as I said... more desktop related than not :) | 19:55 |
| racarr | Ok. So the pipeline was stalled for other stuff | 19:55 |
| racarr | makes sense :) | 19:55 |
| kgunn | didrocks: you on ? | 19:55 |
| didrocks | kgunn: spammed with pings, yeah | 19:55 |
| racarr | ricmm: That makes enough sense :D I was worried that it was failing in some way that wasn't related to just ABI or some such | 19:56 |
| racarr | and trying to track down what was happening | 19:56 |
| kgunn | didrocks: sorry to add to the noise...so...question is, when can we try to push libmirclient3 again... | 19:56 |
| kgunn | didrocks: no one understands why it failed.... | 19:56 |
| didrocks | kgunn: no | 19:56 |
| racarr | ricmm: Working on DPMS, just need to patch some support in to demo-server for a test, and go through the whole dance of updating my phone, etc. | 19:56 |
| didrocks | kgunn: we try to have an image out | 19:56 |
| kgunn | didrocks: thanks...nice clear anser | 19:56 |
| didrocks | kgunn: once the image is done | 19:57 |
| didrocks | and we have as well indicators in | 19:57 |
| didrocks | we can reput libmirclient3 | 19:57 |
| didrocks | IF as an upstream, you handle the whole transition | 19:57 |
| didrocks | to not block everyone | 19:57 |
| ricmm | racarr: please do, about the phone updating it should be enough to flash -pending and update from the ubuntu-unity/daily-build ppa | 19:57 |
| ricmm | I'll bother you again in a while ;) | 19:57 |
| kgunn | didrocks: thanks... we will pend on you saying its ok to go again...sound ok ?? | 19:57 |
| didrocks | kgunn: perfect | 19:58 |
| didrocks | kgunn: probably tomorrow TBH | 19:58 |
| didrocks | kgunn: workarounding the latest Mir added a bunch of complication | 19:58 |
| didrocks | so still building things | 19:58 |
| kgunn | didrocks: that's fine...i think racarr has a way fwd for dpms in touch....so we're only delaying xmir | 19:58 |
| didrocks | ok, good :) | 19:58 |
| kgunn | didrocks: i'm so sorry...i will punch myself in the face later as punishment :-/ | 19:59 |
| didrocks | kgunn: well, on that one, you're not to blame ;) | 19:59 |
| didrocks | kgunn: but we need to discuss on process when the team is planning to transition | 19:59 |
| didrocks | as it affect multiple pieces, there are things to do | 19:59 |
| didrocks | and there is a process on the FAQ page | 20:00 |
| didrocks | that I wish your team would follow ;) | 20:00 |
| didrocks | https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI | 20:00 |
| kgunn | didrocks: yep...got it...and team should be aware & i'll reiterate | 20:00 |
| kgunn | in person next week | 20:00 |
| didrocks | thanks | 20:00 |
| didrocks | I won't stay in Boston, lucky you! ;) | 20:00 |
| * kgunn probably doesn't punch as hard as didrocks...thanks goodness didrocks leaves boston | 20:01 | |
| * ricmm has been trying to find a flight for a while | 20:01 | |
| ricmm | there are none | 20:01 |
| didrocks | kgunn: ahah ;) | 20:01 |
| === dandrader|afk is now known as dandrader | ||
| racarr | red light of dweath on nexus 4...it does this sometimes when it runs out of battery hardcore though | 21:02 |
| racarr | back to the lightning bolt and battery thing! Yay not bricked | 21:14 |
| kdub | racarr, yeah, that happens fairly often to me, never had a brick yte | 21:17 |
| kdub | rsalveti, in the 'android-platform-headers' package, would it be difficult to add the hwcomposer.h and hwcomposer_defs.h from libhardware? | 22:44 |
| RAOF | Grah. | 23:38 |
| RAOF | Why does radeon suddenly work today? | 23:38 |
| RAOF | I'm all ready to debug bypass and multi-monitor... | 23:44 |
| RAOF | Oh. | 23:44 |
| RAOF | Because it's not running Mir. | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!