| duflu | RAOF: Are the new valgrind failures related to your stuff that landed? https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/820/console | 06:21 |
|---|---|---|
| RAOF | duflu: Indirectly, yes; leaks in the clients are now fatal, too. | 06:23 |
| duflu | RAOF: Hmm, but existing bugs should have blocked it from passing CI before it landed | 06:24 |
| RAOF | duflu: But these are obviously nondeterministic failures, because my CI run passed. | 06:24 |
| duflu | Whee | 06:24 |
| RAOF | I love a nondeterministic leak in the morning! | 06:24 |
| duflu | Woo code review backlog halved yet again | 07:30 |
| duflu | Interesting. I had to start almost 50 Mir clients blended over each other before any of them slowed down. That's probably pretty good. | 07:38 |
| duflu | Arguably 100 (dual screen clone mode) | 07:39 |
| === alan_g is now known as alan_g|reboot | ||
| duflu | alan_g, alf__: Am I the only one subscribed to USC bugs? | 09:30 |
| duflu | Or am I just the only one particularly interested in them? :) | 09:30 |
| alf__ | duflu: I am not getting any notifications, let me change that | 09:30 |
| alan_g | duflu: you're interested in USC bugs?! | 09:30 |
| duflu | alan_g: I mean willing to triage | 09:31 |
| duflu | alf__: Particularly Ubuntu project bugs for package "unity-system-compositor" ;) | 09:31 |
| duflu | alf__: I found myself looking at how the cursor logic works, and wonder; do we ever intend to support multiple cursors? | 09:49 |
| duflu | MirMotionEvent would appear to not care how many there are | 09:49 |
| alf__ | duflu: I haven't heard of such a requirement. Is there a use case for multiple cursors? | 09:52 |
| duflu | alf__: Just wondering, if I had to modify it whether only one would still be acceptable | 09:52 |
| alan_g | duflu: I don't think we have any cursor "use cases" but racarr is working on that. I've seen mentions of touch devices having multiple cursors (up to ten) - but I don't know if that is the same thing (because we've not decided what a cursor is) | 09:56 |
| duflu | OK, doesn't seem like a big issue | 09:57 |
| RAOF | alan_g: Actually, Apple touchpads do up to 15 touches, for some reason :) | 09:57 |
| * alan_g counts fingers, toes, nose and wonders... | 09:58 | |
| RAOF | duflu: Those cursors in MirMotionEvent correspond to touches; unless you think we don't need to support >1 touch, you'll need to keep them all :) | 09:58 |
| duflu | RAOF: The issue then is you have to assume pointer[0] is the cursor | 10:00 |
| RAOF | No you don't. | 10:00 |
| RAOF | Sorry; phone. Let me expound: | 10:04 |
| RAOF | You don't assume pointer[0] is the cursor; you only move the cursor in response to MirMotionEvents that come from relative input devices; mice, trackpads, etc. | 10:05 |
| RAOF | And then, generally, only when there's a single entry in pointer[] (because otherwise you're on a touchpad doing something like a two-finger scroll, which shouldn't move the cursor) | 10:05 |
| duflu | RAOF: Maybe it's just that I never cared to find out the kind of device a motion event comes from, trying to be widely compatible... | 10:06 |
| RAOF | Yeah, but for cursors you need to care. Because cursors only make sense for relative input devices. | 10:07 |
| === dandrader is now known as dandrader|afk | ||
| alan_g | is anyone looking at the CI failures? Seems to be bug 1293944 | 10:46 |
| ubot5 | bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged] https://launchpad.net/bugs/1293944 | 10:46 |
| === dandrader|afk is now known as dandrader | ||
| alan_g | alf__: is anyone looking at the CI failures? Seems to be bug 1293944 | 12:08 |
| ubot5 | bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged] https://launchpad.net/bugs/1293944 | 12:08 |
| alf__ | alan_g: I am not (not yet at least) | 12:09 |
| alf__ | alan_g: What changed and we are now having this problem? I don't remember having that issue in the past. | 12:11 |
| alan_g | alf__: I don't know - I've not looked into it either. (It might well "go away" as the CI system images get updated) | 12:13 |
| alf__ | alan_g: it could also be a CI script issue... Why is libmirserver16 even installed at that point? The packages built by CI have libmirserver17 in them. | 12:19 |
| alan_g | Could it be a transitive dependency? e.g. mesa? | 12:28 |
| alf__ | alan_g: It could, but unfortunately the logs are not verbose enough to see what's being installed | 12:31 |
| alan_g | alf__: OK I'll go ask on #ubuntu-ci-eng | 12:40 |
| alan_g | It seems odd that we install *any* to build Mir. | 12:43 |
| alan_g | **any* Mir library | 12:43 |
| === alan_g is now known as alan_g|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf__: cjohnston thinks he may have found the CI problem - testing now. (Hopefully we'll see a result before EOD) | 14:21 |
| cjohnston | alf__: AIUI, with the system-images.u.c changes, that broke our flashing jobs, which prevented devices from being cleaned before the next job ran | 14:22 |
| alf__ | alan_g: cjohnston: thanks! | 14:22 |
| robotfuel | alan_g: fyi ci is failing because a json file moved on a server and phablet-flash isn't resetting the devices like it should be. the phablet-flash jobs are being updated now. | 14:25 |
| robotfuel | kgunn: ^ | 14:26 |
| kgunn | thanks for the heads up | 14:26 |
| kgunn | wondered why our mp's were so "red" this morning | 14:26 |
| kgunn | thot jenkins was a hater | 14:27 |
| mterry | alan_g, I just retested all my split stuff with Mir 0.1.7 and I'm seeing similar (not sure if same yet) symptoms to before your fix to the early buffers in nested mode landed. Were there other changes that might have affected that? | 15:13 |
| alan_g | mterry: otp - 30min | 15:14 |
| mterry | np | 15:14 |
| davmor2 | kgunn: I'm not loving mir today | 15:15 |
| kgunn | got it | 15:15 |
| === dandrader is now known as dandrader|lunch | ||
| alan_g | mterry: sorry - meeting covered a lot more that I expected | 16:40 |
| mterry | alan_g, no worries, I got sidetracked myself | 16:40 |
| mterry | alan_g, so! I remember testing your branch earlier in relative isolation on top of 0.1.6 | 16:40 |
| mterry | alan_g, and what I saw was seamless transitions between my "spinner" app and the greeter. This was presumably because the greeter didn't create a surface until it had one ready to paint | 16:41 |
| alan_g | mterry: I'm not aware of there being anything that reverts the changes, but there are some issues seen elsewhere. Mo | 16:41 |
| mterry | alan_g, today I tested on top of 0.1.7 and I'm seeing a "black gap" between spinner and greeter | 16:41 |
| mterry | alan_g, not sure if you're familiar with what I mean by spinner | 16:42 |
| alan_g | mterry: I'm not | 16:42 |
| alan_g | But these are similar effects to what you describe: <kgunn> bugs -> https://bugs.launchpad.net/mir/+bug/1294051 https://bugs.launchpad.net/mir/+bug/1294053 https://bugs.launchpad.net/mir/+bug/1294048 | 16:42 |
| ubot5 | Ubuntu bug 1294051 in Mir "Apps are much slower to open" [Critical,New] | 16:42 |
| ubot5 | Ubuntu bug 1294053 in Mir "Settings app opens to a blank screen unless given enough time to render or the app is touched" [High,Confirmed] | 16:42 |
| ubot5 | Ubuntu bug 1294048 in Mir "Touch has a rotate issue" [Medium,Confirmed] | 16:43 |
| mterry | alan_g, the spinner is just a small client that USC uses when a Mir session is supposed to be focused but isn't ready yet (like on boot, or on lock if the greeter is slow to appear) | 16:45 |
| alan_g | I guessed as much | 16:45 |
| mterry | alan_g, and USC switches to the session once it has a surface | 16:46 |
| alan_g | And the "black gap" was the sort of artifact you saw when the nested session posted buffers prematurely? | 16:48 |
| alan_g | AlbertA: not sure if you've found anything, but this ^^ sounds like it might be another symptom of the same problem. | 16:49 |
| mterry | alan_g, yeah | 16:49 |
| AlbertA | alan_g: yeah I found the issue | 16:49 |
| * mterry perks up | 16:49 | |
| alan_g | \o/ | 16:49 |
| alan_g | What is it? | 16:50 |
| AlbertA | alan_g: | 16:50 |
| AlbertA | alan_g: oops, it's renderable.buffers_ready_for_compositor() > 1; | 16:50 |
| AlbertA | it should be > 0 | 16:50 |
| AlbertA | in rendering operator | 16:50 |
| alan_g | It shouldn't | 16:50 |
| AlbertA | it always misses the last frame | 16:50 |
| AlbertA | because it's asked | 16:50 |
| AlbertA | after compositing | 16:51 |
| AlbertA | not before | 16:51 |
| alan_g | But the one it just composited is still "ready" | 16:51 |
| AlbertA | alan_g: nope | 16:51 |
| alan_g | and shouldn't be counted | 16:51 |
| AlbertA | alan_g: that | 16:51 |
| alan_g | AlbertA: but the renderable doesn't know which compositor rendered the buffer: there's always one "ready". | 16:53 |
| AlbertA | alan_g: ummm | 16:53 |
| * mterry can easily test to see if it at least solves my problem (as a data point) | 16:54 | |
| AlbertA | alan_g: why would there always be one ready | 16:54 |
| AlbertA | in any case it does solve the 3 bugs | 16:55 |
| alan_g | At the expense of always scheduling another compositing pass. | 16:55 |
| AlbertA | alan_g: because there were buffers ready though | 16:55 |
| AlbertA | alan_g: from my log the client posted one | 16:55 |
| AlbertA | alan_g: and it was not composited | 16:56 |
| AlbertA | alan_g: at the end | 16:56 |
| AlbertA | alan_g: i.e you see a client_release, but no following compositing step | 16:56 |
| alan_g | AlbertA: OK that is wrong, but I don't think the fix is right (or at least complete) | 16:57 |
| AlbertA | alan_g: sounds like a race between asking the number of ready buffers | 16:57 |
| AlbertA | alan_g: and when compositors release the acquired buffer? | 16:58 |
| AlbertA | alan_g: from what I gather from your comments | 16:58 |
| alan_g | The fact that a buffer has been composited doesn't make it unavailable for compositing | 16:58 |
| alan_g | Because another compositor can use it for the same frameno on a different screen | 16:59 |
| AlbertA | alan_g: right...but then we need a notion of | 16:59 |
| AlbertA | alan_g: of buffers not posted by any compositor | 16:59 |
| AlbertA | alan_g: call I suppose | 16:59 |
| AlbertA | alan_g: ahh which I guess nCompositors fills that role | 17:01 |
| alan_g | But compositor B still needs to render the buffer even though compositor A has already done so. | 17:03 |
| AlbertA | alan_g: yeah I got that | 17:03 |
| AlbertA | alan_g: just trying to see how we can check the number of pending buffers for a specific compositor | 17:04 |
| AlbertA | alan_g: since right now rendering operator does not have any knowledge of what compositor is being called from | 17:05 |
| alan_g | I figured it was the number ready for compositing less the one we just composited. | 17:05 |
| AlbertA | well in the case of one compositor | 17:05 |
| AlbertA | only | 17:05 |
| AlbertA | nready does go down | 17:05 |
| alan_g | But you're right - that one can have been "eaten" by the client | 17:05 |
| AlbertA | but for multi compositor it does not for the reasons you mention | 17:05 |
| * alan_g didn't do enough testing on single monitor setup. /o\ | 17:06 | |
| alan_g | So if we move "uncomposited_buffers |= renderable.buffers_ready_for_compositor() > 1;" to the top of the function? | 17:11 |
| alan_g | We'll get the count we actually want regardless of the number of compositors? | 17:11 |
| AlbertA | alan_g: I think so, but still racy isn't it between compositors? | 17:12 |
| alan_g | AlbertA: I think they should see the same value - because the count changes later. | 17:14 |
| alan_g | But this isn't my favourite code to reason about | 17:15 |
| kdub | yeah, not mine either | 17:17 |
| kdub | seems a good time to diffuse some of it though | 17:17 |
| AlbertA | alan_g: yeah the nReady logic is hard to follow | 17:18 |
| alan_g | AlbertA: are you set up to test shifting the assignment? | 17:20 |
| AlbertA | alan_g: I'm about to test it | 17:20 |
| AlbertA | alan_g: I mean on android, I don't have a multimonitor setup at the moment | 17:22 |
| alan_g | AlbertA: I do - and am about to build it | 17:22 |
| mterry | AlbertA, I did test your > 0 change for giggles and it didn't fix the issue I was seeing. Should I try moving assignment or do you think that means that my problem is not the same? | 17:23 |
| AlbertA | mterry: probably not the same then | 17:23 |
| AlbertA | alan_g: yeah moving the assignment works well here | 17:24 |
| alan_g | AlbertA: I don't see any obvious side-effects on multi-monitor | 17:29 |
| mterry | alan_g, AlbertA: assuming that wasn't my bug then, I'll take any wild guesses before I start deep-diving to find difference | 17:29 |
| AlbertA | mterry: yeah this is more about not compositing the last posted buffer from a client | 17:31 |
| AlbertA | mterry: sounds like you still have a blank buffer kinda issue no? | 17:31 |
| mterry | AlbertA, alan_g: currently USC is just using the existence of a surface to start showing it. Should I be calling something like "ready_to_composite()" on the surface/session to confirm it's ready to be shown? | 17:32 |
| alan_g | mterry: there's a buffer available when swap_buffers after called with a non-nullptr parameter | 17:34 |
| alan_g | mterry: there's a buffer available after swap_buffers called with a non-nullptr parameter | 17:34 |
| alan_g | The surface exists as soon as the client creates it | 17:35 |
| mterry | alan_g, guh, OK. I have to go back to intercepting swap_buffers. When I tested with your branch before, I didn't need to bother with that, so I assumed things had changed. No biggie. I can test with that | 17:35 |
| mterry | alan_g, thanks | 17:35 |
| anpok | hm is there something wrong with nested in devel? | 17:44 |
| alan_g | anpok: other than ^^? | 17:45 |
| anpok | :) | 17:46 |
| anpok | if i start demo shell as root, chmod 666, then conenct another demo shell as user, vt switch does not hang.. everything seems fine | 17:46 |
| anpok | as soon as I start e.g. finger paint connecting to the nested shell vt freezes | 17:47 |
| alan_g | anpok: are the server processes still running? | 17:48 |
| anpok | sleeping all of them. | 17:52 |
| alan_g | anpok: what about simpler clients? mir_demo_client_basic for example? | 17:54 |
| anpok | not yet tried .. first tried on my branch then on devel .. | 17:54 |
| anpok | if it fails you see me reconnect.. | 17:55 |
| anpok | since restarting x did not help either | 17:55 |
| alan_g | anpok: the other thing to try is sshing in and "sudo chvt" | 17:57 |
| alan_g | AlbertA: it also fixes lp:1290306 | 18:02 |
| AlbertA | alan_g: really? nice | 18:03 |
| AlbertA | alan_g: so screencasting should be fixed by this too then...let me try | 18:03 |
| AlbertA | alan_g: is the sync logic supposed to track the fastest compositor or the slowest? | 18:11 |
| AlbertA | alan_g: I suppose the fastest making the other drop frames when necessary? | 18:11 |
| AlbertA | the issue with screencasting is if the screencast compositor renders faster than the display compositor | 18:16 |
| AlbertA | the display compositor starts dropping frames | 18:16 |
| AlbertA | I suppose to catch up | 18:16 |
| AlbertA | so the clients think they are rendering faster | 18:16 |
| alan_g | AlbertA: I'm not 100% certain. duflu chose the algorithm | 18:17 |
| AlbertA | but for the special case of screencasting it whould be the other way around | 18:17 |
| alan_g | Anyway, I'm past EOD - so if there's nothing urgent? | 18:17 |
| === alan_g is now known as alan_g|EOD | ||
| AlbertA | alan_g: no, just rambling | 18:18 |
| dansuf | Hi, I'm porting touch to my phone, I've got this error when running lightdm: http://pastebin.com/KMaQKNEL | 21:23 |
| dansuf | and in unity-system-compositor-log I've got this error: | 21:24 |
| dansuf | terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' | 21:24 |
| dansuf | what(): error during hwc set() | 21:24 |
| kdub | dansuf come back! | 21:26 |
| anpok | adreno200 | 21:29 |
| mterry | If I wanted to call "set_focus_to(session1); set_focus_to(session2)" in USC, how do I guard that so that the user doesn't see a peak of session1? Compositor::stop/start? Scene::lock/unlock? | 23:40 |
| kgunn | racarr_: ^ ? | 23:44 |
| kgunn | i would have guessed, never start the compositor | 23:44 |
| kgunn | .... | 23:44 |
| kgunn | kdub: or AlbertA might know as well... ^^ | 23:45 |
| kdub | where did he go... | 23:47 |
| AlbertA | yeah I would say don't start the compositor until after session2 focus | 23:47 |
| kdub | why would the compositor affect the input focus? | 23:56 |
| AlbertA | I believe he's trying to hide the surface more than anything | 23:57 |
| mterry | AlbertA, kdub: I want the graphics system to not make any immediate changes when I do set_focus_to(session1), but wait until I'm done setting focus to(session2) | 23:59 |
| mterry | or at least, not render the changes | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!