| RAOF | Today, on “Well, that's weird”: Surprise Wallaby! | 06:21 |
|---|---|---|
| duflu_ | RAOF: ? | 07:40 |
| === duflu_ is now known as duflu | ||
| === didrocks1 is now known as didrocks | ||
| alan_g | alf__: anpok anyone fancy a quick USC MP? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/tidy-config-options/+merge/210381 | 10:58 |
| alf__ | alan_g: sure | 10:58 |
| === alan_g is now known as alan_g|lunch | ||
| === lool- is now known as lool | ||
| === w00t_ is now known as w00t | ||
| kgunn | davmor2: on that bug 1290416 | 13:46 |
| ubot5 | bug 1290416 in unity-mir "Mako locks up roughly once a day since R226" [Critical,Confirmed] https://launchpad.net/bugs/1290416 | 13:46 |
| kgunn | you can still repro with the same steps you listed there in the report i assume ? | 13:47 |
| kgunn | just checkin' | 13:47 |
| kgunn | altho...this now seems to be a hang in unity-mir | 13:47 |
| kgunn | dandrader: are you free enough today to dive into this bug ^ | 13:54 |
| kgunn | dandrader: it was originally thot to be the null-snapshots for apps problem we found in the mwc images | 13:55 |
| kgunn | but that fix has landed in archive/image...and davmor2 says he can still get a crash/hang but just less frequent | 13:56 |
| kgunn | bregma: can you or a designate use the silo packages to test unity8 preview and make sure that bug is actually fixed ? | 13:56 |
| kgunn | or did you test dev branch already ? | 13:56 |
| bregma | kgunn, is the silo ready to test? | 13:57 |
| kgunn | ...building | 13:57 |
| kgunn | just planning ahead :) | 13:57 |
| bregma | OK, ping me again when it;s ready to test and I'll verify -- it's a quick test | 13:57 |
| bregma | either you can log in, or you reboot | 13:58 |
| kgunn | coolio | 13:58 |
| davmor2 | kgunn: It's happened to me twice over the weekend, and I think popey got hit by it this morning too. (but that may of been something else) | 13:59 |
| davmor2 | kgunn: it's slowed down in appearance though. | 14:00 |
| dandrader | kgunn, I'm working on the "unity8 as mir compositor" front, but I can switch to this bug if it's more important | 14:01 |
| kgunn | davmor2: can you verify that it's creating a crash file ? or how do we know this is still unity-mir ? | 14:01 |
| kgunn | davmor2: and ...i guess this is going to take hours at a time to test ? :-/ | 14:02 |
| kgunn | dandrader: you might be able to continue working....while you test ^ :) | 14:02 |
| popey | davmor2: no, i dont believe I have seen that | 14:03 |
| davmor2 | kgunn: yeap it takes hours, no there is no crash file, I think that I got all the info I could for the guys and added it to that bug when it was in the locked state | 14:04 |
| davmor2 | popey: that's fine then | 14:04 |
| kgunn | davmor2: sorry to be a pest....just want to chat through it... as to help dandrader or whoever gets the bug | 14:04 |
| kgunn | davmor2: so...no real repro steps, just play with the phone and let it sit ? | 14:05 |
| kgunn | does it happen when interacting with the phone ? or the phone is just resting ? | 14:05 |
| kgunn | e.g. is the phone always in "screen off/blanked" state ? | 14:06 |
| davmor2 | kgunn: it happens most for me from what I've noticed interacting in the dash so, closing apps, swiping between screens | 14:06 |
| davmor2 | kgunn: I don't remmeber it locking while resting | 14:06 |
| kgunn | davmor2: ok...that's good to know, can you run "top" on it while locked up ? | 14:07 |
| davmor2 | kgunn: I did and gave feed back nothing was 100%+ | 14:07 |
| kgunn | davmor2: ok...no worries, that could just mean deadlock somewhere... | 14:08 |
| davmor2 | kgunn: I don't know if that was added to the bug but I can certainly see if I can find the pastes | 14:08 |
| kgunn | davmor2: cool... | 14:08 |
| === alan_g|lunch is now known as alan_g | ||
| davmor2 | kgunn: which is what I think daniel has diagnosed it as iirc from the bug right? | 14:09 |
| kgunn | davmor2: yep | 14:09 |
| kgunn | davmor2: i was just poking you for info that might not be in the bug... :) | 14:09 |
| davmor2 | kgunn: meh I can't find the pastes in the irc logs :( I'll have another dig in a bit. | 14:17 |
| kgunn | davmor2: no worries... | 14:18 |
| davmor2 | kgunn: from the photo attached to the bug you can see where it locked up I was swiping out the launcher :) | 14:18 |
| kgunn | davmor2: thanks...and basically that image just sits there, and no touch inputs are responded to right ? (e.g. classic hang) | 14:19 |
| === jono is now known as Guest78266 | ||
| davmor2 | kgunn: 2 things happen the screen blank kicks in or it displays that image and nothing else, so when you hit the power button it is straight back to that screen rather than the welcome screen (hope that made sense) | 14:21 |
| kgunn | davmor2: yes...makes sense...and that's interesting too | 14:21 |
| kgunn | definitely a user space deadlock...kernel is ok | 14:21 |
| kgunn | davmor2: ok...i'm a liar, one last question :)...any chance you've seen this _without_ activing the OSK ? | 14:23 |
| davmor2 | kgunn: every thing works via adb so I could run top, I could trigger the backtraces that the guys asked for I just couldn't get the graphics to do anything :) | 14:23 |
| kgunn | mmm...i was thinking input lockup for a moment, but you're right, more likely render side | 14:24 |
| davmor2 | kgunn: pass I'd of been using it on and off throughout the whole day so the OSK would of been open at some point but it hasn't crashed while the osk has been open if that helps | 14:24 |
| kgunn | davmor2: if you do find those top traces....let us know...i'd be curious about mem stats too | 14:25 |
| davmor2 | kgunn: yeap give me about an hour to finish off some other stuff and I'll have a proper dig | 14:26 |
| === psivaa_ is now known as psivaa | ||
| kgunn | davmor2: no problem...we've got plenty to chase in the meantime :) | 14:27 |
| === dandrader is now known as dandrader|afk | ||
| alan_g | kgunn: this seems to do it: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/prepare-for-Mir-0.1.7/+merge/211334 | 15:14 |
| kgunn | alan_g: thanks...i had the exact change almost...but i missed the removal of stand-alone bit | 15:14 |
| alan_g | kgunn: yeah. I stole yours | 15:16 |
| === dandrader|afk is now known as dandrader | ||
| davmor2 | kgunn: meh I can't find them and I think I know why I think it was banded around in the landing hangout not on irc so I'm kinda stuffed when it locks up again I'll get you some copies of top | 16:34 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | davmor2: thanks for looking | 16:59 |
| kgunn | yeah...just dump it in the bug | 16:59 |
| kgunn | bregma: hey on the cursor topic...racar says... | 17:09 |
| kgunn | racarr> finished step 1 of 3 steps for client cursor API | 17:09 |
| kgunn | but still desktop preview can be unblocked by just enabling the cursor in USC with a command line option or something | 17:09 |
| kgunn | bregma: so will enabling hw cursor via u-s-c do it for you ? | 17:09 |
| racarr_ | Looks like Canonical has approved a number of travel REQ’s to the upcoming sprints in Austin, Las Vegas, Malta and London. As a result I have been sent multiple travel requests all within hours of each other. | 17:14 |
| racarr_ | las vegas oO? | 17:14 |
| bregma | kgunn, I don't see an appropriate command-line switch listed in unity-system-compositor --help ... the 'or something' might need a little fleshing out | 17:19 |
| racarr_ | No there is nothing yet I meant | 17:19 |
| racarr_ | we can add one | 17:19 |
| bregma | racarr_, we'd also need to patch lightdm, and prepare for complaints about having the cursor with no mouse: maybe it's still better to wait for proper support altogether | 17:21 |
| === om26er_ is now known as om26er | ||
| ogra_ | kgunn, can we land this in the not to far future ? https://code.launchpad.net/~unity-team/unity-system-compositor/new-gl-screen/+merge/210466 | 17:29 |
| racarr_ | bregma: Wait what? why patch lightdm | 17:31 |
| racarr_ | and what do we mean the cursor | 17:31 |
| racarr_ | with no mouse | 17:31 |
| bregma | racarr_, lightdm is what spawns unity-system-compositor, any command-line option needs to be added there, and a cursor with no mouse happens when you unplug your mouse (or don't have a mouse at all) and there's a cursor | 17:32 |
| bregma | eg. the Asus transformer | 17:32 |
| bregma | or my Yoga2 when it's folded into tablet mode | 17:33 |
| racarr_ | ah | 17:33 |
| racarr_ | second bit isnt entirely trivial to fix | 17:34 |
| racarr_ | patching lightdm doesnt seem that bad...isnt the command line in some conf file anyway | 17:35 |
| ogra_ | we support asus transformer with any image out there ? | 17:35 |
| racarr_ | ogra_: u8 desktop preview | 17:35 |
| ogra_ | racarr_, we still dont have any arm images for tegra devices anymore | 17:35 |
| ogra_ | (tegra was happily dropped all over the place) | 17:36 |
| racarr_ | oh I thought there were x86 ones | 17:36 |
| racarr_ | lol I have no clue | 17:36 |
| racarr_ | anyway I dont have a strong opinion on whether we should do the cursor command line thing | 17:36 |
| racarr_ | but a proper fix is unlikely to land before next monday and it keeps on coming up | 17:37 |
| ogra_ | heh, well, there probably are ... i stopped looking at transformers a while ago :) | 17:37 |
| === dandrader|lunch is now known as dandrader | ||
| racarr_ | bregma: kgunn: So is the conclusion we are happy if the more detailed cursor fix makes it to mir/devel by monday | 17:58 |
| racarr_ | and we can avoid doing this thing in USC/lightdm | 17:58 |
| racarr_ | or | 17:58 |
| bregma | racarr_, yes, that should be OK | 17:58 |
| racarr_ | the opposite | 17:58 |
| racarr_ | ok | 17:58 |
| === alan_g is now known as alan_g|EOD | ||
| kgunn | racarr_: if we could get something nice by monday...we'd all be good to go...just note...march 23 is final beta for trusty | 18:04 |
| kgunn | final freeze is apr 10th | 18:04 |
| racarr_ | yeah it seems kind of | 18:04 |
| racarr_ | that was kind of my point espescially with | 18:04 |
| racarr_ | sasy mir/devel by monday | 18:05 |
| racarr_ | worst case is a whole extra week | 18:05 |
| racarr_ | I dunno though. We can reevaluate wednesday | 18:05 |
| racarr_ | not counting the time to get stuff to archive etc. | 18:05 |
| kgunn | racarr_: we can cherry pick also...which would be a quicker landing | 18:05 |
| kgunn | (for mir) | 18:05 |
| racarr_ | mm | 18:05 |
| racarr_ | ok well lets reevaluate wednesday or so the | 18:05 |
| racarr_ | workaround can be | 18:06 |
| kgunn | yep | 18:06 |
| kgunn | sounds good | 18:06 |
| racarr_ | done all in one day | 18:06 |
| racarr_ | so no hurry | 18:06 |
| racarr_ | Lunch! | 18:23 |
| kgunn | bregma: yo!...we got some packages | 18:56 |
| kgunn | https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+packages | 18:56 |
| racarr_ | annn back | 18:58 |
| kgunn | thomi: so is there an "autopilot for dummies" around?...like, if someone just knows they want to add | 19:01 |
| kgunn | say a specific test, but doesn't want to learn all the fmwk'y stuff... | 19:01 |
| thomi | heh | 19:01 |
| thomi | well | 19:01 |
| kgunn | template i'm thinking | 19:02 |
| thomi | you'd typically talk to your QA representative | 19:02 |
| thomi | who will write the first few tests for you, and show you how it's done / train your team | 19:02 |
| kgunn | but.....? | 19:02 |
| thomi | no 'but', I'm just too tired to structure English sentences properly yet - haven't had my first coffee yet | 19:03 |
| thomi | Who have you guys been working with from the QA dept? | 19:03 |
| kgunn | ah | 19:03 |
| === dandrader is now known as dandrader|afk | ||
| thomi | kgunn: If you're not already working with someone, I can find someone to help you out | 19:07 |
| bregma | kgunn, can't test mir 0.1.7 with unity8 because libunity-mir1 has not been rebuilt against it | 19:11 |
| kgunn | bregma: hmmm, i'm just updating my phone....libunity-mir1 should be in those packages... | 19:12 |
| kgunn | does that make sense ? | 19:15 |
| kgunn | it should work | 19:15 |
| === dandrader|afk is now known as dandrader | ||
| bregma | maybe the publish hadn't made it out to my local mirror, I'll update again | 19:21 |
| bregma | ... yep, looks like that was the problem | 19:28 |
| bregma | kgunn, unity8 no longer crashes on startup on the desktop with 0.1.7 from the silo ... something else is totally messed up and nothing renders, but at least it's not crashing | 19:54 |
| kgunn | bregma: i don't know whether to be happy or cry | 19:54 |
| bregma | kgunn, it may not be a problem in Mir, there are lots of places where things can go wrong between the renderer and the desktop shell | 19:55 |
| bregma | one of the errors: QOpenGLShader::link: "error: linking with uncompiled shadererror: linking with uncompiled shader" | 19:56 |
| bregma | that's not a Mir problem | 19:56 |
| kgunn | ah...phew | 20:00 |
| === dandrader is now known as dandrader|afk | ||
| racarr_ | bregma: Err, not sure what the context is but this may be an old issue surfacing up again | 20:13 |
| racarr_ | where qtubuntu forces a GLES context but Qt packages on the desktop are statically compiled | 20:14 |
| racarr_ | against desktop GL | 20:14 |
| racarr_ | so sometimes QML emits shaders that | 20:14 |
| racarr_ | dont compile | 20:14 |
| racarr_ | we got randomly lucky initially in that the shell worked fine, because it just happened to emit shaders | 20:14 |
| racarr_ | in the common subset | 20:14 |
| racarr_ | but some of the qml examples always had this problem | 20:15 |
| racarr_ | anyway unless anyone ever fixed that its very likely a qt update or random | 20:15 |
| racarr_ | shell QML change | 20:15 |
| racarr_ | could have created issues | 20:15 |
| bregma | racarr_, I'm familiar with the problem (I'm the one who fixed it in qtubuntu) but it may well be the same problem elsewhere in the stack | 20:16 |
| bregma | problem is it's hard to tell who is compiling the shaders | 20:16 |
| bregma | ...unless Qt5.2 was built to use GLES only,..... | 20:17 |
| racarr_ | haha thats what | 20:17 |
| racarr_ | I was just going to say | 20:17 |
| racarr_ | re: who is compiling the shaders | 20:17 |
| racarr_ | you mean where they are coming from? | 20:17 |
| racarr_ | LIBGL_DEBUG=1 MESA_DEBUG=1 | 20:19 |
| racarr_ | will show the GL errors as they occur (link, etc) | 20:19 |
| racarr_ | and GLSL_DEBUG=dump will dump shaders but im nots ure that will give you the errors right away | 20:20 |
| racarr_ | may help | 20:20 |
| bregma | I don;t have a problem seeing the errors: keywords like 'highp' is throwing off the compiler (it's GLES only, Qt build for GL would strip that keyword out of shader code before compiling, which leads me to believe it's a Qt5.2 problem) | 20:21 |
| racarr_ | sounds like the original problem is back right the | 20:21 |
| racarr_ | oh no I misread sorry | 20:22 |
| racarr_ | so, the context is desktop GL (no highp) | 20:22 |
| racarr_ | but Qt is now compiled to emit GLES | 20:22 |
| racarr_ | its really shocking to me that that is a | 20:22 |
| racarr_ | ./configure option | 20:22 |
| racarr_ | and not like | 20:22 |
| racarr_ | a runtime option | 20:22 |
| racarr_ | or anything else | 20:22 |
| racarr_ | but anyway | 20:22 |
| racarr_ | sounds like...fix qt (probably not lol) and or change qtubuntu back to use | 20:23 |
| racarr_ | GLES | 20:23 |
| kgunn | wondered if qt5.2 was going to throw a wrench somewhere | 20:23 |
| racarr_ | ...ugh already feels like a long day | 20:38 |
| racarr_ | unfortunately a little to early for that | 20:38 |
| rsalveti | racarr_: unfortunately that's a build time decision, and we're also having issues with that for the x86 emulator, as we need gles by default | 21:26 |
| rsalveti | I know we have people upstream working to dynamically select the right backend, but would probably be something for qt 5.4 | 21:26 |
| racarr_ | rsalveti: Mm thats what I was saying shocking that it is a ./configure option | 22:16 |
| racarr_ | ok so it is GLES now though so qtubuntu ust needs to use GLES as well | 22:16 |
| racarr_ | / request a GLES context | 22:16 |
| racarr_ | and everyone can be happy | 22:16 |
| racarr_ | bregma: ^ | 22:16 |
| rsalveti | it's not gles by default though | 22:16 |
| rsalveti | desktop uses qt built with gl | 22:17 |
| rsalveti | I think qtubuntu-desktop is also using gl | 22:17 |
| bregma | it looks to me like the patch Add-workaround-for-GL-on-Android-emulator.patch applied to Qt5.2 just Does the Wrong Thing regarding shaders on the desktop -- it forced GLES shaders on the desktop _unless_ it's running on an Android emulator, if I'm readong the code correctly | 22:18 |
| rsalveti | that patch was dropped for qt 5.2 | 22:18 |
| rsalveti | and I'm adding it again, that's just for emulator | 22:19 |
| rsalveti | we had it in 5.0 for months | 22:19 |
| bregma | I just pulled ubuntu:qtbase-opensource-src, it does not appear to be dropped | 22:19 |
| rsalveti | it only affects the shader if render string is Android Emulator | 22:19 |
| rsalveti | upstream is only using that for the android backedn | 22:20 |
| rsalveti | at least that was the case when I backported the patch | 22:20 |
| rsalveti | checking that again | 22:20 |
| racarr_ | oh sorry misunderstood what rsalveti said | 22:20 |
| racarr_ | thought you meant switched to GLES by deault | 22:20 |
| racarr_ | not need | 22:21 |
| racarr_ | auto optimism completion ;) | 22:21 |
| bregma | "if (d->shaderType == Fragment && !ctx_d->workaround_missingPrecisionQualifiers)" is the key line, and workaround_missingPrecisionQualifiers is false on the desktop, meaning with the patch, the GLES-specifci keywords will not be removed from the shader code | 22:24 |
| bregma | which is exactly what I;m seeing | 22:25 |
| === dandrader|afk is now known as dandrader | ||
| bregma | workaround_missingPrecisionQualifiers is only set to true if glGetString(GL_RENDERER) == "Android Emulator", which is not generally true on the regular desktop | 22:26 |
| rsalveti | bregma: right, but that is the expected behavior | 22:26 |
| rsalveti | the problem here is why are we getting a GLES specific keyword? | 22:26 |
| bregma | oh, so you expect Qt5.2 to not support the desktop? | 22:26 |
| rsalveti | that workaround is needed by the emulator because it uses a GLES->GL translator driver | 22:26 |
| rsalveti | that's why the need to remove the GLES specific keyword | 22:26 |
| rsalveti | a workaround in Qt would be to always force the workaround with true in case the host renderer is GL | 22:27 |
| bregma | that would do it | 22:28 |
| rsalveti | but that will just be indeed a workaround as the main problem is that it shouldn't even be getting the GLES specific shader at all | 22:28 |
| bregma | the only GLES-specific thing about these shaders is the highp/midp/lowp keyword, at least up until recently | 22:29 |
| rsalveti | yup | 22:29 |
| rsalveti | bregma: do you know who is sending the GLES specific shader? | 22:29 |
| bregma | when I was hunting down the qtubuntu problem, they were all default Qt shaders | 22:30 |
| rsalveti | hm, that would be unexpected, as qt was built with GL by default on x86 | 22:31 |
| rsalveti | bregma: we didn't have this issue before, right? | 22:31 |
| bregma | there's only one set of shaders, only difference is the precision keyword that gets undef'd | 22:31 |
| bregma | until I upgraded my desktop to QT5.2, Unity8 was running (with a patched Mir) | 22:32 |
| bregma | now I don't need the Mir patch | 22:32 |
| rsalveti | right, shouldn't be related with mir | 22:34 |
| rsalveti | then, if you want to have this patch applied more generically, we'd need to find a generic way to find if the host is using GL | 22:35 |
| bregma | I think you'll find that if Qt doesn't want to render things nicely on the desktop, there will be a lot of dissatisfied Kubuntu users | 22:37 |
| rsalveti | that's for sure, but if that is indeed broken (qt by default sending GLES specific shaders), we have a major issue | 22:38 |
| rsalveti | I'm still not sure if this is indeed not caused by our stack | 22:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!