[00:06] * robert_ancell -> lunch [01:20] does anyone know the reasoning behind the piles of these compile warnings? http://paste.ubuntu.com/6177885/ [01:22] I would have thought that "const typet" and "typet const" would have been interchangable, but g++ is complaining that const std::shared_ptr< msh::DisplayLayout > is different than std::shared_ptr< shell::DisplayLayout > [01:22] sigh, moment... const std::shared_ptr< msh::DisplayLayout > and std::shared_ptr< shell::DisplayLayout > const [01:38] sarnold: I agree they look the same :/ Make sure you're using gcc 4.8 or later...? [01:40] duflu: this appears to be gcc-4.8_4.8.1-10ubuntu4 [01:41] sarnold: Oh, I see. You probably have not aliased "msh". Replace it with "mir::shell" [01:43] duflu: this is in the standard fullscreen_placement_strategy.cpp file, "namespace msh = mir::shell; [01:44] Don't know then [01:44] drat :) [01:44] src/client/gbm/* is full of similar looking warnings.. [01:46] duflu, hey, i've a question, what does fullscreen mean to mir atm? [01:47] ie. if we want to take a window and make it full screen (say its 1080x768 surface on a 1600x900 screen) [01:47] s/window/surface [01:48] bschaefer: The fullscreen state is "set" but not used. Our demos "fullscreen" just by setting the window size manually. The two are not wired up yet [01:48] duflu, will there be an API for this? To turn the active surface fullscreen? [01:49] bschaefer: Yes it exists, but does not affect surface size at all yet ... mir_wait_for(mir_surface_set_state(surface, mir_surface_state_fullscreen)); [01:50] duflu, awesome, I didn't see that when I was digging through the API :) [01:51] I saw I could make the server fullscreen, by an option, but that caused some problems (crashes) [01:51] bschaefer: Yes I agree it's confusing but you can see the function in include/client/mir_toolkit/mir_client_library.h and the args in include/shared/mir_toolkit/common.h [01:52] duflu, yeah I missed this: shared/mir_toolkit/common.h:65: mir_surface_state_fullscreen, along with the set state [01:52] that'll fix up my problem where im not sure what to do when asked to make the window fullscreen :) [01:53] bschaefer: It will still do nothing for now. :) [01:53] duflu, but when it does, I should be safe :) [01:54] duflu, O yeah, about that scroll V/H bug you made [01:54] * bschaefer digs it up [01:54] That comes under the heading of "surface resizing not implemented yet" [01:54] https://bugs.launchpad.net/mir/+bug/1233089 [01:54] Ubuntu bug 1233089 in Mir "MirMotionEvent can't tell which direction the mouse wheel is scrolling" [Undecided,New] [01:54] duflu, Cool, hopefully when its implemented that API will stay somewhat the same [01:55] bschaefer: You have a solution for scrolling? [01:55] duflu, So I had that scroll direction implemented, but we talked that this should be handled differently, as one big problem was the event queue was being overflowed [01:55] duflu, Yeah I did, then we talked about it in Denmark, and we reverted it [01:56] https://code.launchpad.net/~brandontschaefer/mir/mir-vscroll-hscroll-event-data [01:56] bschaefer: Cool, please link relevant stuff and comment [01:56] duflu, i've done, but its reverted, let me make a new branch and get that back in :) [01:56] It was another problem I needed to address in my own project [01:56] bschaefer: I didn't start working on Mir until many months after Denmark... ?! [01:57] duflu, hmm I swear that was Denmark ... but now that I think about it it was Okalnd [01:57] Oakland* [01:57] Yeah about then. I started immediately after [01:57] Oh [01:57] Oops [01:57] No [01:57] to many places with small rooms with out windows [01:57] I had started by then [01:58] hehe [01:58] It was San Mateo. Yeah :) [01:58] Cool :), yeah it was more about the responsibility of what mir should be doing [01:59] duflu, It was a bit ago, soo Im now forgetting the complete reason... [02:01] Where am I now? :S [02:01] duflu, O yeah, you mentioned it should be the toolkit that is responsible for it [02:01] https://code.launchpad.net/~brandontschaefer/mir/remove-vscroll-hscroll-events/+merge/162284 [02:01] bschaefer: I have no opinion on the solution until I get to reviewing it :) [02:02] duflu, well let me propose the old solution I had, then when a correct one comes around we can drop it :) [02:09] duflu, https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188498 [02:10] so a MirMotionEvent motion; can get the v/h scroll info by: motion.pointer_coordinates[0].hscroll/motion.pointer_coordinates[0].vscroll [02:12] duflu, though...this will break the ABI :( [02:15] bschaefer: Possibly... That's actually less important for the server right now. But changing the structure size for clients could be a problem. [02:15] bschaefer: Fortunately we have a few unused fields in MirMotionEvent to steal bytes from ;) [02:15] robert_ancell: know anything about the ubuntu_platform_api_mirclient library implementation? [02:16] duflu, well if I can steal 2 then this will work :), I could also use a union and only need to steal 1 [02:16] or, alternatively, know anyone who's awake right now who does? [02:16] thomi, not really [02:16] racarr, ^ ? [02:16] as it can only be a vscroll xor hscroll === jhodapp is now known as jhodapp|afk [02:18] though a union would not look very pretty :( [02:19] bschaefer: It's generalized for any device (including those which don't exist yet) so perhaps don't assume XOR [02:19] duflu, very true! [02:24] duflu, We could also hold off on this bug until something else that needs to break any structures anywhere to merge this in with that? [02:24] duflu, as Im assuming the ABI will have to be broken again at some point... [02:24] bschaefer: I hope that time comes... it's a matter of project planning [02:25] duflu, Right, and letting those who use Mir know when its coming I would think [02:25] duflu, think again, I don't know what: touch_major; touch_minor are for in the motion struct [02:25] s/think/then* [02:26] bschaefer: Yes there's a lot of copy/paste from Android. Hence bug 1175362 [02:26] bug 1175362 in Mir "MirMotionEvent fields lack documentation" [Medium,Triaged] https://launchpad.net/bugs/1175362 [02:27] Thats a good bug :), the v/hscroll bits where in there at that point haha [02:36] duflu: thanks for the help :) [02:36] robert_ancell, kgunn: Should we add bug 1227739 to the phone priorities? [02:36] bug 1227739 in Mir "Mir continues to render application surface even when the indicator surface is on top" [High,Triaged] https://launchpad.net/bugs/1227739 [02:36] (cos I know how to solve that one :) [02:36] duflu, looking [02:36] racarr: ping? [02:36] sarnold: No problem [02:37] thomi: maybe ricmm [02:37] ricmm: awake? [02:37] kgunn: so I've gotten it to the point where I think it should work, but I get a segfault instead :-/ [02:38] duflu, I agree with kgunn here - it's just an optimization so it doesn't need solving until we have all the other phone v1 features done [02:38] duflu: of course...if its done prior...its gravy [02:39] mmm gravy [02:39] Gravy's full of wheat :/ [02:40] heh, will you look at that. segfault comes from libmirclient3 :-( [02:43] duflu: gluten free icing ? [02:44] thomi: do you need some help [02:44] from mir team [02:44] kgunn: Surprisingly icing sugar is also often flour :/ [02:44] kgunn: my plan at the moment is to clean this up and push it, then send you an email [02:44] kgunn: it doesn't look like anyone who understands the platform API is awake, so... [03:04] thomi, do you have a WIP MP? [03:04] robert_ancell: really soon... [03:04] robert_ancell: just doing packaging changes now. Branch is at lp:~thomir/python-ubuntu-platform-api/add-mir-pkg [03:04] robert_ancell: will make a MP once the packaging stuff works === chihchun_afk is now known as chihchun [03:20] robert_ancell: Mp created: https://code.launchpad.net/~thomir/python-ubuntu-platform-api/add-mir-pkg/+merge/188503 [03:20] duflu: gotta ur nexus4 back yet ? [03:20] kgunn: I expect it would have only just arrived there. Expect about another week :P [03:21] thomi, the segfault is in libmirclient or libmirserver? [03:21] thomi: is there a "here's how you run AP tests on the phone" wiki [03:21] libmirclient3 [03:21] duflu: bummer [03:21] kgunn: So I reverted to Nexus7. Not quite usable for Mir but much better than expected [03:21] duflu: shocking really [03:21] ... as in there's only one bug AFAIK [03:22] kgunn: I don't think there's a wiki page. I believe most people still use the 'phablet-test-run' script [03:23] kgunn: just doing some research for you. I believe you can run 'phablet-click-test-setup' to download all the test cases [03:23] and then 'phablet-test-run unity8' for example to run that test suite [03:26] kgunn: Tracking says it arrived Sydney on Friday [03:28] Although the Australian Play Store still shows (discounted) Nexus 4 in stock [03:42] Can we assume all touch surfaces are full screen right now? Or do they exclude the notification bar? [03:42] -touch +phone [04:12] duflu, hey, one more question :). If I set mir_surface_state_fullscreen, then when its toggle off of fullscreen should the state be set to: mir_surface_state_restored? [04:12] or possibly unknown? [04:12] bschaefer: A floating window will usually be "restored" I think [04:13] duflu, hmm so thats more or less the default state of a surface? [04:13] * bschaefer should have just checked the source for the default state :) [04:14] duflu, Looks like: mir_surface_state_unknown; is getting set on the creation of a MirSurface [04:14] * bschaefer finds that to be a strange state name...unknown... [04:15] bschaefer: Tis correct. The state is stored in the server and the client considers the state unknown till it receives the first notification of what the state is [04:16] bschaefer: The server won't send such a notification unless you change it I think... ? [04:16] duflu, so when we want to set the state back to default, unknow it is! Sounds good, just wasn't the first thing I thought it was doing... [04:16] bschaefer: That will probably fail. I think restored is a more sane default [04:17] duflu, O, that makes sense as well :) [04:19] bschaefer: Oh. I vaguely recall that setting unknown is know you force the server to tell you the real value. Just wait_for the set and then get the value [04:19] -know +how [04:19] !? [04:19] duflu, well my goal is to set fullscreen when asked, thats simple [04:20] the thing is once fullscreen gets toggled off, the state will still be fullscreen, so i was just wanting to go back to default in a sense [04:20] duflu, Should I be setting the state on creation? [04:21] duflu, Im also not sure if these things are even hammered out yet :) [04:24] duflu, You're correct, if the state is unknown, then the surface gets configured when asked what the state is: [04:24] http://paste.ubuntu.com/6178269/ [04:29] bschaefer: Restored is a safe bet. "Restore" means "please put the surface back how it was before fullscreen/maximize. [04:29] " [04:29] duflu, yeah, that sounds good, I just got curious on how unknown was handled :). Thanks! I should head off for the night [04:30] duflu, have a good rest of your day! [04:30] bschaefer: I don't think I intended "unknown" to be used by clients [04:30] ... [04:30] Good night [04:30] :), well at lease it doesn't look like it should be used haha [08:05] holla mirs [08:06] Is Mir perhaps the reason I cannot get synergyc to connect to another synergys? [08:06] synergyc is running on a 13.10 machine with Mir [08:07] and synergys is running on 13.04 [08:21] version difference I guess? [08:21] synergy has a debug mode that might help [08:37] alan_g: The question is whether we should treat send failures as critical errors and close the connection, or rely on getting an error next time we try to read from the socket (as is done now). The latest version of socket-messenger-race keeps the current behavior and doesn't propagate the send errors further. [08:39] alf_: until recently ProtobufMessageProcessor::dispatch() handled write errors by dropping the connection. I think we should reinstate that. [08:40] It changed as a side-effect of suppressing a lack of error handling when sending unsolicited events to the client. [08:41] alan_g: I agree, and also make sendmsg() (for FDs) failures throw too. Does the client handle such events properly now? [08:42] alf_: I've a rework of the client -side code sitting on a branch that does handle stuff correctly. Not sure about trunk [08:42] alan_g: Not immediately required, but if you come across any documentation for asio that's actually readable (unlike the official docs) then please let us all know?... It seems very black magic [08:43] duflu: I was moaning about the same thing in Boston [08:44] alan_g: My concern is that it seems like only one of us (you?) has ever figured out how it works. And that's detrimental to our maintenance efforts [08:48] duflu: I share your concern (and I don't have it figured out yet) [08:49] * alan_g thinks that if he ever does figure it out an article would be a good idea. [10:00] * duflu gets out the pen an paper; finds 12 server-side "surface" classes and counting :P [10:04] greyback: Unity8 on Mir ... forgive my ignorance but is that finally multi-surface? And are app surfaces usually fullscreen on the phone? [10:05] duflu: shell is single surface at the moment, work in underway to change that though. Yes app surfaces are usually fullscreen [10:05] greyback: So the shell gets lowered or always-on-top-but-hidden? [10:06] duflu: always on top, marks itself transparent to hide [10:06] s/marks/makes/ [10:06] greyback: Argh. OK... so that's using Mir's hidden attribute? [10:07] duflu: sorry no, it just makes its surface transparent, so surface underneath is visible [10:07] greyback: Oh. That will pose a problem to my occlusion testing I guess.... unless... the whole surface has alpha==0 ? [10:07] It does not tough the visible/hidden attribute [10:09] duflu: no, say if launcher out, the launcher bit is fully opaque, but the rest of the shell surface is transparent [10:10] greyback: Eeek. So I can't do occlusion testing on that. I guess I need to wait for Unity changes [10:10] greyback: Unless there's a definitive way to identify when the top (shell) surface and launcher is hidden? [10:11] duflu: sorry for my ignorance how, but what is occlusion testing? [10:11] greyback: Finding out what's hidden to optimize rendering [10:12] greyback: Final question before I go: Can I tell from Mir that the launcher is hidden by the shell surface state somehow? [10:13] duflu: I see. Shell is doing complex things, so there's no easy way for outsider to determine what parts of the surface is opaque and not [10:13] greyback: Well, I'm looking from inside the server, not outside. But still, will need something more efficient than testing every pixel of the surface for opacity [10:14] That's OK, I've found more things that need cleaning up and moving around before any of that [10:14] duflu: you could watch the input areas that the shell surface defines. Generally if it has an input area, that area is not-transparent [10:15] greyback: Interesting heuristic but not reliable. At least not on non-touch platforms [10:15] but that's the only way I can think mir is even aware of what shell is doing [10:15] yep, I've nothing better to suggest, sorry [10:15] greyback: OK, keep me posted on changes to the shell surface implementation? [10:15] Time to make dinner! [10:15] duflu: sure, but I expect it to be after the 1.0 release [10:15] greyback: Yep [10:16] bon appetit === alan_g is now known as alan_g|afk === hikiko is now known as hikiko|lunch === alan_g|afk is now known as alan_g [10:49] kgunn: well that is my plan of using mir all day out of the window, no sound on received calls or sms, I'm just going to compare that with SF but I can't understand why mir would stop that [10:51] * ricmm was making calls on Mir yesterday [10:51] theres is no reason for Mir to block any kind of sound, something else in your setup is probably triggering it [10:51] perhaps something triggered by the Mir selector, but certainly not the shell itself [10:53] ricmm: it's okay it dead on sf too apparently there was an issue that is/has been resolved and I might just need a new image and then I can start again [11:02] perfecto [11:06] ricmm: apparently it is an issue with the infographics stuff so it effects anything it touches, so no camera sms or phone by the look of it :( [11:19] wow === chihchun is now known as chihchun_afk [11:24] ricmm: ah usermetrics sorry, the bit that infographics gets it's info from :) === hikiko|lunch is now known as hikiko === jhodapp|afk is now known as jhodapp [12:31] mornin greyback, need any help ? [12:32] kgunn: not yet, am not out of ideas just yet === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [13:28] racarr, ping [13:29] tjaalton: mlankhorst hey do you guys know anything about potential open source driver roadmaps, primarily when/if opengl4 would be supported? [13:30] when we get around to it, if someone gets around to it :P [13:30] kgunn: http://www.x.org/videos/XDC2013/ian_romanick_mesa_update.avi that should tell, iirc [13:31] maybe next year [13:31] sarnold: might know better than me, tbh [13:31] sarvatt* [13:33] http://www.youtube.com/watch?v=Lk20sLDI1eE&feature=youtu.be [13:33] better link [13:43] alan_g: what does this error imply: what(): bind: Address already in use === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:07] kgunn: ping [14:08] ricmm: pong [14:08] kgunn: hey kevin, about the autopilot stuff... Mir blows up internally when the hwc is in a blanked state upon starting [14:08] thats not really the shell's fault, the Mir code needs to account for this case [14:08] bring the hwc to a clean slate etc [14:08] greyback: oh crap... alan_g is out this afternoon dealing with a speeding ticket i think [14:08] it is possible that unity8 will crash unexpectedly at some point while the screen is blanked [14:08] alf_: ^ can you help greyback [14:09] in which case Mir needs to make sure it can account for a startup with a hwc in any state [14:09] the only case unity8 can protect is the oen where it has been explicity asked to quit itself [14:09] one* [14:10] greyback: perhaps some left-over mir socket file? [14:10] its usually the left over /tmp/mir_socket yea [14:10] ricmm: hmmm....wonder if that's because of some discussion i saw yesterday about AP stuff, creating some objects out of order... [14:10] greyback: you sure its not there? [14:10] kgunn: its not APs fault, nor the shell [14:10] ricmm: i'm not saying it is [14:11] ricmm: I get this when running shell through AP, so need to figure out why [14:11] greyback: only through AP? [14:11] ricmm: i'm saying that you're right in that we may need to put in some safety code for a new order of things [14:11] ricmm: yep, I can run manually [14:11] greyback: can you run in gdb and get a backtrace? [14:11] greyback: just strace it, you'll see the failing syscall() [14:12] kgunn: indeed, we need some protection when initializing the hwc to make sure it is reset to an unblanked state [14:12] kgunn: technically spurious ->blank() or ->unblank() calls shouldnt fail, according to API [14:12] but robert's code is catching it somewhere [14:12] im sure he can sort it in miutes [14:13] ricmm: well...that is semiCo code :) [14:13] ricmm: yeah...we have mir stand up in 45 minutes [14:13] kdub always makes it... racarr is a sometimes... [14:16] kgunn: I could join and explain if you want [14:16] ricmm: sounds great [14:16] will invite [14:16] perfect [14:18] kgunn: oh, just a note, when you merge from the dev branch to trunk, please use a better and more detailed commit message "merge from latests dev branch" isn't very informative :) [14:19] didrocks: ack....i can populate with aggregate commit [14:19] kgunn: yeah, seems to be the right strategy ;) [14:19] * kgunn still claims victory for not breaking build :) [14:41] The performance of Mir on Nexus 4 was on par with SF a few weeks ago, what changed? Is there a bug report somewhere ? [14:42] davmor2, maybe you know ? ^ [14:46] om26er: I don't have mako I have maguro which is slower anyway. [14:48] om26er: I took some basic videos yesterday and posted them here showing that mir was slower. I was going to run with mir all day today but then I get no notifications about calls and messages so need to get image 75 first. [14:49] davmor2, is 75 coming soon ? [14:49] om26er: as soon as all the bits required have built which isn't happening currently [15:02] kdub: alf_ racarr hikiko ricmm standup === dandrader is now known as dandrader|lunch [15:05] joining kgunn [15:29] goodbye! [15:38] kdub: ping [15:38] pong [15:38] kdub: http://paste.ubuntu.com/6180049/ [15:38] you can see the last working blocking pread() on the vsync fd in line 1 [15:38] returns in line 7 with valid data [15:39] line 8's returns immediately with empty data [15:39] off the top of my head [15:39] and then its spuriously happening like that consuming the full CPU where that thread schedules [15:40] that looks like the vsync signal that is polled for, which surfaceflinger uses to trigger its own composition, and sends that signal on to the clients [15:40] we should probably disable/enable that signal on a blank [15:40] you dont use that signal at all? [15:40] and i'll think about disabling it, we're getting vsync from the commit fences right now [15:40] right [15:40] oh then by all means disable it [15:41] as it wakes the thread on vsync [15:41] yeah, disabling it makes more sense [15:41] not costly, but then it causes this crap [15:41] i might re-enable it for performance logging or something at some point though [15:41] is it easy to disable? [15:41] yeah, easy [15:41] * ricmm likes these answers [15:41] tell me how I can test :) [15:43] kdub: why are we polling for the signal anyways? or is that the hwc polling it [15:43] if its unused for anything in Mir I mean [15:43] we used to use it to get vsync [15:43] ah ok [15:43] and hwc10 still does [15:43] maguro is 1.0 ? [15:43] right [15:43] hmm [15:44] I havent tested this breakage in maguro, although in maguro we dont blank [15:44] we just suspend [15:44] which in turn turns the hwc off and gpu, etc [15:44] ricmm, http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/graphics/android/hwc_common_device.cpp#L68 [15:44] I guess it will blow up maguro if you remove it, which we dont wanr [15:45] turn that last argument from a 1 to a 0 [15:45] or just delete lines 68-76 [15:45] ok [16:00] alf_: i'd ask duflu...since he's not on, do you know if raof/duflu actually fixed the radeon corrupt render issue ? [16:01] alf_: having a hard time deciphering bug correspondence [16:07] android display creation needs some cleanup [16:08] kgunn: the radeon issue we were seeing during the sprint (vertical black lines) has been fixed: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1218815 [16:08] Ubuntu bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Fix released] [16:08] kgunn: however, there seems to be a new radeon glitch: https://bugs.launchpad.net/mir/+bug/1233545 [16:08] Ubuntu bug 1233545 in mir (Ubuntu) "Screen corruption on radeon chipset" [Critical,New] [16:08] alf_: thanks...arg, marked invalid for xmir...that's why [16:08] alf_: yeah...saw that :) [16:14] greyback: @"bind: Address already in use" - the socket filename is already being used [16:14] Hello! I'm looking at a bug with unity8-on-Mir where a frame or two of the dash can be seen before the greeter appears on screen-turn-on. I'm told that the Mir compositor stops accepting frames when the screen is blanked. But it seems that Mir is shutting down frames sooner than unity8 can respond to the screen-blank event and thus can't prepare the screen. :( Any hints? [16:15] racarr, alan_g: ^ ? [16:16] mterry: not anything I'm familiar with. Sorry [16:17] kdub: seems to be doing the same [16:17] I still get the VSYNC pollers [16:18] perhaps they are enabled by default, what I did was remove the code [16:18] * ricmm readds [16:23] kdub: http://androidxref.com/4.2.2_r1/xref/hardware/libhardware/include/hardware/hwcomposer.h#337 [16:24] yeah, we're doing that wrong [16:24] * mterry has to run for lunch, but will be back [16:28] ricmm, try setting to zero [16:28] really, that thread looks like its started in registerProcs [16:30] kdub: so should I first disable in the eventControl before registering the thread with registerProcs? [16:30] perhaps it doesnt disable on the fly [16:31] kdub: neg this is how SF does it so should be fine [16:31] just reading through the code for that thread [16:32] it should be able to be disabled on the fly [16:32] and it should start off [16:33] well I still see the pread()s [16:33] is it possible that what is disabled is the event delivery through vsync() ? [16:33] yet it still polls internally [16:37] it should be waiting on a condition variable here https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-10.1/libhwcomposer/hwc_vsync.cpp#L96 === dandrader|lunch is now known as dandrader [16:59] alf_, do gbm buffers have fences? [17:00] just wondering if mg::BufferBasic should have fence-related functions, or if that's just an android think [17:00] thing === alan_g is now known as alan_g|EOD [17:10] Back. Still curious if anyone knows much about Mir compositing as the screen blanks [17:30] kdub: im at a loss here, im clearly disabling it [17:31] condition is zero'd in the qcom hwcomposer [17:31] so that thread should block on it [17:31] but its still not blocking? strange [17:31] yea [17:31] we shouldn't be reaching the pread at all [17:32] racarr, ping [17:32] kdub, I see you in bzr log for some HWC stuff. Do you know much about how Mir handles blanking/unblanking the screen? Specifically, is there an opportunity for the shell to change the screen before Mir stops accepting new frames upon a blank event? [17:33] mterry: the blanking is requested by the shell, so yes the shell knows when its going to unblank [17:33] exactly what are you trying to do? [17:33] ricmm, requested by shell? Not powerd? [17:33] ricmm, I'm looking at a bug with unity8-on-Mir where a frame or two of the dash can be seen before the greeter appears on screen-turn-on. It seems that Mir is shutting down frames sooner than unity8 can respond to the screen-blank event and thus can't prepare the screen [17:34] well, i think powerd talks dbus to the shell, and the shell commands mir what to do [17:34] if i understand [17:35] mterry: powerd -> DBus to shell -> shell out to Mir to blank [17:35] yup [17:35] kdub, interesting... ideally what I'd really like to happen is "blank screen; display something on that screen; have Mir stop accepting new frames" [17:35] ricmm, kdub: OK, will look in shell code for where we do that. May help me figure a workaround [17:35] AFAIK hwcomposer blanking means the composer stops accepting frames, as well [17:36] so whatever you want in place needs to be there before the blanking happens [17:36] because also when we return to powerd, it will try to suspend (stop some pipelines, more weird behaviour( [17:36] well, we stop the composition pass, which in effect, stalls the clients [17:36] ricmm, seems like a jarring experience for user. Ideally they see dash -> black -> greeter [17:37] so seems we could display a fade (or whatever design wants) to black [17:37] then blank [17:37] then turn on, and start rendering a fade from black (or whatever) [17:38] I would believe that would be communication between shell and greeter [17:38] shell can hide, draw greeter and blank [17:38] it all happens rather quickly anyways [17:41] bschaefer: Pong [17:41] racarr, hey, sooo it looks like we want v/hscroll back into mir again :( [17:41] racarr, problem, is we break the size of the event structure mp: [17:41] https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188666 [17:42] racarr, and was wondering if you have any preference to which event info we could remove to make room for v/h scroll info :) [17:42] OK, yup. I see chain now. powerd calls com.canonical.Unity.Screen.setScreenPowerMode (defined in unity-mir) which calls Mir's configure_output [17:43] racarr, i also need to fix that branch up...some extra stuff got into it? [17:43] bschaefer: I don't think...at least first thought [17:43] that we should remove another event [17:43] to make room for v/h scroll [17:43] sounds like eventually you have to break ABI twice [17:43] i.e. will we want it back later [17:43] racarr, true, thats another option :) [17:43] just a big confusion [17:43] etc [17:43] yeah [17:44] so I would rather just bump mir client ABI but maybe [17:44] i can fix up the branch and wait for the next ABI break to go in [17:44] its really not opssible anymore [17:44] yeah I think that would be good unless its a rush [17:44] missing that event info causes some things to not work, but not a rush [17:47] greyback, so I'm looking at sequence on screen-blanking. unity-mir receives a request from powerd to blank, then it asks Mir. Is it reasonable to add a unity-mir signal to shell that it is about to blank, "better get any frames that you want in now"? === jhodapp is now known as jhodapp|lunch [17:49] greyback, maybe in Unity.Application...? [17:49] mterry: maybe? So you want shell to be able to delay the screen blank? [17:50] greyback, I don't know about delay, but I'd like to prepare the screen for wake-up, so that user doesn't see a frame of the dash upon wakeup before the greeter can appear [17:50] kgunn: When can we break mirclient ABI again? [17:51] racarr, :) [17:52] I have an idea [17:52] re: mterry and greyback [17:52] mterry: sure, I understand the problem. But how to make sure we've the right frame ready isn't obvious to me. I thought the easiest solution is for Mir's compositor to allow shell to push a few more frames after the screen has blanked... [17:52] The problem is, the client tries to swap buffers after [17:52] the screen blanks [17:53] which blocks, because it cant get a new buffer, because the compositor can't display its buffer [17:53] its old buffer [17:53] greyback, well, we could also squeeze in a frame before blanking, same diff? I don't know if we do it right before blanking if user would see it before screen goes dark or not [17:53] so basically the problem is that there are these 1 or 2 [17:53] buffers in flight, 1 held by the client [17:53] which it wants to swap [17:54] and potentially the last one held by the compositor which it may have not gotten a chance to render yet [17:54] racarr: could we just empty the Buffer ring for shell? [17:54] yes, that's what I am getting at [17:54] just cancel all the buffers, so after screen unblank [17:54] yep, sounds ok to me [17:54] the first swap buffers wont display anything/perhaps its some sort of error [17:55] and then you get a buffer back, and get a chance to draw a frame [17:55] yeah :D [17:57] Ok [17:57]