| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === jono is now known as Guest96931 | ||
| stgraber | is anyone from the mir/unity8 team around? | 08:19 |
|---|---|---|
| stgraber | I'm preparing a demo for Malta and I'd like to know if it's at all possible to get unity8+mir running under kvm? | 08:20 |
| stgraber | so far I tried with all video drivers and they all get me an error about some drm operation being unsupported | 08:20 |
| stgraber | I can get things working the way I want on bare metal but it's slightly annoying having to reboot every few minutes to get out of Mir and back to X... | 08:21 |
| alf_ | stgraber: we haven't tried under kvm yet. Actually running under VMs of all kind is a topic for Malta next week. | 08:23 |
| alf_ | stgraber: Why do you need to reboot to go from Mir to X? Doesn't 'sudo restart lightdm' work for you? | 08:23 |
| stgraber | alf_: so the demo I'm preparing is running unity8+mir from utopic inside an LXC container on trusty. I got things to work though once unity8 starts I'm unable to kill it or even VT switch | 08:28 |
| stgraber | so far the only way I've found out of it is to use sysrq to physically reboot my machine... | 08:28 |
| alan_g | stgraber: I saw an email that might apply (from Friday). Forwarding... | 08:30 |
| * ogra_ remembers seeing a bug about Mir not working in virtual envs | 08:30 | |
| alan_g | But like alf says this is something we're getting to real soon now | 08:31 |
| stgraber | cool, that'll be helpful. Until then, how am I expected to get unity8+mir to exit once started? I'm sure there's a way but it's either broken (possibly my fault) or I just haven't found it yet ;) | 08:32 |
| anpok | there was a strange ci failure on friday it seems - could someone retrigger https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806/comments/525069 | 08:32 |
| alf_ | anpok: sure | 08:33 |
| alan_g | stgraber: "stop unity8"? SIGTERM? Ctrl+Alt+Backspace? | 08:33 |
| stgraber | alan_g: stop unity8 or sigterm would probably work if I could get to a shell first (I'm working away from home so just have the one laptop). ctrl-alt-backspace didn't work. VT switching hotkeys didn't either. | 08:35 |
| * alan_g thinks if input isn't working... "start unity8 & (sleep 10 && stop unity8)" | 08:39 | |
| stgraber | well, input seems to work, I can type in unity8 just fine, I just can't figure out the right sequence to get out of it :) | 08:41 |
| alan_g | stgraber: is input still working after starting unity8? | 08:45 |
| alan_g | "ctrl-alt-backspace didn't work. VT switching hotkeys didn't either" | 08:45 |
| stgraber | text input after starting unity8 works fine, it's just the ctrl-alt-* hotkeys that seem entirely ignored | 08:47 |
| alan_g | stgraber: so you can start the terminal app? | 08:49 |
| alan_g | alf_: I'm tempted by the idea that we should have "slow, clumsy, unreliable, muted" test executable for bad tests rather hiding them as unit/acceptance tests. It would make the problem more visible and provide a focus for any "clean up" drive. | 09:40 |
| alf_ | alan_g: A lot (all?) of our slow tests are actually stress tests. I would be OK with having a separate stress test category. A problem I see with moving all clumsy/unreliable etc tests to a separate executable is that we would need to (de)duplicate the infrastructure needed for them to run. | 09:48 |
| alf_ | alan_g: I agree that having a separate executable would increase visibility, but on the other hand it may also reduce the incentive to do so. For example, a mentality of: we have a category for bad tests so it's OK to have a bad test and put it there and forget it | 09:49 |
| alf_ | alan_g: "reduce the incentive to fix it" | 09:50 |
| alan_g | alf_: we'd need a rule "for each new new bad test you write you must remove at least one existing one" | 09:51 |
| alan_g | You and I have both proposed DISABLED tests recently...if we'd had to fix an existing test... | 09:54 |
| alan_g | alf_: I do agree that having stress tests in mir_unit-tests is misleading at best (as is requiring libumockdev-preload) | 09:56 |
| * alan_g hates waiting 30sec for tests to run | 09:57 | |
| === mpt_ is now known as mpt | ||
| === alan_g is now known as alan_g|lunch | ||
| anpok | https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806 any objections against landing this? | 12:10 |
| greyback | alf_: just to confirm Compositor::stop should be called on display blank for a nested server? | 12:43 |
| alf_ | greyback: do you mean as part of the sequence Compositor::stop, reconfigure, Compositor::start? | 12:46 |
| alf_ | greyback: I think that at the moment only the host server (i.e. unity-system-compositor) does anything about the "power off" event | 12:49 |
| === alan_g|lunch is now known as alan_g | ||
| === pete-woods is now known as pete-woods-lunch | ||
| stgraber | system-settings: /build/buildd/platform-api-1.1.0+14.10.20140515.1/src/ubuntu/mirserver/ubuntu_application_api_mirserver.cpp:106: UApplicationInstance* u_application_instance_new_from_description_with_options(UApplicationDescription*, UApplicationOptions*): Assertion `surface_coordinator' failed. | 13:24 |
| stgraber | any idea what would cause that? ^ | 13:24 |
| stgraber | it's apparently preventing me from starting any app from unity8 here | 13:24 |
| stgraber | (that's still in my weird LXC environment, so I may be missing some env variables or packages) | 13:25 |
| alan_g | stgraber: for platform api I usually ask greyback YMMV | 13:27 |
| stgraber | greyback: ^ | 13:28 |
| greyback | stgraber: have you QT_QPA_PLATFORM set in your env? | 13:28 |
| greyback | stgraber: for apps, it should be set to "ubuntumirclient" | 13:29 |
| stgraber | greyback: ah, that may be the problem then, I have it set to ubuntumirserver in order to start unity8, it may then get picked up for the rest too... | 13:29 |
| greyback | stgraber: yeah, ubuntumirserver only for unity8, ubuntumirclient for all apps | 13:30 |
| ogra_ | stgraber, take a look at /etc/environment on a phone/tablet | 13:30 |
| stgraber | greyback: oh, looks like I can drop the export as the upstart job does that for me nowadays | 13:30 |
| ogra_ | there are a lot of env vars | 13:30 |
| greyback | stgraber: it does indeed | 13:30 |
| ogra_ | (half of them probably obsolete) | 13:30 |
| ogra_ | QT_SELECT=qt5 .... QT_IM_MODULE=maliitphablet ... QML2_IMPORT_PATH=/usr/lib/arm-linux-gnueabihf/qt5/imports ... | 13:31 |
| ogra_ | these look relevant | 13:31 |
| stgraber | greyback: that did the trick, thanks! | 13:32 |
| greyback | stgraber: yw | 13:32 |
| ogra_ | the QT_SELECT one is needed so that apps start up fine btw ... | 13:32 |
| ogra_ | else it will try to default to Qt4 | 13:33 |
| stgraber | ogra_: I'll take a look at those, I still have an issue with libEGL complainig that my platform is unsupported so maybe one of those will fix that (required by at least the webbrowser AFAICT) | 13:33 |
| ogra_ | ubuntu-touch-session also sets a few ... | 13:34 |
| ogra_ | in the lightdm bits it ships | 13:34 |
| ogra_ | (this is all a serious mess we need to clean up beofre RTM) | 13:34 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|tea | ||
| === pete-woods-lunch is now known as pete-woods | ||
| racarr__ | morning | 14:59 |
| anpok | hi | 15:01 |
| === alan_g|tea is now known as alan_g | ||
| anpok | hm is there a workaround for the issue with gdb? | 15:42 |
| alan_g | anpok: what issue? | 15:43 |
| anpok | the current unicorn version crashes when it tries to load the mir_unit_tests | 15:43 |
| anpok | https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1319316 | 15:47 |
| ubot5 | Ubuntu bug 1319316 in gdb (Ubuntu) "gdb: Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)" [Undecided,Incomplete] | 15:47 |
| alan_g | dunno - I've not got a problem | 15:50 |
| anpok | then dont upgrae :) | 15:52 |
| kdub_ | any other reviews on https://code.launchpad.net/~kdub/mir/post-if-optimizable/+merge/217991 ? | 15:55 |
| alan_g | Why would I? ;) | 15:57 |
| === dandrader is now known as dandrader|lunch | ||
| mterry | racarr__, kdub_, (or others): I'm looking at an issue in split greeter mode. When sliding the greeter away, the user can see a bit of their session underneath because the greeter is transparent. This works fine when seeing the unity8 shell underneath. But if the user session is running an app on top, the surface appears just black, until the session is focused again. Why might that be? | 16:43 |
| racarr__ | top approve https://code.launchpad.net/~mir-team/mir/cursor-spike-bonus-phase-correct-gbm-cursor-hide/+merge/219764 ? | 16:46 |
| racarr__ | mterry: No immediate ideas -.- | 16:46 |
| racarr__ | turning it over in head though | 16:47 |
| mterry | racarr__, I believe the app would be 'lifecycled' during that period | 16:47 |
| mterry | I think... | 16:47 |
| mterry | But I don't know if the black is expected behavior in that state (I would think not, just keep the last frame, eh? but who knows) | 16:48 |
| racarr__ | hmm I guess I would expect the last frame too | 16:49 |
| racarr__ | certainly not black | 16:50 |
| greyback | mterry: check if the app surface is hidden when lifecycles. I suspect it might be | 16:57 |
| === alan_g is now known as alan_g|EOD | ||
| racarr__ | ah | 16:58 |
| === dandrader|lunch is now known as dandrader | ||
| anpok | mterry: is unity8 rendering in that case? | 17:11 |
| anpok | while sliding away the greeter.. i mean.. | 17:11 |
| mterry | anpok, I don't know about active rendering | 17:12 |
| mterry | anpok, let me test with something that woulld play animation | 17:12 |
| mterry | anpok, yes, active rendering | 17:13 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| racarr__ | Just reading mps... | 18:04 |
| racarr__ | This is the last time I ill bring it up lol but | 18:04 |
| racarr__ | I really feel we made a mistake with server side window decorations | 18:04 |
| racarr__ | already there is all this stuff to support them, and various concerns (i.e. even in DPI branch) | 18:05 |
| racarr__ | and I don't remember any reasons to do server side. | 18:05 |
| racarr__ | Also kind of feels like we are at MP gridlock again | 18:17 |
| racarr__ | kgunn: What is the deal on RAOF or someone getting a touchscreen...I've found out whats wrong with desktop touchscreens | 18:20 |
| racarr__ | but am not totally confident in fixing without doing some experimenting | 18:20 |
| kgunn | racarr__: can you purchase one reasonably ? | 18:22 |
| kgunn | if so, please do and expense | 18:22 |
| kgunn | racarr__: btw, i thot voss wanted "mir" side decorations, but client side not server side ? | 18:23 |
| racarr__ | Haha theres always an option 3 | 18:23 |
| racarr__ | um...I wasnt aware thats what tvoss wanted, I know its come up before | 18:24 |
| racarr__ | sounds better than server side to me. | 18:24 |
| kgunn | racarr__: yeah...but i can't remember why i'm convinced of that... | 18:24 |
| racarr__ | but I think since | 18:24 |
| racarr__ | um | 18:24 |
| racarr__ | not this last london sprint | 18:24 |
| racarr__ | but the one before that | 18:24 |
| racarr__ | everyone has been on the server side decorations boat | 18:24 |
| * kgunn wonders if the terms are getting overloaded and not specific enough | 18:25 | |
| racarr__ | also now we have some server side decorations | 18:25 |
| racarr__ | haha, well you can get more specific | 18:25 |
| racarr__ | but server side/client side is still meaningful as | 18:25 |
| racarr__ | rendered by the server or rendered by the client | 18:25 |
| racarr__ | you could also say "in/out buffer" | 18:25 |
| kgunn | right, i think people say "server side"....when they really don't mean the server side | 18:26 |
| kgunn | e.g. "client side of mir" | 18:26 |
| racarr__ | hmm | 18:26 |
| kgunn | racarr__: but anyway...its worth bringing up | 18:27 |
| racarr__ | maybe some people. I dunno | 18:27 |
| kgunn | with voss and duflu | 18:27 |
| kgunn | maybe even on mir-devel... | 18:27 |
| racarr__ | I know the shell team is on drawing the decorations server side with qt | 18:27 |
| racarr__ | because its quite easy and nice...im not sure how much harder it really is on the client though (I dont think it is) | 18:27 |
| racarr__ | *shrug* | 18:27 |
| racarr__ | ILl bring it up in malta! | 18:27 |
| racarr__ | lol | 18:28 |
| anpok | i thought there was a discussion to allow both | 18:28 |
| racarr__ | certainly client side is allowed, I mean you can freestyle window type | 18:28 |
| kgunn | anpok: 4th option :) | 18:28 |
| racarr__ | then draw your own decorations | 18:28 |
| anpok | that certain areas were prepared for the client to render ontop of the decoration the server would provide if necessary | 18:28 |
| racarr__ | oh in a seperate client rendered buffer... | 18:29 |
| anpok | i think tvoss shared a drawing some time ago | 18:29 |
| anpok | i think so | 18:29 |
| anpok | well | 18:29 |
| racarr__ | I remember that coming up too lol, yes I think that is tvoss's concept | 18:29 |
| anpok | separate buffer should be the easiest way to do that | 18:30 |
| racarr__ | I still cant think of any reasons | 18:31 |
| racarr__ | to do anything besides client side decorations though | 18:31 |
| anpok | :) | 18:31 |
| racarr__ | which is the simplest | 18:31 |
| racarr__ | and almost certainly | 18:31 |
| racarr__ | the most efficient | 18:31 |
| racarr__ | I guess | 18:32 |
| anpok | that way you can easily ensure that each decoration works and looks the same, and if clients are not supposed to draw any decoration it is far more easy to provide the client surfaces without decoration | 18:32 |
| anpok | of course you could also let the client draw to one buffer with decoration, and request additional information which parts of the buffer belongs to the decoration and which is the actual content.. | 18:33 |
| racarr__ | but I mean, I dont think we have any cases like | 18:34 |
| anpok | we? | 18:34 |
| racarr__ | this windo has a decoration and then loses it without | 18:34 |
| racarr__ | client cooperation | 18:34 |
| racarr__ | what is | 18:34 |
| tvoss | racarr__, the real question is: How do you enforce some baseline consistency for the decorations if you only do client side decorations? | 18:34 |
| anpok | you mean actively request rerender because you need the client with different decoration configuration? | 18:35 |
| racarr__ | tvoss: librender_unity_decorations::RenderDecorations(EGLSurface,Context) | 18:35 |
| racarr__ | in toolkit ports | 18:35 |
| anpok | then you are as complex as ssd | 18:35 |
| racarr__ | anpok: I mean the client doesnt change decoration configuration | 18:35 |
| tvoss | racarr__, that's a guideline at best :) | 18:35 |
| racarr__ | ever unless it changes window type | 18:35 |
| racarr__ | tvoss: But then why support freestyle surfaces? I mean chromium will want that right, presumably some other things | 18:36 |
| racarr__ | so there is always going to be a way to do your own window decorations | 18:36 |
| tvoss | racarr__, chromium would actually be better off with separate surfaces for decorations | 18:36 |
| tvoss | racarr__, sure,but freestyle is really only meant to be reserverd for special cases like vmware fusion mode | 18:37 |
| racarr__ | tvoss: "thats a guideline at best" | 18:37 |
| tvoss | racarr__, sure, but we can guard usage of that surface type with an apparmor hook | 18:38 |
| racarr__ | That's true | 18:38 |
| racarr__ | I guess I didn't think we were taking rogue decorating apps that seriously | 18:39 |
| tvoss | racarr__, we would like to be able to at least | 18:39 |
| racarr__ | Mm. | 18:40 |
| mterry | greyback, just getting back to you now about the "check if session is hidden when lifecycled" and yes, it is in unity-mir. Would there be ill-effects if we don't do that? | 19:16 |
| greyback | mterry: I don't apps running if the greeter hiding them | 19:17 |
| greyback | +is | 19:17 |
| mterry | greyback, sorry didn't parse | 19:17 |
| greyback | mterry: ill-effects of a hidden session being lifecycled was the topic, no? | 19:18 |
| greyback | ah | 19:18 |
| mterry | greyback, ill effects if we lifecycle an app but don't hide it | 19:18 |
| greyback | mterry: that's fine. No ill effects I can think of anyway. unity-mir does hide surfaces that belong to lifecycled apps, to optimize compositing just that little bit more | 19:19 |
| mterry | greyback, I'll try a patch and see if that fixes my black screen behavior | 19:20 |
| === dandrader is now known as dandrader|aflk | ||
| === dandrader|aflk is now known as dandrader|afk | ||
| greyback | mterry: ok. That compositing point above is the only impact not-hiding will have - but I think we did that for a reason, so best not disable it altogether | 19:22 |
| mterry | greyback, I'll see if bzr blame gives an explanation | 19:23 |
| greyback | mterry: we did it as compositing with multiple apps open got too slow and the frame time went too high, so the UI juddered | 19:25 |
| greyback | as the compositor was drawing the bottom surface, then the next one on top, then the next one, and so on | 19:26 |
| greyback | which is wasteful as we know only the top surface is actually visible | 19:26 |
| mterry | greyback, ah right... that makes sense for apps hidden underneath | 19:27 |
| mterry | greyback, but now I'm interested in just the top app | 19:27 |
| mterry | greyback, it would be nice to have a way to suspend but not hide that app | 19:27 |
| greyback | mterry: yep. Those operations will need to be de-coupled in unity-mir to fix your problem | 19:28 |
| mterry | greyback, maybe it would make sense in this case to just not hide the focusedApp. unity-mir has enough info to do that itself | 19:29 |
| greyback | mterry: yep, that would be fastest option | 19:30 |
| mterry | or either stage app I guess | 19:30 |
| mterry | greyback, OK will test with that plan and propose an MP if it works for me | 19:30 |
| mterry | greyback, thanks! | 19:31 |
| === dandrader|afk is now known as dandrader | ||
| anpok | hm we could also at some point stop using rgba buffers when other buffer types are available | 19:35 |
| === josharenson1 is now known as josharenson | ||
| greyback | anpok: +1 | 19:57 |
| kgunn | AlbertA: i'm testing silo1 with the powerd rework..looks like greeter never returns after the first dismissal | 20:30 |
| AlbertA | kgunn: did that make it in? https://code.launchpad.net/~albaguirre/unity8/use-new-display-power-state-interface/+merge/219552 | 20:32 |
| kgunn | AlbertA: yes, its in the mp list, but...package looks old ish...built on 5/16 ? | 20:33 |
| AlbertA | kgunn: what does this say: | 20:35 |
| AlbertA | adb shell cat /usr/share/unity8/Shell.qml | grep Powerd.Off | 20:35 |
| kgunn | if (status == Powerd.Off && (flags & Powerd.UseProximity) == 0) { | 20:36 |
| kgunn | and | 20:36 |
| kgunn | if (status == Powerd.Off) { | 20:36 |
| AlbertA | yeah it still the old version | 20:37 |
| kgunn | AlbertA: ok, lemme rebuild | 20:37 |
| kgunn | hmm | 20:37 |
| kgunn | yeah...that'll take a while | 20:39 |
| racarr__ | the more I look at the compiz focus stealing prevention code the more im convinced | 20:43 |
| racarr__ | its in correct in like 4 places in the same function | 20:43 |
| racarr__ | ...*puts on blinders* | 20:43 |
| mterry | racarr__, I know 2 don't, but surely 4 wrongs make a right? | 20:49 |
| racarr__ | damnit short email turned in to a small essay again :( | 20:50 |
| racarr__ | mterry: Lol maybe | 20:50 |
| racarr__ | rotating in a circle is actually very much like what happens to the truth values in this codepath | 20:50 |
| racarr__ | ol | 20:50 |
| racarr__ | ok afk for 20 minutes or so to clear head before I dive in to DDX | 21:00 |
| racarr__ | compiz code stirred up this whole dormant tree of my brain lol | 21:00 |
| racarr__ | back | 21:26 |
| kgunn | AlbertA: looking good man...powerd stuff | 22:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!