[00:57] That's confusing... [00:57] mir (0.15.1+15.10.20150903-0ubuntu1) wily; urgency=medium [00:57] [ Kevin Gunn ] [00:57] * released-rebuild-for-vivid-overlay [00:57] -- CI Train Bot Thu, 03 Sep 2015 18:50:01 +0000 [00:57] but also doesn't change anything [01:11] duflu, does XMir crash immediately when you launch it on a Nexus 4? [01:11] robert_ancell: Yeah, but I'm pretty sure I know why. I'll test and fix that today [01:11] duflu, I'm wondering why I don't see that [01:11] No idea why your vivid would work cos it's the same package. [01:12] perhaps you have newer drivers [01:12] robert_ancell: It might be you have an older kernel and your GLES version is < 3.0 [01:12] That would make epoxy skip over the problem [01:12] glamor GL version: OpenGL ES 3.0 V@53.0 AU@ (CL@) according to the log [01:14] duflu, do you know how to get XMir to dump core on the phone? It seems ulimit -c unlimited doesn't help. [01:14] robert_ancell: It's a Xorg thing and I forget... [01:14] And I love how that log message always says "dumping core" regardless of if if actaually does [01:14] robert_ancell: Yes it's dumping with a limit of zero [01:14] I guess that's technically true [01:15] robert_ancell: The "dumping" message would come from libc or something, userspace. But the actual dumping is a kernel operation. So blame libc for not checking the kernel setting [01:16] yeah, it's libc [01:16] The -core flag is supposed to dump core but still not getting any core files [01:17] * duflu wishes nobody ever stripped debug symbols. Although that would require abandoning bloaty things like C++ [01:18] * robert_ancell wishes we'd abandon C++ [01:19] Well Microsoft kind of did. Apple completely did. Google mostly did. But you'll find small traces of C++ in all of them [01:19] -completely +mostly [01:21] Even C is often much much bigger with debug symbols. [01:34] RAOF: Yes but much bigger C is still single digit bloat. C++ is often double or even triple digits (1-2 orders of magnitude) [02:12] robert_ancell: I'll confirm today but it might be uninitialized memory. So zero for me gives a nice crash. You however might have got some readable bytes, which would let it keep going since it's just doing strcmp [02:13] zero what? [02:13] robert_ancell: Zero result from glGetStringi [02:13] NULL [02:13] duflu, I'm getting your crash now, but only after updating to get your colour fixes [02:14] robert_ancell: Probably not related but also uninitialized memory issues would move with different logic. I'll confirm soon [02:14] I was getting the same crash before that fix [02:14] yeah, I'm thinking something like that. The changes don't seem likely to cause the problem. [02:14] ok [02:59] robert_ancell: This is annoying. epoxy is doing the right thing only calling GLESv3 functions after it confirms the version is >= 3.0. And hybris is doing the right thing, only claiming to export GLESv2 functions (which unfortunately for mako report their version as 3.0) [02:59] We need to break one of them [03:00] duflu, how is mako reporting gles? [03:00] robert_ancell: The mako driver lives in /android and libhybris proxies into it with its own libGLESv2.so [03:01] duflu, which part is saying it does 3.0? [03:02] robert_ancell: The log message on startup :) [03:02] From the GL version string [03:02] duflu, why don't we make hybris export 3.0? [03:02] robert_ancell: Because it's structured to implement v1 and v2 separately. Adding v3 under that structure is a very large undertaking [03:03] duflu, ok, but that sounds like the correct solution right? Instead of breaking one thing. [03:05] robert_ancell: It would be a silly investment of a large amount of time to implement all of v3. I'd rather stick the one v3 function we need in the v2 implementation. Or work around elsewhere [03:05] Our code actually links to GLESv2. It's just because epoxy queries things dynamically that we find it using v3 functions [03:06] Actually fixing epoxy to limit its efforts to GLESv2 might be more sane [03:12] Yes, I will do a one line mod to epoxy so it will never crash when used with hybris... [03:21] RAOF: If I want to add an Ubuntu-only patch to a package that is still "copied from debian sid", who do I talk to? [03:22] duflu, you just need anyone with appropriate upload permissions [03:22] duflu, do you want to patch libepoxy? [03:23] robert_ancell: Lemme check it works first ;) [03:25] robert_ancell: Success! It now fails later, the same as on desktop with -egl [03:26] Although I might need a second epoxy fix for that. Let's see [03:33] robert_ancell: Here tis. This might change what you see too: https://bugs.launchpad.net/ubuntu/+source/libepoxy/+bug/1494240/comments/4 [03:33] Ubuntu bug 1494240 in xorg-server (Ubuntu) "Xmir crashes immediately on startup using glamor on Nexus4" [High,In progress] [03:33] duflu, ta [04:25] duflu, it looks like GLES3 uses libGLES2.so so it's probably not hard to add a few new wrapped functions in hybris [04:39] robert_ancell: Not worth the effort. The epoxy fix is logically correct for any GL version. So is safe to keep [04:39] duflu, excepts it's a patch that will never be accepted upstream [04:40] robert_ancell: We could modify it to delete the unnecessary redundant (and crashing) code. That would also be correct [04:40] duflu, which code is crashing? [04:49] robert_ancell: The strcmp after glGetStringi [04:50] robert_ancell: It's an Ubuntu-specific problem. I'm happy to make it an Ubuntu-only patch, or generalize a proposal to upstream under the title of "add support for libhybris" (which is not Ubuntu specific) [04:50] duflu, but I don't get why we don't just make hybris wrap glGetStringi [04:50] Although I suspect more libepoxy fixes will be required first [04:50] Then everything will just work right? [04:51] robert_ancell: Yes, but that's uglier and less correct. You're adding v3-only function to something that only claims to support v2 [04:51] Using glGetString instead of glGetStringi works for all versions. Nice and cleanly [04:52] Also, I think we might need to make additional patches to libepoxy's extension maps, unrelated to this [04:53] So can't escape needing to patch libepoxy [04:53] A third reason is it would help Mir a lot. But Mir can't use it till we fix it [05:17] * robert_ancell -> EOD === chihchun_afk is now known as chihchun [10:26] is greyback on holidays? I now got the total hang on my personal use krillin again and filed bug #1494692 (I'll fill in more later) [10:26] bug 1494692 in mir (Ubuntu) "Total hang of the krillin with a graphics artifact" [Undecided,New] https://launchpad.net/bugs/1494692 [10:29] (ok, yes he is) === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [13:03] alf_: did pat's new log help any on that sms-freezes ui bug ? [13:04] kgunn: I am going to look into that in a bit, I wanted to first publish the voice call blanking improvements [13:04] kgunn: feel free to try out https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+packages [13:04] sure [13:05] alf_: pat has a special love for us...did you see he logged another [13:05] https://bugs.launchpad.net/bugs/1494513 === alan_g|lunch is now known as alan_g [13:05] Ubuntu bug 1494513 in unity-system-compositor (Ubuntu) "When a message is received while the screen is dimmed it does not restore full brightness" [Undecided,New] === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader