| mterry | Hrm. Does trusty's Mir ftbfs for anyone else? | 02:58 |
|---|---|---|
| * mterry wonders how close new Mir is to landing | 02:58 | |
| duflu | mterry: Like https://bugs.launchpad.net/bugs/1285955 ? | 03:00 |
| ubot5 | Ubuntu bug 1285955 in mir (Ubuntu) "Ubuntu trusty update "glm 0.9.5.1-1" broke Mir builds" [Critical,Triaged] | 03:00 |
| mterry | duflu, looks like it, yeah | 03:01 |
| * mterry resigns himself to building mir/devel | 03:01 | |
| mterry | I suppose I could steal that one patch | 03:01 |
| duflu | mterry: It's a simple patch to backport | 03:01 |
| mterry | duflu, thanks for the link | 03:01 |
| mterry | duflu, yeah, but I might as well test against latest anyway. It's been a while since Mir dropped | 03:02 |
| duflu | mterry: Yeah 0.1.6 grew a bit larger than other releases | 03:02 |
| duflu | On the plus side, that means lots of fixes | 03:02 |
| * mterry loves fixes! :) | 03:03 | |
| duflu | mterry: BTW I've made changes to the rendering interfaces in 0.1.7 and more to come. So I would not recommend building /effects/ of any sort on what we have just yet | 03:04 |
| duflu | Because what we have won't exist that way for long | 03:04 |
| mterry | hmm, OK. I'm just trying to track down weird nested mode behavior with split mode | 03:05 |
| duflu | The good news is, changes in that area are now landing(!) | 03:05 |
| duflu | mterry: Anything we know about? https://bugs.launchpad.net/mir/+bugs?field.tag=nested | 03:05 |
| mterry | duflu, no, don't think so. I'm not even sure it's a Mir bug yet, but it's a good place to start debugging for one of my issues | 03:06 |
| mterry | duflu, these only show up when using split mode. So may be a bug in my integration | 03:07 |
| duflu | mterry: Does split mean sidestage? | 03:07 |
| mterry | duflu, no sorry. I mean split greeter | 03:07 |
| mterry | duflu, so like an actual separate greeter process | 03:07 |
| RAOF | Welcome to: It Works Fine On My System, XVII | 08:07 |
| RAOF | duflu: So, apparently bzr lp-sumbit doesn't particularly care to respect the submit branch I try to set :) | 08:32 |
| duflu | Hurrah | 08:33 |
| didrocks | RAOF: you have to set a target branch | 08:33 |
| didrocks | in your branch config | 08:33 |
| didrocks | (I know, it's stupid, but that's a launchpad "feature") | 08:34 |
| didrocks | I had to workaround that for daily release, so really conscious about the problem :) | 08:34 |
| RAOF | What? | 08:34 |
| didrocks | RAOF: what branch do you want to target against? | 08:34 |
| RAOF | The docs for bzr lp-propose strongly imply that ‘bzr lp-propose lp:mir/devel’ will try to be submitted to lp:mir/devel. On the basis that it's called SUBMIT_BRANCH :) | 08:35 |
| didrocks | yeah, but then launchpad is trying to be smarter | 08:35 |
| didrocks | and think "oh, but this SUBMIT_BRANCH has this parent branch" | 08:35 |
| didrocks | so I'll target that… | 08:35 |
| didrocks | RAOF: try running: bzr config -d lp:mir/devel public_branch=~mir-team/mir/development-branch | 08:36 |
| didrocks | then resubmit | 08:36 |
| RAOF | We'll see next time I want to submit something; I've already retargetted. | 08:42 |
| RAOF | Hm. google::protobuf declares itself to be not threadsafe for non-const methods. Why do we explicitly release all our locks before calling protobuf methods? | 08:57 |
| duflu | RAOF: Good question. I think otherwise it led to deadlocks. But that doesn't make it right | 08:59 |
| duflu | RAOF: Do we really have multiple threads using the protobuf objects though? | 09:01 |
| RAOF | If we have a multithreaded client, certainly. | 09:01 |
| duflu | RAOF: Ah | 09:01 |
| RAOF | Such as, say, having two separate nested outputs... | 09:02 |
| duflu | Critical blocking CI: https://bugs.launchpad.net/mir/+bug/1287600 | 09:02 |
| ubot5 | Ubuntu bug 1287600 in Mir "./cross-compile-chroot.sh: line 83: popd: build-android-arm: invalid argument popd: usage: popd [-n] [+N | -N]" [Critical,In progress] | 09:02 |
| duflu | Anyone? | 09:02 |
| RAOF | duflu: SUre. | 09:06 |
| duflu | RAOF: Ta | 09:07 |
| alan_g | duflu: @"something should be mentioned in debian/changelog" - I don't see anything in the changelog for the changes that broke USC (mostly -r1420) | 09:45 |
| duflu | alan_g: I just mean if it's not a standard part of the 0.1.6 release (r1433) then it needs a separate mention | 09:46 |
| alan_g | duflu: got it | 09:47 |
| duflu | alan_g: At the top-level of the bullet points so it's not under the 0.1.6 release stuff | 09:47 |
| alan_g | Although IIUC kgunn was busy pulling more stuff into 0.1.6 yesterday | 09:47 |
| alan_g | so it might be moot | 09:48 |
| duflu | alan_g: I reverted that. Because it included mostly my own work which I intentionally omitted from 0.1.6 wanting it to mature some more | 09:52 |
| alan_g | alf_: does "frame" mean "buffer filled with fresh pixels we want displayed" to you? | 10:26 |
| alf_ | alan_g: frame => "buffer filled with pixels". Whether it's "fresh" or we want it displayed is another story. | 10:30 |
| alf_ | alan_g: i.e. these are not implied by the term 'frame' without any other context | 10:31 |
| alan_g | alf_: thanks. Then "usable_frames()" would be reasonable for buffers we can compose? | 10:39 |
| alf_ | alan_g: pending_frames? | 10:42 |
| alan_g | I don't like "pending" as it can include a frame that has been composited (either on this display compositor or one one for another output) | 10:43 |
| alan_g | "frames()"? | 10:44 |
| alan_g | completed_frames()? | 10:45 |
| alf_ | alan_g: I don't agree with Daniel about using the terms 'frames'. This is a *Buffer*Stream, and I find using 'frames' confusing in this context. BufferStream::completed_buffers()? ready_buffers? | 10:51 |
| alan_g | alf_: the reason I went for composable_buffers() was that it also supplies client buffers and I wanted to avoid any possible confusion | 10:53 |
| alan_g | filled_buffers() | 11:10 |
| anpok_ | I havent used our demos on android some time now, any ideas why clients cannot connect to demo shell | 11:34 |
| alan_g | anpok_: they can | 11:36 |
| anpok_ | "Can't get connection" | 11:37 |
| alan_g | Are you running as the same user? | 11:37 |
| anpok_ | yes | 11:37 |
| anpok_ | tried with and without supplying the path to server and client. socket file is created properly | 11:38 |
| alan_g | It works on my kit | 11:38 |
| anpok_ | hm i just stopped unity8 and lightdm | 11:39 |
| anpok_ | ok will try with devel | 11:39 |
| anpok_ | system error thrown by asio when it tries to connect to the socket .. cannot examine the system error category but error val is 2 | 11:43 |
| anpok_ | and that would be address in use o_O | 11:43 |
| anpok_ | or no such file or directory | 11:44 |
| anpok_ | oh ok that was all me | 11:46 |
| * alan_g assumes it works on anpok_'s kit too | 11:48 | |
| alan_g | alf_: "buffers_ready_for_compositor_aka_frames()"? | 11:49 |
| alf_ | alan_g: :) | 11:51 |
| anpok_ | sounds reasonable | 11:55 |
| anpok_ | hm is it intended that all motion events go to the topmost or focused surface even when those motion events did not originate from the screen region of the surface? | 12:10 |
| alan_g | anpok_: I think that is probably a policy decision - check the design guidelines | 12:13 |
| anpok_ | ah ok that is the behavior of demo shell | 12:13 |
| anpok_ | using focused application -> default_surface, which also explains why multi win behaves that way | 12:14 |
| alan_g | alf_: happy with the latest comment? https://code.launchpad.net/~alan-griffiths/mir/add-some-intelligence-to-scheduling-compositing/+merge/208633 | 12:24 |
| anpok_ | wet_buffers() ? | 12:27 |
| anpok_ | that would have the freshly paint pixels.. and the term buffers | 12:27 |
| * ogra_ hands anpok_ a mop | 12:28 | |
| anpok_ | nah not needed, they are not leaking | 12:29 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| kgunn | alan_g: so i saw duflu reverted our promotion branch, so re-cherry picked... | 14:26 |
| kgunn | http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1440 | 14:26 |
| kgunn | and | 14:26 |
| kgunn | http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1438 | 14:26 |
| kgunn | just fyi | 14:26 |
| kgunn | i'm supposing it was the renderable for rendering stuff he didn't want in yet | 14:27 |
| alan_g | kgunn: I am content to let you and duflu reach a consensus | 14:28 |
| alan_g | Anyway, your choices look sensible. | 14:34 |
| anpok_ | do we have a usage scenarios behind set_inpput_rectangles? | 16:25 |
| anpok_ | what is supposed to happen if somebody creates a surface. resizes it. then sets input_rectangles.. should the input_rectangles be resized too? | 16:26 |
| kdub | anpok_, is https://code.launchpad.net/~andreas-pokorny/mir/cursor-position-on-rotated-output/+merge/209076 ready to go? | 16:29 |
| anpok_ | yes | 16:29 |
| kdub | cool | 16:31 |
| anpok_ | alan_g: alf_: racarr_: kdub: I plan to propse something that would scale the input rectangles on resize, and apply the other transformations to the input rectangles (rotation and positioning) when querried through contains..? | 16:32 |
| anpok_ | kdub: the other two things .. hot spot setting and managing rotated buffers will be done later.. hmm but should be straight forward.. | 16:33 |
| alan_g | anpok_: would it be easier to merge the input rectangles into the surface hierarchy and not have to keep updating copies of the data? | 16:33 |
| anpok_ | hm you mean reworking inputwindowinfo/handle? | 16:35 |
| alan_g | anpok_: we've far too many implementation classes representing the way surfaces interact with parts of the system. It sounds like you're struggling with keeping the input one in step with the others | 16:38 |
| * alan_g is guessing as he's not looked closely | 16:38 | |
| anpok_ | true, but the problem is now internal in basic_surface::input_rectangle not being updated | 16:40 |
| anpok_ | actually revisiting the other bug.. I wonder which portion of the android object went out of date... since the main query method goes for surface::contains anyhow | 16:41 |
| anpok_ | so maybe I will soon provide a cleaner fix for the other bug too, which ripps out more of the InputInfo | 16:42 |
| * alan_g is mildly irritated that a bug he fixed days ago on a one branch hosed his system when testing on another branch | 17:43 | |
| alan_g | alf_: do you have time to re-review before EOD? https://code.launchpad.net/~alan-griffiths/mir/nested-sessions-dont-post-buffers-until-something-happens/+merge/209107 | 18:02 |
| === alan_g is now known as alan_g|EOD | ||
| racarr_ | ok now that im not worried about accidentally saying chromium I live here again | 18:28 |
| racarr_ | hi everyone :p | 18:28 |
| === WebbyIT is now known as rpadovani | ||
| bschaefer | racarr_, the chromium work looks awesome! :) | 20:08 |
| === veebers_ is now known as veebers | ||
| racarr_ | bschaefer: Thanks :) | 20:48 |
| mterry | mf::Shell::open_session() is turning on the display for me :-/ | 22:24 |
| kdub | maybe its triggering a callback for a new surface | 22:25 |
| mterry | kdub, new surfaces turn on the display | 22:29 |
| mterry | ? | 22:29 |
| kdub | mterry, not sure why that would happen | 22:35 |
| kdub | mterry, have any ideas about this in unity-system-compositor.log, "Unable to set active session, unknown client name session-0" | 22:35 |
| mterry | kdub, that is known (harmless for now) race, fixed by a branch of mine.... | 22:36 |
| mterry | https://code.launchpad.net/~mterry/unity-system-compositor/greeter-depth/+merge/207549 | 22:37 |
| kdub | mterry, ok | 22:38 |
| kdub | mterry, another question, who is in charge of turning on the display today? | 23:13 |
| kdub | unity8, or usc | 23:13 |
| mterry | kdub, a bunch of people :) Normal flow is powerd asks USC to turn it on | 23:14 |
| mterry | kdub, unity8 shouldn't be involved anymore | 23:14 |
| kdub | and thats all landed? | 23:14 |
| mterry | kdub, yeah | 23:14 |
| kdub | and this branch did that? https://code.launchpad.net/~mterry/unity-mir/drop-dbusscreen/+merge/202236 | 23:16 |
| kdub | i'm trying to test some mir changes with the whole stack, having a hard time getting all the ducks in a row | 23:16 |
| mterry | kdub, no, that just removed some old unused code (unused because USC is claiming the bus unity-mir wanted, so it never got it) | 23:16 |
| mterry | kdub, the branch that made the switch was just enabling nested mode by default | 23:17 |
| mterry | kdub, USC has had a copy of that dbus_screen code for a while, it just wasn't used until it got turned on by default | 23:17 |
| kdub | mterry, okay, thanks | 23:17 |
| mterry | Huh. SessionMediator::next_buffer turns on the display | 23:20 |
| mterry | I'm not sure I like that | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!