#ubuntu-mir 2013-09-09
<RAOF> Ok. Now that I can boot again...
<olli> RAOF, ping
<RAOF> olli: Pong
<olli> hey
<olli> I don't have the dial in information yet, but will send it via mail to you at the start of the meeting (which starts in 2h:16min)
<olli> we won't have IRC at the partner side and (g)mail overall is flaky at best
<olli> RAOF, do you want to give me a cell I can send the information to just in case?
<olli_> RAOF, we are starting a bit early
<olli_> mike should have sent you the dial in information
<RAOF> olli_: Yes.
<RAOF> Although without a country code.
<RAOF> olli: http://lists.freedesktop.org/archives/mesa-dev/2013-August/044021.html
<RAOF> olli: (Vendor-neutral OpenGL dispatch)
<RAOF> olli: Are you likely to need me more on this call?
<olli> RAOF, we are good
<olli> thanks for joining!
<RAOF> Thanks.
 * RAOF heads ZoÃ«wards
<mlankhorst> RAOF: hmz enough mir bugs filed against xserver :P
<alf_> mlankhorst: any thoughts on https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html ?
<mlankhorst> alf_: yeah, not sure if it only affects the mir case, I've seen a bug like that before
<mlankhorst> alf_: by any chance can you compile intel-gpu-tools?
<alf_> mlankhorst: I can, do you need any specific version (e.g. not what's in the package right now)?
<mlankhorst> git
<alf_> mlankhorst: ok, getting and compiling will ping you when I am done
<mlankhorst> grab the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/
<mlankhorst> and then boot it, you don't need to install intel-gpu-tools, just compile it
<alf_> mlankhorst: ok
<alf_> mlankhorst: (I am already using drm-next kernel)
<mlankhorst> test if the bug still occurs there, if so please run intel-gpu-tools/tests/gem_flink_race ?
<mlankhorst> requires i915
<mlankhorst> and also prime_self_import
<alf_> mlankhorst: bug still occurs (gem objects "disappear" when using prime fds, work correctly when using GEM names)
<alf_> mlankhorst: result of tests: http://paste.ubuntu.com/6083268/
<mlankhorst> alf_: hm can you set pls_die = 0 before each pthread_create in those 2 tests?
<alf_> mlankhorst: ok
<mlankhorst> alf_: hm and also run the commands without Xorg running :)
<mlankhorst> alf_: hm, also seems that it requires RAOF's patch for determining dma-buf size
<mlankhorst> but that one doesn't matter as much
<mlankhorst> it's a separate test
<alf_> mlankhorst: I have added pls_die before the loops that pthread_create() in the tests
<mlankhorst> yeah then just retry from console, -41 is suspect :P
<alf_> mlankhorst: gem_flink_race consistently succeeds without leaks but prime_self_import occasionally fails at export-vs-gem_close-race
<mlankhorst> alf_: oops, lost connection
<mlankhorst> did I miss anything?
<alf_> mlankhorst: gem_flink_race consistently succeeds without leaks but prime_self_import occasionally fails at export-vs-gem_close-race (http://paste.ubuntu.com/6083327/)
<mlankhorst> alf_: is that with Xorg killed?
<alf_> mlankhorst: ah, I thought you meant "not in Xorg" not with Xorg killed :) Will try...
<thomi> morning
<mlankhorst> alf_: considering it uses debugfs, the test is probably useless if xorg can do things behind it's back, but meh that seems to mean that there is no race in i915 at least..
<alf_> mlankhorst: ok, without X running tests work consistently
<mlankhorst> alf_: hmz
<mlankhorst> nasty stuff this lifetime thing..
<mlankhorst> alf_: you'd be my hero if you could come up with a testcase not involving mir, or some way for me to reproduce it, iirc radeon had some weird bug too?
<mlankhorst> on non-nested mir with xorg-server
<mlankhorst> oh.. hmz
<alf_> mlankhorst: Instructions to reproduce it with Mir are in the mailing list email. I am not sure how easy is going to be to reproduce this problem outside of Mir, given that we (at least I) have no idea what could be causing it internally  :/
<mlankhorst> alf_: from what I can tell GEM internally uses no refcount.. eg if you import a bo twice and call close once, the handle will disappear..
<mlankhorst> or if you import to the same fd, and call close once
<mlankhorst> close -> GEM_CLOSE
<mlankhorst> flink also doesn't seem to survive if GEM_CLOSE is called though.. meh wtf
<mlankhorst> what's the mir ml?
<mlankhorst> nm got it
<mhall119> RAOF: ping
<mlankhorst> alf_: I'm guessing it's a bug in mesa, specifically the calls like intel_process_dri2_buffer
<mlankhorst> it assumes that the same fd can be opened multiple times without consequences
<mlankhorst> the solution is to compare against the internal gem handle instead
<mlankhorst> which is drm_intel_bo->handle, or w/e equivalent is returned from drmPrimeFDToHandle :P
<mlankhorst> guaranteed to be unique to the fd, I'll try to cook up some patch
<alf_> mlankhorst: That would be great! Ping me if you want me to try out anything. Another related question: My initial implementation of eglcreateimagekhr used image->dupImage() (#if-ed out in the mesa patch) but that doesn't work at all (the creation succeeds)... Any quick ideas why? Does the imag need to be used on the same DRIScreen (the original image is created in the GBM provided DRIScreen)?
<mlankhorst> alf_: mixing things is probably a recipe for disaster :P though I guess they might be identical
<mlankhorst> dno tbh
<mlankhorst> radeon_winsys_bo_from_handle seems to handle it correctly
<alf_> mlankhorst: (@dupImage, thanks, at least we have a way to create the image that works)
<mlankhorst> alf_: http://paste.debian.net/37451/
<mlankhorst> no idea if that works or not
<mlankhorst> oops needs refresh :P
<mlankhorst> http://paste.debian.net/37452/
<mlankhorst> that one probably compiles
<mlankhorst> alf_: let me know if it fixes your issue
<alf_> mlankhorst: will do thanks
<mlankhorst> oops :p
<dandrader> racarr, ping
<mlankhorst> plan b for fixing, this one didn't work..
<mlankhorst> alf_: http://paste.debian.net/37460/ that one should compile correctly
<alf_> mlankhorst: ok, I will try in a bit
<mlankhorst> alf_: ugh it's missing a chunk
<alf_> mlankhorst: ?
<mlankhorst> alf_: because I suck at making packages, try mesa 9.2-1ubuntu2~ppa1 from https://launchpad.net/~canonical-x/+archive/x-staging/+packages
<alf_> mlankhorst: @populating region.name, if we are dealing with prime fd buffers, won't all incoming buffer only have the .fd field populated? Setting the region flink name, won't help us avoid recreating the region. Am I missing something?
<kdub> alf_, going to try nested mir on android today... alan_g mentioned there might be some branches that could help with that?
<alan_g> alf_: I meant the cleanup to the "nested" code that you pointed out last week
<alf_> kdub: alan_g: the changes are here, although there is also a lot of debug code lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack/
<kdub> alf_, cool, thanks
<alf_> kdub: the relevant changes are in nested/* files in revision 1054
<alan_g> alf_: kdub - if there's no objections I'll wrap them in an MP  to get them onto trunk
<alf_> alan_g: no objections, although they may need some design love... they were made as a quick POC
<alan_g> alf_: Understood, was planning that
<kgunn> alan_g: alf_ kdub ...thanks for all the focus, i'm gonna head to lunch/gym...any questions for me before i head out?
<alf_> mlankhorst: tried the patches (I applied the intel changes to a local clean branch of RAOF's git to be exact), no change :/
 * kdub thinks NativePlatform and Platform should be the same interface
<racarr> dandrader: Pong?
<dandrader> racarr, check private messages
<kdub> alf_, (if you're still around) would you mind me removing the NativePlatform interface?
<alan_g|EOD> kdub: why would you want to do that?!
<kdub> its the same as the Platform interface
<alan_g|EOD> It is there because we haven't yet proved that they need to be the same.
<alan_g|EOD> I was keeping it separate with the intention of refactoring to remove duplication later
<kdub> alan_g|EOD, okay, i'll leave it for now... but with android it is the same
<alan_g|EOD> kdub: It will probably be the same or a subset
<racarr> Cool to se enested mir on android come together
<racarr> and nested in general :)
<racarr> spinning in circles on this DPMS IPC conundrum though :(
<kdub> racarr, conundrum?
<ricmm> racarr: ping
<racarr> ricmm: Pong
<racarr> kdub: The thing where you turn off the screen via IPC then call next buffer so your server side socket session is blocked
<racarr> and you can never turn the screen back on
<kdub> racarr, ah, yes, that one
<kdub> i guess my thoughts are about the same... swap buffers already has blocking as part of the semantics
<kdub> well, to put it more clearly
<kdub> i'm okay with a client getting stuck in that scenario, would seem like its up to them to avoid
<racarr> ugh sorry internet outage.
<racarr> kdub: The problem isn't exactly the client getting stuck
<racarr> the thing is even if you use async  next buffers
<racarr> your server side processor gets stuck too
<kdub> racarr, yeah, might take some reworking of the message processor then
<kdub> good morning robert_ancell
<kgunn> racarr: thinking aloud...is it that you need to like "drain the render queue+ take no more new render submissions"
<robert_ancell> kdub, hello
<racarr> kgunn: The thing is it will never drain because it wont finish until you turn the display back on
<racarr> which wont happen until your last message (this buffer swap is finished)
<racarr> the buffer swap shouldnt really be an error though
<racarr> it should just be pending and eventually it runs
<kdub> racarr, also though, say that the user pushes the power button on the phone or something like that
<kdub> do we send an event over the wire, the client processes it, and then invokes the 'screen on' command?
<kgunn> racarr: oh, i was saying as a precondition to blanking....so user hits button, then you stop new requests...but let any pending renders complete
<kgunn> racarr: that would be weird to be blanked...then allow a render of a frame or 2 of something ancient
<kgunn> mornin robert_ancell
<racarr> the thing is if you are processing a pending render from the client that asks to turn off the display
<racarr> and in the xmir case it is a client
<racarr> then you never process that message
<racarr> so you never know like "let pending renders complete" etc
<kgunn> robert_ancell: is the last mp to kill to the vt input security bug ? https://code.launchpad.net/~robert-ancell/mir/drop-focus-on-vt-switch/+merge/183059
<racarr> kdub: On the phone its all in the shell
<racarr> and clients are just told screen on/off via display configuration and can do their things
<kdub> racarr, right
<racarr> swap buffers will block, everyone is happy
<racarr> xmir is the onlyproblem I thin
<racarr> and mir demo client display config :p
<kgunn> racarr: got it...i was thinking of draining renders more from the hw side of things
<robert_ancell> kgunn, yes, but it's not working. And after talking to RAOF we think it might work better to use the app lifecycle events instead
<robert_ancell> racarr, How are you supposed to access ApplicationSession? The container just has Session so you'd have to cast it - why doesn't the container contain ApplicationSession?
<racarr> kgunn: mm
<racarr> robert_ancell: It's just a matter of where you have to cast
<racarr> if the container contains ApplicationSession then you have to cast to frontend session in some places
<racarr> iirc, or some nonsense like that
<racarr> it's flipped at least once since we started XD
<racarr> You just have to cast sometimes
<racarr> because msh::SessionManager API is from mf::Shell so it deals in frontend::Session
<robert_ancell> racarr, but the container always contains ApplicationSession - so shouldn't we just change the container?
<robert_ancell> Otherwise what do I do if I can't cast?
<racarr> robert_ancell: Throw an exception or assert
<racarr> changing the container is reasonable
<racarr> there is a bit of problem with testing because ApplicationSession isnt an interface
<robert_ancell> racarr, why do we need ApplicationSession - why can't this just be part of Session?
<racarr> robert_ancell: Well we want at least some interface, i.e. the frontend shouldn't use the shell implementation class
<racarr> perhaps it should be just like surface, mf::Session and msh::Session
<robert_ancell> ricmm, Should MirLifecycleState contain more states?
<ricmm> no
<ricmm> it could contain more information for the application to do more stuff, but the only state exposed to the application is focused(running)/unfocused(not-running)
<RAOF> mhall119: Yo!
<RAOF> mlankhorst: You sent a midnighht ping?
<RAOF> ricmm, robert_ancell: But the lifecycle state callback needs more information, doesn't it?
<RAOF> ricmm, robert_ancell: Specifically, it needs a cookie so the client can call back to call back to Mir when it's done saving its state.
<robert_ancell> ricmm, I see mir_lifecycle_state_will_suspend,  mir_lifecycle_state_resumed - does that map to focused / unfocused?
<robert_ancell> also what RAOF said
<RAOF> Oooh.
<RAOF> Do we still have time to roll up some more ABI breakage into libmirclient3?
<robert_ancell> RAOF, not really
<RAOF> robert_ancell: It doesn't look like it has been built into a package yet?
<robert_ancell> RAOF, well, right
<robert_ancell> RAOF, I guess you could make a libmirclient4 without any more work
<RAOF> Can be *stop* it being built into a package?
<robert_ancell> RAOF, the numbers cost nothing, it's just the migration. So 2-3 costs the same as 2-99
<RAOF> Eh, ok.
<RAOF> Two more ABI breaks coming right up!
<RAOF> Ah, no. We changed how get_current_buffer works; this won't be an ABI break.
#ubuntu-mir 2013-09-10
<mhall119> RAOF: hey, I was just going to ask if you had any indication from ickle about that patch rejection, other than what was in the git log and NEWS file
<RAOF> mhall119: No, I've not.
<mhall119> I really feel sorry for him, sounds like he's in an unpleasant spot
<RAOF> I don't know; I don't have a feel for Intel-internal politics.
<RAOF> robert_ancell: https://code.launchpad.net/~raof/mir/prebump-abi-for-lifecycle-cookie/+merge/184703 ?
<robert_ancell> RAOF, cool. I have the u-s-c change in lp:~robert-ancell/unity-system-compositor/app-lifecycle - still feels a bit clunky though
<jrr> I tried out mir last night (installed unity-system-compositor , open source radeon driver), and the whole display had small black stripes (say, 5px normal, 5x black, 5px normal... across the whole thing)
<jrr> is this known, or should I re-repro and file a bug?
<robert_ancell> RAOF, so the logic for XMir needs to be, don't grab input devices on startup until you get  lifecycle state set to "mir_lifecycle_state_resumed". Drop them on "mir_lifecycle_state_will_suspend"
<robert_ancell> jrr, just file a bug and we'll mark it duplicate if there is already one
<jrr> alright, will do
<RAOF> robert_ancell: And then tell Mir that it's done, right?
<robert_ancell> RAOF, yes, once we can do that
<robert_ancell> RAOF, and if I don't hear from you in a reasonable amount of time I just drop your connection :)
<RAOF> :)
<robert_ancell> RAOF, how can I build a local XMir to test this?
<RAOF> ./autogen.sh --prefix=$HOME/.local --enable-xmir && make -j9 && make install
<robert_ancell> RAOF, have you made the switch from surface focus to app lifecycle on master?
<RAOF> No, I haven't yet.
 * robert_ancell -> lunch
 * RAOF â coffee
<ricmm> RAOF: no, thats not how the application model is defined
<ricmm> applications are given a long timeframe to save their state
<ricmm> theres no calling back into the server to signal state saving completion
<ricmm> its a hard policy scenario, the client has no say in the time/resource constraints associated with its lifecycle
<RAOF> My reading of the application lifecycle doc was that the on_application_about_to_stop callback would â3. Wait for timeout or completion then SIGSTOP the process.â
<RAOF> Which implies to me that the unity API needs some way to signal completion?
<RAOF> Not that *client code* would be calling it; we don't expect clients to use libmirclient directly anyway.
<RAOF> ricmm: ^^^
<tvoss__> RAOF, nope, the client just receives the signal, and is granted a grace period for serialization
<tvoss__> a.k.a. state preservation
<ricmm> RAOF: if the document says that then it is wrong, will need to update it
<tvoss__> ricmm, taking an AI to update
<ricmm> thanks
<tvoss__> ricmm, might be later my day, though
<tvoss__> google docs are a bit difficult in this place
<ricmm> no worries, about time to sleep over here
<ricmm> RAOF: consider that 3. item broken, tvoss will update document, applications only get signaled of an about_to_suspend() transition
<ricmm> or a resumed() transition if they are previously-stopped applications
<ricmm> otherwise they start from 0, its up to applications to restore their state from their serialization targets
<ricmm> thnks for taking an interest in clarifying the design guidelines
 * ricmm -> beer/sleep
<RAOF> Hm.
<RAOF> I'd prefer if 3. *wasn't* broken, and I'm not sure why we're adamant that it is.
<robert_ancell> RAOF, what's the document link?
<RAOF> robert_ancell: https://docs.google.com/a/canonical.com/document/d/186nT03Jyu_d-GMyJ--8Qp83o1Ey-O1EsWZtwrPGE2TQ/edit
<robert_ancell> RAOF, hmm, I'm not seeing how this can be completed without the shell being signalled when a client has completed
<RAOF> robert_ancell: I think they're just going to not bother with the "until completed"
<RAOF> robert_ancell: So instead it's âSIGSTOP after $TIMEOUTâ
<RAOF> Rather than SIGSTOP after $TIMEOUT or completion, whichever happens first.
<RAOF> Which I think is the trivially better behaviour, so I'm not sure why they're adamant that it should not be that way.
<robert_ancell> RAOF, right, but the component that does the killing is the shell right? Which means it has to know when completion occurs to do the killing. Unless the platform API has a separate thread that does the killing if the function call doesn't return in a sufficient time
<robert_ancell> I'm not sure how this is all implemented
<RAOF> robert_ancell: No, it can just assume that completion has occurred by $TIMEOUT.
<RAOF> ie: the shell sends the "about_to_suspend" signal, and then in 10 seconds SIGSTOPs the client.
<robert_ancell> RAOF, oh, I guess the process will quit before 10s if it is successful, so the "complete" signal is the process termination
<robert_ancell> RAOF, in our case where we don't actually want the process to quit, it doesn't work so well
<RAOF> Oh, no.
<RAOF> The process doesn't quit.
<robert_ancell> or in the case of the shell, it might not be the process termination but the Mir client connection quitting
<RAOF> It just has no completion signal.
<robert_ancell> RAOF, so the shell has 0 idea if the process is actually suspended?
<RAOF> Correct
<robert_ancell> ah
<RAOF> Well, the shell knows, because it's sent SIGSTOP
<RAOF> It has no idea if the process has *saved its state*
<RAOF> Which I think is silly.
<robert_ancell> yes
<RAOF> So I'm going to continue hacking on the cookie branch and then land it when they come to their senses.
<robert_ancell> :)
<robert_ancell> I don't see any reason not to send the signal back to the shell
<RAOF> Right.
<robert_ancell> The apps won't ever know
<RAOF> The shell doesn't have to *wait* for the signal
<robert_ancell> and it will be make debugging a lot easier
<RAOF> Yes.
<robert_ancell> rather than just guessing if an app actually suspended
<RAOF> And, hell, we'll be able to send SIGSTOP *sooner*
<robert_ancell> RAOF, does SIGSTOP free up any resources except for CPU?
<RAOF> And give interesting metrics, like âyour app took 5s to suspend, which is getting close to the 10s timeoutâ¦â
<RAOF> robert_ancell: No
<robert_ancell> I suppose it allows the kernel to page out all the memory for that app
<RAOF> Yeah.
<RAOF> But the kernel could page out all but one page of the app anyway.
<RAOF> (Assuming a reasonable app that's blocked when mir_swap_buffers is blocked)
<robert_ancell> and all apps will be like that :)
<ricmm> RAOF: consider it a no-op to the display server itself
<ricmm> if you want I can rewrite in a way that the Mir protocol itself needs not understand what the passed message means
<RAOF> I think it makes perfect sense for the Mir protocol to understand?
<RAOF> I'm not sure why having a âYo! I've finished this thing you asked me to doâ callback is a bad idea.
<ricmm> well I believe saying "until they come to our senses" is out of place
<ricmm> its irrelevant, this was planned ages ago
<RAOF> It doesn't prevent us from having a hard timeout.
<ricmm> for functionality scheduled to land for 13.10
<ricmm> and which has been in place since a long time ago
<ricmm> Mir being the new player in the game
<RAOF> For a little context: Robert and I would like for this callback to exist, because it's really useful for unity-system-compositor to know when XMir's done handling the "please suspend" message.
<ricmm> I dont think you need to care about the timeout or not, the lifecycle policy itself is up to the shell to implement
<ricmm> not the display server
<ricmm> *policy*
<RAOF> But the shell is a part of the display server. Not the display server policy, certainly, but the callback gives the shell a mechanism for better policy.
<ricmm> hmmm
<ricmm> I'm sorry but the display server is a library that the shell implements
<ricmm> the display server imposing non-display-server policy on the shell is wrong
<RAOF> But this isn't imposing policy?
<ricmm> yes, the shell and therefore the system can decide what policy to implement regarding application management
<ricmm> the display server != application manager
<RAOF> If the shell wants to ignore the completion event that's well within its rights?
<ricmm> the shell *defines* the existance of an event at all
<ricmm> maybe the mistake was exposing it Mir in terms of defined semantics
<ricmm> it should've just been an opaque message passing over a bus
<RAOF> An extensible Mir protocol. Yeah, that would have been a good idea :)
<ricmm> sure, but this is what we have due to lack of assigned man power
<ricmm> if it doesnt fit the XMir world, extend it
<ricmm> and make it fit, without breaking the touch world
<RAOF> Sure, that's what I intend to do.
<ricmm> great, but dont extend the lifecycle states, feel free to add extra stuff to the protobuf message itself
<ricmm> because the first interferes with the defined model
<RAOF> But the cleanest way to do that is to add a completion event to the lifecycle callback added the client passes to libmirclient.
<RAOF> That doesn't extend the lifecycle states, nor does it interfere with the model at all.
<ricmm> that is not going to happen before post-October planning
<ricmm> it demands extending a model that has been in place for many months now
<RAOF> What?
<RAOF> No it doesn't!
<ricmm> and it is not something that will be considered for development 4 weeks before delivery date
<RAOF> I don't see how it extends the lifecycle model?
<ricmm> well first of all I dont see why the *display* *server* needs to care about an application having saved its state
<ricmm> that souns like session/application management
<ricmm> am I wrong to think that?
<RAOF> Not particularly, but session/application management is also handled through Mir.
<ricmm> *if* you are doing some sort of session management in Mir to support XMir itself then thats XMir's problem (which only runs legacy applications, afaik)
<RAOF> This is true.
<RAOF> ricmm: So, http://bazaar.launchpad.net/~raof/platform-api/update-for-lifecycle-cookie/revision/149 is what this would look like, platform-api side.
<robert_ancell> ricmm, the session management is u-s-c managing its children (i.e. XMir), not the applications running underneath those (i.e. the X clients). It's the same logic as in the shell - when an application is no longer visible, then it should be triggered to suspend. In this case, when you switch sessions the old session is asked to "suspend" and it stops reading input (and potentially could do more if it wanted)
<robert_ancell> gtg, bye all
<alf_> RAOF: Hi! Any thoughts on https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html ?
<RAOF> alf_: Not really, no.
<RAOF> Although... hm.
<RAOF> It's possible that you're running afoul of the name caching that i965 does?
<alf_> RAOF: ?
<RAOF> In intel_context.c, intel_process_dri2_buffer
<alf_> RAOF: ah, yes, we were trying various things in there with Marteen yesterday but unfortunately didn't fix the problem
<RAOF> Ah, ok.
<alf_> RAOF: (not to say that the problem isn't there, perhaps we didn't try the right fix :))
<RAOF> âº
<alf_> RAOF: I am just saying that we haven't exhausted the investigation of what could be going wrong in intel_process_dri2_buffer with PRIME fds
<smspillaz> RAOF: does xmir copy the entire root window (as it lives in gpu memory) to a mir surface (which also lives on the gpu)?
<smspillaz> or does it copy and blit each subwindow directly
<RAOF> Entire root window
<duflu> smspillaz: Damage rects only
<smspillaz> ah, that makes sense
<smspillaz> yep +1
<RAOF> I'd like to subwindow it, actually.
<RAOF> But that's a discussion for next week.
<smspillaz> RAOF: that would probably make sense for the noncomposited case
<duflu> smspillaz: At least the intel DDX seems to loop through the rectangles and take as little as possible each frame
<RAOF> duflu: The other DDXen are similar, but they copy the bounding-box of the damage
<RAOF> smspillaz: Indeed.
<duflu> Close (and efficient) enough
<duflu> RAOF: In fact, possibly _better_ for cache performance
<RAOF> Indeed
<smspillaz> RAOF: I guess that's why some parts of xmir had to live in the ddx
<RAOF> Doesn't Intel gate on the number of rectangles, though, and do the bounding box given sufficiently many rectangles?
<smspillaz> because the 2d accel parts are all different wherever you look
<RAOF> smspillaz: Right
<duflu> RAOF: Not AFAIK... it copies the rects as they're given
<smspillaz> cool
<smspillaz> I was just explaining to someone why xmir stuff had to live in the drivers and wanted to make sure I understood the code correctly
<duflu> Speaking of which, I must set up a saucy nouveau today. To figure out which bugs are truly common
<RAOF> There's a long-term intent to do a generic xf86-video-mir using Mir's EGL platform and Glamor, but that's a lot more effort and likely to be less performant.
<alf_> duflu: @https://lists.ubuntu.com/archives/mir-devel/2013-September/000379.html, I think the OP is using fglrx?
<smspillaz> RAOF: as I thought
<smspillaz> RAOF: just to confirm, xwayland works by forcing all windows ot live on the cpu right?
<smspillaz> or at least the root window
<smspillaz> erm
<smspillaz> normal windwos actually
<smspillaz> its rootless
<smspillaz> (so that they can be used as a wl_buffer via shm)
<RAOF> No, XWayland also has DDX patches
<duflu> alf_: Possibly a good point, but not true for the existing reporters of that bug
<alf_> duflu: sure, just for this particular instance
<smspillaz> RAOF: ah okay
<smspillaz> RAOF: I wonder what's to us from having ddx patches which all they do is "copy damaged bit from PixmapPtr to fd however you like"
<RAOF> smspillaz: It's just that there's exactly one maintained xwayland DDX patch - intel. I wrote the ati and nouveau patches a year ago, and they're somewhat out of date.
<duflu> alf_: Unless it _is_ possible to start Mir with radeon while fglrx kmod is loaded?
<RAOF> smspillaz: Well, xwayland *doesn't* copy from the PixmapPtr; it shares the backing BO with weston, and submits damage rects.
<alf_> duflu: no idea if it's possible...
<smspillaz> RAOF: oh weird
<RAOF> smspillaz: Nah, it's perfectly sensible for a client-allocated model.
<smspillaz> I guess that makes sense actually
<smspillaz> because xserver was allocating anyways
<smspillaz> I wonder how hard it would be to beat the xserver into accepting some foreign buffer
<smspillaz> probably quite hard
<RAOF> No, pretty easy actually.
<RAOF> If we single-buffered in Mir I could totally do that for XMir.
<smspillaz> RAOF: ah, right
<duflu> RAOF: BTW, single buffering in SwitchingBundle recently became impossible in order to simplify the logic. But I could add it back in easily enough
<RAOF> I don't think we particularly want to use single-buffering.
<duflu> True
<duflu> That's a new one. Unity panel takes up a quarter of the screen height
<duflu> RAOF: How do I disable i915 and let nvidia/optimus rule?
<RAOF> duflu: In your bios?
<duflu> RAOF: No such option. Either intel only, or both intel+nv with intel given control of all outputs except VGA :(
<RAOF> duflu: You *may* have luck with /sys/kernel/debug/vgaswitcheroo
<RAOF> But it's also possible that the nvidia card is *only* hooked up to VGA
<duflu> RAOF: It certainly looks like nvidia only talks to the VGA port. That's quite annoying and unexpected
<RAOF> Not entirely unexpected. Hardware muxes cost money.
<RAOF> And suck a bit anyway
<duflu> No wonder it cost me so little :/
<RAOF> (Unless you do fancy things, like Apple do/did)
<duflu> Great. Then I still have only intel hardware for saucy/xmir testing.
<RAOF> Except for the vga port? :)
<duflu> RAOF: I particularly needed dual monitor testing
<RAOF> Hm. Less useful.
<duflu> Oookay. Perhaps I need a second desktop and prerequisite electrical upgrades to the house :/
<mlankhorst> alf_: oh btw are you sure it didn't help things? if so can you please do a strace of the failing process?
<mlankhorst> with patches applied
<mlankhorst> I only care about the failing instance, maybe it will show a clue of what's wrong
<alf_> mlankhorst: ok, just be sure (because I am applying the patches to a local tree), I only care about the intel changes from the diff, right?
<mlankhorst> what other changes are there in that diff?
<alf_> various other bits here and there e.g. in the gallium state tracker
<mlankhorst> oh just some whitespace fixups
<alf_> mlankhorst: @populating region.name, if we are dealing with prime fd buffers, won't all incoming buffer only have the .fd  field populated? Setting the region flink name, won't help us avoid recreating the region. Am I missing something?
<mlankhorst> why wouldn't it?
<mlankhorst> if 2 buffers ar equal the flink name would be the same
<mlankhorst> but.. mayb3e stracea will help  find the issue
<duflu> RAOF: Did you (or someone) hack xserver-xorg-video-intel to fix initial mode selection?
<duflu> It's *different* now
<alf_> mlankhorst: sure, but the incoming buffers don't have the .name field set, just the .fd field, so they will always compare unequal to the region. Unless, that is, the buffer information is also updated somehow?
<mlankhorst> alf_: oh like that..
<mlankhorst> alf_: ugh how could that be the case for dri buffers? o.O
<mlankhorst> oh right, mir backend is mapped to dri2
<mlankhorst> bah, I'll need to think about it some more.. grr:P
<RAOF> duflu: Hm, not deliberately? :)
<duflu> RAOF: Oh, one definite change seems to be that the intel DDX no longer accepts NullRegion (now crashes)
<RAOF> Yeah. We should never be passing in NullRegion, though.
<RAOF> Are we?
<mlankhorst> dun dun duuuun
<alf_> mlankhorst: that sounds ominous :)
<duflu> RAOF: No, but I may need to as a workaround. Unless I can figure out how to fix the intel code :P
<duflu> RAOF: Did you investigate https://bugs.freedesktop.org/show_bug.cgi?id=68969 ?
<ubot5> Freedesktop bug 68969 in Driver/intel "xf86-video-intel 2.99.901 + XMir + multimonitors = all displays black" [Normal,Resolved: notourbug]
<RAOF> duflu: I did have a look, but didn't get as far as reproducing.
<RAOF> duflu: I pulled the latest xmir patch from ickle's branch into the latest Ubuntu package, though, so it's some other change in the tree breaking it.
<alf_> RAOF: https://github.com/RAOF/mesa/pull/4
<RAOF> alf_: Hm. What frees dri2_surf in that case?
<alf_> RAOF: dri2_surf is just a cast of surf to dri2_egl_surface, they are the same thing
<RAOF> ...urgh. Quite true!
<mlankhorst> alf_: hm i have a fix for i965, i think
 * alf_ is excited...
<mlankhorst> http://paste.debian.net/37818/
<mlankhorst> no idea if it works though or if the fd is correct ;;p
<alf_> mlankhorst: thanks, will check
<duflu> RAOF: It *looks* like the intel DDX is tracking its own damage per-pixmap, and XMir's multi-monitor optimization of only submitting outputs/pixmaps when dirty is confusing it. Any ideas? I'm going round in circles
<alf_> mlankhorst: no luck, bug still occurs? Do you want me to get an strace?
<mlankhorst> definitely
<alf_> mlankhorst: btw, I tried another experiment: I also pass the GEM name with the incoming buffer (name provided by Mir), but use the fd to create the buffer, and setting the name in the region manually with flink (like the previous patches). I still get the bug, which indicates that the core problem may not be (only) in intel_process_dri2_buffer()
<mlankhorst> alf_: fun :p
<mlankhorst> alf_: oops, can you set singlesample_mt->region->handle = region->handle in intel_miptree_create_for_dri2_buffer ?
<alf_> mlankhorst: sure
<mlankhorst> it would appear I missed that part on importing bo's, so it was still 0 ;)
<alf_> mlankhorst: https://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment
<alf_> mlankhorst: (https://github.com/afrantzis/mesa.git branch egl-platform-mir-egl-image-i965-experiment)
<mlankhorst> alf_: do you close the original gbm bo afterwards?
<mlankhorst> or at any point
<alf_> mlankhorst: the BOs are closed only when the Mir surface is destroyed
<mlankhorst> what about the pixmap created with dri2_create_image_khr_pixmap
<mlankhorst> do you ever close that one?
<alf_> mlankhorst: also when the surfaces are destroyed (the bo and respective EGL images are created lazily when the compositor/clients needs them the first time).
<mlankhorst> ok but this definitely looks wrong here..
<mlankhorst> +   dri2_img->dri_image =
<mlankhorst> +      dri2_dpy->image->createImageFromName(dri2_dpy->dri_screen,
<mlankhorst> +                                           width,
<mlankhorst> +                                           height,
<mlankhorst> +                                           format,
<mlankhorst> +                                           flink_arg.name,
<mlankhorst> +                                           stride / 4,
<mlankhorst> +                                           NULL);
<alf_> mlankhorst: ok, what is wrong with it?
<mlankhorst> you can't use FLINK internally
<mlankhorst> you'd need to use the dupimage call, assuming it works
<alf_> mlankhorst: it doesn't...
<mlankhorst> what happens when you try?
<alf_> mlankhorst: the call succeeds but I still get errors further down when rendering, even when using GEM names
<alf_> mlankhorst: let me paste...
<mlankhorst> alf_: yes probably, but it's more correct than flinking
<alf_> mlankhorst: here is the strace output with USE_DUP 1 , http://paste.ubuntu.com/6087181/
<mlankhorst> still more correct
<alf_> mlankhorst: btw, why can't I FLINK? Note that this is still happening at the EGL platform level, outside any driver specific context.
<mlankhorst> alf_: because there is no refcounting in drm
<mlankhorst> if you close 1 handle, everything is invalid. userspace has to explicitly keep track themselves
<alf_> mlankhorst: I am only getting the global name, I am not opening/closing anything
<mlankhorst> alf_: you are creating a new representation of the bo through createImage.
<mlankhorst> alf_: but regardless in this case the problem didn't change.. can you add extra traces to libdrm/intel to the GEM_CLOSE calls?
<alf_> mlankhorst: I guess that is drm_intel_gem_bo_free(), sure
<mlankhorst> with indication of which handle closed, I'm not good enough to understand that part from the ioctl numbers yet :P
<alf_> mlankhorst: http://paste.ubuntu.com/6087259/, with USE_DUP = 1
<duflu> I give up
<mlankhorst> alf_: what do close messages look like?
<alf_> mlankhorst: "drm_intel_gem_bo_free: ..."
<mlankhorst> alf_: because I see some handles that are being re-created after close
<mlankhorst> however due to flushing they may not be killed right away after destroying
<mlankhorst> alf_: I think mir needs to be smarter, and cache the fd's. check if it's seen them before or not and if so re-use them..
<mlankhorst> or better yet
<mlankhorst> allocate them on the client side and give them to mir for use
<alf_> mlankhorst: so instead of sending the Prime FD every time, send it once and then send an another id back and forth?
<mlankhorst> alf_: no, keep the fd cached on the client side, don't close it
<alf_> mlankhorst: hmm, I think we are already doing this in the client
<alan_g> alf_: I may have missed the context, but we have two client processes in the chain - nested-mir and the application. Both get passed the fd
<RAOF> Yeah, we cache fds.
<alf_> alan_g: This is about buffer fds used by the final application. (As you know) nested-mir creates the surface/buffers itself.
<alan_g> alf_: Ok then. Sorry for the noise
<kgunn> RAOF: you and ricmm all ok ?
<kgunn> :)
<alan_g> alf_: Are you OK with the updated https://code.launchpad.net/~alan-griffiths/mir/spike-nested-input/+merge/184351?
<alf_> alan_g: approved
<alan_g> alf_: thanks
<mlankhorst> alf_: anyway the final application is messing up here, nothing the nested mir could do would cause -ENOENT here unless they share the drm fd.. :P
<alf_> mlankhorst: the final application gets the drm fd so it can use it with mesa
<alf_> mlankhorst: and handles everything through it (and libmirclient)
<alf_> mlankhorst: through it == mesa
<mlankhorst> alf_: yes, but is the same fd shared between mesa and nested mir?
<alf_> mlankhorst: yes (of course not with the same fd number, but the same underlying file)
<alf_> mlankhorst: host mir, nested mir and clients/mesa use dup()-ed fds that point to the same drm file instance
<kgunn> didrocks: ping
<didrocks> kgunn: pong
<kgunn> didrocks: hey...been a while, hope time off was good
<kgunn> didrocks: just wanting to know...are you ok with resolution here
<kgunn> https://bugs.launchpad.net/xmir/+bug/1221209
<ubot5> Launchpad bug 1221209 in unity-system-compositor (Ubuntu) "need to establish upgrade action when xmir becomes default" [Undecided,New]
<didrocks> kgunn: was excellent, thanks! In a sprint in Boston this week (so investigating some part of holidays to travel ;))
 * didrocks looks
<kgunn> didrocks: basically...robert recommending reboot on xmir distro roll out
<didrocks> kgunn: yeah, it sounds good (and the right way to implement it)
<kgunn> didrocks: cool...just wanted to make sure we're ok (before the 11th hour gets here :)
<didrocks> kgunn: but I think people won't reboot every 4 hours for now (as we release every 4 hours)
<didrocks> kgunn: so, it comes back to the discussion about ABI stability, is it coming so that we can remove the "hack" for forcing rebuilds in both u-s-c and unity-mir?
<didrocks> seems I was disconnectedâ¦
<didrocks> 10:33:11      didrocks | kgunn: yeah, it sounds good (and the right way to implement it)
<didrocks> 10:33:29      didrocks | kgunn: but I think people won't reboot every 4 hours for now (as we release every 4 hours)
<didrocks> 10:33:54      didrocks | kgunn: so, it comes back to the discussion about ABI stability, is it coming so that we can remove the "hack" for forcing
<didrocks>                        | rebuilds in both u-s-c and unity-mir?
<didrocks> kgunn: ^
<kgunn> didrocks: do you recall if there is a bug for that hack ? if not...i'll log one...and tag it for "make-xmir-default"
<kgunn> https://bugs.launchpad.net/xmir/+bugs?field.tag=make-xmir-default
<didrocks> kgunn: indeed, let me log it as a bug, one sec
<kgunn> didrocks: oh..thanks...yeah, i think its a seperate issue from the reboot discussion
<didrocks> kgunn: it's linked as because of this, it means that potentially, we force every 4 hours people to reboot
<didrocks> as we rebuild u-s-c as soon as there is a commit in Mir
<kgunn> didrocks: true...i see the link...just saying, it deserves its own bug
<didrocks> kgunn: https://bugs.launchpad.net/xmir/+bug/1223393
<ubot5> Launchpad bug 1223393 in XMir "ABI stability of libmirserver" [Undecided,New]
<didrocks> let me add the tag
<didrocks> kgunn: TBH, I think ABI stability needs to happen in the incoming 2 weeks
<didrocks> seeing how far we are, we need to try to stabilize now
<kgunn> didrocks: no doubt
<hikiko> bye
<mlankhorst> alf_: ARRRRRRRGHHHHHH
<mlankhorst> ARGHH
<mlankhorst> bad alf_
<mlankhorst> bad!
<alf_> mlankhorst: ?
<mlankhorst> alf_: if any client closes the bo, they will be closed for all clients..
<mlankhorst> you can't dup the drm fd for that reason
<alf_> mlankhorst: but open()-ing a new drm_fd works?
<mlankhorst> yes
<alf_> mlankhorst: and possibly sending it over a unix socket?
<mlankhorst> it will, but the dup is why it fails
<mlankhorst> if the nested mir closes their bo it was closed on the other one too :P
<mlankhorst> causing the -ENOENT out of nowhere
<alf_> mlankhorst: ok, I will try to de-dup() and see if that helps. Note, though, that I don't think we are explicitly closing anything during rendering...
<mlankhorst> maybe, but it will at least nail the issue down to the process causing it
<alf_> mlankhorst: ah, sorry for the false alarm, we actually fixed that long ago... we drmOpen() a new fd and send it to clients :/
<alf_> mlankhorst: but hmm...
<alf_> mlankhorst: I actually see a dup() in NestedMir... I will get rid of this and check what is going on
<alf_> mlankhorst: removed stray dup() in nested mir, no change :/
<alan_g> kgunn: nested input works on android drivers. (still needs more test coverage, but sort of there) - https://code.launchpad.net/~alan-griffiths/mir/missing-links-to-wire-up-input/+merge/184824
<kdub> alan_g, yay
<alan_g> kdub: let's forget about this mesa stack. ;)
<kgunn> alan_g: wow!...i guess input was easier than render
<kgunn> awesome!
<alan_g> kgunn: all the input problems were in code we "own"
<kdub> alan_g, we could table it! http://translate.google.com/#es/en/mesa
<alan_g> kdub: sadly, in the UK "table it" means something different.
<kdub> need to find an idiom translator now...
<alan_g> http://en.wikipedia.org/wiki/Table_(parliamentary_procedure)
<alan_g> Anyway, a good point for...
<kgunn> kdub: so technically mterry could take your android updates+ alan_g|EOD 's input and try to integrate greeter against it
<kdub> kgunn, sure, it would be easier if its the ubuntu touch shell/greeter (qml apps?) as opposed to lightdm and xmir though
<racarr> I think I've come up with a way to rebuild message processor + socket session + session mediator
<racarr> that will fix this DPMS IPC issue but it's kind of invasive
<racarr> wondering if I should run with it, or refocus on perhaps doing DPMS for XMir via some out of channel API for the time being
<kdub> racarr, whats the plan?
<racarr> kdub: So the essentialy difficulty is now, that the message reading loop runs like
<racarr> Step -1: Begin read in constructor
<racarr> Step 0: Respond to asynbc read
<racarr> Step 1: Allow the message processor and session mediator to fully handle the message (i.e. then say block on Surface::advance_buffer
<tvoss_> racarr, why is that? I thought we tried to avoid blocking event loops and be as parallel as possible?
<racarr> STep 2: Schedule the next asynchronous read.
<racarr> tvoss_: No, the way it's architected now we can't read a second message from a client until a first is fully processed
<tvoss_> racarr, ?
<racarr> tvoss_: Because things are written as in Steps 0-2 there, we don't
<racarr> read a second message until we have finished processing the first one completely
<racarr> which we use to keep messages in order
<racarr> the problem is not all messages are in the same "channel"
<kdub> racarr, can't we have a special case on the client side though... "if you are the client that turned off the screen, you'll get an error if you try to swapbuffers before you turn the screen on"
<kdub> (or did we already consider that?)
<racarr> and the particular problem is, say you use DPMS to turn off the screen, then call advance buffer
<tvoss_> racarr, which would be fine, too, if the message handling just handles stuff like dpms asynchronously
<racarr> and you are
<racarr> perpetually blocked on advance buffer
<racarr> so you can never turn
<racarr> the screen back on
<racarr> kdub: It could always be racy I think (because other people can turn on/off the screen...but it's a possibility)
<kdub> racarr, even the server could turn on the screen, but then it would just be an event sent to clients
<tvoss_> kdub, I would rather want to avoid such a hacky appraoch
<racarr> kdub: The plan I was developing, was instead to read messages as fast as possible, then the SessionMediator uses a thread pool
<racarr> to perform the actual operations and returns futures or whatever to the message processor
<racarr> the SessionMediator can use, multiple locks
<racarr> to enforce the different channels
<racarr> i.e. there is a
<racarr> SessionMediator::display_configuration_lock
<racarr> and SessionMediator::surface_channel_lock
<racarr> so, you can't execute resize_surface while swap is still executing
<racarr> but you can reconfigure the display, or say receive a display reconfiguration event
<racarr> you know messages within a "sequence" i.e. alll protected by the surface channel lock
<racarr> will all be in order, because you don't read the next message
<racarr> until you have actually received the std::future from the SessionMediator
<racarr> at which point you know the lock from that channel is held
<racarr> I am pretty sure it works, but am nervous about doing it because it changes the entire server side threading model basically
<racarr> and who knows what that does
<racarr> I mean I guess hypothetically I should
<kdub> racarr, yeah, thats why i keep thinking
<racarr> but I don't seem to be confident about that :p
<kdub> 'there's got to be some smarts we could put into the client side'
<racarr> I think it's always a race on the client.
<racarr> also this may show up other places
<racarr> i.e. two surface clients
<racarr> if you have to wait until the server responds that you have swapped one buffer before you can begin swapping the next
<kdub> its a big change, because client requests go from in-order to out of order
<kdub> or rather two (or more channels) and we have to do the sync logic in the server at some point
<racarr> kdub: No, that's the thing with still not reading the next message until the SessionMediator takes some lock for you
<racarr> it's just there become seperate channels, i.e. display-configuration, and surface
<kdub> racarr, well, thats the sync i was talking about :) taking the lock
<racarr> but messages in the surface channel will still be processed in the order they are sent
<racarr> ah yeah
<racarr> yeah
<racarr> and it's not super trivial with all the thread pools and such
<kdub> with swapbuffers, we currently say 'this might block!'
<kdub> we could just say like, 'after calling 'block server/turn screen off' the only thing you can do is some subset of the server functionality'
<racarr> I think we understand that to mean though, that mir_client_swap_buffers_sync might not return immediately
<racarr> not that you can't call any mir_client_ functions
<racarr> Mm. I guess we could say that, espescially perhaps to XMir
<racarr> but it seems really difficult if you are writing a multithreaded client
<kdub> well, the renderthread just knows the swap could wait an arbitrarily long time
<kdub> it doesn't have to know why
<racarr> and I worry we will end up with bugs that literally mean the screen turns off and can't come back on :p
<racarr> ?
<racarr> if xmir accidentally swaps after turning off DPMS
<racarr> the swap thread will wait infinitely
<kdub> racarr, if it has two threads
<kdub> a render thread, and display management thread, its not a problem
<racarr> You mean, it's not a problem as long as the client
<racarr> never calls swap_buffers after turning off the display?
<racarr> I am just not sure it's a good idea to put that requirement on the client when the failure case is
<racarr> restart the entire session
<kdub> right, as long as the client remembers the well-known "swapbuffers can wait a really long time sometimes"
<racarr> ? How does that help you?
<racarr> It will wait forever
<racarr> there's no way for the system to recover
<racarr> even if the client uses
<racarr> async swap buffers
<racarr> and the client itself isn't blocking
<racarr> it can still never turn the display back on.
<kdub> ah, the 'server thread is blocked' problem
<racarr> Yes :(
<kdub> still coming back into the problem :)
<racarr> haha no worries, it's confusing, I didn't realized this is what was happening on GBM
<racarr> ...for a long time haha
<kdub> well, if the client sends 'display off', then 'swapbuffers'
<kdub> we know when we receive the swapbuffers command
<kdub> that we cannot guarantee that we will ever be able to service the command
<kdub> so perhaps an error?
<racarr> kdub: I've been thinking about an error yeah
<racarr> the thing is how does the client know when to call swap buffers again
<racarr> the client then has to like
<racarr> call swap buffers, if error, see if the error was because the display was off
<kdub> when it turns the screen back on, or sees that the screen has been turned back on
<racarr> if so, update some flag so we watch the display configuration for the display to come back on to start our render loop
<racarr> the thing is there will be apps and stuff too who will try and swap buffers while the screen is off, not just the client who has to turn the screen back on
<racarr> so it has to be a reasonable behavior for them too
<kdub> well, those can block
<kdub> normally
<racarr> unless we throw an error :p
<racarr> in which case they have to decide what to do with it, which can't just be call swap_buffers again because they need to be sleeping while
<racarr> the screen is off
<kdub> just the client that is turning the screen on and off is the problem one that we have to give an error to
<kdub> so i think that approach would work, but there's also the reworking of the session mediator
<racarr> hmm yeah maybe just errors to the one client...
<kdub> because, although i sorta like it the way it is :) if we have a new scenario we might have to improve it to fit the new scenario
<racarr> I think it could be improved in general some
<kdub> like... on new message, make a std::async to service the request
<racarr> I think you should be able to process messages from the same client
<racarr> about different surfaces
<racarr> concurrently
<racarr> (as an example of a general improvement which has kind of similar requirements to this)
<kdub> racarr, right
<kdub> there's a few other ones i'm sure where that would be beneficial
<kdub> racarr, i'm starting to lean more towards improving the server so that a new message is handled in a future
<racarr> kdub: Yes I think it should work...I'm worried it might be too big to finish this week though
<racarr> lots of test redoing, etc.
<racarr> I just had an interesting idea for a "solution"
<racarr> if you swap buffers while you turned off the display
<racarr> you turn it back on XD
<kdub> racarr, it is a fair amount of test reworking and restructuring
<racarr> and then xmir tries to do the right thing
<racarr> but if it ever fails its not catastrophic
<racarr> i.e. the session mediator implicitly turns it on for you
<kdub> racarr, not a bad solution :)
<racarr> kdub: Mm.
<racarr> Ok thanks for talking through it with me :D I'm going to work on other stuff for a few hours
<racarr> and then revisit and choose an approach
<racarr> maybe wait to sync with Alan in the morning, I bet he has an opinion :D
<kdub> racarr, no problem... if you want, we could call a hangout on it for tomorrow morning
<racarr> kdub: Mm good idea, ill make sure to be up early enough and we can just do it after the standup
<mlankhorst> alf_: meh new strace then :P
<mlankhorst> with the dup removed still
<kgunn> mornin robert_ancell
<robert_ancell> kgunn, hello
<kgunn> robert_ancell: curious, any joy on fixin the sec bug/vt input shotgun style
<robert_ancell> kgunn, we had a disagreement with ricmm/tvoss over using the app lifecycle api, so we need to do some more convincing there
<kgunn> robert_ancell: we're supposed to be  default on the 19th....i fear we're running out of runway
<robert_ancell> kgunn, very much so
<robert_ancell> kgunn, I think we're just going to have to make the API change - it shouldn't affect the shell team
<robert_ancell> didrocks, still around?
<didrocks> robert_ancell: yeah, I'm in Boston right now in a sprint
<robert_ancell> didrocks, oh, cool. All the autolanding is off for mir right? How do we push through releases now?
<didrocks> robert_ancell: we just workarounded a dns issue that we are having for the last 3 days
<didrocks> (an infra issue)
<didrocks> when I say just, it's really *just*
<robert_ancell> didrocks, oh, they weren't intentionally blocked?
<didrocks> so at least, we'll have build for dailies
<didrocks> 2 issues :)
<didrocks> 1. intentionally block
<didrocks> 2. dns issues making things even not building for the past 3 days
<didrocks> count 2 as fixed
<didrocks> for 1, we need to ensure the current image is fine
<didrocks> and then doing the unity8+mir transition
<didrocks> is what is in mir trunk for that goal?
<didrocks> (the thing you do want to release?)
<didrocks> sorry, but on holidays and then, just back on this sprint, so quite lost on all the things that happened :)
<didrocks> robert_ancell: still around?
<robert_ancell> didrocks, yep
<didrocks> does my question make sense?
<robert_ancell> didrocks, mir trunk should still be going into saucy, otherwise we wont get any critical fixes or features for the phone
<robert_ancell> brb, need to restart modem
<robert_ancell_> blew our 100G cap, just upgraded to 200G. The 64k throttled speed is so unusable...
<didrocks> robert_ancell_: ok, let's try to get mir, u-s-c, unity-mir and qtubuntu rebuilt for making the transition
<robert_ancell_> didrocks, the mirclient3 transition?
<robotfuel> robert_ancell_: https://bugs.launchpad.net/bugs/1218381 is happening on saucy, with additional black vertical lines (there is a bug for the black lines)
<ubot5> Launchpad bug 1218381 in XMir "saucy has horizontal distortion on ati" [High,Incomplete]
<robert_ancell> robotfuel, ta
<didrocks> robert_ancell: urgh, transition?
<didrocks> robert_ancell: no transition right now please
<didrocks> asac tries to get unity-mir on
<asac> :)
<asac> yay!!
<asac> we all try to get it in
<asac> not me :)
<RAOF> Transition all the things!
<kgunn> ok
<RAOF> robert_ancell: Incidentally, http://bazaar.launchpad.net/~raof/platform-api/update-for-lifecycle-cookie/revision/149 is the platform-api update for our proposed change.
<robert_ancell> RAOF, yes, saw that
<robert_ancell> RAOF, any luck convincing ricmm?
<RAOF> Not really.
<robert_ancell> RAOF, ricmm, I was also thinking, if the correct behaviour when switching sessions is that the hidden session should suspend its apps the only way this can occur is if the system compositor can notify the shell. So it makes sense in the Unity 8 case as well as the XMir case
<robert_ancell> RAOF, we should code it up without the cookie for now. That's at least an improvement on the current case. It will have the input overlap issue potentially
<RAOF> Yeah. I'll just push the branch so you can test.
#ubuntu-mir 2013-09-11
<RAOF> robert_ancell: If you'd like to test, the ubuntu branch of github.com/RAOF/xserver.git should work for you.
<robert_ancell> RAOF, awesome, thanks
<robert_ancell> that has packaging right?
<RAOF> Yup.
<RAOF> It's a simple "DEB_BUILD_OPTIONS=parallel=9" debuild -i -I -us -uc away!
<RAOF> tvoss_: Around?
<kgunn> RAOF: you know he's in asia right?
<RAOF> kgunn: Yes, which is why he might be around :)
<tvoss_> RAOF, yup
 * robert_ancell ->lunch
<RAOF> tvoss_: So, I'd like to raise https://code.launchpad.net/~raof/mir/prebump-abi-for-lifecycle-cookie/+merge/184703 and the associated platform-api change http://bazaar.launchpad.net/~raof/platform-api/update-for-lifecycle-cookie/revision/149 again :)
<RAOF> duflu: Good morning!
<duflu> RAOF: Morning; goodish
<robotfuel> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1218815 this bug needs triage.
<ubot5> Launchpad bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Triaged]
<duflu> robotfuel: It is triaged already. What are you aiming for? :)
<robotfuel> having it assigned to someone.
<robotfuel> duflu:
<robotfuel> ^
<duflu> robotfuel: Ah, yes. I think RAOF thinks he knows the answer. Although a proper fix might require enhancements to Mir first
<RAOF> Yeah, throw it here.
<robotfuel> duflu: if it was medium or high I could see it not being assigned while there are critical bugs. but all critical bugs should have someone assigned to it, even if it's just the project lead. :)
<duflu> robotfuel: I disagree. Too often bugs are assigned to people who have other things on their plate. The bug never gets started or taken up by anyone else because it looks like it belongs to someone already
<duflu> RAOF: Are you _sure_ you need a scanout flag for that?
<RAOF> duflu: To do it correctly, yes.
<RAOF> duflu: That flag doesn't need to be a *guarantee* that it'll be scanned out, but it does need to indicate that this buffer needs to be treated as if it could be scanned out.
<RAOF> We really need the same for intel, it's just that intel can make a reasonable guess as to whether it might be scanned out or not. Radeon can't.
<duflu> RAOF: Yeah. So why/how is the stride info we have wrong? Why wouldn't we just fix that?
<RAOF> Because it's not stride.
<duflu> Umm, pitch
<duflu> ?
<RAOF> It's not pitch, either. It's bound up with how the tiling is arranged.
<duflu> Ugh
<RAOF> Right
<duflu> Damn DDXs
<robotfuel> duflu: that's what the in progress flag is for in status, if your team wants to do differently then I am okay with that.
<RAOF> Radeon *is* a bit of a fan of crazily duplicating code and hoping that everyone's using the same stuff.
<RAOF> But, as we found, it's the same for Intel - scanout needs to be handled a bit specially.
<duflu> RAOF: When I started (and finished) bypass support, I had no idea the DDXen would play with the hardware this much :P
<duflu> I thought I knew what a "client" was. But that's not true for XMir
<RAOF> I suspect we'll need to do similar things in the Mir EGL platform; we might just not have hit the problems yet.
<duflu> Less likely. I actually tested it all with EGL on intel + radeon + nouveau
 * RAOF could really do with a working second monitor
<duflu> Admittedly, I have never needed two. Just happened to buy one for the old office, and brought it home when I left
<RAOF> Urgh, wow. This is messed up on radeon.
<RAOF> But, of course, I can't reproduce the graphical glitches.
<RAOF> Because that would make things too easy.
<RAOF> duflu: The environment variable to disable bypass was MIR_BYPASS=0, right?
<duflu> RAOF: Yes. Just need to make sure the variable makes it though to the USC process :)
<duflu> *through
<RAOF> Ok, so radeon exhibits damage problems in multihead.
<RAOF> And also exhibits that "you need to VT switch to get Mir to send new buffers with bypass" problem that we had earlier.
<duflu> RAOF: I noticed bypass did make bug 1211700 worse. But the bug itself existed before bypass
<ubot5> bug 1211700 in Mir "[radeon] [nouveau] Unthrottled EGL clients cause Mir to slow, sometimes to a halt" [High,New] https://launchpad.net/bugs/1211700
<RAOF> That wouldn't be exposed by XMir; XMir *is* throttled.
<RAOF> Well, ish.
<RAOF> Although XMir is kinda unthrottled, that bug would not be what's affecting XMir, because XMir is idle, waiting in select() when you gdb into it.
<duflu> RAOF: I had some ideas on how to relieve the problem a while back. And I have nouveau hardware that reproduces it easily. Just wasn't a priority compared to the other issues
<RAOF> Yeah.
<RAOF> Although, to some extent, it's a combination of correct behaviour and insufficient kernel smarts.
<duflu> Yeah Maarten started talking about GPU threads and scheduling on the GPU. It's a whole new world
<RAOF> Basically what we want is a deadline scheduler for the GPU.
<duflu> RAOF: Extending MirBufferPackage.... that shouldn't break any ABIs right?
<RAOF> Correct.
<RAOF> As far as I can tell.
<duflu> We get it by pointer
<duflu> which is good
<RAOF> Because we allocate them ourselves.
<duflu> Except that we return the pointer by parameter from a function with returns void. Which is weird
<RAOF> Yeah, because reasons.
<RAOF> Actually, why do we have that idiom?
<duflu> RAOF: I think it was a mistake which we overlooked at the time. Returning a pointer as the function result would have been slightly nicer
<smspillaz> duflu: RAOF: isn't MirBufferPackage allocated by the client?
<smspillaz> or am I thinking of something else
<RAOF> smspillaz: Not anymore
<RAOF> It was
<duflu> smspillaz: How? It's returned as "type **x"
<smspillaz> RAOF: does this mean I have to change all my code again ? :(
<duflu> smspillaz: It's not changing
<RAOF> smspillaz: A little bit, yes.
<smspillaz> RAOF: when did this change happen?
<RAOF> duflu: At one point it was a client-allocated MirBufferPackage * that got passed in.
<duflu> Oh
<duflu> Umm, then Sam's client code shouldn't build so long as warnings are errors... ?
<smspillaz>   MirBufferPackage *surface_buffer;
<smspillaz>   mir_surface_get_current_buffer (impl->surface, &surface_buffer);
<smspillaz> looks like I wrote the gtk+ stuff after that change :)
<RAOF> :)
<duflu> Cool
<RAOF> Yay kernel builtin edids!
<jrr> yay!
<robert_ancell> RAOF, I can confirm the input works switching between two sessions - just need to get it switched up to VT switching away from all sessions
<RAOF> robert_ancell: That just requires hooking up in unity-system-compositor, right?
<robert_ancell> RAOF, mostly exposing it from Mir
<RAOF> Right, as expected.
<RAOF> Oooh.
<RAOF> Interesting.
<RAOF> *that's* definitely racy...
<RAOF> Should be pretty difficult to hit, though?
<duflu> ??
<RAOF> duflu: Hey, we're always going to be triple buffering, right?
<duflu> RAOF: Nope. That's kind of a bug. We will and should switch to double when possible
<RAOF> At the *moment* we always triple buffer, yes?
<RAOF> I'm just doing a by-hand verification of my damage tracking logic.
<duflu> RAOF: Yes, kind of... If the client is slow enough then SwitchingBundle might only hand out 2
<duflu> RAOF: BTW, I removed all the damage and age tracking and that bug remained. It's not in the damage tracking AFAIK
<RAOF> duflu: Oh, we get the damage_for_current_buffer *after* we submit the previous buffer. So, in the unlikely event that X gets preempted and the swap completes before the next line we'll clear the damage from the wrong place.
<duflu> RAOF: Sounds similar to my first theory. I now forget why I stopped believing it
<RAOF> Because you removed all the damage tracking and the bug remained? :)
<duflu> RAOF: Maybe...
<duflu> RAOF: I mean I got rid of age tracking and set the dirty region to the whole xmir_win (or empty)
<duflu> Then the bug remains. But if you never allow dirty to be empty then the bug will be hidden
<RAOF> Right. Because you just continually render
<duflu> RAOF: Boo... Mesa requires MirBufferPackage never grows:
<duflu> mir_advance_colour_buffer(struct dri2_egl_surface *surf)
<duflu> {
<duflu>    MirBufferPackage buffer_package;
<duflu>    if(!surf->mir_surf->surface_advance_buffer(surf->mir_surf, &buffer_package))
<duflu> I can work around it I think
<RAOF> duflu: Oh. Yay for having two distinct APIs for exactly the same thing
<robert_ancell> duflu, racarr, kdub, alf_ hikiko - meeting
<robert_ancell> kgunn too
<kgunn> :)
<hikiko> it seems i am alone in the hangout :) rejoining
<robert_ancell> hikiko, we're there!
<hikiko> question: :)
<hikiko> is magic sysrq disabled on kernel?
<robert_ancell> hikiko, it works for me
<duflu> Good question. It never works for me. But I likely get it wrong
<robert_ancell> I use it frequently when the VTs break
<hikiko> robert_ancell, how did you enable it? in /proc/sysrq?
<robert_ancell> for me: hold down alt+PrintScr, then s-u-b
<robert_ancell> hikiko, I don't think I've done anything to enable it
<hikiko> yes, I know but it's a laptop here and sysrq doesnt work so I was wondering if I have to do something:/
<hikiko> oh no :D it worked now :D thanks robert_ancell
<robert_ancell> hikiko, np
<hikiko> I was trying with s u g/h :)
<robert_ancell> hikiko, you can check in dmesg if any SysReq events have occurred
<robert_ancell> bye all
<duflu_> Ha. Works now :)
<alf_> RAOF: what's the process for getting Mesa updates in the archive? Are they picked up automatically from your github branches?
<hikiko> \m/
<RAOF> alf_: No, I do that manually.
<mlankhorst> alf|xmir_devel: ping
<alf|xmir_devel> mlankhorst: pong
<mlankhorst> alf|xmir_devel: can you help me reproduce the issue? what branches etc do I need
<alf|xmir_devel> mlankhorst: follow the instructions from https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html
<alf|xmir_devel> mlankhorst: for mesa you can use the https://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment branch
<mlankhorst> ok
<alf|xmir_devel> mlankhorst: for mir use lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack as noted in the mail, I have updated it remove the stray dup()
<alf|xmir_devel> mlankhorst: the mesa branch contains the i965 changes which you may want to remove or change, and also in platform_mir.c don't forget to set USE_DUP and USE_PRIME to the values you want
<mlankhorst> alf|xmir_devel: oh using drm bus id is a bad idea, best to open dev directly, but unrelated to your issue :P
<mlankhorst> RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=60182 with fix it seems :p
<ubot5> Freedesktop bug 60182 in DRM/Radeon "X.Org Server terminate when I close video player" [Critical,New]
<mlankhorst> alf|xmir_devel: oh btw test seems to fail when I try building mir there..
<mlankhorst> The following tests FAILED:
<mlankhorst>          10 - acceptance-tests.TestNestedMir.* (Failed)
<mlankhorst>          55 - unit-tests.GBMGraphicBufferBasic.* (Failed)
<alf|xmir_devel> mlankhorst: yes, don't worry, it's because I have updated/hacked the code without updating the tests
<mlankhorst> ok
<alan_g> alf|xmir_devel: @"mlankhorst: I actually see a dup() in NestedMir... I will get rid of this and check what is going on" - the frontend code closes FDs after sending them to the client to avoid resource leaks.
<mlankhorst> alan_g: then why is that dup needed at all?
<alf|xmir_devel> alan_g: right, the point is that we should be opening a new drm fd instance, not duping the drm fd we use in the platform
<mlankhorst> pretty much
<alf|xmir_devel> alan_g: I have hacked a fix in lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack for testing purposes, but we need to find a better way to do it.
<alan_g> alf|xmir_devel: Shall I leave you to it? Or get involved?
<alf|xmir_devel> alan_g: If you can take a look at the latest commit in lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack, and come up with a better design for it, it would be great. Right now I am passing an auth_magic std::function to NativePlatform::initialize which is platform-specific in the sense that it is only needed on GBM.
<alf|xmir_devel> alan_g: (but it is not urgent, we first need to solve the egl image problem before any of this is usable on trunk)
<mlankhorst> ok I've merged the branch against 9.2 and built the packages :P
<alan_g> alf|xmir_devel: OK, I was going to look at tidying some of the "nested" code that has landed, and then look at the differences between what kdub landed on trunk for android and what we had on the gbm spike.
<alan_g> This fits into the latter category
<alf|xmir_devel> alan_g: sounds good
 * alan_g wonders: "Prisoner Of War"
<olli> compositor wars...
<mlankhorst> alf|power_outage: fwiw, nested mir works for me on nouveau, I'll try on intel..
<mlankhorst> ok crash, weeeee
<hikiko> question:
<hikiko> 131 [ 473.381] (==) Depth 24 pixmap format is 32 bpp
<hikiko> 132 [ 474.356] (==) FBDEV(0): Backing store disabled
<hikiko> 133 [ 474.358] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
<hikiko> I get this failsafe log
<hikiko> when xmir crashes
<hikiko> and i wonder if someone knows what it means (I find different explanations here and there) + I am trying to understand if this caused the crash or it is a result of the crash or irrelevant
<RAOF> hikiko: That'd just be the failsafe X log. That gets started if X crashes on startup for some reason.
<hikiko> so, it's totally irrelevant
<hikiko> isn't it?
<RAOF> Yeah.
<duflu> hikiko: fbdev is the fallback driver of last resort. It does not support Mir (yet) and means the real driver failed to start USC
<hikiko> cool :)
<RAOF> That'll only happen *after* you crash the original X :)
<duflu> So long as fbdev isn't crashing too
<hikiko> it isnt
<hikiko> and another question: sometimes I restart lightdm and instead of starting X with xmir it starts X
<hikiko> if I restart many times
<hikiko> and I have no clue why I dont get a crash at that point
<duflu> hikiko: In theory, X is meant to start in legacy mode *every time* Mir (unity-system-compositor) fails to start
<hikiko> if I just run restart lightdm too many times at somepoint X starts instead of X -mir
<hikiko> oh
<duflu> hikiko: We always (1) Try Mir and if that fails (2) Start legacy X
<duflu> If (2) fails then that's a new bug
<hikiko> but if 2 fails then
<hikiko> we start Mir or X?
<duflu> hikiko: If (2) fails then that's a new bug no one has logged yet. Sounds important :)
<hikiko> what happens is:
<hikiko> (in some cases)
<hikiko> I run restart lightdm many times and mir restarts ok with no crash
<hikiko> at some point I restart and X starts
<hikiko> (no crash)
<hikiko> and then if I restart lightdm
<hikiko> Mir will start and crash
<duflu> hikiko: If Mir crashes then look in /var/log/lightdm/unity-system-compositor.log for the cause. Hopefully it's a bug we already know about
<hikiko> ok :)
<hikiko> thanks duflu RAOF
<duflu> No problem
<mlankhorst> alf|power_outage: does the nested mir server only use a single drm fd?
<mlankhorst> screw it, I'm going to make the kernel tell me why ENOENT happens
<mlankhorst> [  105.467925] [drm] unknown target object for relocation 7
<mlankhorst>  2: 2 (batchbuffer)@0x000000e0 -> 7 (region)@0x00000000 + 0x00000000
<mlankhorst> odd
<mlankhorst> which is from intelAllocateBuffer
<alan_g> mlankhorst: the nested mir uses a drm fd for two things: to init gbm and to send to clients that init gbm. I got the second from the first using dup() because FD sent to clients get closed automatically), but IIUC alf|power_outage changed that...
<mlankhorst>  ====== Created gbm_bo 0x7f2e340026f0 0x7f2e340026f0 with image 0x7f2e34002740 handle: 7 screen: 0x72d390 ======
<mlankhorst> which no longer exists, it seems..
<mlankhorst> alan_g: yes, and each client needs their own instance of the drm fd
<mlankhorst> else really really bad things(TM) will happen
 * alan_g already knows he got it wrong
<mlankhorst> alan_g: the question is.. does non-nested mir share its own drm fd too?
<alan_g> mlankhorst: no, it uses drmOpen()
<mlankhorst> ok good.. still things are messing up somewhere :P
<alan_g> mlankhorst: if it helps the host mir uses int mggh::DRMHelper::get_authenticated_fd() to get the FD it passes out. (I've not yet looked at alf|power_outage nested code)
<mlankhorst> hm in this case it seem likely isolated to the nested server only now for sure
<alf|power_outage> alan_g: it's almost the same code, with the difference that we need to ask the host mir server to auth the magic cookie (since the nested mir is non DRM master)
<alf|power_outage> mlankhorst: ^^
 * duflu goes to create some culinary splendour
 * alan_g goes to make some tea
 * RAOF decides that his manual review of the XMir damage logic suggests that it's sound, and EODs.
<mlankhorst> alf_: my only conclusion is that nested mir and master mir share the drm fd..
<mlankhorst> and I'm damned sure that's the case
<mlankhorst> see http://paste.debian.net/38295/
<mlankhorst> Linux kernel complains relocation target 7 no longer exists..
<mlankhorst> oh no, in this case it was 6
<mlankhorst> hm damn wtf is going on :P
<alf_> mlankhorst: that is what I have been wondering for a few days now :)
<mlankhorst> ok so intel does enable bo re-use..
<mlankhorst> meh lets kill that off first
<mlankhorst> oh i see
<mlankhorst> probably intel bug..
<mlankhorst>  ====== platform_mir: dri2 swap buffers: before flush ======
<mlankhorst>  0: 8 (prime)
<mlankhorst>  1: 9 (vb)
<mlankhorst>  2: 2 (batchbuffer)@0x00000010 -> 8 (prime)@0x00000000 + 0x00000000
<mlankhorst>  2: 2 (batchbuffer)@0x00000094 -> 8 (prime)@0x00000000 + 0x00000000
<mlankhorst>  2: 2 (batchbuffer)@0x000000e0 -> 6 (region)@0x00000000 + 0x00000000
<mlankhorst>  2: 2 (batchbuffer)@0x00000174 -> 9 (vb)@0x00000000 + 0x00000000
<mlankhorst> there is a relocation for 6, but that bo is not mentioned on the validation list
<mlankhorst> it's still a valid bo, afaict
<mlankhorst> so now to figure out why relocation is failing like that :P
<mlankhorst> alf_: ah, intel has an internal cache that gets re-used for flink..
<alan_g> alf_: what's the state of the art branch for nested/gbm?
<alan_g> lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack?
<alf_> alan_g: ~afrantzis/mir/spike-nested-gbm-egl-image-hack yes
<alan_g> alf_: OK to top-approve lp:~alan-griffiths/mir/cleanup-NativeAndroidPlatform?
<alf_> alan_g: I am OK, although I haven't tested it on an Android device, but it seems harmless.
<mlankhorst> alf|xmir-devel: definitely some memory corruption going on, no idea what exactly though
<mlankhorst> huh wtf
<alf|xmir-devel> mlankhorst: ?
<mlankhorst> alf|xmir-devel: hitting some very weird bug, it's probably in intel but I don't see why it's doing whatever it is it's doing..
<mlankhorst> oh finally some sense..
<mlankhorst> (gdb) print bo->bufmgr
<mlankhorst> $6 = (drm_intel_bufmgr *) 0x6580d0
<mlankhorst> (gdb) print bo->bufmgr
<mlankhorst> $5 = (drm_intel_bufmgr *) 0x636280
<mlankhorst> why are there 2 drm_intel_bufmgrs ?
<mlankhorst> seriously..
<mlankhorst> gbm can create a screen, egl probably creates a separate screen or something
<mlankhorst> #7  0x00007ffff3d821be in gbm_create_device (fd=16) at ../../../../src/gbm/main/gbm.c:156
<mlankhorst> #8  0x00007ffff61d3dea in eglInitialize (dpy=0x64e3b0, major=0x7fffffffe1f8, minor=0x7fffffffe1fc) at ../../../../../src/egl/main/eglapi.c:317
<mlankhorst> so eglInitialize and gbm_create_device
<alf|xmir-devel> mlankhorst: perhaps that's why dupImage doesn't work at all, and we need to create a new image for the Mir EGL screen (USE_DUP=0)?
<mlankhorst> alf|xmir-devel: no you really need to get rid of the separate copy
<mlankhorst> RAOF wrote the code, he may know how to do that..
<alf|xmir-devel> mlankhorst: which code?
<mlankhorst> the 'screen' comes from mir
<mlankhorst> but you're creating the gbm without any knowledge of it
<alf|xmir-devel> mlankhorst: I guess we could go the other way too, as I think platform_drm does... use the dri2 info from GBM to set up the EGL dri2.
<mlankhorst> that's the thing you should do
<mlankhorst> does that kill off the platform_mir by any chance? :P
<mlankhorst> probably not, but in any case mir probably needs to know about the gbm screen and use it
<alf|xmir-devel> mlankhorst: no, we have our own native display and window types
<mlankhorst> specifically
<mlankhorst>    if (!dri2_create_screen(disp))
<mlankhorst>       goto cleanup_dpy;
<mlankhorst> that line is wrong
<mlankhorst> please don't make such hard to debug problems in the future
<mlankhorst> :P
<mlankhorst> (and I checked git blame, so I know it was you)
<alf|xmir-devel> mlankhorst: I need to talk to RAOF tomorrow, to see how we can move ahead with this, since I think that it involves some significant changes in platform mir and the information we pass to platform mir from mir (right now it is just the drm fd)
<mlankhorst> sure
<mlankhorst> and you're welcome, please try to give me easier problems next time ;)
<alf|xmir-devel> mlankhorst: thank you :) I really appreciate your time and effort!
<mlankhorst> after that dupimage will work correctly and flink vs w/e doesn't matter
<mlankhorst> is there anything else using gbm? :P
<alf|xmir-devel> mlankhorst: the display subsystem is using gbm internally, but that's using platform_drm so no problems there
<alf|xmir-devel> mlankhorst: (in host mir)
<alan_g> alf|xmir-devel: it sounds like you understand the problem (if not the solution)?
<mlankhorst> well there were 2 problems, but seems so :p
<mlankhorst> other problem was sharing drm fd
<kgunn> mlankhorst: \o/
<sil2100> kgunn: hi!
<sil2100> kgunn: we have a critical bug in Mir related to intel (most probably) - could you guys take a look at that and check if it's indeed a Mir issue? Or maybe something wrong with the intel driver?
<sil2100> kgunn: https://bugs.launchpad.net/mir/+bug/1223889
<ubot5> Launchpad bug 1223889 in Mir "Mir crashing on Intel drivers - memory corruption in /usr/bin/X" [Critical,New]
 * kgunn looks
<sil2100> kgunn: if you need some more logs besides lightdm.log, x.log and unity-system-compositor.log then this is the last chance ;p Since I need to restart the container, as it's dead
<kgunn> sil2100: go ahead
<kgunn> sil2100: so this is effectively the ppa from daily-build ??
<kgunn> just curious how we potentially bisect
<kgunn> ....and ironically mlankhorst was working on intel mem corruption a moment ago....same thing ?
<sil2100> kgunn: yes, this is using the current daily-build PPA contents, at least for the mir parts
<mlankhorst> kgunn: only affected nesting
<mlankhorst> afaik xorg-server doesn't use gbm
<kgunn> mlankhorst: was worth a hope :)
<kgunn> alf|xmir-devel: ...i don't want wreck your train of thot, but could you take a closer look at https://bugs.launchpad.net/mir/+bug/1223889
<ubot5> Launchpad bug 1223889 in Mir "Mir crashing on Intel drivers - memory corruption in /usr/bin/X" [Critical,New]
<kgunn> since RAOF & duflu are sleeping
<kgunn> sil2100: i assume this means usc/mir/xmir are held up
<alf|xmir-devel> alan_g: mlankhorst: yes (more or less), but I am not clear of the details of the solution yet... it is complicated because we need to pass to the "client" version of EGL platform mir information that only a server has (e.g. gbm_device*)
<sil2100> kgunn: well, yes, and it's also a bit inconvinient as because it causes an X crash, it breaks our intel machine, so it blocks up the whole release queue - since the broken, X-less intel machine is hanged until timeout or until someone notices to abort manually...
<mlankhorst> alf|xmir-devel: not really.. server doesn't need egl platform mir. Only nested client does. :P
<sil2100> kgunn: so essentially this problem breaks and slightly blocks all other packages, because it's breaking our test architecture
<kgunn> sil2100: is there a simple way to roll back the ppa to be based on the "previous" version of u-s-c/mir/xserver-xorg-video-intel  that was working for you
<alf|xmir-devel> mlankhorst: that's what I mean, a client (nested mir) needs to pass information to Mesa that is server related (gbm_device*)
<alf|xmir-devel> mlankhorst: remember we are doing server buffer allocation
<sil2100> kgunn: sadly not really... we would have to know what revision caused the failure, revert, rebuilt etc. - worse if the intel upload causes the problems
<sil2100> kgunn, didrocks: if you don't mind, I'll skip mirslave release this tick
<sil2100> kgunn, didrocks: we know it's broken and at least it won't break all other stacks :) We can run it later
<kgunn> sil2100: so you're saying that standalone X intel is fine with this xserver-xorg-video-intel...right ?
<sil2100> kgunn: yes, it's only happening when mir is used apparently
<sil2100> Would have to see locally on my machine if the crash is happening, but there's so many things pending...
<kgunn> sil2100: just for bisecting...we know that yesterday, had no problems....and this morning...we have problems right ?
<kgunn> meaning...we must have pushed something in xmir/mir/xserver-xorg-video-intel w/in last 24 hours that caused this
<sil2100> kgunn: let me check that, since we had some 'other' problems yesterday, but I'll check - from what I know it only happened today
<kgunn> sil2100: that would be really helpful to know....when the last good combo was
<sil2100> kgunn: bad news is... we didn't have a successful run yesterday as well, but not because of an X crash
<sil2100> kgunn: we DNS-resolve problems, so no release happened
<kgunn> ok but maybe last friday was ok?
<kgunn> sil2100: ^
<sil2100> kgunn: the last successful run was on the 6th, then the infra errors started happening
<sil2100> kgunn: yes, it seems we didn't have a successful run since libmirclient3 was introduced ;p
<sil2100> I mean, just today seems to be the first time the tests are actually ran
<kgunn> sil2100: hmmm....could be
<kgunn> but the build order took care of that sort of thing i thot
<mlankhorst> kgunn: please just valgrind ;P
<mlankhorst> it's there for a reason! :D
<mlankhorst> make /etc/X11/X2 with these contents: #!/bin/bash
<mlankhorst> exec /usr/bin/valgrind --show-reachable=yes --track-fds=yes --leak-check=full --error-limit=no --freelist-vol=500000000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -core -verbose 10 &>>/var/log/valgrind.log
<mlankhorst> and install xserver.*dbg
<mlankhorst> symlink /etc/X11/X to it, /etc/X11/X must stay a symlink :p
<alf|xmir-devel> kgunn: I will try to reproduce/investigate a bit later
<kgunn> alf|xmir-devel: i assume you understand 'how to' what mlankhorst just said :)
<racarr> Morning!
<kgunn> mornin'
<tvoss> hey guys :)
<didrocks> sil2100: ack
<racarr> hey tvoss :)
<tvoss> racarr, o/
<racarr> tvoss: Will you be in Lexington?
<tvoss> racarr, nope, unfortunately not :/
<racarr> Aww
<ricmm> racarr: ping
<ricmm> racarr: how are we doing with the DPMS-android stuff
<ricmm> is there an API in place in Mir yet or not? if not, I'll need some of your aid to reach the hwcomposer hal directly from powerd
<ricmm> :)
<tvoss> ricmm, kdub might be able to help, too
<ricmm> right just wondering as we had this discussion last week and there was a quick testing that was gonna happen
<ricmm> so, if it hasnt happened then I'll make the call of doing direct powerd->hal access for the screen control
<ricmm> until theres a problem the_shell_display_power_controller() or whatever under android, heh
<ricmm> an interface, not a problem, sorry
<racarr> ricmm: Pong!
<racarr> ricmm: There is an API in place
<ricmm> racarr: awesome
<ricmm> which one is it? got a landing rev? sorry
<racarr> ricmm: Part of the display configuration API
<racarr> no worries! lemme find it
<racarr> also standup? No one else is there
<ricmm> darn that one is complicated
<hikiko> i am racarr
<hikiko> but i see nobody else :p
<hikiko> let me relogin again
<ricmm> 1054
<hikiko> racarr, still alone :)
<alan_g> I see no-one too
<kgunn> i see alan
<alan_g> I see kgunn
<racarr> ricmm: 1054
<racarr> ricmm: The impl isn't landed due to a series of issues with doing it over IPC
<hikiko> racarr, we are all at the same hangout!
<racarr> s/landed/proposed
<racarr> hikiko: Can you give me the link?
<ricmm> yea thats what im just seeing
<racarr> CAlendar link isn't working for me
<ricmm> if theres no impl then I cannot use it
<ricmm> racarr: can you point me to the HAL interface you were planning to use?
<racarr> ricmm: hwcomposer.h blank/unblank
<racarr> ricmm: It all works actually for android, I can propose the android impl asap
<ricmm> gbm is the one thats broken?
<ricmm> well to be fair I might do the direct powerd access as theres no short-term plan for the shell policy enacter
<ricmm> so it will still have to be powerd
<ricmm> simpler to do powerd -> hal instead of powerd -> dbus -> shell -> hal
<racarr> Mir has to know to stop rendering, etc though, and dieally wouldn't report this as errors
<racarr> actually I can sort of make
<racarr> GBM work the problem is it's over
<racarr> well let me explain in just a few minutes
<racarr> standup :)
<ricmm> ok
<kgunn> alf|xmir-devel: i was just wondering aloud to robert if this https://code.launchpad.net/~robertcarr/mir/dpms-support-api/+merge/181884 might have been the issue
<kgunn> but....the build stacks should'be taken care of it
<kgunn> new api, but no new impl....should'be just rebuilt
<kgunn> alan_g: assume you had a problem....can you rejoin hangout?
<kgunn> alan_g: racarr wanted to chat about ipc wrt dpms
<alan_g> kgunn: no - just no interest in the followup conversation
<ricmm> racarr: ping, got a minute now then?
<ricmm> kgunn: does that mean that the discussion didnt happen? :)
<kgunn> ricmm: we're discussing mir ipc wrt dpms atm on a hangout
<ricmm> awesome
<didrocks> kgunn: hey! yesterday I asked to not migrate the libmirclient ABI
<didrocks> as asac and I are trying to get the unity8 on Mir
<didrocks> and once again, the transition was doneâ¦
<didrocks> it's the 3rd time that happens from the Mir team that we ask to not do risky things and this happen
<kgunn> didrocks: who did you ask?
<didrocks> now all dailies are busted
<didrocks> can check the logs
<ricmm> didrocks: it was bumped?
<didrocks> kgunn: the last 2 times, you were in the loop IIRC
<didrocks> ricmm: to libmirclient3
<ricmm> darn
<didrocks> let me check for that one
<didrocks> kgunn: robert_ancell
<didrocks> 2013-09-10 17:33:56     robert_ancell_  didrocks, the mirclient3 transition?
<didrocks> 2013-09-10 17:45:52     didrocks        robert_ancell: urgh, transition?
<didrocks> 2013-09-10 17:45:58     didrocks        robert_ancell: no transition right now please
<didrocks> 2013-09-10 17:46:09     didrocks        asac tries to get unity-mir on
<kgunn> didrocks: ok
<ricmm> didrocks: unity-mir doesnt depend on libmirclient3, only qtubuntu/platform-api -> apps
<didrocks> it's the 3 times on 3 when we ask the Mir team to be cautious and it seems we are unheard
<ricmm> err, mirclient in general
<didrocks> I'm *really* unimpressed
<ricmm> didrocks: what room are you in?
<kgunn> didrocks: ....cause we did screw up on libmirclient2...no mir-devel mail (someone screamed)...
<kgunn> didrocks: then...we did diligence https://lists.ubuntu.com/archives/mir-devel/2013-September/000373.html
<didrocks> ricmm: right, but the drivers are depending on it
<kgunn> didrocks: but no one replied on mir-devel
<didrocks> kgunn: you know, we deliver in ubuntu
<didrocks> kgunn: ubuntu-devel would be the first step
<didrocks> and checking with the integration team would have been great
<didrocks> and when the integration team tells "please no", listening to them would be good
<kgunn> didrocks: i thot agreement was mir-devel
<didrocks> kgunn: I'm not on that last
<didrocks> kgunn: I can't be on all upstream ML
<didrocks> list*
<kgunn> didrocks: yes...chatting with robert A on irc...i would've thot would take care
<kgunn> didrocks: ok...so now, ubuntu-dev....if we mail out a warning on that...that is where you want to see it ?....is there another mail for "integration team"
<kgunn> ?
<didrocks> kgunn: it's the main ubuntu ML
<didrocks> so everyone is supposed to read it
<kgunn> didrocks: ok, just trying to make sure...when libmirclient4 happens we dont f up again....so ubuntu-dev...right?
<didrocks> kgunn: right ubuntu-dev, and as it's a packaging change, pinging the integration team
<didrocks> so that they can review it
<kgunn> didrocks: integration team being you, mirv, sil ? anyone else?
<didrocks> kgunn: ~ubuntu-unity as per https://wiki.ubuntu.com/DailyRelease/FAQ#What.27s_needed_to_be_done_when_proposing_a_branch_or_reviewing.3F
<kgunn> https://launchpad.net/~ubuntu-unity <- didrocks
<didrocks> kgunn: right
<racarr> ricmm: Ok so the DPMS issue is the IPC API doesn't work but that';s only for xmir
<racarr> so if you want I can try and propose an android impl soon (should take like 2-3 hours of work to finish it off)
<racarr> that will work via in server APIs
<didrocks> kgunn: discussing with asac
<didrocks> we revert the change now
<kgunn> didrocks: ack...compiling note to the team for permanence....sorry it happened
<didrocks> kgunn: thanks
<sil2100> kgunn: is the revert taking place now? If not, I'll revert it myself if needed, as we want to have this resolved ASAP
<ricmm> racarr: please do, but that wont really land anytime soon into a released image
<ricmm> racarr: but we need it in there one way or another :) will ping you in a couple hours to see how we are doing
<didrocks> sil2100: ok, it seems kgunn isn't available, we already agree on the revert, please do
<sil2100> ACK
<kgunn> didrocks: can we still help win you time ?
<didrocks> sil2100: did you do it? ^
<kgunn> racarr: can we back out the libmirclient3 change ?
<didrocks> kgunn: only backing out that one before next tick (so in the next 10 minutes) will help
<kgunn> didrocks: sil2100 ...this is the correct one right ?
<kgunn> https://code.launchpad.net/~robertcarr/mir/dpms-support-api/+merge/181884
<sil2100> didrocks: compiling
<kgunn> sil2100: thanks
<sil2100> I need to test build my revert
<sil2100> kgunn: yeah, that's the one, I made a revert and checking if it builds
<kgunn> sil2100: thanks...i was going to pull & update myself if needed...
<didrocks> thanks kgunn and sil2100
 * didrocks continues on unity8/unity-mir meanwhile
<kgunn> always a bit dangerous to have managers touching code
<didrocks> heh
<sil2100> Build already daaamn! *hastes his bzr bd*
<jono_> kgunn, hey
<jono_> when do we plan on switching on Mir by default in 13.10?
<kgunn> our goal  is next week sept 19, we have key bugs to address next week we have
<kgunn> a sprint in lexington
<kgunn> to try to kill off the ones we consider "make xmir default" blockers
<kgunn> jono_: ^
<jono_> kgunn, perfect
<jono_> thanks :-)
<jono_> kgunn, how is everything going?
<jono_> frantic I assume :-)
<kgunn> jono_: yeah...frantic is a decent description (w/o swear words that is)
<jono_> lol
<jono_> :-)
<kgunn> sil2100: gotta mp yet ? lemme know i'll top approve
<sil2100> kgunn: I have it up, but it's not building correctly on my system - I have some unresolved symbol, need to check if it's a result of the changes or not
<sil2100> kgunn: https://code.launchpad.net/~sil2100/mir/revert_libmirclient3/+merge/185110
<sil2100> kgunn: could you maybe try?
<kgunn> sil2100: will do (switching machines)
<kgunn> racarr: ^ mind being a savvy set of mir-team eyes on this one https://code.launchpad.net/~sil2100/mir/revert_libmirclient3/+merge/185110
<sil2100> racarr: I'm gettin the following error: /opt/tmp/canonical/stacks/tmp/build-area/mir-0.0.10+13.10.20130904/obj-x86_64-linux-gnu/bin/unit-tests: symbol lookup error: /opt/tmp/canonical/stacks/tmp/build-area/mir-0.0.10+13.10.20130904/obj-x86_64-linux-gnu/bin/unit-tests: undefined symbol: eglCreateImageKHR
<sil2100> racarr: you know if this could be caused by the revert?
<sil2100> racarr: or is there something just wrong on my system
<kgunn> sil2100: are you building for arm or amd64 ?
<kgunn> oh sorry...i see x86_64
<sil2100> Yes, building locally, since cross-building would take even more time
<kgunn> sil2100: right...but target build is amd64....not arm right ?
<kgunn> sil2100: is mesa &  xserver-xorg-video-intel driver up to date
<sil2100> kgunn: that's why I wanted you to try and build it locally on your machine just in case ;) I'm building lp:mir right now, if that fails as well then it's not the revert's fault
<kgunn> sil2100: i suspect its unrelated...no gl code touched in that libmirclient3 code change
<bschaefer> sil2100, mines defined here:
<bschaefer> eglext.h:84:EGLAPI EGLImageKHR EGLAPIENTRY eglCreateImageKHR (EGLDisplay dpy, EGLContext ctx, EGLenum target, EGLClientBuffer buffer, const EGLint *attrib_list);
<bschaefer> possibly missing an update to egl :)
<sil2100> bschaefer: right, lp:mir failed as well here ;)
<bschaefer> :), sorry, just saw the undefined symbol and looked it up
<sil2100> bschaefer: but interesting, my libegl1-mesa is up-to-date!
<sil2100> And libegl1-mesa-dev as well ;p
<bschaefer>   Installed: 9.2-1ubuntu1?
<sil2100> 9.2-1ubuntu1, yes
<bschaefer> sil2100, hmm it should be  dpkg -L libegl1-mesa-dev
<bschaefer> installing it...
<sil2100> I have eglCreateImageKHR in the header as well, but hmmm
<bschaefer> o...then that is indeed strange
<sil2100> I wonder what's up ;) bschaefer does lp:mir build for you normally?
<sil2100> kgunn: but anyway, if it builds for you, let's approve it
<bschaefer> sil2100, let me check!
<sil2100> CI will build it as well and only merge if it's ok
 * bschaefer can also check libmesa to see if that function is defined or not...
<sil2100> bschaefer: thanks!
<sil2100> Maybe EGL_EGLEXT_PROTOTYPES is undefined on my system ;p
<bschaefer> possibly! Its just having problems linking right? Sooo it must not be finding where its defined...strangly
<bschaefer> sil2100, mine compiles fine
 * bschaefer does a complete rebuild
<kdub> i can check too
<bschaefer> sil2100, I also just did a dist-upgrade a bit ago
<kgunn> building...
<bschaefer> sil2100, possibly trying a --reinstall on libegl1-mesa-dev?
<sil2100> Could you guys also check if https://code.launchpad.net/~sil2100/mir/revert_libmirclient3 is fine?
<sil2100> bschaefer: will try, strange thing!
<sil2100> But I got used to my system having build problems
<kdub> sil2100, looking it over
<sil2100> kdub: thanks ;)
<bschaefer> np, I can merge it in with trunk mir and build it to check as well
<sil2100> There's a merge, if anyone can help kgunn reviewing that and approving - we need to revert that as per didrocks decision (and the many many problems we have because of that)
<kgunn> damn slow machine....50% thru
<kdub> sil2100, i approved it, small comment
<kgunn> sil2100: if i build ok, i'll run a client demo for sanity...if all ok, i'll top aprove
<kgunn> 80%...
<kgunn> like watching paint dry
<bschaefer> my branch compiled, i can run some demos for sanity as well
<kgunn> bschaefer: you so speedy...please do
<bschaefer> :)
<kgunn> bschaefer: you must be on an i7
<sil2100> :)
<bschaefer> kgunn, nope an i5, but seems to work well :)
<bschaefer> i wish!
<bschaefer> kgunn, demos are working fine! (also forgot about the flashing one...)
<kgunn> linking...drumroll please
 * bschaefer doesn't know how to express that in IRC
<kgunn> all done
<kgunn> bschaefer: i know...i miss noise making in office
<bschaefer> kgunn, well i've never worked in an office, but I can imagine its a bit easier :)
<sil2100> kdub: approved the code perspective
<sil2100> bschaefer: does the branch I pointed work for you?
<bschaefer> sil2100, yup!
<kgunn> sil2100: bschaefer kdub racarr ...built, and worked for demos...i feel good
<kgunn> ready for me to approve
<sil2100> kgunn: could you top-approve? Thanks!
<kgunn> sil2100: roger that
<sil2100> Thanks guys!
<kgunn> sil2100: done...and no thank you...sorry for the poop-storm
<kgunn> sil2100: gonna go eat & exercise... bschaefer & kdub  got your back if you need it i'm sure...
 * bschaefer will be around for a while...
<racarr> I am trying to understand this libmirclient3 stuff
<racarr> 1. How can I not fuck things up in the future.
<racarr> 2. What is meant by problems and how is it expected that this will fix them?
<racarr> Lunch
<racarr> back
<kgunn> bschaefer: everything ok? verizon decided i shouldn't have interenet for the last little while
<ricmm> racarr: ping
 * kgunn hears verison
 * kgunn hearts verizon even
<bschaefer> kgunn, everythings been quite
<kgunn> except ricmm pining...we ok ricmm ?
<ricmm> we ok, just reaching out to robert
<bschaefer> hopefully everything is :)
<ricmm> see if he has had any progress on the DPMS for android impl
<ricmm> as he had said 2-3 hours
<ricmm> a few hours back
<ricmm> its the last piece of the puzzle from your team, so far
<ricmm> ;)
<kgunn> ah yes...
<kgunn> mmm.... racarr might be lunching
<racarr> ricmm: Pong
<racarr> ricmm: Ok great, so yes I am working on it now half done but there is a problem! which I was waiting to ask kgunn about
<racarr> The API got reverted.
<racarr> kgunn: I don't understand what happened.
<racarr> kgunn: I don't understand what happened. 1. How do I not mess it up in the future. 2. What were the problems? 3. How is this supposed to fix them
<kgunn> racarr: not your fault
<kgunn> racarr: #1 - see the email i sent to team
<racarr> whoops had some up arrow = repeating myself XD
<racarr> I'm not actually THAT confused :)
<kgunn> #2 - didrocks asac and ricmm asked for libmirclient3 not to land until unity-mir was in...
<racarr> oh I missed that...I was waiting on it earlier
<racarr> Oh. I see now
<kgunn> #3....i honestly didnt get it either...i think cause they were using daily-build ppa's somehow ?
<kgunn> if total rebuild...it should be ok...but maybe they weren't doing that
<racarr> Ok. I understand more now :) sorry about missing the email.
<racarr> the MR to revert it cites issues on intel on the desktop, etc
<racarr> which really sounds like we have some sort of
<racarr> infrastructure or roll out error
<racarr> because I dont think the change can break anything besides through ABI
<kgunn> racarr: agreed
<kgunn> again...you did nothing wrong....and followed what i thot was the right way (email on mir-devel)...
<kgunn> no worries....
<kgunn> we'll get it right on libmirclient4
<kgunn> :)
<racarr> :D thanks
<racarr> I feel like it's worth trying to figure out what happened though with things being broken on the desktop
<racarr> More of a thought than a feeling I guess :p
<kgunn> me & bschaefer built locally....then sil2100 could not...something about not finding eglCreateImageKHR
<kdub> nothing should really link directly to that function
<racarr> hmm...now I am remembering I saw that once in the last few weeks
<racarr> how did I resolve it
<kgunn> racarr: so i think....when didrocks & ricmm say they have a green image w/o libmirclient3....you could then push the dpms + libmirclient3 to provide the fix
<racarr> I think I dist upgraded
<racarr> How will we get a green image without screen blanking -.-
<kgunn> everything else minus screen blanking
<ricmm> racarr: the green image is not feature-complete Mir
<racarr> ok
<kgunn> i would guess
<ricmm> its just SF with all the Mir stuffed landed but not enabled
<racarr> oh. good idea
<kgunn> ricmm: but don't we want some level of sanity test result of the mir-enabled in the same image as well ?
<ricmm> so whatever you need to depend on for DPMS, use it
<racarr> I didn't understand that :)
<ricmm> plus, its a server API, no?
<ricmm> shouldnt impact mirclient
<racarr> ehhh
<ricmm> not that I mind about mirclient, the problem with that one was desktop-related
<ricmm> but it held up the whole pipeline
<racarr> I guess it could be masked from mirclient
<racarr> its a client API too (for xmir)
<ricmm> that sounds wrong
<kgunn> mmm right...thanks ricmm forget touch will be sever side
<racarr> ! that's the bit I don't understand how did it trigger
<ubot5> racarr: I am only a bot, please don't think I'm intelligent :)
<racarr> problems on the desktop?
<racarr> ...no worries ubot5
<kgunn> ricmm: xmir is a native client
<ricmm> mirclient was bumped but that required a rebuild of everything and its mom
<ricmm> which caused problems as we had the pipeline stalled for the unity stuff
<kgunn> ricmm: did we rebuild for its dog & brother too ?
<racarr> oh
<ricmm> cousins too
<kgunn> :)
<ricmm> again, im not that familiar with the mirclient blockage, as I said... more desktop related than not :)
<racarr> Ok. So the pipeline was stalled for other stuff
<racarr> makes sense :)
<kgunn> didrocks: you on ?
<didrocks> kgunn: spammed with pings, yeah
<racarr> ricmm: That makes enough sense :D I was worried that it was failing in some way that wasn't related to just ABI or some such
<racarr> and trying to track down what was happening
<kgunn> didrocks: sorry to add to the noise...so...question is, when can we try to push libmirclient3 again...
<kgunn> didrocks: no one understands why it failed....
<didrocks> kgunn: no
<racarr> ricmm: Working on DPMS, just need to patch some support in to demo-server for a test, and go through the whole dance of updating my phone, etc.
<didrocks> kgunn: we try to have an image out
<kgunn> didrocks: thanks...nice clear anser
<didrocks> kgunn: once the image is done
<didrocks> and we have as well indicators in
<didrocks> we can reput libmirclient3
<didrocks> IF as an upstream, you handle the whole transition
<didrocks> to not block everyone
<ricmm> racarr: please do, about the phone updating it should be enough to flash -pending and update from the ubuntu-unity/daily-build ppa
<ricmm> I'll bother you again in a while ;)
<kgunn> didrocks: thanks... we will pend on you saying its ok to go again...sound ok ??
<didrocks> kgunn: perfect
<didrocks> kgunn: probably tomorrow TBH
<didrocks> kgunn: workarounding the latest Mir added a bunch of complication
<didrocks> so still building things
<kgunn> didrocks: that's fine...i think racarr has a way fwd for dpms in touch....so we're only delaying xmir
<didrocks> ok, good :)
<kgunn> didrocks: i'm so sorry...i will punch myself in the face later as punishment :-/
<didrocks> kgunn: well, on that one, you're not to blame ;)
<didrocks> kgunn: but we need to discuss on process when the team is planning to transition
<didrocks> as it affect multiple pieces, there are things to do
<didrocks> and there is a process on the FAQ page
<didrocks> that I wish your team would follow ;)
<didrocks> https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI
<kgunn> didrocks: yep...got it...and team should be aware & i'll reiterate
<kgunn> in person next week
<didrocks> thanks
<didrocks> I won't stay in Boston, lucky you! ;)
 * kgunn probably doesn't punch as hard as didrocks...thanks goodness didrocks leaves boston
 * ricmm has been trying to find a flight for a while
<ricmm> there are none
<didrocks> kgunn: ahah ;)
<racarr> red light of dweath on nexus 4...it does this sometimes when it runs out of battery hardcore though
<racarr> back to the lightning bolt and battery thing! Yay not bricked
<kdub> racarr, yeah, that happens fairly often to me, never had a brick yte
<kdub> rsalveti, in the 'android-platform-headers' package, would it be difficult to add the hwcomposer.h and hwcomposer_defs.h from libhardware?
<RAOF> Grah.
<RAOF> Why does radeon suddenly work today?
<RAOF> I'm all ready to debug bypass and multi-monitor...
<RAOF> Oh.
<RAOF> Because it's not running Mir.
#ubuntu-mir 2013-09-12
<racarr> ricmm: Got screen blanking working, an early version (needs some cleanup before proposable) is at lp:~robertcarr/mir/test-android-screen-blanking
<racarr> you can see how it works in examples/demo-shell/window_manager.cpp
<racarr> can test (hasnt been tested on gnex) by running mir demo server shell and using any hardware button
<racarr> which will turn the display on and off
<RAOF> racarr: Hey, is there a way to get libmirclient to dump a bunch of debug info via an environment variable?
<racarr> RAOF: I think there is MIR_CLIENT_RPC_REPORT=log
<RAOF> racarr: Ta.
<RAOF> That might have less of a timing impact than gdb breakpoints, which is what I'm currently using.
<ricmm> racarr: nice, any chance it can be proposed today?
<tvoss> RAOF, http://unity.ubuntu.com/mir/component_reports.html
<RAOF> tvoss: Ah, thanks.
<rsalveti> kdub: that's fine, mind just opening a bug against libhybris?
<rsalveti> will take care of it tomorrow morning
<duflu> RAOF: Do you have sufficient hardware to prove bug 1216472 is indeed intel-specific?
<ubot5> bug 1216472 in XMir "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,In progress] https://launchpad.net/bugs/1216472
<RAOF> duflu: I think I have a counterexample in my radeon system, to which I've managed to attach my partially broken second LCD.
<duflu> RAOF: "Counter" as in radeon with two outputs works fine?
<RAOF> No, as in radeon with two outputs suffers a similar problem.
<duflu> Ugh
<duflu> RAOF: I've been trying to avoid a simple and ugly workaround (if damage for any output is empty give it one pixel's worth)
<RAOF> Although that's somewhat masked by what appears to be âmir with fails to send buffers to radeon with two monitorsâ
<RAOF> A bug which is apparently timing related, as when I dump logs and attach gdb it no longer appears.
<duflu> RAOF: Without bypass? :)
<RAOF> duflu: Works, but exhibits the frame ordering issue.
<duflu> RAOF: Is it possible the breaking-up of the root window is similarly incompatible with multiple DDXen?
<RAOF> Possibly?
<RAOF> Hm.
<RAOF> Not a huge fan of the bug where closing a window will sometimes kill X.
<duflu> Doesn't Unity8 solve that? (no way to close apps) ;)
<RAOF> Bah. Stupid lttng.
 * RAOF lunches
<jrr> yay heisenbug
<alf|xmir-devel> RAOF: duflu: Could some of our problems be caused by xmir creating a mir surface for each output, which for "clone" mode end up at the same area in our virtual space (e.g. both have top-left at 0,0)?
<RAOF> alf|xmir-devel: That's possible (and I'm pretty sure there's at least one damage-tracking bug in there), but this occurs with non-overlapping outputs, too.
<alf|xmir-devel> RAOF: btw, thanks to Marteen's investigation, we believe that the egl image problems for nested mir are caused by having different dri2 screens for egl and gbm. At least for the nested mir case (i.e. optionally), we need to pass the used gbm_device to platform mir and initialize the egl dri2 using the gbm dri2 setup (liked platform_drm does). Do you see any possible blockers with this approach?
<RAOF> robert_ancell: DEB_BUILD_OPTIONS="notest" bzr bd -- -us -uc
<RAOF> robert_ancell: DEB_BUILD_OPTIONS="notest parallel=9 nostrip noopt" bzr bd -- -us -uc
<duflu> alf|xmir-devel: I can't yet imagine how it would cause functional problems, but sounds like bug 1216748
<ubot5> bug 1216748 in XMir "XMir display buffer layout sometimes overlaps and disagrees with that shown in xrandr/control-center" [Medium,Triaged] https://launchpad.net/bugs/1216748
<RAOF> alf|xmir-devel: You mean that the nested server's EGL needs to use the same drm fd as the nested server's mir platorm?
<alf|xmir-devel> RAOF: no, it must use the same dri2 screen/implementation as the gbm_device the nested server is using, so that it can share resources proprely (e.g. like the bo image).
<RAOF> alf|xmir-devel: Can we do that?
<alf|xmir-devel> RAOF: platform_drm seems to be doing exactly that, so it seems possible... although we won't know for sure until we try.
<duflu> RAOF: This looks related to out of order frames... The DDX is accessing the MirBufferPackage after free(); bug 1224296
<ubot5> bug 1224296 in XMir "XMir: DDX memory use after being freed from libmirclient" [Critical,New] https://launchpad.net/bugs/1224296
<RAOF> Thanks for the pointer.
<RAOF> (Bam, ching!)
<duflu> RAOF: Does X build with symbols by default? I did not expect "??"
<RAOF> You'd need to install xserver-xorg-core-dbg
<RAOF> And the corresponding intel -dbg, too.
<hikiko> duflu, are you still getting the crash with the drm permission message? in a fresh installation I got it once and then I upgraded and since then I've restarted lightdm more than 20 times and I dont get it
<duflu> hikiko: Yeah occasionally. As many people do. Seems to be the most popular Mir bug :(
<hikiko> ouf :/ what might happened and I cant reproduce it anymore :S unity compositor + mir are running for sure and I was getting it until 1 hr ago when I upgraded :S :S
<duflu> RAOF: OK, got full debug symbols. Now doesn't look related to frame order... bug 1224296
<ubot5> bug 1224296 in XMir "Freed memory read in damageDestroyPixmap() from sna_early_close_screen() from xf86CrtcCloseScreen()" [Critical,New] https://launchpad.net/bugs/1224296
<duflu> Also bug 1221616
<ubot5> bug 1221616 in XMir "xmir_resize() releases a pixmap it does not own, leading to freed memory reads" [Critical,New] https://launchpad.net/bugs/1221616
<RAOF> duflu: Aha. Thanks.
<duflu> As it happens, both bugs now look like things ickle was very vaguely referring to a while ago, but failed to explain or pinpoint
 * RAOF fixes it, and goes to see if it magically fixes everything
<RAOF> Oh, right.
<duflu> RAOF: I expect it will *only* make mode setting more stable... ?
<RAOF> Yes, that's a bit silly
<mlankhorst> or is it?
<RAOF> mlankhorst: Me DestroyPixmap()ing a Pixmap that I didn't allocate *is* a bit silly, yes :)
<mlankhorst> depends, were you allowed to do so?
<RAOF> ...maybe.
<robert_ancell> bye all, see you in Boston
<alan_g> alf|xmir-devel: Update pushed to https://code.launchpad.net/~alan-griffiths/mir/combine-nested-gbm-and-android/+merge/185054
<alf|xmir-devel> alan_g: thanks, I will check in a bit, my experiments have broken XMir currently :)
<alan_g> alf|xmir-devel: I expect you to learn from your experiments. ;)
<mpt> Is it possible to open a surface without specifying what size it is? (If not, there's no point remembering the size of a surface to restore it next time, like we would for position.)
<smspillaz> mpt: you need to specify the size
<mpt> ta
<smspillaz> mpt: also nonzero positions aren't supported (yet) iirc
<mpt> smspillaz, okay, so Mir has complete control of (absolute) position, while the app has complete control of size.
<mpt> (Unless it requests a size larger than any display, I guess.)
<smspillaz> mpt: it technically has complete control of both
<smspillaz> (mir)
<mpt> yeah, hence the brackets :-)
<smspillaz> part of the reason for using server side buffer allocation was so that we could limit the memory usage of applications
<smspillaz> so its theoretically possible that you could be denied certain sizes
<smspillaz> however, I don't know any good reasons other than memory pressure as to why that would be done in practise
<duflu> smspillaz: I'm /told/ much because that's the way Android does it ... (?)
<duflu> mpt: Clients (apps) have no control over position. Although there is a hint for what monitor to appear on (used by XMir)
 * duflu migrates to the laptop
<mpt> smspillaz, if you close a document that was open on a Cinema Display, then reopen it when the only display is a tiny ThinkPad, Mir shouldn't let it open at its previous size.
<smspillaz> mpt: it doesn't matter, the application makes the request for the buffer size
<smspillaz> the point I was trying to make is that you may (as an application) request a size of M x N
<smspillaz> but if you're under memory pressure then you might get something smaller
<smspillaz> I wouldn't imagine there'd be any policy implemented on the display server side to prevent applications from creating big windows otherwise
<smspillaz> generally as a display server you should probably just respect what the client wants unless it creates a security or performance problem
<mpt> smspillaz, I'm writing up the policy right now ... I guess it's window manager level rather than display server level, though.
<smspillaz> *shrug* I'm not involved with mir's development so I don't care that much
<mpt> Thanks for the answers. :-)
<smspillaz> though I will say that trying to have the window manager control application sizes is a bad idea for multiple reasons
<smspillaz> mostly because the edge cases end up in the window manager and not the individual applications
<mpt> smspillaz, what I have currently is that the only case, where the window manager will force a smaller size, is where there is no display available large enough to show it at the requested size
<smspillaz> makes sense
<smspillaz> mpt: it might be worth discussing that with the developers directly though :)
<mpt> For sure, I only asked the channel in general because tvoss wasn't here. :-)
<alan_g> mpt: The general answer is that the Mir library provides hooks for the shell to intercept and tailor the requests. And it is the shell that sets the strategy.
<mpt> ta
<mpt> tvoss_, have you given any thought to how toolkits will place tooltips close to the screen edge, when they don't know how close the window is to the screen edge?
<mpt> how close the parent surface is, I mean
<tvoss_> mpt, not yet, but the idea I have in mind is like: apps provide an anchor point in surface relative coordinates, and unity decides where to put the surface depending on closeness to the edge
<mpt> tvoss_, makes sense.
<tvoss_> mpt, cool
<hikiko> question: in /etc/init.d/ there's a lightdm script that should print some messages, where are these messages printed? I cant see them at syslog + I inserted some echo "foo" >> /tmp/foo but there's no /tmp/foo when I restart lightdm... I didnt find any relevant info in the upstart documentation so far any idea?
<alf|xmir-devel> hikiko: /var/log/lightdm/*
<hikiko> no alf|xmir-devel
<hikiko> I dont want to get the lightdm log
<hikiko> I want to get the output of the script that starts the lightdm
<hikiko> in /etc/init.d
<hikiko> to see if a signal is send twice
<kgunn> kdub: ping
<kdub> kgunn, pong
<kgunn> kdub: hey...gotta request...can you flash the pending image http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/
<kgunn> this contains mir, but not on by default
<kdub> okay, will try
<kgunn> to turn on....just modify the /etc/environment file...for QT_QPA_PLATFORM=ubuntumirclient
<kgunn> then, rename/delete SF
<kgunn> on nexus4
<kgunn> and see what you see :)
<kgunn> team in lexington is claiming its flickering very very bad...but want to know what you see
<kgunn> kdub: greyback says he does not see this flicker on galaxynexus
<kgunn> kdub: guys in lexington said they saw it on nexus4
<kgunn> racarr: ^ ...in case you're awake & on :)
<kgunn> kdub: racarr ... i am trying here....but fear messing something up...(first time i did this...it was stuck at google splash)
<kgunn> on my second attempt
<greyback> kgunn: I'm having same problem actually. It's like upstart isn't starting hte user session any more. Did mterry's stuff change that?
<kgunn> greyback: hmm...so i'm using pending, adb pull etc/environment, modify to QT_QPA_PLATFORM=ubuntumirclient, then adb push, then adb remount, rm /etc/bin/surfaceflinger, reboot
<kgunn> i get stuck at splash every time
<greyback> kgunn: perfect. I'm getting the same. unity8 isn't being started
<greyback> kgunn: if you adb in, can run it manually with "GRID_UNIT_PX=18 QT_QPA_PLATFORM=ubuntumirserver unity8"
<greyback> but the lenses and indicators are not running either
<greyback> so it's kinda blank
<kgunn> greyback: couldn't decipher mterry's response...so is it related ?
<kgunn> do we need to go whine to asac to get that last piece in?
<greyback> kgunn: I don't think so. But something has changed, and I've no idea what
<kgunn> greyback: did you ever get past the splash (....thot you said you saw flicker at some point)
<greyback> kgunn: well I need someone who understand the upstart situation to help out
<kgunn> greyback: oh duh...you manually launched
<greyback> kgunn: I ran it manually with that command. And can launch and switch apps when
<greyback> s/when/then/
<kdub> i get 'Library unity-mir not found/loaded "
<kgunn> kdub: what the what? ^ greyback
<greyback> kgunn: aha, that was fixed in trunk. As workaround, please install "libunity-mir-dev"
<greyback> kdub: ^^
<dandrader> where mir log goes by default?
<kdub> /tmp/
<dandrader> ok, thanks
<kdub> dandrader, --glog-log-dir can change the directory
<kdub> greyback, how do you normally compile unity8 for the phone?
<kdub> i've been trying in an armhf chroot on and off, never seem to have much luck with that method
<dandrader> kdub, does logging work as usual even when you run those examples like mir_demo_standalone_input_filter?
<greyback> kdub: on the device itself. I've also not got chroot working
<kdub> dandrader, i think it should, haven't tried with that specific example though
<greyback> kdub: this is closest I've got: https://wiki.ubuntu.com/SimpleSbuild
<greyback> but I'm stuck on older kernel without aufs (don't ask), and I need to compile it myself. Never got around to it
<kdub> greyback, thanks, i guess i'll try on the phone
<kdub> greyback, now i get "ASSERT: "!isEmpty()" in file /usr/include/qt5/QtCore/qlist.h, line 288
<kdub> "
<greyback> kdub: no idea how you got that. Please apt-get update everything, then check QT_QPA_PLATFORM=ubuntumirclient in your env
<alan_g> kdub: re problem I'm seeing with multiwin under nested. If I increase the alpha (to, say, 0xe0) then it works - does that suggest anything to you?
<kdub> alan_g, that the alpha is being mis-set somewhere
<kdub> alan_g, it could just be that the alpha in the example has to be turned to opaque
<alan_g> kdub: I do get show through - so it isn't just treating as opaque
<kdub> greyback, still getting that isEmpty() error after the upgrade :/
<kdub> alan_g, perhaps the example is picking the wrong pixel format?
<kdub> greyback, maybe there's a ppa i haven't installed?
<greyback> kdub: what device are you using? No ppa is necessary
<kdub> mako
<alan_g> kdub: It looks right. (And why the different behavior in nested - it ought to be nested code that causes problems).
<kdub> alan_g, perhaps the incorrect egl configuration is chosen
<kdub> let me check...
<kgunn> kdub: new image...http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/
<kgunn> greyback: ^
<kgunn> racarr: ^
<kdub> kgunn, is it important to test the image? i was just going to see if i can compile it myself to see the flicker
<greyback> kgunn: yay
<kgunn> kdub: nah...keep compiling
<kgunn> i was just pointing it out....it only _might_ be interesting
<kgunn> it could also be a mess
<greyback> I'll downloading it now, will let oyu know
 * greyback decided not to bother about correct English any more
<kgunn> dude...aren't you irish ??....you're worse than american :)
<kdub> me fail english? that's unpossible!
<kgunn> only american's allowed to butcher english....and not speak any other languages to boot :)
<racarr> *clinks red white and blue power rings with kgunn and kdub*
<racarr> America!
<kgunn> racarr: ....its wonder twins power activate
<racarr> lol
<racarr> ill test the image
<kgunn> racarr: http://www.youtube.com/watch?v=ktUx57i63e0
<kgunn> explains alot about my inner workings ^
<kgunn> ...oh... racarr i just got it... note america.... 'merica!
<greyback> oh for the love of all that's holy
<kgunn> hmmm...im still stuck at splash (w.o command line)
<greyback> me too :(
<greyback> kdub: and now I get your failure too
<kgunn> hmmm...it complains on command line for me
<kgunn> seg fault
<greyback> and has weird backtrace. http://pastebin.ubuntu.com/6098316/
<greyback> wtf is happening?!
<racarr> How to use bzr
<racarr> I can't merge trunk int o dpms-support-api without it...removing all of dpms
<kdub> racarr, that's happened to me before, shortcoming of bzr
<kdub> i usually just make a patchfile and apply on top :)
<racarr> :( yeah
<racarr> or you can do reverts
<kdub> well, might be a shortcoming of bzr, or a shortcoming of my knowledge of how to use bzr
<greyback> kdub: try "export QT_SELECT=qt5" and then try shell
<greyback> no actually, no good either
 * greyback needs to EOD
<kdub> mmk
<kgunn> kdub: gonna step out for a very late lunch (read as errands)
<kgunn> let me know how your build effort concludes
<racarr> Lunch
<kgunn> kdub: curious how your build is going ?...went ?
<kdub> kgunn, still going :) arm compiles
<kdub> tinkering with the mali604 in the meantime
<kgunn> ooo you must be native compiling
<kdub> yeah, i had some issues with a qemu/chroot compile (which greyback said he had too)
<kdub> kgunn, i still get that isEmpty() error from qlist.h with the version i compiled
<kgunn> :-/
<kdub> the mali driver is a bit weird... but got just got a client frame to render!
<kgunn> kdub: \o/
#ubuntu-mir 2013-09-13
<mlankhorst> mali hw is weird :P
<alf_> RAOF: My attempts to reuse the dri screen in platform Mir have been unsuccessful so far (see http://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment). I am probably missing some background to make this work, and I don't think it is productive to try blindly now. Hopefully we can tackle this next week.
<alf_> alan_g: FYI, ^^
<alf_> RAOF: (reuse the gbm device's dri screen in platform mir)
<alan_g> alf_: that's about resolving the gbm stack problems for nesting Mir?
<alf_> alan_g: yes
<alf|afk> nick alf_
<alan_g> alf_: have you time/headspace to look at nested/android egl with me?
<alf_> alan_g: sure, although I am not currently set up to try it out on a device
<alan_g> alf_: I'm set up - but I can't make sense of what I see. Grab lp:~alan-griffiths/mir/multiwin-hacks-for-nested/
<alf_> alan_g: ok
<alan_g> What I see is that multiwin works when talking to the host Mir session, but if talking to the nested one the screen remains blank
<alan_g> I've tried various things, but the only thing that makes a difference is increasing the alpha on the windows. I.e. with alpha 0x50 the screen is blank, with 0xe0 it shows transparent windows
<alan_g> With 0xff the windows are solid
<alf_> alan_g: where do you change the alpha?
<alan_g> multiwin.c
<alf_> alan_g: is there a cutoff alpha value for visibility (e.g. the 0xe0 you mentioned?), or from 0x50 to 0xe0 the opacity is gradually increased?
<alan_g> alf_: just doing a binary search...
<alan_g> between 0xa0 (fail) and 0xb0 (pass)
<alf_> alan_g: btw, which pixel format does multiwin reports that it is using?
<alan_g> 0xa0 fails and 0xa1 passes
<alan_g> 1 - mir_pixel_format_abgr_8888
<alan_g> FWIW that's the same for talking to host and to nested
<alf_> alan_g: can you try 1. changing egl_attribs in nested_output.cpp to match the ones used in nested_display
<alan_g> alf_: yes
 * alan_g missed the change from using mgn::nested::attrbutes
<alan_g> alf_:  that does it
<alf_> alan_g: \o/
<alan_g> thanks
<alf_> alan_g: yw
 * alan_g knew it would seem obvious once someone pointed it out
 * alf_ wonders what strange format the android EGL impl. had selected to cause the alpha cutoff... perhaps something with EGL_ALPHA_VALUE = 1?
<alf_> (1 bit of alpha)
<alan_g> alf_: Wouldn't that just give blank or opaque
<alf_> alan_g: right, I forgot that we had a translucent state too
<alan_g> alf_: hold a moment - it might not be working after all.
<alf_> alan_g: holding on...
<alan_g> WTF I'm now running the same instrumented version that appeared to work...and it doesn't
<alan_g> Not sure what happened when it appeared to work
<alan_g> :(
<alan_g> Hmm, there's now some intermittent working
<alan_g> alf_: OK, the images through nested are a lot fainter than with the host. (Like the alpha is applied in the host render too?)
<alf_> alan_g: Is this condition stable, is that what you were seeing before thinking it didn't work?
<alf_> alan_g: also is the alpha rendered gradually (though fainter) in this case?
<alan_g> alf_: am still experimenting - the change had an effect, but when I tidied the code I tried a lower alpha and couldn't see the image
<alan_g> alf_: Sorry - have to deal with a crisis
<alan_g> alf_: OK, now I'm looking more carefully, I've also noticed that the nested image from egltriangle is fainter than that from the host session.
<alan_g> (It is harder to tell with plasm or fingerpaint)
<alf_> alan_g: perhaps changing the clear color in gl_renderer.cpp will give more visual clues (e.g. glClearColor(1.0f, 1.0f, 1.0f, 1.0f); before glClear())
<alf_> alan_g: also I wonder... we are probably getting an argb surface from mir but are using an EGL config without alpha
<alf_> alan_g: two things to try: 1. force nested mir to create an opaque mir surface with mir_pixel_format_xbgr
<alf_> alan_g: (and separately) 2. ask for a config with ALPHA
<alan_g> alf_: can we do that when the only supported format is mir_pixel_format_abgr_8888?
<alan_g> What's the incantation for 2? "EGL_ALPHA_SIZE, 8,"?
<alf_> alan_g: yes
<alan_g> changing the clear colour just changes the background - no obvious artefacts
<alf_> alan_g: @mir_pixel_format we can, it is supported according to the Android code. Actually the pixel formats we are checking in nested mir are the pixel formats of the display (e.g. of a scanout surface). We need to check the surface formats for now (unless we want to use bypass, which is another story).
<alan_g> alf_: the pixel format seems to be an answer.
<alf_> alan_g: good to hear, let's see if (2) works too
<alan_g> alf_: no - that doesn't work
<alf_> alan_g: is the background color also more faint?
<alan_g> alf_: I reverted that change - but don't remember there being a difference. Am checking the pixel format logic - as forcing argb also seems to work.
<alan_g> No that was a mistake.
<alan_g> I'll check the background
<alan_g> alf_: no change to the background colour.
<dandrader> kgunn, I'm knee deep in the work of modifying android-input to support gesture accept/reject. I wonder if I should join mir daily standups so that people are aware of what I'm doing
<kgunn> might not be a bad idea dandrader ....altho you'll have encourage racarr to join if you want him there (it's an 8am for him...he'll make it on demand :)
<kgunn> dandrader: put you on the invite...its in 30 minues
<kgunn> minutes even
<dandrader> hmm, right. indeed the main point is in having racarr aware of it
<dandrader> kgunn, ^
<alan_g> alf_: requesting egl config with alpha works. but only with glClearColor(_, _, _, 1.0f)
<alan_g> So because I'd reverted the glClearColor() call it didn't
<alan_g> alf_: so I have two fixes and too little knowledge to chose the best.
<alan_g> 1. Add glClearColor(0.0f, 0.0f, 0.0f, 1.0f); and EGL_ALPHA_SIZE, 8,
<alan_g> 2. use mir_pixel_format_xbgr_8888 regardless
<alan_g> alf_: is there a 3?
<alf_> alan_g: nothing comes to mind... I think it makes sense for nested mir to draw to an opaque surface, since it is its "framebuffer" (host mir renders to an opaque buffer too). I don't think we currently have a use case for nested mir needing selective translucency.
<alan_g> alf_: OK, does it make sense for the glClearColor(0.0f, 0.0f, 0.0f, 1.0f) to stay in GLRenderer::clear()?
<alan_g> Or is there a better place in the nested code?
<alf_> alan_g: of course, ideally, we won't hardcode to xbgr_8888, but search the formats instead for a supported opaque format.
<alf_> alan_g: as long as our "framebuffer" surfaces are opaque, setting the clear color alpha to 1.0f doesn't make a difference
<alan_g> alf_: I understand that, but do we have a suitable list of formats to search?
<alf_> alan_g: mir_connection_get_available_surface_formats
<alan_g> alf_: I'll have a look there.
<kgunn> kdub: mornin' you on ?
<kdub> kgunn, yep
<kdub> good morning
<kgunn> kdub: hey so pending is all good (sort of)...
<kgunn> flash, then apt-get dist-upgrade it....then rm surfaceflinger, mod env file, etc
<kgunn> basically...our #1 is the little white flickers
<kgunn> http://www.youtube.com/watch?v=HaPKxLh9_So
<kgunn> kdub: ^
<kdub> kgunn, i see...
<kdub> haven't seen that before
<kdub> will look of course
<kgunn> kdub: gerry says it doesn't exist on GN...and actually...i have always seen it on N4
<kdub> yeah, looks like something framebuffer related perhaps
<kgunn> tvoss said it wasn't in this video https://plus.google.com/u/0/photos/117745549829232162250/albums/5922939740350969137/5922939748109840754?authkey=CMau8ZXwtKyjuwE
<kgunn> but if you look real close....it was there
<kgunn> its 2 weeks old...so yeah...
<kgunn> i'm thinkin' some niggling android fb thing
<kdub> kgunn, when we say flash these days... is that 'cdimage-touch' or 'ubuntu-system'
<kdub> i don't really know the different :-[
<kgunn> cdimage-touch kdub
<kdub> kgunn, ok, thanks
<kgunn> kdub: at least i 've seen some struggles with systemimage....but if you want to try ....do this https://www.stgraber.org/2013/09/05/ubuntu-touch-system-images-now-default/
<kgunn> greyback: you've been doing cdimage as i have right ?
<greyback> kgunn: I've been using it, yes
<kgunn> greyback: do you have any idea what touch /home/phablet/.display-mir is ?
<greyback> kgunn: yes, that's the switch used to decide whether to boot in SF mode, or Mir
<greyback> if that file exists, it boots Mir, else..
<kgunn> greyback: is it shearly the file existing ? or does it need content?
<kdub> good morning racarr
<alan_g> alf_: Does this make sense? https://code.launchpad.net/~alan-griffiths/mir/multiwin-fix-for-nested/+merge/185535
<greyback> kgunn: just the file existing
<davmor2> kgunn: there is an email that says just touch the file and then sergiusens  also said as much,  the operation of the gfx is slower and jumpier with the file in place too
<davmor2> kgunn: you have to reboot after creating the file
<kgunn> davmor2: hmmm
<greyback> kgunn: yep, sorry reboot is needed after creating/deleting the file
<kgunn> davmor2: the way i am running...mod'ing the environment file for the qpa to be ubuntumirclient & deleting surf flinger
<kgunn> with good results
<kgunn> wondering if using the .display-mir is not quite right
<greyback> kgunn: none of that is necessary now, that "touch /home/phablet/.display-mir" command looks after all that for you
<kgunn> greyback: yeah...just wondering, so many complaints with that...
<kgunn> vs old way
<greyback> kgunn: really? What problems are people having?
<kgunn> davmor2: ^ can you share
<davmor2> greyback: gfx transitions are slow, opening contacts from the launcher has locked the screen repeatedly
<greyback> davmor2: you using a Galaxy Nexus?
<davmor2> greyback: Yeap
<racarr> Morning
<greyback> davmor2: unfortunately the slow gfx is a Mig bug, being worked on I believe
<greyback> davmor2: crashiness is probably my problem
<greyback> davmor2: all you're doing is launching the contacts apps from the launcher, yes?
<davmor2> greyback: let me go through the steps once more to confirm and I'll throw a bug together for it
<greyback> davmor2: appreciated, thank you. Please log against "unity-mir"
<davmor2> greyback: any logs that would be useful?
<greyback> davmor2: the contents of $HOME/.cache/upstart/unity8.log would be great
<davmor2> greyback: no worries give me about 10 minutes
<greyback> cheers
 * alan_g decides it is time to prepare laptop and netbook for sprint 
<kdub> oh yeah, i should do that too :)
<kdub> my quarterly 'upgrade the laptop for the sprint!'
<kgunn> davmor2: funny kdub was just asking me about my post on performance GN vs N4
<kgunn> davmor2: https://plus.google.com/116997345010659023379/posts/cWSUVkvpGax
<kgunn> GN is a dog for oh so many reasons
<davmor2> kgunn: yeah but at the time it was the phone I could afford :)
<davmor2> greyback: I think I have it nailed now it's if you drag the launcher out while the app is still loading.  I.e. while contacts is still light grey (before the contacts info/title loads) open the launcher again.   It probably happened on the Surface flinger too but didn't present due to the addition speed
<greyback> davmor2: good observation. I'll try to repo shortly (compiling)
<racarr> ricmm: I am moving the screen blanking branch to lp:~robertcarr/mir/dpms-with-screen-blanking
<racarr> contains the DPMS base too
<ricmm> ok great
<davmor2> greyback: https://bugs.launchpad.net/unity-mir/+bug/1225077
<ubot5`> Launchpad bug 1225077 in unity-mir "Maguro: Opening launcher before an app is fully loaded crashes the gfx" [Undecided,New]
<greyback> davmor2: thank you!
 * greyback needs to reboot, bbiab
<racarr> kdub: I am just finishing off my unit tests for android screen blanking
<racarr> want a test like....uh...well that just tests display::Configure
<racarr> Display::configure oO
<racarr> applies the PowerMode to the DisplayBuffers
<racarr> fromt eh configuration
<kdub> racarr, integration test?
<racarr> Is there a test fixture that deals already with mocking the Display buffers?
<kdub> there's one that actually drives the display :)
<racarr> kdub: no I think its a unit test on android_display
<racarr> that, uses a mock framebuffer window, and a stub display buffer factory that returns mock display buffers
<kdub> kgunn, been playing with this for a while, haven't seen the flicker yet
<racarr> I saw the flicker the last time I set up unity-mir (~2 days)
<kdub> hmm, is it always white like I saw in the video?
<racarr> no
<racarr> ok well actually I have seen two things
<kdub> oh, just saw a tear
<racarr> 1 week or so ago I was seieng some "flickering" which actually semeed to be the app underneath the shell bubbling up a frame
<racarr> and then, 2 days ago was seeing
<racarr> tearing
<racarr> but nothing I would call "flickering" I guess
<racarr> just tearing
<kdub> like a split screen vertical tear
<racarr> oh
<racarr> err
<racarr> do you mean a horizontal tear from missign vsync
<racarr> or an actual vertical tear
<kgunn> kdub: open up some apps
<kgunn> maybe ?
<kdub> kgunn, just saw it
<kdub> its pretty similar to things i've seen from hwc before... have to dig a bit
<kdub> our demos should have a 'bank' of animations to select from on the command line
<kdub> especially animations that are well-known to expose visual problems
<kdub> like... scrolling :)
<racarr> how about we make that my new job, writing animations in the demo clients
<racarr> should take me like 2-3 months, real intense focus
<racarr> ok thanks kgunn
<kdub> hey, i thought of it! my job!
<kdub> :)
<kgunn> u guys
<racarr> :p
<alan_g> I think the boss wants to steal that task
<kgunn> :)
<mlankhorst> shake it
<mlankhorst> we need the full compiz fusion set of plugins ;)
<mlankhorst> wobbly windows you give some acceleration and watch it fly over the screen
 * greyback eow
<racarr> Lunch!
 * kdub lunch
<racarr> back
 * kdub back
<kgunn> kdub any news?
<kdub> no, keep hitting walls getting into a test/compile/test cycle
<kdub> it looks like something hwc-related though to me
#ubuntu-mir 2013-09-15
<dazza5000> !history
<dazza5000> when is the best time to get assistance?
<smartboyhw> Hmm
#ubuntu-mir 2014-09-08
<duflu> AlbertA: Got your timezones confused? :)
#ubuntu-mir 2014-09-09
<duflu> RAOF: Reconsider? https://code.launchpad.net/~vanvugt/mir/relax-libmirplatform2/+merge/233682
<duflu> I mean... "Fixed"
<RAOF> duflu: Enjoy
<duflu> camako: Are you sure the fixes we want to release quickly are ABI breakers? I don't think they are. We could just do a 0.7.1
<camako> duflu, probably not, but I've requested a silo for the 0.8.0, so we might as well have them go out with 0.8..
<duflu> camako: Well, you have the option of not doing a major release. Any resulting pain was your choice :)
<camako> Well, I'll be spreading the pain around this time :-)
<camako> duflu, yeay privatize-underused is landing... if you wanna land the server-abi-26 branch by hand... be my guest! Anyways, it's way too late for me to be here.. good night!
<duflu> camako: Unfortunately landing that one by hand is likely to break CI for *all* other branches
<duflu> So I won't yet
<duflu> camako: Night
<RAOF> There we go; first cut at symbol versioning HOWTO.
<duflu> (the crowd goes wild)
<duflu> (or something)
 * RAOF wonders what would fix LTO for clang
<RAOF> duflu: Oh, did I argue enough for dont-kill-the-poor-clients?
<duflu> RAOF: I haven't checked it today, but doubt it :)
<RAOF> Heh
<duflu> RAOF: Happy to be your tester if you can't reproduce the issue
<RAOF> The MP doesn't actually touch any of the code around that codepath anyway.
<RAOF> Well, once you remove the eglapp changes.
<duflu> Extra weird then
<RAOF> It's an existing race, I tells ya!@
<duflu> Does anyone know why we have deep library directories? Seems at least one level is superfluous: /usr/lib/x86_64-linux-gnu/mir/platformgraphics/mesa/libmirplatformgraphics.so as "platformgraphics" is mentioned twice
#ubuntu-mir 2014-09-10
<AlbertA2> duflu: do you have permissions to add a commit message to this: https://code.launchpad.net/~vbocek/unity-system-compositor/fix-hammerhead-backlight/+merge/233572
<AlbertA2> duflu: ?
<AlbertA2> I can't add it...I'd like to start the silo build for it...so I Can test it in the morning...
<AlbertA2> or RAOF: ^
<duflu> AlbertA2: Apparently yes. Done
<AlbertA2> duflu: thanks!
<duflu> Huh. That explains why other people don't fix commit messages on reviews as much as I do
<duflu> ... because they can't?
<AlbertA2> well in mir mps I can...but I don't have permissions for unity-system-compositor
<duflu> Curious
<alf_> Saviq: kgunn: Hi! We would appreciate the unity8 perspective on https://code.launchpad.net/~vanvugt/mir/drop-dead-internals/+merge/233487 (i.e. whether we think the removed functionality could be useful for unity8 in the future)
<kgunn> dandrader: greyback__ mzanetti ^ if you have an opinion
<mzanetti> really a question for greyback__...
<dandrader> alf_, so it removes the in-process client feature?
<alf_> dandrader: yes
<dandrader> alf_, ok from my side. I don't see us wanting to use that.
<alf_> dandrader: ack, thanks
<dandrader> alf_, but would be good to check with greyback__ as well. maybe he thinks differently
<alf_> dandrader: will do
<alf_> greyback__: ^^
<greyback__> sorry, just back from my run
<greyback__> will look now
<kgunn> robotfuel: hey, so duflu looked into this and says its media player and dbus...
<kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1354068
<ubot5> Ubuntu bug 1354068 in unity8 (Ubuntu) "/usr/bin/unity8:11:std::function:SlotWrapper:core::Signal:core::dbus::Signal:operator" [Undecided,New]
<kgunn> do you know the project name for media player?
<kgunn> was gonna retarget it
<kgunn> racarr: ^ nvmd that unity8 crash i was suspecting might relate to surfaces
<robotfuel> https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app
<robotfuel> kgunn:
<robotfuel> ^
<kgunn> ah ta
<racarr> kgunn: Yay! thanks
<Tassadar> AlbertA: hey, saw that MP was merged and that it didn't have commit message?
<Tassadar> what does that mean, it had one Oo
<Tassadar> the one from this commit - http://bazaar.launchpad.net/~vbocek/unity-system-compositor/fix-hammerhead-backlight/revision/172
<Tassadar> or do I have to enter it separately into launchpad?
<AlbertA> Tassadar: we added one...
<AlbertA> I just didn't have the perms so I had to ask duflu to do it for me...
<Tassadar> I think it was showing the commit message from that commit I linked above in the "Commit Message" in that merge proposal Oo
<Tassadar> just asking what did I do wrong so I can not repeat it later
<AlbertA> oh the MP itself didn't not have a commit message
<AlbertA> only a description
<Tassadar> oh, right bzr squashes all the commits from the branch when merging, right?
<AlbertA> right well launchpad yeah...
<Tassadar> (that was not what I inteded to do)
<Tassadar> I suppose the commit message for MP is under that more options/advanced section I didn't look into when creating the proposal?
<AlbertA2> yeah
<Tassadar> okay, thanks
#ubuntu-mir 2014-09-11
<alf_> duflu: When you get some time can you please check if https://bugs.launchpad.net/mir/+bug/1352772 is fixed for you too?
<ubot5`> Ubuntu bug 1352772 in Mir "gdb mir_demo_server_shell takes a very long time to start (over a minute)" [Medium,New]
<duflu> alf_: It was still very slow a few days back. Will retest
<duflu> RAOF: What happened to your "link to libmirplatform properly" branch?
<duflu> Can't see it having landed
<duflu> alf_: Umm, maybe. I seem to have overcommitted to too many activities again
<RAOF> duflu: It ran into awkwardness - specifically, the wonders of the protobuf singleton (can we remove that?)
 * duflu shrugs. Not wanting to commit to more threads of discussion
<bregma> anyone know why unity-system-compositor would fail opening the DRM device http://paste.ubuntu.com/8322285/ ?
<RAOF> bregma: Because Mir hasn't managed to find a DRM device that has any outputs available.
 * bregma thinks that doesn't really help much
<bregma> would that be because the guy is trying to run in a VM?
<RAOF> That's entirely possible.
<RAOF> I think the vmware drm module doesn't expose any connectors, tripping that check.
<RAOF> I *also* thought we had removed that check because the vmware drm module doesn't expose any connectors.
#ubuntu-mir 2014-09-12
<RAOF> Man, I _really_ wish that libprotobuf didn't have an __init section.
<duflu> RAOF: Yeah I noticed too... https://code.launchpad.net/~vanvugt/mir/fully-defined/+merge/234261
<RAOF> Incidentally, isn't https://code.launchpad.net/~vanvugt/mir/version-drivers/+merge/234278 fully subsumed by https://code.launchpad.net/~raof/mir/versioned-library-loader/+merge/234062 (at least, once the latter lands!)
<duflu> RAOF: No, you need versioned package names as well as library names to resolve bug 1293944 (which is blocking any further bumping of the server ABI)
<ubot5> bug 1293944 in Mir "[regression] Mir deb packages with versioned names cannot be installed simultaneously any more" [Critical,In progress] https://launchpad.net/bugs/1293944
<RAOF> Oh, bah, sorry, wrong MP: https://code.launchpad.net/~raof/mir/privatise-all-the-things/+merge/234063 is what I meant.
<RAOF> Man I wish CI didn't take so long.
<RAOF> Or, alternatively, that I could easily reproduce the CI environment locally.
<duflu> RAOF: Don't know. I'm ignoring it on size alone right now. That and I got proof last night my smaller branch sufficiently unblocks CI \o/
<RAOF> Oh, yeah, it will.
<RAOF> It's a bit wrong, though :)
<RAOF> The binding between the driver and the platform isn't libmirplatform's SOVER; it's just the ABI defined by what gets dlsym'd by libmirplatform.
<duflu> Madness madness everywhere. We just have to stop adding features for a year or two. Clean up what we have, then carry on :)
<RAOF> We actually _have_ a defined ABI for that, though :)
<RAOF> And it hasn't changed over the last 6 months.
<duflu> Except the server ABI, that changes every week or two :)
<RAOF> Right, but the platform drivers don't care about that.
<duflu> OK, platform-api is now on my list. It won't ever get forgotten in SDK testing again
<duflu> I really didn't expect platform-api to be full or Mir server header usage
<RAOF> Oh.
<RAOF> We've overprivatised  things.
 * RAOF should do an out-of-tree X11 platform module. It'd make greyback happy.
<RAOF> In fact...
<RAOF> I'm tired and annoyed. Let's call that a Friday Labs project and have a play.
 * duflu -> lunchtime sunshine
<RAOF> HURRAY!
<RAOF> CI finally passes!
<RAOF> Ok, so why do we have PendingCallCache::force_completion(), and why do we think it might do something useful?
 * duflu shrugs. It's undergone at least one rewrite since I last looked there
<RAOF> I'm not entirely sure how âlet's call the function that handles the reply, except handing it a non-replyâ is supposed to be a good idea :)
<RAOF> _Particularly_ since it's not clear that it's possible for the reply handler to determine whether or not the reply object is a reply or not.
 * duflu shrugs again. Trying to not get caught up in new topics on a Friday afternoon
#ubuntu-mir 2015-09-07
<Hawk_> like to try out the newer version of mir in ubuntu touch
<Hawk_> can I just installed related debs?
<Hawk_> such as https://launchpad.net/~mir-team/+archive/ubuntu/staging/+build/7842048
<Hawk_> doing a port of sony xperia L
<Hawk_> there is some opengl error. icons are missing
<Hawk_> wily seem to be packaged with mir 0.14?
<duflu> Hawk_: wily images with Mir 0.15 do exist. They are called the 'devel-proposed' channel
<duflu> Technically mixing debs with the touch images is unsupported and can break things. Although we rely on such hacks for testing things
<Hawk_> just want to test out
<duflu> Yeah, we all install debs, so that's fine. Just don't expect your debs to still be correct after over-the-air updates
<Hawk_> :(
<Hawk_> wont have over the air updates
<Hawk_> this is a xperia L porting
<Hawk_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
<Hawk_> is this the image for the devel-proposed branch?
<duflu> Hawk_: No problem then. Also if you run out of space:   http://askubuntu.com/a/660886/439189
<Hawk_> thanks for the head up on the space. yeah 2GB is running tight it seem
<duflu> Hawk_: To get the latest, you should ideally put the phone in fastboot mode. Then:   ubuntu-device-flash touch --bootstrap --developer-mode --channel=devel-proposed
<Hawk_> probably wont need 6GB though
<duflu> Hawk_: It's shared space (thanks to sparse filesystems). It won't use the space until you actually use the space
<Hawk_> I dont have the luxury of ubuntu-device-flash
<duflu> Yeah fair point
<Hawk_> i am trying to do a porting
<Hawk_> fixing opengl issue is out of my league
<Hawk_> just trying out any option that might help with the issue
<duflu> Hawk_: Actually you probably won't ever need to do OpenGL. It's just all operating system hacking
<Hawk_> guess not. thats the reason I would like to try newer version of mir
<Hawk_> CM kernel for xperia L totally killed the gralloc hal
<Hawk_> causing reboot
<Hawk_> AOSP kernel seem to work on most stuff
<Hawk_> icons are not showing on dash and app scope
<Hawk_> QOpenGLShader::link: "--From Vertex Shader: Error: Symbol textured defined with different precision in vertex and fragment shaders.
<Hawk_> unity log have opengl errors
<duflu> Hawk_: Sounds like a bug in the latest Unity8. Or a package mismatch. Either way, it's not really a device specific failure
<duflu> Sometimes on the bleeding edge, you will bleed a bit
<Hawk_> i got the same error for vivid and wily image
<Hawk_> i am using the current image in both build
<Hawk_> unfortunately, its not affecting the official buid so it might be be noticed or have patch available :(
<duflu> Hawk_: The current wily *.img files are unfortunately not being well tested right now. The team is focusing on delivering for vivid-based devices for the moment
<duflu> Although vivid should work
<Hawk_> i was using vivid all the while
<Hawk_> switch to wily to check if issue still exist
<duflu> Hawk_: Yeah, let me find where that error is
<Hawk_> duflu, need any log from my end?
<duflu> Hawk_: Was there anything other than that link message?
<Hawk_> there are many different precision in vertex and fragment shaders
<Hawk_> I am listing one of those
<Hawk_> dont have the device with me atm
<Hawk_> in any case, i have never gotten the icons since my port
<Hawk_> just for the record
<Hawk_> so the opengl error and the missing icons might not be related?
<duflu> Hawk_: Actually the toolkit (including icon display) is heavily dependent on OpenGL extensions and sensitive to platform changes
<duflu> More than you'd think
<duflu> Hawk_: Can you please document the issue here so the relevant people will see it?... https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug
<duflu> Heh.
 * duflu waives to Saviq on that note
<duflu> waves
<Hawk_> u think its an issue worth logging?
<Hawk_> and not due to porting?
<duflu> Hawk_: Doesn't matter if it's a mistake of your own making or ours. Logging a bug is a nice formal way to figure out which is true
<Hawk_> ok, will do it later when i have the device with me.
<Saviq> o/ duflu
#ubuntu-mir 2015-09-08
<RAOF> git rebase --exec is really nice.
<RAOF> Relatedly: I wonder how I could make linking libmirserver.so faster :)
<anpok> linking with gold?
<RAOF> Hm, maybe.
<RAOF> Nah, not substantially faster.
<RAOF> Oh, *slighty* faster, in that it fails to link libmirplatform :)
<duflu> RAOF: AFAIK it's the shear number of symbols. And most of those will be from template usage. Haven't audited it but have been meaning to. Sometimes you can make simple changes to reduce the problem...
<anpok> hm our ci is not pulling in stable phone overlay - is that intended?
<duflu> Not sure. Is there a distro project to see what's in the overlay?
<anpok> it des not pick up the liibnput library I need
<anpok> so I guess it does not include the overlay ppa
<duflu> greyback: Thanks for the pointers. Turns out nothing in our stack holds wake locks for the sake of performance (the kernel stats show powerd's wake locks are hardly used). But also adding wake locks to prevent idling is not enough to make a noticeable improvement to graphics...
<greyback> duflu: so it seems something else is managing gpu clock speed?
<greyback> is it gpu clock speed, or cpu, you suspect?
<duflu> greyback: Yeah the scaling governors are annoyingly independent
<duflu> greyback: CPU is sufficient. while(true); is enough to make the rest of the system smooth
<anpok> hm governors and wake locks are two competing proposals on managing system throttling
<duflu> anpok: Yes, I can see now they are separate
<anpok> wake locks in powerd, thats requestSysState?
<greyback> duflu: is surfaceFlinger doing anything special?
<greyback> anpok: yep
<anpok> greyback: android kernels do have special fds to request the system to stay awake.. and there are code paths to manage hand overs before and after ipc ..
<duflu> greyback: SurfaceFlinger is not special. We can get the same performance (or better?) with Mir in simple non-nested server testing. The challenge is how to keep parallelism and performance high in the nested scenario, because that's where we're going to sleep.
 * greyback grumbles about nested servers again
<duflu> Seems like we need more parallelism still
<anpok> duflu: hm maybe looking at lttng traces can help
<duflu> If for no other reason than to keep the system awake
<anpok> i.e. compare with and without touch interaction?
<duflu> Also, triple buffers seems to be an important factor in keeping the system busy and awake. Double (or dynamic scaling) makes it sleepy and slow.
<anpok> or is it really just that touch adds more work for the currently running process to dispatch the input events and hence keeps the cpu (and the other cores) spinning
<duflu> anpok: Yes there are many ways to trick the system into staying fast
<duflu> like while(true) {}
<alf_> mzanetti: Saviq: Is there anything more to do for silo 14, or is it "Ready for QA"?
<mzanetti> alf_, Saviq was running some tests still I think. good to go from my end
<alf_> mzanetti: ack, thanks
<duflu> It's also possible mt-cpufreq is less good at its job than others
<duflu> because doing the same things on mako and arale you can see mako scales up to multiple cores immediately. arale stutters and takes a lot of convincing before it does (mt-cpufreq)
<duflu> greyback: Any way to get Qt to thread more?
<greyback> duflu: that's a very vague question
<guest42315> :))
<duflu> greyback: I mean use more threads to do the same work, rather than doing so much in one event loop
<greyback> it has 1 thread for input & event processing, one thread for rendering
<duflu> Yeah I've gathered that
<duflu> Just being hopeful
<greyback> answer is no
<duflu> I have a prototype branch to get Mir itself to thread more
<greyback> that doesn't strike me as solving a problem. It's treating a symptom.
<greyback> using more threads to try to convince the kernel scheduler that you need more cores, to trick performance to improve
<duflu> greyback: Absolutely. However the problem seems to be compiled into the Android kernel. Not even a module with parameters we can tweak. The most you can do is convince it to wake up more
<greyback> we have the kernel source and can tweak it
<greyback> or at least understand what metrics it's using
<duflu> greyback: That's fine. I can find the source already. Unfortunately different devices are different.
<greyback> true
<greyback> but they all run android, so must have lots in common
<duflu> greyback: I don't think it's that we need to waste energy waking up, just find more points of premature sleeping (like Mir's socket send issue)
<duflu> and not sleep in those places where we need to do time critical tasks after the sleep
 * duflu tries getting some stats
<alan_g> duflu: mcphail http://unity.ubuntu.com/mir/ is back! (Work still in progress to fix properly)
<mcphail> alan_g: woohoo! Cheers
<mcphail> (no excuse for me to avoid some hacking this evening, now)
<Saviq> alf_, mzanetti, just finishing up, sorry for the delay
<mzanetti> nw... partly my fault anyways...
<alf_> Saviq: np, thanks
<davmor2> mzanetti: you don't need to accept blame any more it's all Saviq 's fault again ;)
<Saviq> davmor2, sure he does, I'm his mgr now
<mzanetti> haha
<mzanetti> yeah... all the blame will fall through directly to me now, maybe amplified a bit
<davmor2> mzanetti: hahaha
<Saviq> isn't that what being a mgr means?
<davmor2> Saviq: no it means it's all your fault you de man ;)
<Saviq> damn, I wonder if I can still reconsider...
<ogra_> davmor2, a proper manager delegates propely to his minions ;)
<davmor2> ogra_: He has to accept the blame to protect his minions, so they get to do all the work, pretty sure those are the rules ;)
<davmor2> ogra_: the delegation is only on work not blame ;)
#ubuntu-mir 2015-09-09
<robert_ancell> duflu, hey, up for some XMir volunteering?
<duflu> robert_ancell: Yes. But in a hangout right now
<robert_ancell> np
<duflu> robert_ancell: OK, now just need to finish the morning's bug triage and code review check-up
<robert_ancell> duflu, sure
<duflu> robert_ancell: OK, what's the best hardware setup (in the absence of a slimport cable and bluetooth mouse)?
<duflu> I can use a mouse on arale (USB)
<robert_ancell> I'm just sshing into my Nexus 4 and running XMir from one connection and the apps from another
<robert_ancell> I haven't got past tackling output issues
<duflu> robert_ancell: rc-proposed on mako then?
<robert_ancell> duflu, I've just been using the stable image and dist-upgrading. Then building the git branch of XMir on the phone.
<duflu> robert_ancell: Oh so you use wily?>
<robert_ancell> No, it says vivid in /etc/os-release
<robert_ancell> I've been dist-upgrading just to be newer than the OTA updates to rule out various Mir fixes.
<duflu> robert_ancell: Sorry, forgot dist-upgrade never upgrades the dist :)
<robert_ancell> I'm happy to hear other methods if there are easier ones.
<robert_ancell> duflu, yeah, worst name eva
<duflu> robert_ancell: You know wily works on mako?... in the devel-proposed channel. Just some bugs to contend with
<duflu> And wily has the latest Mir the soonest
<robert_ancell> duflu, do you think it's worth trying? We don't need wily specifically.
<robert_ancell> And these might well not be Mir issues
<duflu> robert_ancell: So long as your vivid ends up with Mir 0.15 it's not necessary
<robert_ancell> Looks like I have Mir 0.14
<duflu> robert_ancell: Before I downgrade mako for this, should I use arale instead? I can at least use a mouse on arale
<duflu> robert_ancell: Yeah 0.14 is soon going to be two releases behind. I guess the overlay's not updated yet
<robert_ancell> I have no idea what the state of arale is - but it could be useful to have a datapoint if the same issues exist there.
<robert_ancell> duflu, basically any ARM hardware is a useful dev platform to start tackling these issues.
<duflu> Actually I do have a Bluetooth Apple Magic Trackpad. Just never succeeded in pairing it to a phone
<robert_ancell> duflu, you really don't need any input devices
<duflu> Yeah I gathered that
<duflu> Trying to sacrifice arale first. As I like to reserve mako for wily testing
<robert_ancell> duflu, try it on wily
 * duflu does both in parallel
<RAOF> Sight.
<RAOF> Sigh.
<RAOF> What is the actual *failure* in https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6547/console ?
<duflu> robert_ancell: "The git branch" of XMir?
<robert_ancell> duflu, lp:~xmir-team/xorg-server/+git/xmir
<duflu> RAOF: If everything crashes like that it's possible you've broken an ABI but forgot to bump it
<RAOF> duflu: But nothing seems to have crashed? All the tests run to completion.
<robert_ancell> I compile with --enable-glamor --disable-xwayland --disable-xorg --disable-xnest --disable-xephyr --disable-xvfb
<RAOF> Oh, ho. eglflash (and, apparently, *only* eglflash) dies with a segfault on exit.
<RAOF> Intriguing.
<duflu> That sounds familiar
<duflu> Wonder why
<duflu> RAOF: Well extra datapoint: It doesn't happen to other branches right?
<RAOF> Not consistently, at least ;)
<RAOF> But I'll work under the assumption that it's hitting a real problem, at least for now.
<duflu> Fun! rc-proposed is a mixture of Mir 0.14.1 and 0.13.3
<duflu> Because libmirclient8
<robert_ancell> duflu, how can Mir solve the texture format issues? As far as I can tell they are in the OpenGL layer.
<duflu> robert_ancell: So zenity works on desktop I assume?
<robert_ancell> duflu, yes
<robert_ancell> zenity is just the "simplest X app I can run" case I'm working on.
<robert_ancell> And then some hand written trivial GTK+ apps.
<duflu> robert_ancell: It's just related work, not a complete solution. Mir 0.15 adds a new function to choose pixel formats automatically and correctly (which is a big problem for mako)
<duflu> Mir 0.15 also adds more pixel formats and massively improved texture upload support
<robert_ancell> duflu, right, the problems are in the Glamor layer - i.e. XMir is not picking the formats.
<duflu> robert_ancell: Also it's almost obvious Glamor is doing things with extensions not present on phones. I know the alternatives that do work, but need a build environment first obviously
<duflu> robert_ancell: What's the magic for running Xmir so as to avoid...
<duflu> XKB: Failed to compile keymap
<duflu> Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
<duflu> I remember hitting that before
<robert_ancell> duflu, hand on, my phone just resarted
<duflu> I'm sanity checking on desktop first
<robert_ancell> It's just couple of symlinks
<duflu> While the phone installs things
<robert_ancell> ln -s /usr/bin/xkbcomp install/bin/
<robert_ancell> ln -s /usr/share/X11/xkb/ install/share/X11/xkb
<robert_ancell> substitute where you install to and I think you have to delete the existing installed directory
<duflu> robert_ancell: Always rootless right?
<robert_ancell> duflu, no, never rootless
<duflu> Oh... ok
<robert_ancell> rootless has other issues
<RAOF> Like crashing as soon as you start xeyes :)
<robert_ancell> :(
<robert_ancell> xeyes is our number 1 feature
<robert_ancell> The killer app
<duflu> Hmm, corrupt mouse cursor on desktop
<duflu> Sometimes corrupt means invisible
<duflu> robert_ancell: OK, I've made a start thanks. Need to run to the post office and grab lunch too
<robert_ancell> duflu, ok, cool
<robert_ancell> I'll be EOD by then but I'll catch up tomorrow
<robert_ancell> duflu, fyi I just tried backporting all the glamor changes from master and it doesn't fix the crashers :(
<RAOF> Oh, fun. It is a real issue, but odd.
<robert_ancell> RAOF, hey, could you help me understand why we use DRI2 and not DRI3?
<RAOF> robert_ancell: Intel driver had some problems with it at some point.
<robert_ancell> RAOF, for Mir I mean.
<RAOF> We don't use DRI at all for Mir?
<robert_ancell> Last I heard it was due to buffer allocation.
<RAOF> Oh, you mean for XMir?
<robert_ancell> RAOF, so Glamor provides DRI3 by default, but we've disabled that and copied over the DRI2 code
<robert_ancell> yeah
<RAOF> Right, allocation issues.
<RAOF> Specifically: in DRI3 the client allocates their buffer and tells the server about it. We've no support for that in Mir; clients use the buffers Mir sends them.
<robert_ancell> RAOF, can DRI3BufferFromPixmap not be used to do server side allocation?
<RAOF> That's not how DRI3 clients - specifically mesa - use it.
<robert_ancell> or does that only return a buffer if the pixmap was created with DRI3PixmapFromBuffer
<robert_ancell> RAOF, we can't stop Mesa direcly allocating buffers anyway can we?
<RAOF> We can, and do; DRI2 uses server allocated buffers.
<robert_ancell> i.e. a GTK+ app running inside Mir can happily grab buffers from the Intel driver
<RAOF> Right, but the GTK+ app can't set that as the surface buffer.
<RAOF> (This might actually change with the New Buffer Semanticsâ¢, in which case we'd just do DRI3 as-is)
<robert_ancell> That would make life easy
<RAOF> Yes, it would, wouldn't it.
<robert_ancell> So I guess we need to wait to see the result of that before doing much.
<robert_ancell> Because I figure DRI3 could do what we want, as long as Mesa knew it was in a "use DRI3BufferFromPixmap not DRI3PixmapFromBuffer case"
<robert_ancell> But that would require proposing a DRI3 change
<robert_ancell> And I think we'll have trouble convincing Xorg to take XMir with all the DRI2 code copied.
<RAOF> I'd raise client-allocated buffers at whatever stakeholder meeting you can get to.
<RAOF> Yeah, DRI2 is not the new hotness.
<RAOF> XMir has *always* wanted client-allocated buffers; they'll make it much simpler because you're not fighting X's normal desire to allocate.
<robert_ancell> OK, I guess I'll raise this with Will / Kevin that we're kind of blocked carrying XMir until we decide if we can do DRI3 / new buffer stuff.
<RAOF> A bunch of the NBS stuff has landed, but client-allocated buffers is an additional change on top.
<robert_ancell> I might also look at upstreaming XMir minus the DRI code and then we can solve that later.
<RAOF> One that should be easy, because NBS will have cleared the path, but still something that needs to happen.
<robert_ancell> RAOF, is there a bug for this feature?
<RAOF> robert_ancell: No
<robert_ancell> RAOF, so what is the client side feature - Mir will support both methods where possible?
<robert_ancell> client allocated I mean
<RAOF> robert_ancell: So, the NBS is that clients have a direct handle on their buffers; as it currently stands they still call into the server to allocate, but once they've received the handles they have the handles and can submit them in whatever order they want, etc.
<RAOF> The obvious extension is to not call into the server, and instead have a mirclient function that takes an already-allocated buffer; a dma-buf + some metadata like size, stride, etc.
<robert_ancell> RAOF, and that only works on the desktop drivers?
<RAOF> You could probably get it to work on the android side as well, but I'm less familiar there.
<robert_ancell> RAOF, I'm really struggling to work out what the original reason was for server side allocation
<RAOF> There are a bunch of optimisations you can do with it.
<robert_ancell> And they don't matter anymore?
<robert_ancell> And the optimisations are better than a well behaved client?
<RAOF> Well, *everything* is equivalent with a perfectly-behaved client.
<robert_ancell> So we were just taking responsibility for the clients optimisations
<robert_ancell> And now we will offer two methods - the easy one of using server side allocation and the harder one of doing the allocations yourself.
<robert_ancell> Can Mir deallocate a buffer the client allocated?
<RAOF> No
<RAOF> Well, ish.
<robert_ancell> Is that the major downside of letting the client do it? A bad client might starve the buffers?
<RAOF> It requires less communication with the client to get good behaviour.
<robert_ancell> RAOF, ok, thanks. I think I understand better.
<RAOF> Any optimisation the server might want *can* be done by sending a message to the client instead and having the client do the equivalent thing.
<robert_ancell> RAOF, as long as the client hasn't gone rogue and is no longer listening to messages from the server.
<RAOF> Right. And if you're doing that then any *new* optimisation you might want to make may require a whole new set of clients.
<RAOF> Because you might need to send a new message, etc.
<robert_ancell> RAOF, but it would be wrapped up in libmirclient right?
<RAOF> Not necessarily.
<RAOF> It'd probably be wrapped up in libEGL, though.
<RAOF> Slash XMir.
<robert_ancell> Right, so it would be clients(n) where n is a small number and likely under the same development control as Mir.
<RAOF> You'd get almost all of the way with EGL, GTK, Qt, SDL and XMir, yeah.
 * RAOF is not particularly invested in server-side allocation
<robert_ancell> I'm particularly annoyed by server-side allocation...
<robert_ancell> RAOF, thanks again, heading off now.
<RAOF> I'm not entirely sure that you'll be able to escape it on android, though.
<RAOF> Raise it with kdub!
<RAOF> robert_ancell: Have a fine evening!
<robert_ancell> bye all
<bschaefer> RAOF, do you see this crazyness? Or understand it?
<bschaefer> https://code.launchpad.net/~mir-team/mir/attestable-timestamps-client/+merge/270470
<bschaefer> somehow *.moved files got added to my MP (i dont remember adding it)
<bschaefer> then i bzr rm the moved files only
<bschaefer> diff showed that was fine, now its showing the files as added/removed?
<RAOF> *.moved implies a merge conflict at one point.
 * bschaefer grabs a fresh branch to check the damage
<bschaefer> RAOF, right which i resolved
<RAOF> Ooooh, yeah.
<RAOF> I suspect you've run into bzr's tracking of renames.
<bschaefer> usually when theres a *.moved file you just need to pick one
<bschaefer> eww
 * bschaefer guesses i need to edit something in /.bzr
<RAOF> Specifically - each file gets an inode which is independent of the filename, so you *can* both remove and add a file at the same time :)
<bschaefer> RAOF, haha.... hmm
<bschaefer> RAOF, i wonder if the *.moved files were being re-generated
<bschaefer> when i pushed the branch and said it was a child of the server branch...
<RAOF> *Was* it a child of the server branch?
<bschaefer> RAOF, well i merged the server branch into a fresh mir branch
<bschaefer> commited that, then merged the old attestable branch
<bschaefer> fixed conflicts
<bschaefer> then pushed that branch as the split between the two
<o> hi all
<bschaefer> RAOF, how else would you normally split a branch? I suppose ... i should have just added the changes to the server branch
<RAOF> bschaefer: Frankly? The normal way that I'd split a branch is to clone it into git, do a bunch of rebasing, and then push.
 * bschaefer doesnt know git well enough
<bschaefer> RAOF, i know bzr better :)
<RAOF> Bzr does *not* make splitting branches a sensible operation.
<bschaefer> which as it turns out isnt good enough
<bschaefer> :(
<bschaefer> RAOF, i was just imagining a nice split where the server changes would already be commited then i would commit the difference
<bschaefer> into a new branch
<RAOF> Well, it *can* be; if *all* the server changes occur before *all* the client changes then you can just branch from the point that it switches...
<bschaefer> RAOF, i think ill just put the client code on hold
 * duflu learns about git for launchpad and the world gets better
<bschaefer> until server merges
<bschaefer> then rebase vs trunk
 * bschaefer starts learning git
<RAOF> Yeah, that might help. Rebasing in bzr basically isn't supported.
<RAOF> It's somewhat opposed, philosophically.
<bschaefer> yeah, trunk is always kind to me, or rather a frash branch :)
<bschaefer> RAOF, cool, ill just make a comment on the branch that it'll be fixed but you can still review the code...
 * bschaefer goes away for the night
<RAOF> Urgh. Our example of creating decorations is all manner of wrong.
<RAOF> Or, at least, awkward for me :)
<anpok_> RAOF: is Danger 5 really a thing in australia?
<RAOF> anpok_: Define âa thingâ
<anpok_> popular?
<RAOF> Moderately?
<RAOF> Certainly among a certain demographic.
<RAOF> But generally? I don't think it's a mainstream thing.
<anpok_> humm what could cause the cross compile to fail with: src/protobuf/mir_protobuf_wire.pb.cc:174: undefined reference to `google::protobuf::io::StringOutputStream::StringOutputStream(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)'
<RAOF> anpok_: C++ std::string ABI issues.
<RAOF> ?
<anpok_> ahh i was using gcc 5 with a vivid cross environment
<anpok_> thx
<RAOF> Ba baw!
<anpok_> aye and multistrap works with phone overlay \o/
<duflu> anpok_: cross-compile-chroot.sh -d vivid fixes that
<anpok_> duflu: well not if you then go and selsect CC_VARIANT=-5 :)
<anpok_> -s
<duflu> Bad anpok_
<duflu> anpok_: BTW it's changed names. You should pull from lp:mir
<zzarr> hello! I installed ubuntu-lxc on a computer running Wily today, but it hangs on login, it seams to be a common problem, is there a solution?
<duflu> zzarr: This is probably the wrong channel. Try #ubuntu-desktop. Although that's probably not the best one either
<zzarr> duflu, I know, but I thought as it's a mir related question I'd ask here
<zzarr> is #ubuntu-devel a better place to ask?
<duflu> I think so
<zzarr> I'll try
<zzarr> I realized I wrote the wrong name on the package, it sould be unity8-lxc
<duflu> zzarr: Ah ok, then try #ubuntu-unity
<duflu> or #ubunt-touch
<duflu> because that's where unity8 people live
<zzarr> okey, thanks
<Guest30312> zzarr, and you are right on time, usually they pop up on the channel at this hour
<zzarr> nice, thanks to you too
<Guest30312> :P
<anpok_> .. our cross compile ci run, does it run tools/setup-partial-armhf script or just the cross-compile-chroot script?
<anpok_> ah ok the latter
<anpok_> alf, alan_g: where is the cross compile ci job defined?
<anpok_> is there a bzr repository with the script?
<alan_g> anpok_: IIRC You need to poke around the Jenkins job definitions to find it. (And since I can't get the VPN working I can't look at those currently)
<tedg> bregma: Is there any chance of getting a Mir snap that would work with the RaspPi2 touch screen?
<bschaefer> tedg, mir doesnt work on raspi :(
<bschaefer> not at lease the last time i tested it out
<bschaefer> since raspi2 doesnt support/have /dev/dri and doesnt support software rendering and does use (something else? atm)
<bregma> tedg, no
<bregma> tedg, it has to do wit hthe rendering path through Mesa, er sumpin'
<bregma> there is a queued work item to get that working, prolly in the 0.17 release
 * bschaefer would enjoy that as well
<RAOF> bregma, tedg: You could also prod foundations/kernel to get the open-source rpi2 drivers enabled - http://dri.freedesktop.org/wiki/VC4/ :)
<bschaefer> RAOF, thats the only issue?
<bschaefer> o yeah that would make it work
<RAOF> :)
#ubuntu-mir 2015-09-10
<robert_ancell> duflu, how does mir_pixel_format_xrgb_8888 and mir_pixel_format_bgr_888 have the red channel in the same location?
<robert_ancell> Where are the pixel formats defined?
<duflu> robert_ancell: common.h ... the 32-bit formats are designed to be expressed as uint32 whereas the 24-bit formats are three bytes. So for little endian they are the reverse
<duflu> That said, I'm not sure X can deal with the latter at all
<robert_ancell> very confusing
<duflu> We use endianess like that so software apps using 32-bit formats don't need to ever do byte swapping to work on any machine.
<duflu> robert_ancell: Yes, but it makes sense and is the best option if you think about it. The alternative is that every app would need #ifdef for different endianness
<duflu> Unfortunately endian does not apply to 3 byte pixels. It makes no sense there
<duflu> BTW, I did not design it that way. It was like that before I/we joined Mir
<duflu> And it seems like the right solution too. Just confusing when dealing with some APIs like OpenGL that do the opposite
<robert_ancell> duflu, so your branch corrects the wrong masks right? The rest of it is just code moved around.
<duflu> robert_ancell: Yes, and it ensures everything (screen and windows) agrees on the format of TrueColor pixels
<duflu> Although it's still not ideal for EGL. More work is required there
<robert_ancell> duflu, btw we do know that software mode works - the goal is to get EGL to work
<duflu> More importantly, I've now done an MP in git-for-launchpad :)
<robert_ancell> duflu, yeah, well done!
<robert_ancell> duflu, you can just push into the xmir branch
<duflu> robert_ancell: Yes, software has always worked. Although the upload/copy operations in software are slowish, rendering the same in OpenGL arguably uses even more resources. And OpenGL needs the buffer held for longer. The only problem is some droids (and I noticed it on mako) sometimes corrupt software buffers on screen. That's usually a flags bug in the Mir android code
<robert_ancell> duflu, what do you mean by "uses even more resources"?
<robert_ancell> Software mode seems poor when resizing windows, I'd expect that to be faster in OpenGL right?
<duflu> robert_ancell: Both rendering approaches require an "upload" or copy of the whole surface. However there's no OpenGL state and texture to worry about in software
<duflu> robert_ancell: Yeah some things will be faster in GL on some devices. But there's not a huge difference if your apps are software rendering in the first place
<robert_ancell> duflu, so, do you think getting EGL to work is a waste of time?
<duflu> robert_ancell: No, I think EGL will be faster for some things and we should do it
<duflu> Even the upload itself may be faster in some GL implementations
<duflu> robert_ancell: It's satisfying being able to play /usr/games/sol on the phone :)
<robert_ancell> heh
<duflu> robert_ancell: Theoretically rootless should let us skip a copy completely. Because the X server no longer has to composite its apps in software into the screen surface. But I don't know the reality of the implementation. That's just theory.
<robert_ancell> duflu, yeah, I guess
<duflu> robert_ancell: BTW found a simpler solution to the xkb problems. Just configure with --prefix=/usr
<duflu> So it finds everything in the right place
<robert_ancell> duflu, and you can then run without installing?
<duflu> robert_ancell: Yep, no installation
<robert_ancell> sweet
<duflu> Sweet unless there's an ABI break
<duflu> But I don't think Xorg does ABI breaks much
<RAOF> Xorg breaks ABI every release.
<RAOF> Not quite, but very nearly.
<RAOF> Hm. That's got to be a gcc bug.
<RAOF> auto foo = [this]() { return display_config; }; foo().active_configuration(); blows up.
<RAOF> auto foo = [this]() -> mg::DisplayConfiguration const& { return display_config; }; foo().active_configuration(); works as expected.
<bschaefer> RAOF, how is 'this' actually defined? Just a pointer to the class right? (raw c pointer?)
<bschaefer> nm what i was thinking makes no sense (was thinking something with a std::unique_ptr)
<RAOF> Yeah, âthisâ is a keyword meaning âpointer to the implicit first parameter of the function callâ :)
<bschaefer> RAOF, yeah was trying to find the actual definition in the standard but 'this' is an over used word :)
<RAOF> Ok, wtf?
<RAOF> How is DefaultServerConfiguration::configuration_options being set to a non-null value in the constructor, but then the_options() SEGVing because configuration_options contains null?
<duflu> Cosmic rays
<RAOF> Hm, or slicing?
<RAOF> $1 (this) = (mir::DefaultServerConfiguration * const) 0x1c44e10
<RAOF> (Contains correct value)
<RAOF> $4 (also this) = (const mir::DefaultServerConfiguration * const) 0x1c44e10
<RAOF> Oh, no. That's the same value.
<RAOF> It looks different in gdb :)
<RAOF> Watchpoint it is.
<Guest44551> duflu, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1493185
<ubot5> Ubuntu bug 1493185 in unity8 (Ubuntu) "missing icons in dash/app scope for ubuntu touch vivid image" [Undecided,New]
<duflu> Guest44551: Thanks. Sounds like the ubuntu UI toolkit (that is shader heavy and sometimes the least portable part)
<Hock> anyone looking into it?
<duflu> Hock: I will reassign it. Can you attach a screenshot? That URL does not work..!?
<duflu> Hock: The relevant people log on in a couple of hours
<duflu> They should notice it
<Hock> i attached it
<Hock> i submitted this bug two days ago. :(
<duflu> Hock: Thanks. I just checked the source code. Looks like ubuntu-ui-toolkit. It's possible you'll get a better response now it's assigned to the right project today
<Hock> duflu, great! thanks
<duflu> Hock: We had a similar issue recently. ubuntu-ui-toolkit is ambitious, sometimes to the point of non-portable
<Hock> this will not be related to gralloc hal crashing using CM kernel, right?
<duflu> Hock: No, your kernel unity8 and Mir seem to be working fine
<Hock> this is fine as its on aosp kernel
<Hock> when i tried using CM kernel, the gralloc refused to start.
<Hock> just died
<duflu> Hock: Nice working getting that far
<duflu> *Nice work
<Hock> nice. but still long way to go
<duflu> I'm not so sure it's a long way
<Hock> wifi doesnt work as the stock kernel does come with source
<Hock> its binary wlan.ko
<Hock> have been trying a few prima sources but insmod hung
<Hock> and wlan0 does not get created
<Hock> CM kernel cant be used as their gralloc dont play nice with ubuntu touch
<Hock> anyway hint on how to get cm gralloc to work?
<duflu> Hock: Don't know. If you don't get a response within a day then the person is:  https://launchpad.net/~loic.molinari
<duflu> For the bug that is
<Hock> ok.
<Hock> how can I tell the verion of mir that I am running on?
<Hock> version
<duflu> Hock: dpkg -l | grep libmir
<duflu> But Mir is working (or else many things would have failed before the screen got painted that much even)
<Hock> 0.13.3+15.04.20150617-0ubuntu1
<Hock> libmirclient9:armhf                                  0.14.1+15.04.20150821-0ubuntu1
<Hock> mixed of 0.13 and 0.14
<duflu> Hock: Sounds like vivid (which is presently a mix of 0.14.1 and 0.13.3, the latter is for some clients that haven't been updated)
<Hock> yes, mir is working. just the icons
<Hock> yes, i switched back to vivid
<Hock> going to wily does not solve the icons issue
<RAOF> Ok, that's weird.
<RAOF> If you call the_frontend_display_changer() from the_session_coordinator(), Mir crashes.
<RAOF> OH!
<RAOF> Because there's a cycle there.
<RAOF> Nice of ABSOLUTELY NOTHING AT ALL to notice a stack overflow.
<tedg> RAOF: Is there a reason that those are needed over the binary blog that the RaspPi folks are using?
 * ogra_ shkes fist towards provider ... 
<ogra_> tedg, kms support perhaps ?
<ogra_> the binary blob is used in any case, you cant boot the board without it
<ogra_> (the bootloader is contained in the blob)
<tedg> Yeah, not sure. I just want Mir on my RPi2 :-)
<ogra_> i dont think we have all needed userspace for the closed driver either yet (libEGL, libGLES etc)
<tedg> So perhaps that is the Mesa work that was mentioned.
<ogra_> yeah
<attente> AlbertA: hi, i'm just wondering if you had a chance to think about how we can implement GtkComboBox behaviour using Mir menu surfaces
<AlbertA> attente: not quite just got back from vacation
<attente> AlbertA: oh, sorry. welcome back!
<dandrader> is mir-platform-graphics-mesa-x4 meant for use in xmir? or is it something else?
<kgunn> dandrader: that might be mir on x
<kgunn> camako: ^
<dandrader> my test laptop (vivid+overlay) is strange after I dist-upgraded and thus got mir 0.15. Some things are not working anymore. Not sure what I messed up. I tried to clean up all traces of mir 0.14 pakages. now at least I can get "sudo mir_proving_server" working
<dandrader> but when I try to run a client, it fails to connect. eg running mir_demo_client_egltriangle  gives a "Can't get connection" failure
<dandrader> I made sure I had MIR_SOCKET=/tmp/mir_socket set
<anpok> dandrader: thats for running mir within x
<dandrader> so, how do I start debugging that?
<dandrader> anpok, ok, so I can safely ignore this
<anpok> hm that should be MIR_CLIENT_SOCKET=
<dandrader> so my mir_demo_client_egltriangle is giving a "Can't get connection" error message when I try to run it in my mir_proving_server. how do I start debugging this?
<anpok> and --arw-file to ensure that the permission .
<anpok> is open enough for other users
<dandrader> anpok, yeah, did "sudo chmod a+rw /tmp/mir_socket" as well
<dandrader> anpok, what client-side env vars should I set to get some logging explaining what's going on?
<dandrader> anpok, or is it really a very basic error where logging wouldn't help anyway...
<anpok> hmm dandrader, tried to reproduce but I my vivid vm now has problems with egl..
<anpok> dandrader: MIR_SERVER_SESSION_MEDIATOR_REPORT and _CONNETION_REPORT = log are the most basic logs for server interactions
<anpok> sorry CONNECTOR_REPORT
<dandrader> anpok, but that's on the server side. any env var I could set on the client side?
<anpok> there is MIR_CLIENT_RPC_REPORT..
<anpok> but not sure what do read out of it
<dandrader> the issue seems to be on the client side. like it's not really finding the socket file. so I would like to know what exactly is the filename + path it's trying to use
<anpok> strace hmm
<dandrader> anpok, thanks for the strace tip. good one
<dandrader> anpok, so the problem seem indeed server side: http://paste.ubuntu.com/12330409/
<dandrader> anpok, what do you make of this exception?
<anpok> hm try fingerpaint?
<dandrader> it's like client process ended suddenly or something
 * dandrader tries
<dandrader> anpok, ah, interesting. it gives more output
<dandrader> anpok,  http://paste.ubuntu.com/12330431/
<dandrader> anpok, seems I'm missing some package :)
<dandrader> I do have  a /usr/lib/x86_64-linux-gnu/mir/client-platform/mesa.so.2
<dandrader> which seems to come from a local build of mir 0.14...
 * dandrader installs mir-client-platform-mesa3
<dandrader> great! now it finally works!
<dandrader> anpok, thanks for the help!
<RAOF> tedg: Right. The bits that are needed are kms (modesetting), EGL-on-KMS (Mir rendering), and EGL hooks (client rendering).
#ubuntu-mir 2015-09-11
<duflu> That's confusing...
<duflu> mir (0.15.1+15.10.20150903-0ubuntu1) wily; urgency=medium
<duflu>   [ Kevin Gunn ]
<duflu>   * released-rebuild-for-vivid-overlay
<duflu>  -- CI Train Bot <ci-train-bot@canonical.com>  Thu, 03 Sep 2015 18:50:01 +0000
<duflu> but also doesn't change anything
<robert_ancell> duflu, does XMir crash immediately when you launch it on a Nexus 4?
<duflu> robert_ancell: Yeah, but I'm pretty sure I know why. I'll test and fix that today
<robert_ancell> duflu, I'm wondering why I don't see that
<duflu> No idea why your vivid would work cos it's the same package.
<robert_ancell> perhaps you have newer drivers
<duflu> robert_ancell: It might be you have an older kernel and your GLES version is < 3.0
<duflu> That would make epoxy skip over the problem
<robert_ancell> glamor GL version: OpenGL ES 3.0 V@53.0 AU@  (CL@) according to the log
<robert_ancell> duflu, do you know how to get XMir to dump core on the phone? It seems ulimit -c unlimited doesn't help.
<duflu> robert_ancell: It's a Xorg thing and I forget...
<robert_ancell> And I love how that log message always says "dumping core" regardless of if if actaually does
<duflu> robert_ancell: Yes it's dumping with a limit of zero
<robert_ancell> I guess that's technically true
<duflu> robert_ancell: The "dumping" message would come from libc or something, userspace. But the actual dumping is a kernel operation. So blame libc for not checking the kernel setting
<robert_ancell> yeah, it's libc
<robert_ancell> The -core flag is supposed to dump core but still not getting any core files
 * duflu wishes nobody ever stripped debug symbols. Although that would require abandoning bloaty things like C++
 * robert_ancell wishes we'd abandon C++
<duflu> Well Microsoft kind of did. Apple completely did. Google mostly did. But you'll find small traces of C++ in all of them
<duflu> -completely +mostly
<RAOF> Even C is often much much bigger with debug symbols.
<duflu> RAOF: Yes but much bigger C is still single digit bloat. C++ is often double or even triple digits (1-2 orders of magnitude)
<duflu> robert_ancell: I'll confirm today but it might be uninitialized memory. So zero for me gives a nice crash. You however might have got some readable bytes, which would let it keep going since it's just doing strcmp
<robert_ancell> zero what?
<duflu> robert_ancell: Zero result from glGetStringi
<duflu> NULL
<robert_ancell> duflu, I'm getting your crash now, but only after updating to get your colour fixes
<duflu> robert_ancell: Probably not related but also uninitialized memory issues would move with different logic. I'll confirm soon
<duflu> I was getting the same crash before that fix
<robert_ancell> yeah, I'm thinking something like that. The changes don't seem likely to cause the problem.
<robert_ancell> ok
<duflu> robert_ancell: This is annoying. epoxy is doing the right thing only calling GLESv3 functions after it confirms the version is >= 3.0. And hybris is doing the right thing, only claiming to export GLESv2 functions (which unfortunately for mako report their version as 3.0)
<duflu> We need to break one of them
<robert_ancell> duflu, how is mako reporting gles?
<duflu> robert_ancell: The mako driver lives in /android and libhybris proxies into it with its own libGLESv2.so
<robert_ancell> duflu, which part is saying it does 3.0?
<duflu> robert_ancell: The log message on startup :)
<duflu> From the GL version string
<robert_ancell> duflu, why don't we make hybris export 3.0?
<duflu> robert_ancell: Because it's structured to implement v1 and v2 separately. Adding v3 under that structure is a very large undertaking
<robert_ancell> duflu, ok, but that sounds like the correct solution right? Instead of breaking one thing.
<duflu> robert_ancell: It would be a silly investment of a large amount of time to implement all of v3. I'd rather stick the one v3 function we need in the v2 implementation. Or work around elsewhere
<duflu> Our code actually links to GLESv2. It's just because epoxy queries things dynamically that we find it using v3 functions
<duflu> Actually fixing epoxy to limit its efforts to GLESv2 might be more sane
<duflu> Yes, I will do a one line mod to epoxy so it will never crash when used with hybris...
<duflu> RAOF: If I want to add an Ubuntu-only patch to a package that is still "copied from debian sid", who do I talk to?
<robert_ancell> duflu, you just need anyone with appropriate upload permissions
<robert_ancell> duflu, do you want to patch libepoxy?
<duflu> robert_ancell: Lemme check it works first ;)
<duflu> robert_ancell: Success! It now fails later, the same as on desktop with -egl
<duflu> Although I might need a second epoxy fix for that. Let's see
<duflu> robert_ancell: Here tis. This might change what you see too:  https://bugs.launchpad.net/ubuntu/+source/libepoxy/+bug/1494240/comments/4
<ubot5> Ubuntu bug 1494240 in xorg-server (Ubuntu) "Xmir crashes immediately on startup using glamor on Nexus4" [High,In progress]
<robert_ancell> duflu, ta
<robert_ancell> duflu, it looks like GLES3 uses libGLES2.so so it's probably not hard to add a few new wrapped functions in hybris
<duflu> robert_ancell: Not worth the effort. The epoxy fix is logically correct for any GL version. So is safe to keep
<robert_ancell> duflu, excepts it's a patch that will never be accepted  upstream
<duflu> robert_ancell: We could modify it to delete the unnecessary redundant (and crashing) code. That would also be correct
<robert_ancell> duflu, which code is crashing?
<duflu> robert_ancell: The strcmp after glGetStringi
<duflu> robert_ancell: It's an Ubuntu-specific problem. I'm happy to make it an Ubuntu-only patch, or generalize a proposal to upstream under the title of "add support for libhybris" (which is not Ubuntu specific)
<robert_ancell> duflu, but I don't get why we don't just make hybris wrap glGetStringi
<duflu> Although I suspect more libepoxy fixes will be required first
<robert_ancell> Then everything will just work right?
<duflu> robert_ancell: Yes, but that's uglier and less correct. You're adding v3-only function to something that only claims to support v2
<duflu> Using glGetString instead of glGetStringi works for all versions. Nice and cleanly
<duflu> Also, I think we might need to make additional patches to libepoxy's extension maps, unrelated to this
<duflu> So can't escape needing to patch libepoxy
<duflu> A third reason is it would help Mir a lot. But Mir can't use it till we fix it
 * robert_ancell -> EOD
<Mirv> is greyback on holidays? I now got the total hang on my personal use krillin again and filed bug #1494692 (I'll fill in more later)
<ubot5> bug 1494692 in mir (Ubuntu) "Total hang of the krillin with a graphics artifact" [Undecided,New] https://launchpad.net/bugs/1494692
<Mirv> (ok, yes he is)
<kgunn> alf_: did pat's new log help any on that sms-freezes ui bug ?
<alf_> kgunn: I am going to look into that in a bit, I wanted to first publish the voice call blanking improvements
<alf_> kgunn: feel free to try out https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+packages
<kgunn> sure
<kgunn> alf_: pat has a special love for us...did you see he logged another
<kgunn> https://bugs.launchpad.net/bugs/1494513
<ubot5> Ubuntu bug 1494513 in unity-system-compositor (Ubuntu) "When a message is received while the screen is dimmed it does not restore full brightness" [Undecided,New]
#ubuntu-mir 2016-09-15
<alan_g> RAOF: Did I answer your "Needs Info"? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599
<duflu> alan_g: Just a bit past his EOD
<alan_g> Oh well...
<alan_g> duflu: you picked up the crash releasing egl resources. You have an idea what's broken?
<duflu> alan_g: Only started on it 15 seconds ago. Will comment soon if at all
<duflu> Feels familiar but not sure why
 * alan_g wants it NOW!! ;)
<RAOF> Oh, I didn't respond to that.
<duflu> Launchpad times out and becomes unusable
<duflu> Must be morning in Europe
<duflu> alan_g: I can't update bugs right now as LP times out. But it's just another Mesa 12.0.2 regression. 12.0.1 works
<alan_g> duflu: I suspected as much, thanks
<duflu> No problem. I still had the old debs handy from the other regression
<duflu> alan_g: If LP works for you please just duplicate to https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1620994
<ubot5> Ubuntu bug 1620994 in mesa (Ubuntu) "EGL clients with SIGSEGV in dri2_destroy_context() (from eglDestroyContext or eglTerminate)" [Undecided,New]
<alan_g> duflu: timing out just now. Will try again later
 * duflu is glad that's not a geographical failure
<duflu> Saviq: Are you confident it's just Mir missing a rebuild against protobuf3? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1621746
<ubot5> Ubuntu bug 1621746 in mir (Ubuntu) "Black Screen, libprotobuf FATAL program was compiled against version 2.6.1 which is not compatible with the installed version (3.0.0)" [Critical,Confirmed]
<Saviq> duflu, I just meant that was a requirement, didn't know whether it was enough
<duflu> Saviq: OK well I believe alan_g already released the protobuf fix that we were waiting on
<duflu> Just need the powers that be to rebuild
<duflu> Who/wherever they are
<alan_g> Saviq: duflu I gave doko a patchfile. AFAIK everything was fine after that
<duflu> alan_g: It got released a while ago according to distro
<duflu> Umm a weekago it hit proposed I mean: https://launchpad.net/ubuntu/+source/protobuf
<duflu> Not sure *which* fix that was
<duflu> It's a miracle. I have time to work on Xmir too
<Saviq> duflu, it was the protobuf rebuild fix, that's in proposed for sure
<duflu> Oh, cool
<Saviq> 'cause we couldn't build u-s-c before
<Saviq> now we could
<duflu> That might be it
<alan_g> greyback_: Did I answer your "Needs Info"? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599
<greyback_> alan_g: yep, no objection here
<alan_g> kdub: can you explain what you're asking? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599/comments/790524
<greyback_> alan_g: "alam@octopull.co.uk" <- typo in your commit message email - in case you've it set up somewhere
<alan_g> greyback_: Oops
<alan_g> Thanks
<kdub> alan_g, with the second part,  I didn't see why we had to have the reference that header from the top-level directory
<kdub> and for the 1st part, that explanation makes sense, but wasn't obvious to me from reading the headers (as my guess was incorrect)
<NotKit> are there any specific hacks needed for hwcomposer on PowerVR MediaTek devices?
<alan_g> kdub: so the first part is answered by -r 3706?
<kdub> alan_g, sure
<alan_g> For the second part, that's consistent with what we do elsewhere.
<kdub> well, why is it needed? (might find out for myself in a minute, compiling now)
<alan_g> A lot of IDEs (including CLion that RAOF and I use) like project headers to be mentioned in the CMakeLists.txt files. We've been adding them for the last year or so.
<NotKit> http://pastebin.com/deuQ3VEC - logcat
<kdub> alan_g, ah, news to me
<kdub> alan_g, alright, lgtm then
<alan_g> kdub: RAOF and I thought no-one would even notice, so we didn't tell anyone.
<kdub> alan_g, yeah, I don't mind as long as it has some purpose
<alan_g> I *think* qtcreator likes it too, but it has been too long since I started it up to be sure
<kdub> I'm still laboring under vim
<alan_g> I use that a fair bit too
<alan_g> But it is really nice to have a key-combo to build and run/debug just the test you're editing
<kdub> yes, that does sound handy
<alan_g> There's a lot of "understanding the language" stuff it makes easy. (A lot of textual manipulation stuff sends me back to vim)
<kdub> yeah, will give it a try
<kdub> there's only so many vim scripts one wants to write
<anpok> did notice .. and thought - oh so visual studio isnt the only ide that needs that..
<alan_g> attente: do you want to discuss further? Or shall we land this version? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599
<attente> alan_g: yeah. sorry, i didn't see the follow up
<alan_g> attente: are you content with the current proposal?
<attente> alan_g: how amenable is it to change? i still want the extra intermediate rectangle, so it would only be an api addition from here
<alan_g> attente: adding another rectangle (and query for it) wouldn't break ABI. But I don't know what to put in it.
<alan_g> So I guess we can land and discuss further
<attente> alan_g: sounds reasonable, thanks. if you land it, i'll see if it's sufficient enough for gtk to infer the information it needs
<alan_g> attente: OK. Meantime I can start adding in the "anchor to surface" constraints.
#ubuntu-mir 2017-09-14
<alan_g> xnox: does this look reasonable to you? https://code.launchpad.net/~raof/mir/more-packaging-tweaking/+merge/330642
<xnox> alan_g, reviewed, +1
<alan_g> xnox: thanks!
#ubuntu-mir 2017-09-15
<alan_g> greyback: workarounds for compiler bugs are usually weird
<greyback> alan_g: yep, I'm not disagreeing :)
