#ubuntu-mir 2013-10-01 * robert_ancell -> lunch <sarnold> does anyone know the reasoning behind the piles of these compile warnings? http://paste.ubuntu.com/6177885/ <sarnold> I would have thought that "const typet" and "typet const" would have been interchangable, but g++ is complaining that const st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abshared_ptr< msh33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abisplayLayout > is different than st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abshared_ptr< shell33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abisplayLayout > <sarnold> sigh, moment... const st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abshared_ptr< msh33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abisplayLayout > and st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abshared_ptr< shell33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abisplayLayout > const <duflu> sarnold: I agree they look the same :/ Make sure you're using gcc 4.8 or later...? <sarnold> duflu: this appears to be gcc-4.8_4.8.1-10ubuntu4 <duflu> sarnold: Oh, I see. You probably have not aliased "msh". Replace it with "mir33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abshell" <sarnold> duflu: this is in the standard fullscreen_placement_strategy.cpp file, "namespace msh = mir33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abshell; <duflu> Don't know then <sarnold> drat :) <sarnold> src/client/gbm/* is full of similar looking warnings.. <bschaefer> duflu, hey, i've a question, what does fullscreen mean to mir atm? <bschaefer> ie. if we want to take a window and make it full screen (say its 1080x768 surface on a 1600x900 screen) <bschaefer> s/window/surface <duflu> 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 <bschaefer> duflu, will there be an API for this? To turn the active surface fullscreen? <duflu> 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)); <bschaefer> duflu, awesome, I didn't see that when I was digging through the API :) <bschaefer> I saw I could make the server fullscreen, by an option, but that caused some problems (crashes) <duflu> 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 <bschaefer> duflu, yeah I missed this: shared/mir_toolkit/common.h:65: mir_surface_state_fullscreen, along with the set state <bschaefer> that'll fix up my problem where im not sure what to do when asked to make the window fullscreen :) <duflu> bschaefer: It will still do nothing for now. :) <bschaefer> duflu, but when it does, I should be safe :) <bschaefer> duflu, O yeah, about that scroll V/H bug you made * bschaefer digs it up <duflu> That comes under the heading of "surface resizing not implemented yet" <bschaefer> https://bugs.launchpad.net/mir/+bug/1233089 <ubot5> Ubuntu bug 1233089 in Mir "MirMotionEvent can't tell which direction the mouse wheel is scrolling" [Undecided,New] <bschaefer> duflu, Cool, hopefully when its implemented that API will stay somewhat the same <duflu> bschaefer: You have a solution for scrolling? <bschaefer> 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 <bschaefer> duflu, Yeah I did, then we talked about it in Denmark, and we reverted it <bschaefer> https://code.launchpad.net/~brandontschaefer/mir/mir-vscroll-hscroll-event-data <duflu> bschaefer: Cool, please link relevant stuff and comment <bschaefer> duflu, i've done, but its reverted, let me make a new branch and get that back in :) <bschaefer> It was another problem I needed to address in my own project <duflu> bschaefer: I didn't start working on Mir until many months after Denmark... ?! <bschaefer> duflu, hmm I swear that was Denmark ... but now that I think about it it was Okalnd <bschaefer> Oakland* <duflu> Yeah about then. I started immediately after <duflu> Oh <duflu> Oops <duflu> No <bschaefer> to many places with small rooms with out windows <duflu> I had started by then <sarnold> hehe <duflu> It was San Mateo. Yeah :) <bschaefer> Cool :), yeah it was more about the responsibility of what mir should be doing <bschaefer> duflu, It was a bit ago, soo Im now forgetting the complete reason... <duflu> Where am I now? :S <bschaefer> duflu, O yeah, you mentioned it should be the toolkit that is responsible for it <bschaefer> https://code.launchpad.net/~brandontschaefer/mir/remove-vscroll-hscroll-events/+merge/162284 <duflu> bschaefer: I have no opinion on the solution until I get to reviewing it :) <bschaefer> duflu, well let me propose the old solution I had, then when a correct one comes around we can drop it :) <bschaefer> duflu, https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188498 <bschaefer> so a MirMotionEvent motion; can get the v/h scroll info by: motion.pointer_coordinates[0].hscroll/motion.pointer_coordinates[0].vscroll <bschaefer> duflu, though...this will break the ABI :( <duflu> bschaefer: Possibly... That's actually less important for the server right now. But changing the structure size for clients could be a problem. <duflu> bschaefer: Fortunately we have a few unused fields in MirMotionEvent to steal bytes from ;) <thomi> robert_ancell: know anything about the ubuntu_platform_api_mirclient library implementation? <bschaefer> duflu, well if I can steal 2 then this will work :), I could also use a union and only need to steal 1 <thomi> or, alternatively, know anyone who's awake right now who does? <robert_ancell> thomi, not really <robert_ancell> racarr, ^ ? <bschaefer> as it can only be a vscroll xor hscroll <bschaefer> though a union would not look very pretty :( <duflu> bschaefer: It's generalized for any device (including those which don't exist yet) so perhaps don't assume XOR <bschaefer> duflu, very true! <bschaefer> 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? <bschaefer> duflu, as Im assuming the ABI will have to be broken again at some point... <duflu> bschaefer: I hope that time comes... it's a matter of project planning <bschaefer> duflu, Right, and letting those who use Mir know when its coming I would think <bschaefer> duflu, think again, I don't know what: touch_major; touch_minor are for in the motion struct <bschaefer> s/think/then* <duflu> bschaefer: Yes there's a lot of copy/paste from Android. Hence bug 1175362 <ubot5> bug 1175362 in Mir "MirMotionEvent fields lack documentation" [Medium,Triaged] https://launchpad.net/bugs/1175362 <bschaefer> Thats a good bug :), the v/hscroll bits where in there at that point haha <sarnold> duflu: thanks for the help :) <duflu> robert_ancell, kgunn: Should we add bug 1227739 to the phone priorities? <ubot5> 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 <duflu> (cos I know how to solve that one :) <robert_ancell> duflu, looking <thomi> racarr: ping? <duflu> sarnold: No problem <kgunn> thomi: maybe ricmm <thomi> ricmm: awake? <thomi> kgunn: so I've gotten it to the point where I think it should work, but I get a segfault instead :-/ <robert_ancell> 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 <kgunn> duflu: of course...if its done prior...its gravy <robert_ancell> mmm gravy <duflu> Gravy's full of wheat :/ <thomi> heh, will you ramirezanna@example.org. segfault comes from libmirclient3 :-( <kgunn> duflu: gluten free icing ? <kgunn> thomi: do you need some help <kgunn> from mir team <duflu> kgunn: Surprisingly icing sugar is also often flour :/ <thomi> kgunn: my plan at the moment is to clean this up and push it, then send you an email <thomi> kgunn: it doesn't look like anyone who understands the platform API is awake, so... <robert_ancell> thomi, do you have a WIP MP? <thomi> robert_ancell: really soon... <thomi> robert_ancell: just doing packaging changes now. Branch is at lp:~thomir/python-ubuntu-platform-api/add-mir-pkg <thomi> robert_ancell: will make a MP once the packaging stuff works <thomi> robert_ancell: Mp created: https://code.launchpad.net/~thomir/python-ubuntu-platform-api/add-mir-pkg/+merge/188503 <kgunn> duflu: gotta ur nexus4 back yet ? <duflu> kgunn: I expect it would have only just arrived there. Expect about another week :P <robert_ancell> thomi, the segfault is in libmirclient or libmirserver? <kgunn> thomi: is there a "here's how you run AP tests on the phone" wiki <thomi> libmirclient3 <kgunn> duflu: bummer <duflu> kgunn: So I reverted to Nexus7. Not quite usable for Mir but much better than expected <kgunn> duflu: shocking really <duflu> ... as in there's only one bug AFAIK <thomi> kgunn: I don't think there's a wiki page. I believe most people still use the 'phablet-test-run' script <thomi> kgunn: just doing some research for you. I believe you can run 'phablet-click-test-setup' to download all the test cases <thomi> and then 'phablet-test-run unity8' for example to run that test suite <duflu> kgunn: Tracking says it arrived Sydney on Friday <duflu> Although the Australian Play Store still shows (discounted) Nexus 4 in stock <duflu> Can we assume all touch surfaces are full screen right now? Or do they exclude the notification bar? <duflu> -touch +phone <bschaefer> 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? <bschaefer> or possibly unknown? <duflu> bschaefer: A floating window will usually be "restored" I think <bschaefer> duflu, hmm so thats more or less the default state of a surface? * bschaefer should have just checked the source for the default state :) <bschaefer> duflu, Looks like: mir_surface_state_unknown; is getting set on the creation of a MirSurface * bschaefer finds that to be a strange state name...unknown... <duflu> 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 <duflu> bschaefer: The server won't send such a notification unless you change it I think... ? <bschaefer> 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... <duflu> bschaefer: That will probably fail. I think restored is a more sane default <bschaefer> duflu, O, that makes sense as well :) <duflu> 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 <duflu> -know +how <duflu> !? <bschaefer> duflu, well my goal is to set fullscreen when asked, thats simple <bschaefer> 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 <bschaefer> duflu, Should I be setting the state on creation? <bschaefer> duflu, Im also not sure if these things are even hammered out yet :) <bschaefer> duflu, You're correct, if the state is unknown, then the surface gets configured when asked what the state is: <bschaefer> http://paste.ubuntu.com/6178269/ <duflu> bschaefer: Restored is a safe bet. "Restore" means "please put the surface back how it was before fullscreen/maximize. <duflu> " <bschaefer> duflu, yeah, that sounds good, I just got curious on how unknown was handled :). Thanks! I should head off for the night <bschaefer> duflu, have a good rest of your day! <duflu> bschaefer: I don't think I intended "unknown" to be used by clients <duflu> ... <duflu> Good night <bschaefer> :), well at lease it doesn't look like it should be used haha <budgee> holla mirs <budgee> Is Mir perhaps the reason I cannot get synergyc to connect to another synergys? <budgee> synergyc is running on a 13.10 machine with Mir <budgee> and synergys is running on 13.04 <mlankhorst> version difference I guess? <mlankhorst> synergy has a debug mode that might help <alf_> 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. <alan_g> alf_: until recently ProtobufMessageProcessor33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abispatch() handled write errors by dropping the connection. I think we should reinstate that. <alan_g> It changed as a side-effect of suppressing a lack of error handling when sending unsolicited events to the client. <alf_> alan_g: I agree, and also make sendmsg() (for FDs) failures throw too. Does the client handle such events properly now? <alan_g> alf_: I've a rework of the client -side code sitting on a branch that does handle stuff correctly. Not sure about trunk <duflu> 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 <alan_g> duflu: I was moaning about the same thing in Boston <duflu> 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 <alan_g> duflu: I share your concern (and I don't have it figured out yet) * alan_g thinks that if he ever does figure it out an article would be a good idea. * duflu gets out the pen an paper; finds 12 server-side "surface" classes and counting :P <duflu> greyback: Unity8 on Mir ... forgive my ignorance but is that finally multi-surface? And are app surfaces usually fullscreen on the phone? <greyback> duflu: shell is single surface at the moment, work in underway to change that though. Yes app surfaces are usually fullscreen <duflu> greyback: So the shell gets lowered or always-on-top-but-hidden? <greyback> duflu: always on top, marks itself transparent to hide <greyback> s/marks/makes/ <duflu> greyback: Argh. OK... so that's using Mir's hidden attribute? <greyback> duflu: sorry no, it just makes its surface transparent, so surface underneath is visible <duflu> greyback: Oh. That will pose a problem to my occlusion testing I guess.... unless... the whole surface has alpha==0 ? <greyback> It does not tough the visible/hidden attribute <greyback> duflu: no, say if launcher out, the launcher bit is fully opaque, but the rest of the shell surface is transparent <duflu> greyback: Eeek. So I can't do occlusion testing on that. I guess I need to wait for Unity changes <duflu> greyback: Unless there's a definitive way to identify when the top (shell) surface and launcher is hidden? <greyback> duflu: sorry for my ignorance how, but what is occlusion testing? <duflu> greyback: Finding out what's hidden to optimize rendering <duflu> greyback: Final question before I go: Can I tell from Mir that the launcher is hidden by the shell surface state somehow? <greyback> 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 <duflu> 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 <duflu> That's OK, I've found more things that need cleaning up and moving around before any of that <greyback> duflu: you could watch the input areas that the shell surface defines. Generally if it has an input area, that area is not-transparent <duflu> greyback: Interesting heuristic but not reliable. At least not on non-touch platforms <greyback> but that's the only way I can think mir is even aware of what shell is doing <greyback> yep, I've nothing better to suggest, sorry <duflu> greyback: OK, keep me posted on changes to the shell surface implementation? <duflu> Time to make dinner! <greyback> duflu: sure, but I expect it to be after the 1.0 release <duflu> greyback: Yep <greyback> bon appetit <davmor2> 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 * ricmm was making calls on Mir yesterday <ricmm> theres is no reason for Mir to block any kind of sound, something else in your setup is probably triggering it <ricmm> perhaps something triggered by the Mir selector, but certainly not the shell itself <davmor2> 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 <ricmm> perfecto <davmor2> 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 :( <ricmm> wow <davmor2> ricmm: ah usermetrics sorry, the bit that infographics gets it's info from :) <kgunn> mornin greyback, need any help ? <greyback> kgunn: not yet, am not out of ideas just yet <Saviq> racarr, ping <kgunn> tjaalton: mlankhorst hey do you guys know anything about potential open source driver roadmaps, primarily when/if opengl4 would be supported? <mlankhorst> when we get around to it, if someone gets around to it :P <tjaalton> kgunn: http://www.x.org/videos/XDC2013/ian_romanick_mesa_update.avi that should tell, iirc <tjaalton> maybe next year <mlankhorst> sarnold: might know better than me, tbh <mlankhorst> sarvatt* <tjaalton> http://www.youtube.com/watch?v=Lk20sLDI1eE&feature=youtu.be <tjaalton> better link <greyback> alan_g: what does this error imply: what(): bind: Address already in use <ricmm> kgunn: ping <kgunn> ricmm: pong <ricmm> kgunn: hey kevin, about the autopilot stuff... Mir blows up internally when the hwc is in a blanked state upon starting <ricmm> thats not really the shell's fault, the Mir code needs to account for this case <ricmm> bring the hwc to a clean slate etc <kgunn> greyback: oh crap... alan_g is out this afternoon dealing with a speeding ticket i think <ricmm> it is possible that unity8 will crash unexpectedly at some point while the screen is blanked <kgunn> alf_: ^ can you help greyback <ricmm> in which case Mir needs to make sure it can account for a startup with a hwc in any state <ricmm> the only case unity8 can protect is the oen where it has been explicity asked to quit itself <ricmm> one* <alf_> greyback: perhaps some left-over mir socket file? <ricmm> its usually the left over /tmp/mir_socket yea <kgunn> ricmm: hmmm....wonder if that's because of some discussion i saw yesterday about AP stuff, creating some objects out of order... <ricmm> greyback: you sure its not there? <ricmm> kgunn: its not APs fault, nor the shell <kgunn> ricmm: i'm not saying it is <greyback> ricmm: I get this when running shell through AP, so need to figure out why <ricmm> greyback: only through AP? <kgunn> 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 <greyback> ricmm: yep, I can run manually <alf_> greyback: can you run in gdb and get a backtrace? <ricmm> greyback: just strace it, you'll see the failing syscall() <ricmm> kgunn: indeed, we need some protection when initializing the hwc to make sure it is reset to an unblanked state <ricmm> kgunn: technically spurious ->blank() or ->unblank() calls shouldnt fail, according to API <ricmm> but robert's code is catching it somewhere <ricmm> im sure he can sort it in miutes <kgunn> ricmm: well...that is semiCo code :) <kgunn> ricmm: yeah...we have mir stand up in 45 minutes <kgunn> kdub always makes it... racarr is a sometimes... <ricmm> kgunn: I could join and explain if you want <kgunn> ricmm: sounds great <kgunn> will invite <ricmm> perfect <didrocks> 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 :) <kgunn> didrocks: ack....i can populate with aggregate commit <didrocks> kgunn: yeah, seems to be the right strategy ;) * kgunn still claims victory for not breaking build :) <om26er> The performance of Mir on Nexus 4 was on par with SF a few weeks ago, what changed? Is there a bug report somewhere ? <om26er> davmor2, maybe you know ? ^ <davmor2> om26er: I don't have mako I have maguro which is slower anyway. <davmor2> 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. <om26er> davmor2, is 75 coming soon ? <davmor2> om26er: as soon as all the bits required have built which isn't happening currently <kgunn> kdub: alf_ racarr hikiko ricmm standup <hikiko> joining kgunn <hikiko> goodbye! <ricmm> kdub: ping <kdub> pong <ricmm> kdub: http://paste.ubuntu.com/6180049/ <ricmm> you can see the last working blocking pread() on the vsync fd in line 1 <ricmm> returns in line 7 with valid data <ricmm> line 8's returns immediately with empty data <kdub> off the top of my head <ricmm> and then its spuriously happening like that consuming the full CPU where that thread schedules <kdub> 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 <kdub> we should probably disable/enable that signal on a blank <ricmm> you dont use that signal at all? <kdub> and i'll think about disabling it, we're getting vsync from the commit fences right now <kdub> right <ricmm> oh then by all means disable it <ricmm> as it wakes the thread on vsync <kdub> yeah, disabling it makes more sense <ricmm> not costly, but then it causes this crap <kdub> i might re-enable it for performance logging or something at some point though <ricmm> is it easy to disable? <kdub> yeah, easy * ricmm likes these answers <ricmm> tell me how I can test :) <ricmm> kdub: why are we polling for the signal anyways? or is that the hwc polling it <ricmm> if its unused for anything in Mir I mean <kdub> we used to use it to get vsync <ricmm> ah ok <kdub> and hwc10 still does <ricmm> maguro is 1.0 ? <kdub> right <ricmm> hmm <ricmm> I havent tested this breakage in maguro, although in maguro we dont blank <ricmm> we just suspend <ricmm> which in turn turns the hwc off and gpu, etc <kdub> ricmm, http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/graphics/android/hwc_common_device.cpp#L68 <ricmm> I guess it will blow up maguro if you remove it, which we dont wanr <kdub> turn that last argument from a 1 to a 0 <kdub> or just delete lines 68-76 <ricmm> ok <kgunn> alf_: i'd ask duflu...since he's not on, do you know if raof/duflu actually fixed the radeon corrupt render issue ? <kgunn> alf_: having a hard time deciphering bug correspondence <kdub> android display creation needs some cleanup <alf_> 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 <ubot5> Ubuntu bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Fix released] <alf_> kgunn: however, there seems to be a new radeon glitch: https://bugs.launchpad.net/mir/+bug/1233545 <ubot5> Ubuntu bug 1233545 in mir (Ubuntu) "Screen corruption on radeon chipset" [Critical,New] <kgunn> alf_: thanks...arg, marked invalid for xmir...that's why <kgunn> alf_: yeah...saw that :) <alan_g> greyback: @"bind: Address already in use" - the socket filename is already being used <mterry> 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? <mterry> racarr, alan_g: ^ ? <alan_g> mterry: not anything I'm familiar with. Sorry <ricmm> kdub: seems to be doing the same <ricmm> I still get the VSYNC pollers <ricmm> perhaps they are enabled by default, what I did was remove the code * ricmm readds <ricmm> kdub: http://androidxref.com/4.2.2_r1/xref/hardware/libhardware/include/hardware/hwcomposer.h#337 <kdub> yeah, we're doing that wrong * mterry has to run for lunch, but will be back <kdub> ricmm, try setting to zero <kdub> really, that thread looks like its started in registerProcs <ricmm> kdub: so should I first disable in the eventControl before registering the thread with registerProcs? <ricmm> perhaps it doesnt disable on the fly <ricmm> kdub: neg this is how SF does it so should be fine <kdub> just reading through the code for that thread <kdub> it should be able to be disabled on the fly <kdub> and it should start off <ricmm> well I still see the pread()s <ricmm> is it possible that what is disabled is the event delivery through vsync() ? <ricmm> yet it still polls internally <kdub> 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 <kdub> alf_, do gbm buffers have fences? <kdub> just wondering if mg33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abufferBasic should have fence-related functions, or if that's just an android think <kdub> thing <mterry> Back. Still curious if anyone knows much about Mir compositing as the screen blanks <ricmm> kdub: im at a loss here, im clearly disabling it <ricmm> condition is zero'd in the qcom hwcomposer <ricmm> so that thread should block on it <kdub> but its still not blocking? strange <ricmm> yea <ricmm> we shouldn't be reaching the pread at all <bschaefer> racarr, ping <mterry> 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? <ricmm> mterry: the blanking is requested by the shell, so yes the shell knows when its going to unblank <ricmm> exactly what are you trying to do? <mterry> ricmm, requested by shell? Not powerd? <mterry> 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 <kdub> well, i think powerd talks dbus to the shell, and the shell commands mir what to do <kdub> if i understand <ricmm> mterry: powerd -> DBus to shell -> shell out to Mir to blank <ricmm> yup <mterry> kdub, interesting... ideally what I'd really like to happen is "blank screen; display something on that screen; have Mir stop accepting new frames" <mterry> ricmm, kdub: OK, will look in shell code for where we do that. May help me figure a workaround <ricmm> AFAIK hwcomposer blanking means the composer stops accepting frames, as well <ricmm> so whatever you want in place needs to be there before the blanking happens <ricmm> because also when we return to powerd, it will try to suspend (stop some pipelines, more weird behaviour( <kdub> well, we stop the composition pass, which in effect, stalls the clients <mterry> ricmm, seems like a jarring experience for user. Ideally they see dash -> black -> greeter <kdub> so seems we could display a fade (or whatever design wants) to black <kdub> then blank <kdub> then turn on, and start rendering a fade from black (or whatever) <ricmm> I would believe that would be communication between shell and greeter <ricmm> shell can hide, draw greeter and blank <ricmm> it all happens rather quickly anyways <racarr> bschaefer: Pong <bschaefer> racarr, hey, sooo it looks like we want v/hscroll back into mir again :( <bschaefer> racarr, problem, is we break the size of the event structure mp: <bschaefer> https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188666 <bschaefer> racarr, and was wondering if you have any preference to which event info we could remove to make room for v/h scroll info :) <mterry> OK, yup. I see chain now. powerd calls com.canonical.Unity.Screen.setScreenPowerMode (defined in unity-mir) which calls Mir's configure_output <bschaefer> racarr, i also need to fix that branch up...some extra stuff got into it? <racarr> bschaefer: I don't think...at least first thought <racarr> that we should remove another event <racarr> to make room for v/h scroll <racarr> sounds like eventually you have to break ABI twice <racarr> i.e. will we want it back later <bschaefer> racarr, true, thats another option :) <racarr> just a big confusion <racarr> etc <bschaefer> yeah <racarr> so I would rather just bump mir client ABI but maybe <bschaefer> i can fix up the branch and wait for the next ABI break to go in <racarr> its really not opssible anymore <racarr> yeah I think that would be good unless its a rush <bschaefer> missing that event info causes some things to not work, but not a rush <mterry> 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"? <mterry> greyback, maybe in Unity.Application...? <greyback> mterry: maybe? So you want shell to be able to delay the screen blank? <mterry> 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 <racarr> kgunn: When can we break mirclient ABI again? <mterry> racarr, :) <racarr> I have an idea <racarr> re: mterry and greyback <greyback> 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... <racarr> The problem is, the client tries to swap buffers after <racarr> the screen blanks <racarr> which blocks, because it cant get a new buffer, because the compositor can't display its buffer <racarr> its old buffer <mterry> 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 <racarr> so basically the problem is that there are these 1 or 2 <racarr> buffers in flight, 1 held by the client <racarr> which it wants to swap <racarr> and potentially the last one held by the compositor which it may have not gotten a chance to render yet <greyback> racarr: could we just empty the Buffer ring for shell? <racarr> yes, that's what I am getting at <racarr> just cancel all the buffers, so after screen unblank <greyback> yep, sounds ok to me <racarr> the first swap buffers wont display anything/perhaps its some sort of error <racarr> and then you get a buffer back, and get a chance to draw a frame <racarr> yeah :D <racarr> Ok <racarr> I can't immediately work on that... <greyback> so we'd need to somehow get to the SwitchingBundle for the shell, and call compositor_buffer on it a few times? <ricmm> if you have no time to work on it right away, why dont we just block unity-mir blanking until the shell says "cool" <ricmm> I can see it being just a few lines of code <racarr> greyback: I think maybe we can use "drop_frames" <racarr> it should be internal to the graphics backend though <greyback> racarr: sure <greyback> mterry: yeah, that's probably the quickest option: to unity-mir add a signal this is emittedwhen powerd asks for blanking. In unity8, connect to that signal, have the greeter slide in <greyback> mterry: then also to unity-mir add an invokable method which actually does the blanking. Then call that function from QML after greeter slide-in animation complete <greyback> so at least the pre-blank and post-blank visuals will be identical <mterry> greyback: I plan to drop the slide-in animation when blanking <mterry> greyback, so should be immediate <racarr> but then there is just <racarr> one frame before you blank <racarr> that is wrong <greyback> mterry: but then we've the problem again. There'll be some old pre-blank frames in the shell's buffer of frames, which will only be rendered after screen unblanked <greyback> Mir does triple buffering for apps, so every app has up to 3 frames ready at any one time <mterry> greyback, heh, you mean by making the greeter show faster, I'm making it worse? :) <greyback> s/apps/clients/ <mterry> greyback, guh, seems like the empty-queue method is the right way <mterry> greyback, but that's not going to happen soon you don't think? <racarr> I mean I can probably get to it by thursday <racarr> I just mean I cant do it right now <mterry> racarr, I don't think this is AAA priority <ricmm> its not AAA priority <mterry> racarr, it is marked for v1freeze, but doesn't need to be fixed today <racarr> ok <ricmm> wait a sec <mterry> racarr, for tracking purposes, bug is 1233564 <racarr> ill mention it at the weekly meeting to confirm the approach <greyback> racarr: yeah, good idea <ricmm> if it will be the Mir way, then it needs to happen ASAP, because Mir has a long turnaround and it usually breaks other things <racarr> and hopefully do it on thursday <ricmm> if its shell it can wait as its higher level and simpler <racarr> mir ;) <greyback> racarr: let us know if the other Mir guys approve of it or not <racarr> ok <racarr> it made it in to the .org file :) <mterry> racarr, to ricmm's point, do you know if there will be enough time afterward to land well? When are you guys planning last drop? <racarr> "last drop" -> *chills up spine* <racarr> I...honestly don't know <racarr> kgunn: ^? <mterry> racarr, thanks btw for offering to do the work. I've got the unity8 side of this, but would not be able to do Mir side in any reasonable timeframe <ricmm> kdub: my bad in the end <ricmm> disabling it does work fine <ricmm> sorry <racarr> mterry: No worries <racarr> my current delegation is to be a unity<->mir bug fairy and work on the mirserver API inbetween :) <kdub> ricmm, no problem, i'll mp a fix that disables that signal <ricmm> kdub: thank you, make sure it doesnt break maguro <racarr> [ RUN ] TestClientInput.clients_receive_injected_input_per_norm <racarr> [ OK ] TestClientInput.clients_receive_injected_input_per_norm (17 ms) <racarr> and they like it too. <racarr> lots of mechanical event conversion code to write + tests before motion events make it through <racarr> but got the inject to handle mechanism established <davmor2> kgunn: image 75 is finally with us, So I'll give mir a hammering tonight and tomorrow am and let you know what I find :) <kgunn> mterry: racarr as to last code drop - well Oct 10 is supposed to be the cut off <racarr> not that anyone is counting right?!?! <racarr> >< ok thanks <thomi> kgunn: ping? <thomi> actualkly, nvm. read my email <kgunn> thomi: :) <thomi> this is such a mess. to make matters worse, I'm pretty sure I'm getting sick :-/ <kgunn> racarr: mterry it seems we almost need a compositor flush command ? <kgunn> if i understand the scrollback correctly <racarr> yeah <davmor2_> kgunn: I had to stop running mir after an hour animation ground to a standstill. Are there any logs or info that would be useful to diagnosing why and I'll try again <kgunn> davmor2_: anything in var/crash ? <davmor2_> kgunn: hud service crash maliit crash and a couple of others. <davmor2_> kgunn: I'll clear it down though then run some more tests, also hud didn't work under mir but is under sf. I'll run top and look at crash reports and grab some logs tomorrow it's getting late now :-) <kgunn> davmor2_: yep...knew about the hud... <kgunn> davmor2_: do you know how to unwind a crash file ?....have to download symbols <kgunn> run apport backtrace or some such....i'll try to find the wiki... <kgunn> but getting slammed in another channel atm <davmor2_> kgunn no rush dude I'm calling it a night just ping me or mail me on ramirezanna@example.org I'll be testing in the morning now any way :-) <kgunn> racarr: ping <racarr> kgunn: pong <kgunn> racarr: in unity...we think we might be screwwed on AP test enabling <kgunn> thomi was just pointing out <kgunn> that AP is built to just launch apps w/o shell <kgunn> but i don't think that's possible (atm) <kgunn> racarr: ^ ? <racarr> part of the plan with <racarr> this idea that only the shell would launch apps/it would verify the PIDs <racarr> were that 1. The shell would grow a dbus interface for launching apps <racarr> 2. upstart could be used directly by things that want to launch apps <racarr> and unity recognizes the PID from upstart and matches them <racarr> I don't believe 2 is implemented <thomi> racarr: is 1. implemented? <racarr> No, but it seems like it could be quickly <racarr> I mean, to unblock things <thomi> ok. We need it in like.... 30 minutes... doable? <racarr> unity-mir could have an environment variable <racarr> UNITY_MIR_DISABLE_SESSION_AUTHORIZER <racarr> for test runs <racarr> that's doable in 30 minutes :p <racarr> god you guys scared me <kgunn> racarr: thanks...if you could.... <racarr> I thought it was just like "none of the tests work" <kgunn> racarr: you have no idea <racarr> yeah will do it right now! <thomi> racarr: so.. we'd need to export that before unity8 started? <thomi> cos that runs inside upstart, so we'd need some upstart hacks as well <thomi> racarr: ? <thomi> I guess this also means that we can no longer run apps without the shell running? <racarr> thomi: https://code.launchpad.net/~robertcarr/unity-mir/disable-authorizer-env/+merge/188717 <racarr> yes <thomi> dandrader: veebers - you guys should probably read this conversation: ^^ <thomi> racarr: yes to which question? <racarr> yes we need to export it before unity 8 starts <racarr> I don't know how upstart environments work <racarr> presumably, as this is a required in 30 minutes solution, upstart can echo UNITY_MIR_DISABLE_SESSION_AUTHORIZER=1 to /etc/some/file/that/i/dont/know/the/name/of <racarr> and restart unity :p <racarr> err <racarr> upstart can echo, I mean <racarr> autopilot can echo <kgunn> veebers: ^ AP can echo ? <veebers> kgunn: yep, it can shell out or write a file etc. <veebers> I'm just reading the backlog to get context <kgunn> racarr: https://plus.google.com/hangouts/_/16ed3d4ac7bbdd50e109aaabbce63c149b8fb526?authuser=1&hl=en <racarr> brt <racarr> ill brb whole system performance <racarr> is awful <racarr> need to restart X <kgunn> thomi: so racarr is free ? <kgunn> ...or we still need the UNITY_MIR_DISABLE_SESSION_AUTHORIZER=1 to /etc/some/file/that/i/dont/know/the/name/of <racarr> seems unnnecessary because <thomi> kgunn: We probabyl won't need that <racarr> they have this desktop file hint workaround thing <thomi> but lets keep it around, just inc ase <thomi> thanks for that though racarr :) <racarr> ok, leaving for space burning man, see you guys in a month. <kgunn> :)) <racarr> ...:p <racarr> back to input injection <racarr> 80% done <racarr> reversing the lexicon and the assosciated tests is turning out to be really tedious <Saviq> racarr, btw, bug #1233245 - known issue? <ubot5`> bug 1233245 in unity8 (Ubuntu) "Volume up/down keys not working with Mir" [High,Incomplete] https://launchpad.net/bugs/1233245 <racarr> Saviq: new to me <Saviq> racarr, we're not getting any VolumeUp / VolumeDown keys - neither when there's an app in focus or not <Saviq> racarr, also, the fact that if you try starting unity8 when screen is blank results in "cannot unblank screen" and then you need to reboot, otherwise "address already in use" happens? <racarr> second one sounds like a stale unity 8 process is lingering <racarr> not sure what is supposed to happen when multiple procsses try and useHWC <racarr> first one...I think ugh <racarr> there may be an issue with unity8 actually getting key events because of the way its input areas work <racarr> its pretty unlikely that it would have key focus... <racarr> I guess, the first step would be to ensure mir_demo_server_input_filter produces key events on volume up/down but im almost certain it does (it certainly used to) <racarr> then to ensure a normal Qt client can receive them <racarr> and if so then the shell just isn't getting focus <racarr> but maybe they are getting lost in the Qt keymapping (As an example) which isn't tested much because OSK shortcircuits it <racarr> Saviq: probably the absolute first thing to try is run unity8 with MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log <racarr> and see how far the events get <racarr> ill start updating my phone ;) <racarr> but I can't spend a bunch of time on it right now, I need to power through this input injection thing <racarr> so we can get the HUD going <Saviq> racarr, yeah, k <racarr> mzanetti: Needs another hour or two of work before it can land but this should work: https://bugs.launchpad.net/mir/+bug/1233378 <ubot5`> Ubuntu bug 1233378 in Mir "Unity requires input injection API from Mir " [Undecided,In progress] <racarr> rtt <racarr> err <racarr> https://code.launchpad.net/~robertcarr/mir/input-injecter-api/+merge/188743 <sarnold> hrm, what does the #ifdef ANDROID _really_ mean here, and why does ANDROID platform not have st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abmake_shared? http://paste.ubuntu.com/6181654/ <racarr> sarnold: IT means is mir built with MIR_PLATFORM=android, i.e. are we using the android graphics drivers <racarr> android does have make_shared, the code is a little tricky to parse, on android it is returning a new instance <racarr> of the MirNativeBuffer object <racarr> on not android (GBM or nested) it is returning an empty shared pointer (null) of type MirNativeBuffer <racarr> "returning a new..." -> "returning a pointer to a newly allocated instance" <sarnold> racarr: thanks :) <thomi> racarr: still awake? <thomi> kgunn: the next issue seems to be input related - the autopilot input emulators don't have any effect on the launched applications. <thomi> as in, we try and tap on a button, and nothing happens <thomi> python <thomi> dammit, wrong window again <thomi> robert_ancell: who else can I ping about this? <racarr> thomi: oi <thomi> oh, you are awake :) <thomi> racarr: so.. any time I try and use the UInput touch driver that autopilot has, a big fat nothing happens on the screen <racarr> ok that is supposed to be synthetic udev devices right? <thomi> yes, essentially it's a user-space udev driver <racarr> It should work, so the first step is really to get MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log <racarr> then we should be able to see if the devices are loaded/recognized <racarr> and what happens <thomi> so, I should set those before starting unity8, and then paste you the unity8 log file? <thomi> I suspect the problem is that the udev device node only gets created when autopilot creates the touch device, which is long after the shell has started <thomi> does that sound plausible? <racarr> about pasting the log file and startying unity8: Yes :D lets get stderr and stdout <racarr> about the theory: It's plausible but device adding/removing should work <thomi> OK, I'll do that now <racarr> cool <racarr> we should have a MIR_DUMP_EVERYTHING_THAT_MAYHAPS_BE_USEFUL_FOR_DEBUGGING #ubuntu-mir 2013-10-02 <thomi> racarr: ok, log incoming <thomi> racarr: http://paste.ubuntu.com/6181800/ <thomi> racarr: I don't see any mention of the uinput device <thomi> racarr: which is called 'autopilot-finger' BTW <thomi> racarr: in that log, the input events are me unlocking unity8 with my finger <thomi> no autopilot <thomi> I wonder about these two lines: <thomi> [EE, android-input] [EventHub]could not open /dev/input/event6, Permission denied <thomi> [EE, android-input] [EventHub]could not open /dev/input/event7, Permission denied <thomi> yeah, so when we create the autopilot touch driver, even6 and event7 appear on the /dev/input folder <racarr> thomi: i would say thats almost certainly it <thomi> not sure why we get 'Permission denied' though, the permissions on those device nodes are identical to all the others <racarr> I guess unity8 isnt run with root, but something sets the permissions on the /dev/input nodes it needs to something it can use <racarr> group? <racarr> apparmor? <racarr> secret-security-framework-number-9 <thomi> group is all the same, android_input <thomi> who would I talk to about apparmor? <racarr> I dunno <thomi> Jamie maybe, if he's still awake <racarr> I bet ricmm would know more than me <racarr> ricmm_: ^ ? <racarr> maybe its a race with setting the permissions <racarr> and opening hte device <racarr> I dont know <racarr> where the permissions <racarr> comes from <kgunn> thomi: good grief... <kgunn> i mean how did that work prior to mir....shoulda been the same right <thomi> kgunn: racarr, OK, I've eliminated apparmor as a culprit <thomi> racarr: are you able to see what would cause that permission denied error in mir? <racarr> its the same error you get if you urn it on the desktop without <racarr> permissions to open the /dev/input devices <racarr> looking <thomi> I see it's in EventHub.cpp:961 <racarr> Mm <racarr> errno doesnt lie <racarr> permission is denied <racarr> (kind of catchy when you say it outloud) <thomi> but... <thomi> http://pastebin.ubuntu.com/6181858/ <thomi> what. thefuck. is. goingon!? <thomi> robert_ancell: does mir drop priviledges after starting up? <thomi> oops, I meant racarr ^ <thomi> like, maybe when it loads initially, it's running as root, but then it drops to being run as a user that isn't root or in the android_input group? <racarr> not that I know of <robert_ancell> thomi, it does not <thomi> bums <racarr> is it possible the devices are being probed after mir opens , mir tries to open them fails, gives up, then they get given <racarr> the appropriate permissions? <thomi> I'll try creating the devices first, then starting mir <sarnold> are there devices that refuse O_RDWR but work fine for O_RDONLY ? <kgunn> thomi: any luck <thomi> kgunn: long answer: check out #ubuntu-touch scrollback. short answer, no ramirezanna@example.org. Have managed to stump several people much smarter than I am :-/ <kgunn> thomi: i see you are basically left to contemplate the infinite in #touch...can you summarize where you are, maybe duflu in his inifinite linux device wisdom might have some tricks * duflu thinks you have the wrong name there <thomi> kgunn: sure <thomi> actually, I should probably file a bug so my progress is not lost to the grey mist I'm happy to call my memory <kgunn> thomi: so this same thing works in SF ? <thomi> yup <thomi> just writing up a bug report. Will be done in a few minutes <kgunn> thomi: hmmm....by removing sf, could something not be setting wider permissions that should? <duflu> Thank you for not continuing the tradition of bugs that only exist in IRC <thomi> we looked pretty exhaustively at permissions <thomi> duflu: :) <thomi> this is a big one <kgunn> ditto to the documenting it in a bug <duflu> robert_ancell: Please stop removing distro tasks. They are absolutely required where bugs are reported against distro, and fixed in distro <robert_ancell> duflu, none of the other bugs have distro tasks and all mir bugs affect distro. There's no need to duplicate entries <duflu> robert_ancell: They're not duplicate. They clearly delineate where a fix is upstream or in distro <duflu> Launchpad is designed that way <robert_ancell> duflu, in the case of mir upstream == distro <duflu> robert_ancell: Not true. Our upstream fixes are usually days (or weeks) ahead of distro. And after we branch properly, months <duflu> Hence you need separate tasks <robert_ancell> duflu, when it's marked fixed released it's in distro <duflu> robert_ancell: No, that means fix released upstream (usually as a tarball). Hence Fix Released upstream often happens after distro in reality <robert_ancell> duflu, in reality our releases are done automatically and straight into distro. There's no tarballs <duflu> robert_ancell: You can't make up your own rules different to the rest of Ubuntu. People need and expect ubuntu tasks to know what's going on <robert_ancell> duflu, you can, we have, there's no point making ensuring ever bug has both an upstream and ubuntu task open on it. All Mir bugs are Ubuntu bugs, we've decided to track them all in the upstream tracker <thomi> duflu: kgunn, anyone else who cares: this is what I've been bashing my head against all day: https://bugs.launchpad.net/mir/+bug/1233944 <ubot5> Ubuntu bug 1233944 in Mir "Unity8/Mir is unable to open autopilot uinput devices" [Critical,New] <duflu> robert_ancell: Anyone who uses Ubuntu and Launchpad knows that fixed in "Mir" does not mean fixed in "Ubuntu". We need to communicate more clearly and there's a simple protocol in place. Why not just make the bugs *accurate* ?! <kgunn> robert_ancell: racarr (if you're on) kdub ^ <thomi> I will purchase many drinks for the person who solves this for me <duflu> robert_ancell: If you want, I will do it. I do so anyway. I just can't stand working in an environment where even the information describing what we're doing is wrong <robert_ancell> duflu, I'd say most people who use Launchpad don't know or care about the distinction between upstream and downstream tasks. The bugs are accurate. <robert_ancell> duflu, no, it's a huge amount of pointless paperwork <duflu> It's not huge, and it has a very clear purpose. Launchpad's bugs a multidimensional for good reason <robert_ancell> duflu, they were done like that because there was a large number of components that have different upstreams and downstreams. In this case that has not occurred. The software center team used this practise because it made things much easier and it matches my experience too <thomi> I gotta go walk in the pouring rain to clear my head for a bit. When I get back, I expect to see a bugfix waiting for me ;) <thomi> brb <robert_ancell> thomi, I'm looking at this bug but you probably know more about the input layer than me <robert_ancell> thomi, I'm a little unsure of what you mean in the report - does Mir never get input from these devices or only if they are created before Mir starts? <thomi> robert_ancell: mir is only able to open the devices if they exist before mir starts <robert_ancell> thomi, and you get the input events from them? <thomi> robert_ancell: well, I never got that far, but the open() call doesn't fail, which is what's happening in the error case <robert_ancell> thomi, so the bug essentially seems to be "mir fails to hotplug input devices"? <thomi> I guess so <kgunn> thomi: robert_ancell ...ok thinking aloud (and yes i'm a manager i'll try not to hurt myself) <thomi> robert_ancell: feel free to change the bug title :) <kgunn> but...it bothers me this is "3rd party code"..so i dig around in cynagenmod <robert_ancell> thomi, can you show me the code that creates the devices? <thomi> robert_ancell: sure... one second <kgunn> it seems that eventhub.cpp is built into either
{'channel': 'ubuntu-mir', 'month': 10}