| racarr_ | but then decided to try and do the right way | 00:00 |
|---|---|---|
| racarr_ | but the right and wrong way were actually the same. cest la vie. | 00:00 |
| thomi | racarr_: so... you're doing the wrong way? :P | 00:00 |
| racarr_ | thomi: RAther what I assumed was the wrong way because it was a shortcut of sorts | 00:01 |
| racarr_ | ...I think is actually the right way :p | 00:01 |
| racarr_ | and it doesnt matter what order | 00:02 |
| racarr_ | they go in | 00:02 |
| racarr_ | ...all shall become clear in MP | 00:02 |
| thomi | I look forward to testing it | 00:03 |
| racarr_ | thomi: Of course part of the mp involves renaming "Surface" to "NotACursor" so it may take a while to land... | 00:06 |
| racarr_ | kidding :p | 00:06 |
| thomi | racarr_: that's ok, the "I'll finish it the week after I get back from Malta" window has well and truly passed by now :P | 00:07 |
| racarr_ | lol | 00:08 |
| racarr_ | sorry | 00:08 |
| === fginther is now known as fginther|away | ||
| === chihchun_afk is now known as chihchun | ||
| === RAOF_ is now known as RAOF | ||
| Saviq | AlbertA, hey | 11:00 |
| Saviq | AlbertA, we'll need you to run http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh on your branch (local and remote) | 11:01 |
| Saviq | AlbertA, so ./strip-u8-tags.sh lp:~albaguirre/unity8/use-new-display-power-state-interface: /path/to/checkout /path/to/another/checkout | 11:02 |
| Saviq | drop the : | 11:02 |
| Saviq | AlbertA, the remote one will take quite a while | 11:02 |
| Saviq | like 10 minutes | 11:03 |
| === bschaefer_ is now known as bschaefer | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === fginther|away is now known as fginther | ||
| === alan_g|lunch is now known as alan_g | ||
| === renato_ is now known as Guest98529 | ||
| Nothing_Much | Are there known problems with XMir and radeonSI? | 12:51 |
| === Guest98529 is now known as renato__ | ||
| Nothing_Much | Anybody? | 13:01 |
| Nothing_Much | https://bugs.launchpad.net/xmir/+bug/1334050 I'm having stuttering problems with the radeosi driver, just thought I'd let people know about this. | 13:15 |
| ubot5 | Ubuntu bug 1334050 in XMir "XMir logs out when locking the screen on Ubuntu 14.04 with radeon" [Undecided,New] | 13:15 |
| Nothing_Much | *radeonsi | 13:15 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| greyback | Nothing_Much: hey, I don't think we've tested XMir with radeon in a while now (are more focused on mobile at the momemt) | 13:38 |
| greyback | thanks for the bug report though | 13:40 |
| Nothing_Much | greyback: Oh okay | 13:40 |
| Nothing_Much | What kind of mobile chips are you testing on, Qualcomm? | 13:41 |
| kgunn | Nothing_Much: iirc, radeon had issues but we corrected them...but it was one of those tail wag the dog...the radeon driver stack changes can effect xmir | 13:42 |
| greyback | Nothing_Much: anything that runs with android :) So yeah Qualcomm & Tegra | 13:42 |
| kgunn | and like greyback said we've not focused much on xmir lately | 13:43 |
| Nothing_Much | oh why not? | 13:45 |
| Nothing_Much | kgunn: ^ | 13:45 |
| Nothing_Much | oh, xmir isn't on mobile so you're just testing out Mir? | 13:46 |
| kgunn | Nothing_Much: precisely | 13:46 |
| kgunn | Nothing_Much: xmir will feed the rootless X concept...but even that is some distance out on our roadmap from where we are | 13:46 |
| Nothing_Much | 16.04? | 13:47 |
| Nothing_Much | Or are you saying something else? | 13:47 |
| Nothing_Much | kgunn: ^ | 13:58 |
| kgunn | Nothing_Much: well we still have part of a person looking at rootless x even in the midst of our mobile push... | 14:00 |
| kgunn | it would be more of a 15.04-ish target... | 14:01 |
| dandrader | alf__, hey | 14:05 |
| Nothing_Much | nice | 14:05 |
| AlbertA | Saviq: ok I'm running sript-u8-tags.sh | 14:06 |
| Nothing_Much | I really would want an Ubuntu Phone that can play Steam games, but that would be only if there's an x86 chip OR if Valve decides to port Steam over to ARM, which the latter would be so much bettter IMO. | 14:06 |
| dandrader | alf__, I'm in the way of updating unity-system-compositor/devel-mir-next to latest mir/devel. And I'm finding myself duplicating the code from SurfaceStack. i.e. creating my own SurfaceSceneElement and RenderingTracker equivalents. So I wonder if at least the RenderingTracker shouldn't be a public class... | 14:06 |
| dandrader | alf__, and speaking of RenderingTracker, RenderingTracker::active_compositors is named as a getter IMHO, but it's actually a setter | 14:08 |
| Saviq | AlbertA, thanks ideally we'd rebuild u8 to get rid of them in the silo, too, but I can just strip them off trunk again after you land | 14:09 |
| alf__ | dandrader: One approach to consider is to not mess with scene at all, but just hide the sessions/surfaces that are not needed by USC (i.e., everything but current and next) | 14:09 |
| dandrader | SceneElement's rendered_in and occluded_in also sound more like getters... | 14:09 |
| alf__ | dandrader: If I undestand correctly, USC just wants to show the two sessions | 14:10 |
| dandrader | alf__, another thing: Is Scene::scene_elements_for called for every rendered frame? | 14:11 |
| alf__ | dandrader: yes | 14:12 |
| AlbertA | dandrader: alf__: FYI, I don't think that is being used right now since the split greeter is disabled...maybe we can revert the USC scene wrapper for now | 14:14 |
| AlbertA | mterry: ^ | 14:14 |
| dandrader | because in the SurfaceStack implementation it allocates SceneElements on every call. And I always heard that it's a bad thing to allocate memory on every frame (because of the memory allocation overhead). that you should instead reuse it, like in a pool | 14:14 |
| dandrader | or is it insignificant as SceneElement is a pretty small class... | 14:15 |
| mterry | AlbertA, I'd like to not dismantle that infrastructure. USC still needs to handle multiple sessions (at least for the boot animation -- and for the desktop use case) | 14:15 |
| alf__ | mterry: Would hiding sessions other than current and next achieve what you need? | 14:16 |
| AlbertA | mterry: ok | 14:16 |
| mterry | alf__, we already don't include anything but those in the renderable_list | 14:16 |
| mterry | alf__, wouldn't hurt to hide as well... | 14:16 |
| mterry | But I'm not sure of the difference between not being in the renderable list and hiding. Does hiding do extra goodness? | 14:17 |
| alf__ | mterry: that's the point, instead of explicitly managing the renderable_list (which has become harder due to recent changes), we can hide and achieve the same (with some care ensuring active session is on top) | 14:18 |
| alf__ | mterry: i.e., we wouldn't need to override Scene at all | 14:18 |
| mterry | alf__, got it. I can't recall a specific reason it wouldn't work to hide instead. | 14:19 |
| dandrader | mterry, ah, ok. so I guess I can just ignore setting the surface visibility then as that's being taken care of by the selecting of who get in the renderable_list, right? | 14:22 |
| alf__ | dandrader: SceneElement is a lightweight class (and we usually only have a small number of them). Your concern is valid in general, but for now I don't think it causes us any issues (allocators are quite fast). Of course we need to benchmark to really find out if it's worth having a pool. | 14:22 |
| mterry | dandrader, sure, I think USC only cares about session visibility, not surface | 14:24 |
| AlbertA | Saviq: ok it's done... so do you want me to rebuild the package in silo? | 14:29 |
| Saviq | AlbertA, not necessary, depends on how close you are to landing? is there anything missing from you just pressing merge? | 14:29 |
| Saviq | AlbertA, ah, it's to-be-published already | 14:30 |
| Saviq | AlbertA, then no, I'll just add myself to the landing line so I get notified when it's merged | 14:30 |
| AlbertA | Saviq: ok, thanks sorry I didn't now we had to strip tags... | 14:31 |
| Saviq | AlbertA, in general we don't... | 14:31 |
| Saviq | AlbertA, but there comes a time when someone digs out an old branch that got infected with old lp:unity tags.. | 14:31 |
| AlbertA | Saviq: so I pull lp:unity from scratch right now..it won't have those old tags? | 14:32 |
| Saviq | AlbertA, yup | 14:33 |
| Saviq | AlbertA, well, it's enough to just run the script on your local branches | 14:34 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| dandrader | input_sender branch doesn't seem to be working well | 15:53 |
| dandrader | I'm getting "terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' | 15:53 |
| dandrader | what(): Failure sending input event : | 15:53 |
| dandrader | " | 15:53 |
| alan_g | anpok_: ^ | 15:54 |
| anpok_ | i am here | 15:55 |
| anpok_ | dandrader: when do you get that? | 15:56 |
| kdub_ | alf__, maybe we could rid of Renderable::id by having the SceneElement remain the same on different calls to generate the scene | 15:56 |
| * kdub_ has a different renderable cleanup and was just thinking about it | 15:57 | |
| dandrader | anpok_, when unity8 calls surface->consume() | 15:57 |
| dandrader | anpok_, but apps are also not rendering correctly as well and maliit-server keeps crashing. so there might be some other issue there | 15:58 |
| dandrader | anpok_, so *right now* I cannot guarantee that I didn't mess up something on my side. but it does raise a concern | 15:58 |
| dandrader | because yesterday, lp:mir/devel + expose_android_input was working fine... | 15:59 |
| dandrader | and I'm getting those issues with lp:mir/devel + input_sender | 15:59 |
| dandrader | I will dig more into this to be certain | 16:01 |
| anpok_ | hm, ok. odd that there is no errno string in the exception | 16:02 |
| anpok_ | can you tell me which of unity8 I have to look at? | 16:02 |
| dandrader | anpok_, it's a whole bunch of branches you have to build, not just unity8. so it takes a while to have the whole everything built :( | 16:02 |
| dandrader | ie: qtmir, qtubuntu, platform-api, unity8, unity-system-compositor | 16:03 |
| dandrader | besides mir, of course :) | 16:03 |
| === dandrader is now known as dandrader|afk | ||
| alf__ | kdub_: it's plausible, depends on what the id() is used for | 16:10 |
| kdub_ | alf__, yeah, maybe? part of the getting the demo shell to play nicely with hwc? still assessing | 16:15 |
| kdub_ | josharenson, I'm starting a performance improvement that might be a good thing to measure/test out the client ui performance stuff | 16:23 |
| kdub_ | are those ui performance examples/tests in CI or some branch? | 16:24 |
| josharenson | kdub_ explain? | 16:29 |
| kdub_ | I heard that there are some UI benchmarks floating around, which would be good for me to measure the branch... and perhaps good for improving or testing those benchmarks | 16:29 |
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| dandrader | anpok, this is what we're getting http://pastebin.ubuntu.com/7707082/ | 17:58 |
| dandrader | and the locals on frame #10 http://pastebin.ubuntu.com/7707086/ | 17:59 |
| anpok | error_status | 18:01 |
| greyback | -9 | 18:05 |
| greyback | whatever that is | 18:05 |
| anpok | could be EBADF | 18:10 |
| greyback | I don't see that in 3rd_party/android-deps/std/Errors.h tho | 18:11 |
| anpok | it reads errno .. and if it is one of the errors it does not handle it retuns -errno | 18:12 |
| anpok | (it == android::InputChannel) | 18:12 |
| === dandrader is now known as dandrader|lunch | ||
| === renato_ is now known as Guest82399 | ||
| === Guest82399 is now known as renato__ | ||
| Saviq | AlbertA, kgunn, any reason why I should not merge&clean silo 20? | 20:40 |
| AlbertA | Saviq: I was about to...:) | 20:40 |
| AlbertA | Saviq: but go ahead | 20:40 |
| Saviq | AlbertA, doing | 20:41 |
| Saviq | AlbertA, don't pull from unity8 for a few mins, stripping the tags | 20:42 |
| AlbertA | Saviq: sure, thanks | 20:42 |
| Saviq | AlbertA, sorry for not being more involved with that work, you've done a grand job there! | 20:43 |
| AlbertA | Saviq: np, cheers! | 20:44 |
| === no_mu is now known as Nothing_Much | ||
| === dandrader|lunch is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!