#ubuntu-mir 2013-05-20
<thomi> ugh
<thomi> it's so easy to lock up the latop when working with mir
<thomi> robert_ancell: is there some magic "kill mir_demo_server" keystroke?
<robert_ancell> thomi, ctrl+c (is sent through to the console). Or alt+ctrl+backspace if that branch landed..
<thomi> robert_ancell: neither seem to be working for me
<robert_ancell> and you can't vt switch away from it?
<thomi> nope
<robert_ancell> it could be mir_demo_shell only has the alt+ctrl+backspace support and there's no escape from mir_demo_server (unless you ssh in)
<thomi> I just have a black screen
<robert_ancell> I'll just check the recent history
<thomi> robert_ancell: OK, ssh fixed it
<robert_ancell> that branch hasn't landed so Ctrl+C / alt+Fn should be working
<thomi> robert_ancell: should I be running mir_demo_server or mir_demo_shell? what's the difference?
<robert_ancell> thomi, mir_demo_server is the trivial server, and mir_demo_shell has some shell like behaviour
<robert_ancell> for testing, mir_demo_server should be good
<thomi> ok
<robert_ancell> though mir_demo_shell is/will be more usable for playing around with
<thomi> urp - I get a segfault inside MirConnection::connect(...)
<robert_ancell> which client?
<thomi> robert_ancell: I don't understand the question - this is in the mir stress test code
<thomi> any ideas? http://pastebin.ubuntu.com/5682538/
<thomi> I know it doesn't crash if the mir demo server isn't running, although that's not very useful
<robert_ancell> nothing on stderr/out?
<robert_ancell> where is your client code?
<thomi> nope
<thomi> not currently pushed anywhere
<thomi> just pushed it to lp:~thomir/+junk/mir-stress
<robert_ancell> ok
<thomi> literally all it tries to do is fire up a single thread, and in that thread, connect to the mir server
<robert_ancell> I think you need to set the app name (http://unity.ubuntu.com/mir/group__mir__toolkit.html#gaf8c65b7597fc560616747cf259dcc045)
<robert_ancell> you set it to 0
<robert_ancell> Silly C++ not being able to tell the difference
<thomi> ahaaaa
<robert_ancell> because that string is passed to the server
<thomi> robert_ancell: so... my mir stress test breaks the demo_server
<thomi> robert_ancell: with four threads connecting & disconnecting simultaniously, I get this: http://pastebin.ubuntu.com/5682684/
<robert_ancell> thomi, well, I guess that's good in a way?!
<thomi> Assuming I haven't make a mistake in my code, yes
<thomi> oooh wait...
<thomi> I think I'm passing the same application name
<thomi> does that have to be unique?
<robert_ancell> I think it's just a tag on each connection, but it's not checked for uniqieness
<robert_ancell> It might be a good idea to give each thread a name though
<thomi> well, I'll make sure that's unique to the thread, and see what happens
<robert_ancell> (it's just passed up to the shell and it can decide what ot do with it)
<thomi> robert_ancell: so am I right in thinking that the client library is what is used by the GUI toolkits (Qt, Gtk etc) in order to render in  a mir-shell?
<robert_ancell> yes
<thomi> robert_ancell: do you know of any restrictions around the number of client connections that can be made per process?
<thomi> I'm using multiple threads to try and break mir, but I wonder if that's a valid test at all - maybe I should be using multiple processes instead
<thomi> like, maybe the mir server code assumes a process will only connect once
<robert_ancell> I'm not sure off hand. Multiple processes would certainly be safer
<thomi> robert_ancell: who should I ask about this?
<robert_ancell> thomi, alan_g or alf are good candidates
<thomi> ok, thanks
<robert_ancell> thomi, ok, I'm off until next week, good luck!
<thomi> robert_ancell: you too !
<robert_ancell> thomi, oh, also ask racarr/kdub about it too - they're in a closer timezone
<thomi> yeah, will do,t hanks
<robert_ancell> bye
<alf__> alan_g: Basically, there are two ways to achieve eglSwapInterval(0). Either the compositor doesn't sync with vsync (so you get tearing), or we provide a "spinning" variant of triple-buffering for client surfaces in which both the compositor and the client always have a buffer available without blocking.
<alf__> alan_g: Kevin's current MP is for the first option
<alan_g> alf__: I think spinning is a no-go on battery powered devices. But is eglSwapInterval(0) actually the right measure?
<alan_g> I mean tearing isn't a good user experience, and you can't actually see "eglSwapInterval(0)" as a user
<alf__> alan_g: neither of these are useful in the normal case, they only make sense when measuring performance. Normal case is going to be either double or (normal) triple buffering.
<alf__> alan_g: We need some way to avoid being bounded above by the refresh rate => eglSwapInterval(0)
<alan_g> So is this benchmark driven optimization? Or is there something in the "normal case" that is improved by it?
<alan_g> The idea is we can better measure the stack throughput is we're not constrained by updating the screen?
<alan_g> s/is/if/
<alf__> alan_g: It's not something that will be on by default, neither it is an optimization. It's just a use case that we need to support, so that we can evaluate maximum performance without the vsync restriction.
<alf__> alan_g: stack throughput is we're not constrained by updating the screen => yes
<alan_g> alf__: OK
<alf__> alan_g: looking at https://bugs.launchpad.net/mir/+bug/1175721, was there a particular test (or tests) that you found difficult to implement with the current infrastructure?
<ubot5> Launchpad bug 1175721 in Mir "We lack a good testing story for our use of egl/drm/gbm/..." [Medium,Triaged]
<alan_g> alf__: I was trying to test that cursor movement resulted in the correct drm calls but to mock those calls got me into a chain of things I needed to replace with test doubles
<alf__> alan_g: ok, in this case where we need to test only the extremes (GBMCursor -> drm calls) I think we can actually use our current design. We need to set up drm resources for the right number of screens etc, but we have support for this.
<alf__> alan_g: I will start working on something along these lines and see how it goes
<alan_g> alf__: what I wanted to test was mocked input to DRM calls
<alan_g> I know there's some support there. But the work needed seemed out of proportion to the code to be tested.
<alf__> alan_g: @message-processor-report-lttng, 1. are you on raring and 2. what version of lttng-ust do you have (dpkg -s dpkg -s liblttng-ust-dev)
<alf__> ?
<alan_g> alf__: 1. yes.  2. 2.1.1-2
<alf__> alan_g: the version is the same as mine... thinking of what may be going wrong...
<alan_g> alf__: let me know if/when I should look closer.
<alf__> alan_g: I will, thanks
<alf__> kdub: Good morning! Can you confirm that both the integration and the acceptance tests don't need to mock EGL/GL or hw on Android?
<kdub> alf__, good morning, will check
<alf__> status: gardening bugs, investigating reported test failure with lttng (which unfortunately can't be reproduced locally or in the builders), improving testing infrastructure
<alan_g> status: catching up after time off. finding test failure with lttng MP (which, for some reason, is easily reproducible for me)
<kdub> satus, mp'd swapinterval 0, going to find some glmark numbers today
<racarr> Morning
<alf__> racarr: Good morning-10 :)
<alan_g> racarr: Afternoon
<alan_g> racarr: https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211 hasn't changed for 2+ weeks. Can we kill it or mark it WIP pending an update?
<racarr> alan_g: I guess kill it
<kgunn> racarr: alan_g you guys are so violent
<racarr> I dont have any further suggestions though
<alan_g> Does anyone have an opinion on: https://code.launchpad.net/~vanvugt/mir/move/+merge/162487 (Nothing happening there either - partly due to duflu being away)
<racarr> I dont think it makes sense to land any more demo code
<hikiko> status: still fixing compiler/linker errors in sdl platform (had to replace a lot of stuff after a local merge I did), fixed some bugs, replaced gcc with cmake to get rid of those compiler internal errors all the time... :)p
<alan_g> racarr: You're advocating more violence?
<kgunn> alan_g: seems he is, how do i move his to wip ? (do i have that power?)
<racarr> alan_g: yes XD
<racarr> mine is not WIP it is just dead :p
<alan_g> kgunn: Near the top, you can try changing the status (There's an odd icon)
<alan_g> If you can't change it the the rest of us can.
<kgunn> alan_g: hmmm, i can only change status to approved/rejected/merged
<alan_g> kgunn: look harder "Work in Progress" is there (at the top)
<kgunn> alan_g: :) i feel stupid now....it was the only one in black text, my eye/brain completely filtered it :)
<alan_g> kgunn: you are not the first
<racarr> Does anyone want to talk about
<racarr> depthify stack? Because I feel like
<racarr> err.. that's what I need to work on
<kgunn> racarr: as part of the unity-mir layer right?
<kgunn> per the comments in the original in mp
<racarr> that's what the thread on launchpad talks about but
<racarr> I don't think that's really what the question is...
<racarr> The surface stack could be implemented in unity-mir or
<racarr> in mir.
<racarr> but, the discussion in this thread, I think gets to the interfaces too
<racarr> i.e. say there is some surface stack interface implemented by unity-mir
<racarr> does it know about depth at all?
<racarr> i.e. are there methods like, raise this surface relative to this surface, etc in Mir
<racarr> the proposal from robert (I don't actually know what alan is proposing/expecting)
<racarr> alan_g: ^ ;)
<kgunn> racarr: "thinking aloud", when we get to the point where we want to
<racarr> Is to not have any of this, and instead have the shell provide a sort function to the compositor and input stack
<kgunn> do dirty region tracking for optimization
<kgunn> wouldn't it actually be best if mir has the z stack (not unity-mir)
<alan_g> racarr: I was expressing doubt that "depth" was adding sufficient flexibility to solve problems
<racarr> Well. I think so :) but it can work without mir having the z stack
<racarr> kgunn: i.e. whatever is tracking this damage calls the shell sort function
<racarr> and determines the z order that way
<racarr> the thing I don't like about it is hmm
<kgunn> racarr: got it...so really no benefit to stick it in mir, since its gotta go check with shell anyway
<alan_g> I've no objection to giving mir a better model of how surfaces are related - just not sure "depth" is the answer
<racarr> kgunn: No I think there is an advantage...I'm trying to explain
 * kgunn shuts up for a minute :)
<alan_g> racarr: kgunn hangout?
<kgunn> sure
<racarr> Sure. It will be easier.
<alan_g> https://plus.google.com/hangouts/_/91e1f9a0e398b79534e877285ddd48e7fe357722?hl=en-GB
<racarr> sorry guys ayudio trouble just a sec
<katie> tvoss,
<racarr> Thanks both :)
<racarr> There are still some loose ends around input now that I will tie up
<racarr> Going to do some diagraming
<racarr> alan_g: Oh! if you have a few minutes I wanted to talk about options
<alan_g> racarr: sorry, missed that - and supper is now ready.
<racarr> alan_g|life: No worries. Enjoy :)
<racarr> Status: Working on hooking the input stack more directly to the surface stack/shell
<racarr> involves some InputDispatcher rework, am trying to figure out how deep I need to go
<racarr> and kind of spiralling but I think I should pull together a plan over lunch
<racarr> spiralling thoughts, not a personal spiral :p
<racarr> anyway lunch!
<racarr> </lunch>
<kgunn> thomi ! hey i updated the test spec....might take a gander, stuff to report & how to interp failures
<racarr> Oh hey thomi I need to harass you too
<racarr> please distract me from this awful world where every class begins with "Input"
<racarr> p.s. not to accuse kevin of harassment but that's my plan
<kgunn> :)
<racarr> diagramming with an aubergine sparkle pen...
<racarr> I am the input princess! *twirls*
<mlankhorst> racarr: What about MirInput class ? :>
<racarr> it's not there! ;)
<racarr> right now I am in the world of android::Input*
<thomi> racarr: hey
<thomi> kgunn: ok, will take a look
<racarr> thomi: Hey. I am about to jump in a meeting re:platform API in 10 minutes so we might have to finish this later
<thomi> ok
<racarr> but I want to get integration testing for mir<->qt in place
<thomi> later would be better for me too
<racarr> in process and out of process
<racarr> ok well ping me later when you have some time to talk about it
<racarr> I don't mean I want to do it RIGHT NOW I just mean I want to get a plan
<thomi> racarr: nah, you ping me after your meeting, I just need a second coffee, that's all :)
<racarr> Ok :D
<racarr> thanks
<thomi> np
<thomi> Hey guys & girls, Mir and unity-system-compositor projects are now in the MBS system, which is suppoosed to trigger a rebuild of U-S-C every time mir lands, to avoid the API breakage issue we currently have. Please let me know if you see anything strange going on there...
<kgunn> thomi: yes...but thot it was because prebuilts were still wonky
<kgunn> but lightdm "held back, not upgraded"
<thomi> kgunn: ummmm
<kgunn> tried to mannually install to update...finally complaining about depends on unity-system-compositor
<thomi> kgunn: possibly lightdm needs to be added to that system as well then. I'm not aware of what that interaction look slike
<thomi> *looks like
<kgunn> but then when i tried to manually install unity-system-compositor it complains
<kgunn> unity-system-compositor : Depends: libmirserver0 (= 0.0.2bzr676raring0) but 0.0.3bzr691raring0 is to be installed
<kgunn> brb
<kgunn> gotta run the son somewhere
<thomi> kgunn: right, I think that should fix itself now
<thomi> once something lands in mir
 * thomi crosses fingers
<kgunn> mmm, ok
<kgunn> well i was trying to build from source this afternoon
<kgunn> got to the "make install"
<kgunn> which then complained....couldn't find /build/doc/html
<kgunn> there's a /build/doc/footer.html
<thomi> kgunn: maybe ping me when you get back?
<alan_g|life> kgunn: @"....couldn't find /build/doc/html" - that's created by "make doc" HTH
<kdub> cross compiling is super fun!
<racarr> kdub: Its hard to think of anything more fun
<kdub> thomi, i don't understand 'mbs' or 'u-s-c' about the changes  you mentioned to the autolanding
<thomi> kdub: u-s-c = unity-system-compositor
<thomi> but that's too long to type
<thomi> and I'm lazy
<kdub> oh, ok :)
<thomi> mbs = meta-build-system, which is something we're working on to solve the problem of "when package X gets rebvuilt, we also need to rebuild packages Y and Z, due to API/ABI compatibility"
<thomi> which is the case with u-s-c and mir
<thomi> so essentially, every time mir lands, we should also build a new u-s-c
<thomi> racarr: I need to talk to you about my mir stress tests as well
<racarr> thomi: Ok! Lets talk
<thomi> racarr: hangout, or...?
<racarr> Sure
<racarr> just give me 2 minutes to finish writing this test.
<thomi> sure
<racarr> [  FAILED  ] SurfaceStack.surface_is_created_with_requested_geometry
<racarr> what a bummer
<racarr> XD
<racarr> ok hangout time
<racarr> thomi: ^
<thomi> sure
<racarr> thomi: Err can you start it I have to use the android client today
<thomi> let me invite you
<racarr> because my audio has chosen to no longer work inside hangouts
<thomi> racarr: invite sent
<thomi> racarr: lp:~thomir/+junk/mir-stress/
<thomi> racarr: http://pastebin.ubuntu.com/5685237/
<thomi> racarr: so I can't run the demo_server under gdb since when it crashes it locks up the system, and I can't start it under SSH, since it can't get a FD for the current VT.
<thomi> perhaps you know of a way around this?
<racarr> it locks up the system or breaks output?
<racarr> What I do is
<racarr> gdb mir > foo.txt 2>&1
<racarr> run
<racarr> make crash
<racarr> switch back to vt
<racarr> bt
<racarr> ctrl+c
<racarr> ctrl+d
<racarr> then answer the insible prompt
<racarr> y
<racarr> then switch to X and back
<racarr> lol
<thomi> haha
<kdub> haha :P
<racarr> then a man will walk up to you and ask you if you like to ride horses
<thomi> I'm trying to sort something out with screen, that might help
<racarr> offer to trade a golden egg for his bow and arrow
<racarr> then the journey begins...
<racarr> would be nice to have
<racarr> mir --debug like unity has
<racarr> that prints a bt on crash
<thomi> yeah, or something like --advanced-debug, which drops you into a gdb session
<thomi> racarr: hmm, if I run the mir_demo_server under gdb it doesn't crash, so it feels like a race condition to me
<racarr> thomi: Of course it doesn't that would be too easy
<racarr> thomi: It would be interesting to see if you could reproduce it
<racarr> with multiple processes disconnecting/reconnecting as fast as possible
<racarr> so we can rule in/out the client library
<thomi> yeah
<racarr> P.S. This exists: https://code.launchpad.net/~robertcarr/mir/enable-surface-placement/+merge/164817 need it for an upcoming input acceptance test
<racarr> thomi: Right now I cant think of anything better than stumbling through the code guessing at race conditions
<racarr> but if you can narrow it to server/client
<racarr> I can do that XD
<kgunn> thanks alan_g|life!
<kgunn> like a champ
<kgunn> bummer...same probs
<kgunn> gotta go tho
<thomi> racarr: so... good news and bad news
<racarr> kgunn: See you!
<thomi> racarr: good news: mir server crashes with multiple processes as well
<racarr> thomi: Uhoh
<thomi> racarr: bad news: mir server crashes with multiple processes as well
<racarr> mm
<racarr> nothing informative in backtrace?
<thomi> I haven't managed to get a backtrace yet,
<thomi> I think I need to look into gdb-remote
<racarr> ok ill spend some time investigating soon
#ubuntu-mir 2013-05-21
<racarr> got a failing acceptance test for touch input picking (i.e. multiple visible clients stacked, such as the launcher and an application)
<racarr> and a plan...lots of steps though
<racarr> hopefully should finish by tomorro
<alf__> alan_g: Good morning!
<alan_g> alf__: Good morning!
<alf__> alan_g: @message-processor-report-lttng, can you please paste(bin) the full (detailed) output of the failing test runs
<alf__> alan_g: (when you get the time)
<alan_g> alf__: I can, but there's nothing that looks more useful than I pasted to the comments. Would it be a better use of our time for me to try debugging for an hour or so?
<alf__> alan_g: Probably :) The error from lttng indicates that the communication threads that lttng uses to communicate with its daemon have either died or never started. I was wondering if there were any other error messages, perhaps at the beginning of the tests, that would give us more hints about what happened.
<alan_g> alf__: I woudln't expect lttng to be doing anything unless asked. (which it wasn't)
<alan_g> alf__: http://paste.ubuntu.com/5686305/
<alf__> alan_g: it opens a connection to its daemon as soon as the lttng-ust shared object is loaded (through a shared object "constructor" function)
<alan_g> Hmm is that a cost we want in "normal" operation?
<alan_g> alf__: without having dived into the code is lttng waiting for a connection to its daemon? And might a timeout there cause a problem with our test setup timeouts?
<alan_g> alf__: I'll see if I can track down exactly what the failure mode is...
<alf__> alan_g: @cost, if it turns out to be a problem, we can work around it by loading liblttng-ust dynamically at runtime when an lttng reporter is constructed
<alan_g> alf__: ack.
<alf__> alan_g: also, looking at the lttng-ust man page, there are the following env. variables:  LTTNG_UST_DEBUG and LTTNG_UST_REGISTER_TIMEOUT which may help debug the problem
<alf__> alan_g: I think I should go with dlopen anyway, and hopefully that will fix the problem you are seeing, too
<alan_g> alf__: the env variables don't affect the test failure (or output)
 * alan_g would like to understand the problem, not just avoid it
<alf__> alan_g: Interesting, I can know reproduce the failures you are seeing! I have no idea what changed :/
<alan_g> alf__: :/
<alf__> alan_g: ok, so make test passes, but ctest (or running e.g. bin/integration-tests directly) fails
<alan_g> alf__: I never run "make test" - but you're right, it passes
 * alan_g thinks that is unreasonable
<alf__> alan_g: I think I found the problem:
<alan_g> \o/
<alf__> From the manpage: "Some extra care is needed when using liblttng-ust with daemon applications that call fork(), clone(), or BSD rfork() without a following exec() family system call. The library "liblttng-ust-fork.so" needs to be preloaded for the application (launch with e.g. LD_PRELOAD=liblttng-ust-fork.so appname)"
<alf__> alan_g: and doing this solves the problem for me
<alan_g> alf__: me too. (How does running via cmake do that?)
<alan_g> alf__: In any case, I think we should be dynamically loading lttng - not requiring it regardless.
<alf__> alan_g: Agreed, I will give dynamic loading a spin and see what comes of it
<alan_g> alf__: I wonder if you can dynamically load liblttng-ust-fork.so in the test configuration or if it needs to be preloaded.
<alf__> alan_g: no idea, I will experiment
<alan_g> Good luck!
<hikiko> alf__, ping :)
<alf__> hikiko: pong
<hikiko> hello, question: what exactly the vt does? you said I don't need it to run the render_to_fb example but without it I get runtime errors: Failed to find the current VT, so I guess I have to add it to my display...
<hikiko> (or maybe I should just add it and have only one vt active? I am not sure I got 100% what it does :))
<alf__> hikiko: The vt is an abstraction for the linux virtual terminal, which is not needed for SDL. 1. are you sure render_to_fb is using the sdl backend when you run it 2. do you use the vt in the sdl platform/display code?
<hikiko> 1. I guess so, I configured cmake to use sdl, I would get a compile error if it didn't isn't it? 2. no
<hikiko> shall I use it?
<alf__> hikiko: you shouldn't use it, SDL doesn't care about VTs
<alf__> hikiko: but you need to find out why you end up in VT code
<hikiko> yes I will :) I just asked you to get sure I don't need the vt!
<hikiko> thanks :)
<alf__> hikiko: sure, np :)
<alan_g> alf__: do you know why OverlayRenderer::render() needs a graphics::DisplayBuffer?  (As opposed to, say, a ViewArea)  I can't find any code that justifies it - and it would simplify some refactoring if it needed less.
<alf__> alan_g: I guess it depends on how generic we would want to make OverlayRenderer. For example an overlay could need to render to an offscreen buffer first (=the display buffer would lose its "current" rendering target status) and then the overlay would need to make the display buffer current again, so it needs some access to the display buffer (or perhaps we could provide it with a std::function<> make_display_buffer).
<alf__> alan_g: but these are only assumptions... For now I don't think anything but the software cursor uses the overlay
<alf__> alan_g: Also I would argue that we don't the overlay at all: whoever needs a special compositing strategy with overlays or whatever, should just create their own new strategy...
<alan_g> alf__: I was wondering what was special about overlays. I didn't find any code using them - where's the software cursor stuff?
<alf__> alan_g: probably hidden in one of racarr's branches :)
 * alan_g thinks "if it isn't on trunk I can break it"
<kgunn> alan_g: alf__ at least on the phone, the hwc api is supposed to be the support mechanism
<kgunn> for overlays
<kgunn> because, everyones hw is a bit weird
<kgunn> e.g. caveats
<kgunn> on things like i can't support bgr mixed with rgb formats
<kgunn> at any rate, overlays are there
<alf__> kgunn: If the OverlayRenderer was indeed meant as an abstraction for the HW overlay, it makes more sense. But I always thought it was just a mechanism to provide an easy way for examples or the shell to draw over the display.
<alan_g> kgunn: you're saying that we need overlay support separately from other surfaces because they don't even go via the DisplayBuffer (and don't need it)
<alf__> alan_g: kgunn: Let's hear what racarr's intention was for it
<kgunn> alf__: ack on that
<alan_g> yep, sorry. (I optimistically hoped for someone that's around would know.)
<kgunn> alf__: not sure i think about it correctly...but yeah, overlays head for a "specialized" piece of hw
<kgunn> and that special hw is really a composition engine
<kgunn> of 2d nature
<kgunn> that's why hwc is attempted to be used....but can result in the "overlay stack" being sent back to the gpu
<kgunn> in order to get composed
<alf__> kgunn: sure, I am just not sure if the particular OverlayRenderer we are talking about was meant for this, or the term "overlay" was used in the more general sense.
<kgunn> alf__: right...i'm tracking, may or may not have been intended for this
 * alan_g sees that he's right: in lp:~robertcarr/mir/demo-software-cursor-junk SoftwareCursorOverlayRenderer just uses the DisplayBuffer to get the size of the view area.
<alan_g> kgunn: alf__ : as far as trunk goes OverlayRenderer is pointless.  FWIW SoftwareCursorOverlayRenderer doesn't use hwc.
<kgunn> alan_g: right...i would think so too because of the name "sw cursor"
<kgunn> whereas a "hw cursor" might try to get an overlay
<alan_g> The implication being that OverlayRenderer is not intended for hardware overlays.  Anyway, I feel confident I can make my changes and we can figure out if there is anything we need OverlayRenderer for later.
<kgunn> alan_g: sure...still a qood ques for racarr later
<kgunn> hikiko: ping
<kdub> good morning, status, updating my android builds, working on getting glmark to run on mir under android drivers
<kdub> if we wanted to add some graphics performance benchmarks that are runnable on both mir and say... surfaceflinger, seems benchmarks/graphics would be a good place for that
<kdub> but we might have to put an Android.mk makefile in there...
<kgunn> kdub: +1
<kgunn> oem's will like that
<kdub> yeah, not super pumped about the Android.mk in there  though... the other option is to have a separate project
<kgunn> right....but seems overkill
<kgunn> ah...maybe a seperate proj is the right thing tho
<kgunn> its for sure the most sanitary
<kdub> i somewhat am leaning towards a separate project... that way we can instruct 'download the ndk...' without re-polluting lp:mir with that
<kgunn> yeah...let's do that
<kgunn> kdub: the main thing is having a nice pointer for the oem's to see
<kgunn> & play with
<alf__> status: debugging lttng issues (also see: https://bugs.lttng.org/issues/538)
<alf__> status: ... and trying to make our lttng reporting work despite those issues
<alan_g> status: refactoring code that's in the way of composition bypass.
<alf__> alan_g: s/refactoring/deleting/ ;) ?
<kdub> alan_g, anything i can help with?
<alan_g> alf__: no
<alan_g> kdub: not for now - I've the next few steps planned out
<alf__> alan_g: too bad, I was in a mood for deletions today :)
<kdub> i might have a deletion! :) there's a class i want to get rid of in src/server/graphics/android
 * alf__ will be right back
<kgunn> alan_g: kdub racarr any of you on saucy?
<alan_g> kgunn: not yet
<kdub> raring for me
<racarr> morning
<racarr> lept in a little late because I am always super tired for the 11 pm weekly :p
<racarr> still on raring...hould be in saucy probably
<alan_g> afternoon
<racarr> alan_g: Reading one of your emails. I think SurfaceCreationParameters belongs in shell
<racarr> or mf::SurfaceCreationRequest (does not feature a top_left)
<racarr> and msh::SurfaceCreationParameters (features a top left)
<racarr> placement strategy takes Request->Parameters
<alan_g> Make it so Mr Carr
<racarr> :)
<kgunn> racarr: was chatting with gerry earlier, as to platform-api changes we're "waiting" on
<kgunn> is it just these 2?
<kgunn> https://code.launchpad.net/~ricmm/platform-api/new_api_with_lifecycle/+merge/160691
<kgunn> https://code.launchpad.net/~robertcarr/platform-api/mir-client-and-server/+merge/163616
<racarr> kgunn: Yes. I am syncing up with ricmm today
<racarr> at 1:30 to figure out how to land them
<kgunn> racarr: great! let me know if you need review "volunteers" (mmwwhaahaha)
<racarr> :) Thanks. I think it's mostly just a matter of everything lining up right
<racarr> i.e. to land my changes we need to introduce some more modularity
<racarr> so it's possible to have say, mirclient for implementing ubuntu_application_ui_*
<racarr> but still get at the GPS via hybris
<kgunn> right
<racarr> and I think some of riccm's refactoring involves this
<racarr> god the amount of time I spend renaming classes...
<racarr> why can't clang do this yet
<racarr> moved surface creation parameters to shell in enable-surface-placement
<kdub> racarr, yeah.. seems something automagical should exist for renaming classes
<racarr> Sometimes deep in the caves of refactoring
<racarr> I wonder if it is worth righting a tool that does common tasks, even if say it only worked on our code tree haha
<racarr> then I tell myself if it were someone would have already done it and to focus
<racarr> then I look at pictures of cats on the internet.
<racarr> writing a tool*
<kdub> we should probably have a FindMirClient.cmake module...
<kgunn> racarr: cracking me up
<racarr> about...30% through getting rid of setInputWindows and having the dispatcher controller use the surface model directly
<racarr> has the nice side effect of enabling input for more than one urface at a time
<racarr> out for 20 minute to take a walk, back soon
<kdub> kgunn, have some numbers for startup cost on the meeting doc
 * kgunn scurries away to read
<kgunn> kdub: well that's interesting, altho double, the value is so small...it shouldn't bother us
<kdub> yeah, thats what i thought too...
<kdub> the cost is probably that we fire off more threads
<kgunn> kdub: its kind of just on the edge of nuisance
<racarr> the most interesting cost-effect for startup time is probably
<racarr> recovering when mir crashes
<racarr> on boot we are drowned in a giant mess of things that take forever to start
<racarr> and I doubt we really show up as a blip
<kgunn> racarr: even on phone?
<kgunn> also....this should be new client, post startup
<racarr> I dunno
<racarr> on the desktop qml-phone-shell for example noticeably takes a second or so to load
<racarr> after the hardware cursor appears
<racarr> we dont do much disk IO is the thing
<racarr> we do start a lot of threads though XD
<kdub> well, firing up qml-phone-shell is more akin to starting a Launcher.apk than it is to starting /system/bin/surfaceflinger
<kgunn> kdub: and i think racarr is talking about system start...not client start
<kgunn> altho i might be wrong
<thomi> morning all
<thomi> I see nobody was brave enough to reply to my email on mir-devel?
<kgunn> thomi: alf did actually
<kgunn> ( i thot)
<thomi> hmmmm, maybe my mail client is bring dumb then
 * thomi restarts thunderbird
<kgunn> thomi: answer was...yes, it should be thread safe
<kgunn> and he was able to repro
<kgunn> so...hooray....plan worked! we found a bug
<kgunn> we = you :)
<kgunn> so thank you
<thomi> he == ?
<thomi> kgunn: ^
<kgunn> thomi: he == alf
<thomi> ahhh
<kgunn> thomi: i spoke with him earlier...he said not as frequent, but definitely seeing race cond of some sort
<thomi> kgunn: it could be because I have a pretty beefy laptop perhaps.
<kgunn> thomi: yep
<thomi> kgunn: any idea when a fix is in the works? I'm wondering if it's worth postponing further development on mir-stress until this first issue is fixed
<thomi> since I can't really exercise the mir erndering stuff until I can reliably connect...
<kgunn> thomi: if he shows to the team meeting you might ask him
<kgunn> otherwise i'll ping him in the morning
<thomi> good point
<kgunn> thomi: btw, are you on saucy or raring
<thomi> kgunn: both :)
<thomi> kgunn: my main laptop is on raring, I have a test laptop that's running saucy + mit-team staging PPA
<thomi> since the PPA sometimes breaks the desktop
<kgunn> thomi: yeah, i was curious....how is the saucy + mir ?
<thomi> kgunn: seems fine to me
<kgunn> thomi: cool
<thomi> kgunn: it builds fine, tests all pass
<thomi> we need to get to the point where it's easy to start unity8 + mir though
<kgunn> yeah, hopefully racarr can push some key platform-api changes through...then he & gerry can create their unity-mir project
<racarr> Lunnnch!
<thomi> brrrreakfast!
<racarr> and back
<racarr> Effective C++ said to provide raw access functions in your resource management classes so there can't be an ything dangerous about adding a .get()/.surface() to msh::Surface right? ;)
<kdub> better cast to void and XOR it with a known constant first :P
<kdub> just kidding :)
<racarr> error: âvoid {anonymous}::FocusNotifyingInputTargeter::focus_changed(const std::shared_ptr<mir::input::SurfaceTarget>&)â marked override, but does not override
<racarr> god I love that kekyword
<racarr> keyword*
#ubuntu-mir 2013-05-22
<racarr> *pant*
<racarr> 2/3rds done!
<racarr> unfortunately diff is already almost 5000 lines, wondering if I should try and propoe part of the branch even if it doesn't make sense on its own
<racarr> Happy weekly meeting!
<racarr> *streamers and loud horns*
<thomi> anyone joining me in the weekly meeting?
<thomi> racarr: ?
<hikiko> thomi, in a sec
<racarr> thomi: Link?
<thomi> https://plus.google.com/hangouts/_/a9abbc8e84f85360faaab30196768ca2d9129d09?authuser=1
<thomi> kdub: ?
<thomi> RAOF: ?
<alf__> thomi: https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211
<alf__> thomi: https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/718/console
<alan_g> alf__: @refactor-compositing-strategy - do you agree with me that the resource holding problem also applies to the "overlay rendering" we were discussing yesterday?
<alf__> alan_g: yes
<alan_g> alf__: I'll roll that fix in too. ;)
<alf__> alan_g: although it's not probable (but it's possible) that the overlay render will actually need to do something that requires resource holding
<alf__> alan_g: Did you get a chance to talk to racarr about the utility of the OverlayRenderer?
<alf__> (vs just rolling a new CompositingStrategy)
<alan_g> alf__: I didn't - there are more urgent questions.
<alf__> alan_g: I am asking because perhaps racarr will agree to that, so we can get rid of OverlayRenderer...
<alf__> alan_g: and save you the trouble of changing OverlayRenderer
<hikiko> the mir/examples are only for the gbm platform?
<alf__> hikiko: no
<hikiko> alf__, I want to get 100% sure that there isn't something in my CMakeLists.txt that causes the render_to_fb example to compile with gbm
<hikiko> it seems to compile with sdl
<alan_g> alf__: when you have time could you look over https://code.launchpad.net/~alan-griffiths/mir/refactor-compositing-strategy/+merge/164945
<alf__> alan_g: sure
<greyback> kdub: hey, an progress with improving performance on Galaxy Nexus?
<hikiko_lunch> alf__, render_to_fb is a standalone prog or i have to run something else before i start it?
<hikiko> There are some brief guides describing how to run the Mir binaries once you have
<hikiko> them built. <- where?
<alan_g> hikiko: render_* are standalone programs
 * alan_g thinks this is https://bugs.launchpad.net/mir/+bug/1108715 again
<ubot5> Launchpad bug 1108715 in Mir "Inadequate documentation of binaries" [Medium,Triaged]
<hikiko> cool, but where are instructions on how to run mir? I found build instructions in several places (eg doc, readme) but I can't find how to run clients etc
<hikiko> yes :D alan_g that's exactly my question
<alan_g> hikiko: The documentation that does exist is under http://unity.ubuntu.com/mir/ - e.g. "Using Mir on a PC"
<hikiko> pfff blind :( so I just start the server and then  I run the client :) thank you alan_g !
<alan_g> hikiko: np - BTW you're welcome to propose improvements to the documentation. (It needs improvement!)
<hikiko> but for the render_* I don't need to run the server isn't it?
<alan_g> hikiko: no, they use the mir library directly
<hikiko> ok :)
<hikiko> thank you!
 * alan_g is always glad to help.
<hikiko> :D
<kdub> greyback, no, haven't looked further into that... maybe we should file a bug?
<greyback> kdub: true, I'll make one
<greyback> kdub: https://bugs.launchpad.net/mir/+bug/1182930 do you need more info?
<ubot5> Launchpad bug 1182930 in Mir "Unity8 low framerate running on Mir on Galaxy Nexus" [Undecided,New]
<alf__> status: more lttng work, started investigating mir stress test crashes
<kdub> greyback, looks like enough info to start
<greyback> ok
<kdub> status, cleanup branch, measured our client's start times in comparison to surfaceflinegr, working on the glmark2 numbers now
<kgunn> greyback: just curious...is the perf drop on n10 & galaxynexus? or more noticeable on one than the other
<greyback> kgunn: Mir not functioning on N10, so I cannot say. I only have 1 device
<greyback> that's running Mir correctly right now
<kgunn> greyback: ack
<greyback> kgunn: probable perf is better. racarr has N4, he can probably say what perf is like
<racarr> Morning
<alan_g> Afternoon
<racarr> today will still be working on this input branch I was on all day yesterday
<racarr> should hopefully be wrapping it up around lunch time
<kgunn> racarr: just curious....on nexus4, do you see the same drop for inprocess shell vs out of process (same as galaxynexus)
<racarr> Not with
<racarr> a cursory glance
<racarr> thats interesting
<racarr> I have had a speculation for a while
<racarr> that perhaps a many threaded process
<racarr> is more difficult to schedule
<racarr> than multiple processes
<racarr> i.e. the assumption has always been that inprocess shell would give us a performance boost
<racarr> but there is no reason why that has to be true.
<racarr> no reason obvious to me*
<kgunn> racarr: mmm, guessing the theory is...its thread switching vs process (context) switching
<kgunn> racarr: so you didn't see a visible drop on nexus4...hmm
<kgunn> kdub: ^
<kdub> ohhh
<kdub> yeah that could explain it :/
<kdub> well, rather, gpu context switching is more of a concern to me
<kdub> because i'd guess the newer cores do that better than the older ones
<kdub> like, i know the nexus4 gpu is 'hyperthreaded' (if i can overload that term :) )
<racarr> kgunn: thread swithcing is definitely cheaper
<racarr> than process switching though...
<racarr> but, maybe that overhead is small for us
<racarr> I have two theories (if it is in fact the case)
<kgunn> racarr: for sure
<racarr> 1. I don't know how the kernel scheduler works anymore but
<racarr> from a high level point of view if you are trying to interleave multiple processes
<racarr> the fewer dependencies they have
<racarr> i.e. threads have a shared memory dependency on eachother
<racarr> whereas processes don't
<racarr> you can be more clever
<racarr> Or, perhaps the scheduler just fights us by default
<racarr> because the desktop scheduler tries to ensure processes get low worst case latency
<racarr> over thouroughput
<racarr> so maybe there is some sort of timeslice that each process gets (I think this is a vast simplification of how the scheduler work now...I haven't known the details in > 2 years and there have been at least 2 rewrite)
<racarr> and the shell is exhausting what would have gone to the compositor
<racarr> if this is the case I bet we can fix it with affinities or priorities or something
<kdub> racarr, i'm suspicious that what is happening is
<racarr> 2. The input setup is different in the out of process case
<kdub> the galaxy nexus gpu has to do a pipeline flush (or something funny like that) on a gpu context switch
<kgunn> racarr: kind of makes sense, about mem dependencies too
<racarr> i.e. it's using a seperate process for input reading and delivery too
<kdub> and so in process thrashes the gpu caches and pipeline
<kgunn> you can hose yourself w. overhead of locking/unlock
<racarr> kdub: It's kind of the same story out of proces though right?
<kdub> well, i guess
<kdub> well
<kdub> still thinking, thats a good point
<racarr> kgunn: It could be an overhead of lock/unlock too
<racarr> some sort of lock contention issue
<racarr> another wild guess: Our surface stack has a single mutex
<racarr> so input events (reading the surface stack/a surface) contend with the compositor (also reading the surface stack/a surface)
<racarr> whereas in the out of process setup
<racarr> where we are using surface flinger
<racarr> there is no contention (granted there is also lot of races :p)
<racarr> (using surface flinger for input that is)
<racarr> A R/W lock would fix that.
<tvoss> racarr, kgunn, kdub how about running it through callgrind?
<racarr> Good idea, or if we had deeper lltng traces might be interesting.
<racarr> I think first we should measure and confirm it XD
<tvoss> racarr, exactly
<racarr> im reading about
<tvoss> racarr, I do not think that we should be slower in process. Why would we need to have more context switches in process?
<racarr> tvoss: Not more context switches
<racarr> I just mean the scheduling is less ideal
<tvoss> racarr, can we try with renicing the the shell then?
<racarr> pthread_setschedparam :)
<tvoss> racarr, our good old friend :)
<racarr> I think
<racarr> something that would be interesting to try in general (even if not specifically in this problem)
<racarr> would be scheduling the compositor thread with SCHED_FIFO
<racarr> and all the other threads with SCHED_OTHER (the default, which is apparently round robin timeslices)
<racarr> the whole theory of this being the source of the performance degredation seems improbable ;)
<racarr> perhaps the surface flinger we use for input in out of process model
<racarr> already has a higher priority
<racarr> or higher priority threads somewhere
<racarr> or something
<racarr> that seems like the kind of thing they would do
<racarr> Ok. Sorry I am rambling, this is just interesting to speculate about XD
<racarr> tvoss: I am rebuilding the input stack to get rid of setInputWindows :)
<tvoss> racarr, great :)
<tvoss> racarr, surfaceflinger has a compositing thread priority of time_critical iirc
<racarr> In the out of process mir demo though (which I think is what the performance degredation was observed relative to)
<racarr> there is the surface flinger
<racarr> input threads still running right
<tvoss> racarr, yup
<racarr> I bet they tweak those threads too..
<racarr> if you really trust what you are doing even, all your input receiving threads on the client (which have a chance to back up the server input processing)
<racarr> should be scheduled FIFO as well, because all they should do is read from the socket, respond and block/yield on injecting the event in to the toolkit thread
<racarr> XD
<racarr> I wish there were a term...
<racarr> I run across this concept a lot, I don't think we are
<racarr> IO bound or CPU bound rather we are
<racarr> "contention bound"
<racarr> kdub: Hmm. About the GPU drivers too..I guess it' not for granted that the flushing etc is the same from threads/processes
<racarr> switching between contexts in the same process
<racarr> you have this instance of the driver, GL API, etc.
<racarr> and a GL context switch require updating state in all of those.
<racarr> in addition to the actual
<racarr> GPU switch
<racarr> whereas when it goes to another process...
<racarr> <blank>
<tvoss> you have to do that, too :)
<racarr> tvoss: Do you?
<tvoss> racarr, at least on a driver level
<racarr> with two proceses though I think its hidden in the kernel layer? or at a lower part of the driver layer
<racarr> whereas say in one process, you have some libglapi.so that has some static TheCurrentGLContextBlaBla data
<racarr> then you have to tear it down and bring it back up when you switch contexts
<tvoss> racarr, unless we use a per-thread context stored in thread-specific storage
<tvoss> racarr, hold on ...
<racarr> Yes.
<racarr> I don't know how it works :) or what
<racarr> all the data might be (context was just a guess)
<kgunn> racarr: mild skim of scrollback...kinda depends on gpu
<kgunn> but you'd take the hit generically in gl context
<racarr> mm
<racarr> what I am saying is some driver implementation models
<kgunn> whether switching egl clients in diff thds or procs
<racarr> might have a higher overhead for
<tvoss> racarr, I *think* I have an idea, we patched parts of bionic for hybris, however, bionic has a pointer to gl stuff in a fixed place to speed up certain operations
<racarr> context switches in the same process
<racarr> espescially fucked up cross libc driver models apparently XD
<racarr> tvoss: Interesting...wait what are the different
<racarr> scenarios in multi process mir/single process though
<tvoss> racarr, well, if you only have one context it might not matter, but assume you cache state in the fixed location ...
<tvoss> state handwavingly wide
<racarr> oh
<racarr> yes
<racarr> that sort of thing.
<racarr> right, you can optimize one GL context per process
<racarr> by penalizing multiple GL contexts per process
<racarr> which is certainly something I would do on a phone
<tvoss> racarr, how many gl contexts do we have for the shell?
<racarr> tvoss: Oh so far just one because the shell is all one surface.
<racarr> in the in process mir case.
<tvoss> racarr, why would it be slower then?
<racarr> then the compositor context
<racarr> well
<racarr> 2 total
<tvoss> that really shouldn't matter
<racarr> No. I agree espescially because
<racarr> out of process, we are running multiple surfaces for launcher dah, etc
<racarr> and its hard to believe
<racarr> libgl state updating actually
<racarr> outweighs
<racarr> flushing the GPU pipeline.
<tvoss> yup
<tvoss> racarr, okay, time to actually measure things
<racarr> Yeah XD I was just going to say I should
<racarr> stop speculating as fascinating as this is...
<racarr> I need to finish off this input branch.
<racarr> tvoss: This branch is the first time we are really messing with the android-input bits much...(removing setInputWindows that is)
<racarr> and I don't think anyone else except you has looked at InputDispatcher that much
<racarr> so I will bug you for review on that part tomorrow or so
<tvoss> racarr, can you send me the branch by mail please?
<racarr> Yes. Will do so :) it's not quite done...I just got through all the mir refactoring that I need to actually make the InputDispatcher changes XD
<racarr> but should finish it soon and will mail you
<racarr> the...InputDispatcher while kind of this nasty object with like 30 responsibilities
<racarr> has really careful threading and I am worried changing anything
<racarr> I am going to break it all XD
<racarr> in a way that the acceptance tests aren't rich enough to expose yet
<racarr> Ok back to the input bubble
<racarr> that was fascinating XD
<racarr> greyback: Hey just wanted to update you...all this landing stuff has been delayed but should be resolved today
<racarr> and in the meantime I have been working on the machinery in mir for doing the stacking (and then making input work with that)
<racarr> so I am hoping we can switch to multi window shell soon
<tvoss> kdub, ping
<greyback> racarr: ok cool, good to know. Anything you need from me?
<greyback> racarr: I recall you wondering about a mock shell, you think it'd be useful? I can get on that
<racarr> greyback: No. Just wondering if that makes sense as a sort of shared target (multi window shell)
<racarr> not sure how much effort it is from your end
<racarr> greyback: Hmm what do you mean?
<greyback> racarr: something to test the basics of window management, launch app, close app, switch between them, etc
<racarr> Oh! Yeah. That's why im trying to get this surace ordering in place
<racarr> so you can see the launcher on top of apps to switch between them XD
<greyback> aha yes
<greyback> ok, well I'll work on the simple QML mock shell for you. It'll be useful for automated testing too
<racarr> I think getting the basic window management in place would be super useful (just this surface splitting has to happen before its useful, not sure how long that will take)
<tvoss> greyback, +1 on the distilled shell
<racarr> greyback: Awesome
<racarr> super useful for automated testing. Need to get
<racarr> qtubuntu auto tested in process
<racarr> greyback: Another thing (sort of ties in)
<greyback> agreed. Ok, adding to my list. I'm working on abstracting the existing WM code from unity8, and hopefully can get the 2 to meet in the middle
<greyback> shot
<greyback> shoot
<racarr> I think we should kick off this, libunitymir or libmirunity codebase.
<racarr> I was thinking about it because I wanted to write
<greyback> tvoss: good god man, don't you ever go offline!
<racarr> the cursor theme loading code
<tvoss> greyback, I'm always around ;)
<racarr> and it doesn't really belong in libmirserver
<racarr> because really it's a utility for unity to use on top of mir
<greyback> racarr: yep, we were thinking similarly. The WM code would best live in a libmirqt or something like that
<tvoss> greyback, but fair point :)
<racarr> or like...outside of mir or whatever
<racarr> greyback: mm
<racarr> so where does the code live?
<greyback> separate project
<tvoss> greyback, racarr how about libam, for libapplicationmanager?
<tvoss> as it is not window but app mgmt
<racarr> tvoss: Hmm. Maybe.
<racarr> tvoss: The way I think of it is
<greyback> cursor is something I'd not thought of. Hmm
<racarr> Lib-utility-machinery--to-bridge-unity-and-mir
<greyback> we need to give this a bit of thought, what belongs where
<racarr> mm
<racarr> Cursor loading isn't exactly part of "mirqt" definitely
<greyback> yep
<racarr> maybe there is a libmirutil and it's unrelated
<racarr> maybe 90% of the code which is in this one file that everyone copies around
<racarr> should really be libcursorthemeloader
<racarr> and this is a red herring
<racarr> XD
<greyback> lol, now my head hurts
<racarr> ignore cursors for now. We do need mirqt though
<greyback> I keed forgetting the answer to this question. For desktop, what draws the window decoration?
<racarr> depends on who you ask and the moon cycle
<greyback> yayz
<racarr> but I think
<racarr> the client :)
<racarr> and I feel rather strongly about it XD
<greyback> okies. I'm not going to open this discussion :)
<greyback> it's not my business! :D
<racarr> haha
<racarr> well, it sort of is, part of the theory behind client side decorations
<greyback> well yes, that's true
<racarr> is that it provides a more uniform model to the shell and mir (simplifying them)
<greyback> yep
<racarr> i.e. you have a surface, and it has x, y and w/h and you can treat them all the same
<racarr> as opposed to like
<racarr> x, y, w/h, border w/h, frame w/h
<greyback> indeed. I see that PoV.
<kgunn> greyback: but are you thinking there should be some common do-hicky that does common window decorations?
<greyback> kgunn: for consistency yes.
<kgunn> unity-mir layer going to be the bucket for everything shell & mir refuse to own :)
<greyback> something has to draw them, I'm just curious as to what's the best place for it
<racarr> greyback: It becomes difficult to model input, with server side decorations, without allowing the concept of embedded surfaces
<greyback> racarr: now that is something I hadn't considered. hmm
<racarr> not impossible, it's just complex, so I lean towards client side decorations, as the consistency bit
<racarr> is solved fine by a libdrawthedecorations that all the toolkits use
<racarr> and, of course applications/toolkits can misbehave
<racarr> but we allow that anyway with "Freestyle" surface type
<racarr> s
<racarr> which are undecorated
<racarr> i.e. chromium
<greyback> yep, it's only a desktop issue. I see your technical point, that's a good one.
<greyback> From user perspective, I definitely always want my close button drawn by something. So as long as we patch all the main toolkits, I'll be happy
<racarr> greyback: I think we can enforce
<greyback> I do like how easily you can draw window decorations with QML on kwin. But that's just a "nice to have"
<racarr> no showing up on the screen unless you tell me where the close button on your decorations are
<racarr> greyback: Couldn't it be the same client side though?
<greyback> racarr: could be. But 1 QML engine in total, versus one per client - would be a lot more expensive
<mlankhorst> is it hard to replace install mir and replace the GLES drivers on nexus4 with mesa?
<mlankhorst> s/replace//
<greyback> racarr: I did say: "I'm not going to open this discussion" :D Sorry, please get back to your work
<racarr> ehe I understand
<racarr> yes sorry! I am
<racarr> ...a little hyperactive on discussions today it seems
<greyback> nah, I don't want to trouble you with discussions that have happened a meellion times or more on the internets
<kdub> tvoss, pong
<kgunn> mlankhorst: http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html
<kgunn> mlankhorst: and actually...you can see all the instrucations here http://unity.ubuntu.com/mir/
<kgunn> mlankhorst: and technically...you're using the android compile gles drivers
<kgunn> on nexus4
<mlankhorst> yeah, but robclark's been working on freedreno, I wonder if I could make it work with mir
<kdub> mlankhorst, in theory, it could
<kgunn> mlankhorst: yeah...in theory
<mlankhorst> that's fine, I don't expect it to completely work anyway
<kgunn> mlankhorst: only worry might be egl-hwcomposer shenningans...but if rob got something working w vsynch likely it'll work
<mlankhorst> I'm not even sure if scanout works at this point, might be worth investigating though :)
#ubuntu-mir 2013-05-23
<racarr> Nothing quite seems to destroy my focus like a cyclic dependency
<racarr> problem...
<racarr> when thinking in circles becomes shockingly literal :(
<racarr> I guess the gmail migration worked because I just started getting work emails on my phone
<racarr> *gulp*
<kgunn> racarr: dont work all night 8am call w greyback
<hikiko>  /j #eclipse
<hikiko> sorry :p
<alf__> alan_g: @fix-bug-1108715, I propose that we sent an email to the list to alert people about the name change (I have been bitten by this in the past)
<alan_g> alf__: good idea.
<alan_g> "the list" == mir-devel?
<alf__> alan_g: that would be my choice
<alan_g> alf__: looks like jenkins is going to avoid confusion - it is flaky again. :(
<alan_g> alf__: did you see the email? (I thought I'd opted out of gmail, but I've not seen any email since the migration.)
<alf__> alan_g: Yes (the fix-bug-1108715 email). I opted out, too.
<alan_g> alf__: I guess opting out worked for you. My account was migrated anyway.
<alan_g> alf__: there a couple of racarr's MPs that (to me) look fit to land - do you want to check them first?
<alf__> alan_g: I will take a quick look. If everything is ok I will top approve.
<alf__> hikiko: basically you will build an SDL client platform and an (unused for now) GBM client platform
<alf__> hikiko: oops, you will build an SDL *server* platform
<hikiko> yes that's what O a, doing
<hikiko> I am*
<hikiko> and it works
<hikiko> the prob is
<hikiko> in the client
<hikiko> where I have to do the same
<hikiko> and I wonder
<hikiko> if I have to implement an sdl_client_platform
<hikiko> and use the gbm for buffers
<hikiko> as I do in the server
<hikiko> or
<hikiko> use the gbm as it is
<hikiko> (add the sdl platform only in CMakeLists as you suggested)
<hikiko> I think I ll try first what you suggest
<hikiko> which is the simplest
<hikiko> and if it doesn't work i will do a dummy implementation
<hikiko> just to have the client compiling without the vt complains :)
<alf__> hikiko: It's possible that you will be able to just use the gbm platform, but that's for the future. For now just try to compile the gbm client platform (check libraries/includes).
<alf__> hikiko: Can you pastebin the build errors you are getting?
<hikiko> if i don't change anything at the client
<hikiko> i don't get any build errors
<hikiko> but I have runtime errors
<hikiko> wait a moment because now I have changed the branch
<hikiko> alf__, I'll try what you said and if I get any build errors I will paste you the output I ll ping you later :)
<alf__> hikiko: sure, thanks
<alf__> hikiko: also ensure that you are using the right (the ones you build in the tree) render_to_fb and libmirserver, and not the ones in the system path e.g. /usr/(local/)...
<alf__> hikiko: if it is a runtime error you are getting, it maybe that you are using a libmirserver that still uses a gbm server platform
<hikiko> yes, that's what I told you that was happening initially, I was using the gbm_platform when I compiled the gbm client library,
<hikiko> I implemented an sdl dummy client platform
<hikiko> because there's a function that returns
<hikiko> which platform to use
<hikiko> anyway, let me try and I ll come back to you later
<alf__> hikiko: There may be a misunderstanding here. The client platform shouldn't be a problem at runtime in any case (libmirclient is not used by render_to_fb). I am saying that you should check that at runtime you are using a *libmirserver.so* built with the right *server* platform (i.e. the one you built in your sdl tree)
<hikiko> oh
<hikiko> I see
<hikiko> hmmm and if not then how can i change this?
<alf__> status: Investigated stress test crash, proposed fix+test MP
<racarr> Morning
<alan_g> Afternoon
<racarr> kgunn: I there a hangout?
<racarr> I joined the one in the calendar but no one is there
<kgunn> https://plus.google.com/hangouts/_/e1a9426c9efc173c7ab60b17323aafbf56b9ae06
<kgunn> kdub: ^
<racarr> alan_g|tea: Have a few minutes?
<alan_g> racarr: sure. What's up?
<racarr> alan_g: I have been working on this branch...
<racarr> step 1. Move input fds to ms::Surfaces, refactor a bunch of the input classes in this process.
<racarr> 2. Port InputDispatcher to use an InputTargetEnumerator (rather than this setInputWindows stuff copying the stack)
<racarr> I guess, the thought is. It's a huge branch, and I feel like you will end up reviewing it since you have seen the most of the input stuff
<racarr> do you want one giant diff or should I split it in to sequenced branches, even if they don't necesarily make sense by themselves (like there is no acceptance test motivating 1)
<alan_g> I guess the two steps are likely easier follow.
<racarr> ok
<racarr> alan_g:
<racarr> Want to talk about options too?
<alan_g> racarr: real options? http://www.infoq.com/articles/real-options-enhance-agility
<racarr> alan_g: Let me learn :p just a sec
<alan_g> racarr: sorry, didn't mean to distract you. What do you want to talk about?
<racarr> alan_g: Haha no, interesting. In the language of that article I would call what I am talking about settings
<racarr> or something instead
<racarr> alan_g: There are lots of little input setting, like
<racarr> various mouse acceleration coeffecients, key repeat rate,
<racarr> key layout, etc
<racarr> that I want to expose. But I don't want
<racarr> well. I think they will be a lot of noise in default_server_configuration.cpp
<racarr> and it doesn't really seem like they belong in --help
<racarr> so I am trying to figure out how to add some hierarchy to the option system
<alan_g> racarr: It's been a while since I looked at the boost.Options docs. I don't remember much hierarchy
<racarr> alan_g: There isn't any really
<alan_g> racarr: do you need them on the command-line or would having them only in env or config file be OK?
<racarr> alan_g: I think env and config file only is perhaps preferable
<racarr> so I thought of trying to use another instance of program options
<alan_g> racarr: that's supported by the boost stuff (but we don't use it yet)
<racarr> but there is lots of coupling with DefaultServerConfiguration
<racarr> alan_g: Well the thing is I don't want to shove them all in the main
<racarr> options lists.
<racarr> because right now, say maybe there are 5 or 6 of them
<racarr> but I think it could quickly get out of control
<alan_g> so you think it is time to do something cleverer?
<racarr> I think so?
<alan_g> Well the "simplest thing that might work" is just to add them to what we have. We can rework after.
<racarr> maybe its not, maybe its enough to have like, mir::DefaultServerConfiguration::the_input_options, that calls something like mi::create_options and then uses the same parse enviroment as in DefaultServerConfiguration
<racarr> Mm. That's true
<racarr> maybe I should just do that
<racarr> the only two I really care about is key repeat and pointer acceleration
<alan_g> racarr: you can also do stuff like --input-params key-repeat=2,pointer-acceleration=100,...
 * kdub likes that a bit better than secret config files
<racarr> hmm
<racarr> Seems like it's time to write a scheme interpreter
<racarr> --input-params (defun key-repeat-function keycode....
<racarr> :p
<racarr> hmm that is kind of nice.
<racarr> your suggestion not the scheme
<alan_g> racarr: I don't see 5 or 6 more command line parameters as a problem
<racarr> Ok :)
<kdub> i don't mind that either
<alan_g> kdub is in a good mood today.
<kdub> very agreeable :)
<racarr> XD
 * kdub goes to work on client swapinterval0
<racarr> so um
<racarr> should new files
<racarr> in 3rd_party/android-input (this question is already sounding incorrect...)
<racarr> use mir style or android style?
<kdub> i'd guess android, but then again
<kdub> we've effectively forked it, so if we're transitioning everything gradually to mir style then...
<racarr> the thing is this is a new interface to be
<racarr> implemented by something in mir::input
<racarr> so if I use the style it's forEach instead of for_each lol
<racarr> kdub: Yeah that's kind of what I was thinking
<tvoss> racarr, +1 on mir style
<racarr> class SurfaceStack : public compositor::Renderables, public input::InputTargets
<racarr> the tldr version of mir
<racarr> XD
<racarr> tvoss: Android license or GPL/LGPL?
<racarr> I think android license...?
<racarr> its not particularly important because it's an interface with one method, but I guess we will have to answer this at some point
<kdub> i thought apache on most of it
<racarr> mm but for new files
<tvoss> racarr, ack, make it LGPL I would think ... but will check back on that
<racarr> apache or
<racarr> LGPL
<tvoss> hmmm
<racarr> It's a little hard to answer I think because
<racarr> adding new files to 3rd_party/something
<racarr> is a bit of a contradiction
<tvoss> racarr, exactly
<racarr> It would be good to talk about the long term trajectory for the input stack
<racarr> removing setInputWindows (and then perhaps InputWindowHandle) in this way
<racarr> it's easier to start sucking the large android side components
<racarr> in to smaller mir side components
<racarr> i.e. in this case, the InputDispatcher had a hidden responsibility (track and enumerate the list of input targets), so this gets sucked over to mir side. Next perhaps, you move over another responsibility (select target from list of targets) and farm this out to the shell
<racarr> I don't know if this is what we want to do, or if we want to keep it in it's little bubble
<racarr> and over what timescales, etc.
<kdub> racarr, maybe we should set up a meeting to talk about it... i'm sure a lot of people would be interested
<racarr> kdub: Hmm sounds like a good idea.
<thomi> morning
<kgunn> thomi!
<thomi> o/
<thomi> what's up in your kneck of the woods kgunn?
<kgunn> success building phablet from scratch (which i'm sure is nothing to most people)
<kgunn> thomi: btw, have you heard from robert A ?
<thomi> kgunn: nope, what would I be hearing from him about?
<kgunn> thomi: baby
<thomi> ahhh, no
<thomi> I haven't heard anything, sorry :)
<kgunn> hope all is ok
<kgunn> alf had a fix for stress test
<thomi> sweet - any idea if it landed?
<kgunn> i think he had you on for review :)
<thomi> ahh sweet
<kgunn> https://code.launchpad.net/~afrantzis/mir/fix-stress-test-crash-1183327
<thomi> I'll take a look
<racarr> lunch time!
<kgunn> racarr: kdub ...i think i just merged the upstream hybris changes for n7, built an image & its actually working!
<kgunn> hell might have frozen over...need to check :)
<kgunn> kdub: before i proceed further are the instructions for android mir still good?
<kdub> kgunn, should be :)
<kdub> i might give it a try too
<kdub> not really sure of the hwc situation on that device
<kgunn> mmm, well, its a ics based device
<kgunn> but ics was first rev...and jb definitely cleaned up some "back doors"
<kdub> either way, back-up gpu composition (hwc-less fallback) worked fine when i tried it in... febuary?
<kgunn> kdub: to be sure i half way understood it :_
<kgunn> :)
<kgunn> was the "nvidia_hack"
<kgunn> the thing that you were toggling ?
<kdub> kgunn, no
<kgunn> hmmm
<kdub> kgunn, its a bit deceptive... things will work until you try to have ipc clients
<kgunn> ah
<kgunn> so best test, load mir and see
<kdub> yeah
<racarr> I couldnt make in process
<racarr> clients work
<racarr> on 7 that is
<bschaefer> Hmm getting a pure function call when trying to release the mir connection? Stacktrace: http://paste.ubuntu.com/5695233/
<bschaefer> and code doing the releasing...: http://paste.ubuntu.com/5695235/
<kgunn> kdub: wrt instructions...the cross-compile says to add ppa to get armhf....but those all fail
<kgunn> kdub: ...and i already have a build branch of the image i'm running
<kgunn> kdub: ring any bell?
<kgunn> e.g. are you still relying on that package pull...or are you using armhf libs some other way
<kdub> kgunn, still relying on the package pull
<kdub> kgunn, you can cross compile normally from within a chroot
<kdub> the cross compile script is just the sane way for a development work-cycle
<kgunn> kdub: right...looking now
<kgunn> kdub: but what's weird...if you go here http://us.archive.ubuntu.com/ubuntu/dists/quantal/universe/
<kgunn> there's no armhf...not sure how that's working for you
<kdub> we're on raring
<kdub> saucy probably works too
<kdub> kgunn, are you trying to cross compile, or compile within a chroot?
<kgunn> yeah...sorry i was poking around
<kgunn> cross compile
<kgunn> i know we're on raring, i was poking around to see if they had been there on quantal or something
<kgunn> ......arg....nvmd, found 'em
<kdub> cool
<kdub> hmm, cant ping launchpad
<racarr> Whee. RUN      ] TestClientInput.multiple_clients_receive_motion_inside_windows
<racarr> [       OK ] TestClientInput.multiple_clients_receive_motion_inside_windows (18 ms)
<racarr> and they dn't talk back about it either :D
<racarr> ugh
<racarr> there is a race condition in the acceptance test (or perhaps in the actual code XD)
<racarr> sometimes the hover exit event (this test drags the mouse over the boundary between two surfaces)
<racarr> doesn't get emitted
<kgunn> kdub: i feel stupid...i was confused b/c by output failures coming from regular repo's....
<kgunn> since you add armhf to dpkg config
<kgunn> it looks for them too there i guess....
<kgunn> but it found the ports just fine
<kdub> kgunn, cool :)
<kgunn> kdub: check my head tho....so i was going to take the hybris i built & plop it into the dir where mir is looking (replacing whatever i just downloaded)
<kgunn> in theory should work right?
<kdub> kgunn, at link time on the host, as long as they have the same symbols, it doesn't matter
<kdub> at runtime, the right library has to be installed into the linker search path
<kdub> so short answer... yes :)
<kgunn> :) right but i might not need to
<kgunn> i get it
#ubuntu-mir 2013-05-24
<racarr> annnnd race resolved
<thomi> anyone awake in here? RAOF perhaps?
<thomi> I'm pretty sure I've found another race condition in mir - this time in the client library. :-/
<alan_g> alf__: re Thomi's email "Mir client library thread safety" - shall I deal with this one?
<alf__> alan_g: I haven't started looking into it yet, so feel free to take it
<hikiko> wow what sort of magic does boost and when you assign a foo shared ptr to a bar shared ptr the ptr has knowledge of the correct type?
<hikiko> it's not based at the template parameter at all
<hikiko> :s/boost/std now :)
<alan_g> hikiko: the first "magic" pointer was this one http://www.octopull.co.uk/arglib/TheGrin.html - shared_ptr is clever - it also allows a user defined deleter
<hikiko> yes yes!! i just saw the boost documentation hehe :) but i can't imagine how the hell they implemented it!!!
<hikiko> i tried without the make shared to see where's the magic and it was in the assignment, then I found the doc but still!! i don't understand it!
<hikiko> I got how it works though :) cool!!!
<alan_g> :)
<alan_g> hikiko: have you seen https://code.launchpad.net/~alan-griffiths/mir/Wno-non-virtual-dtor/+merge/165551 ?
<hikiko> oh no I didn't :) I started geting mir notifications today, that's cool :D
<hikiko> so, you get a warning
<hikiko> immediately
<hikiko> btw alan_g does it happen to you to trigger internal compiler errors with gcc 4.7?
<alan_g> It happens to everyone
<hikiko> cool :) i am not the only one :)
<alan_g> Is a bug in 4.7.2
<hikiko> i switch to clang from time to time, when I have no info about the error at all
<hikiko> but i hope they fix it soon!
<alan_g> hikiko: it is fixed upstream
<hikiko> oh cool then I can just compile the new version
<alf__> alan_g: hikiko: I have 4.7.3 (from raring archives) and I haven't seen compiler errors for a while. I am not sure if 4.7.3 contains the fix, or I have been lucky enough not to trigger them...
<alan_g> alf__: it is fixed in 4.7.4 (and 4.8_
<alf__> alan_g: perhaps the fix has been backported to the ubuntu 4.7.3 packages?
<alan_g> alf__: no, you've just not compiled bad code
<alf__> alan_g: ok
<hikiko> hmm i have 4.7.3
<hikiko> maybe i have to compile the 4.7.4 :)
<kdub> good morning, status, working on swapinterval 0 for clients
<alan_g> Good afternoon. status tweaking code to get the customisation points I want
<alf__> kdub: does that involve BufferSwapperMultiSpin?
<kdub> alan_g, alf__ with adding a swapping algorithm for swapinterval0, i'm weighing 1) just making BufferSwapperMulti more capable or 2) making BufferBundleSurfaces able to change between different algorithms
<kdub> thoughts?
<kdub> i'm sort of leaning towards 2), just because we'll have resizing, composition bypass, synchronous and asynchronous modes
<alan_g> kdub: changing algorithms is something that might help switching to/from composition bypass
<alf__> status: investigating performance issues in Mesa (for some reason we wait for a GPU fence for ~5ms every frame, which doesn't happen for X11)
<alf__> kdub: I vote for (2), too. Btw, in order to get some performance numbers for the Mesa investigation I hacked together a spin version of BufferSwapper (not properly validated or tested though)
<alf__> kdub: I can push it somewhere if you are interested
<alan_g> kdub: for the avoidance of doubt: +1 for 2
<kdub> alf__, yeah, that sounds useful for looking at android performance in the meantime
<alf__> kdub: ... or if your plate is full, I can take on the spin bufferswapper work
<kdub> alf__, i think today i'll focus on making the mc::BufferBundleSurfaces switch between mc::BufferSwapper algorithms
<kdub> so if on monday you want to write a mc::BufferSwapperSpin : public mc::BufferSwapper, that sounds like a good parallelization of work :)
<alf__> kdub: sounds good to me, too :)
<alan_g> sounds excellent to me too. ;)
<alan_g> kdub: what's the motivation for mga::GraphicBufferAllocator (AFAICS it adds alloc_buffer_platform(), which doesn't really do anything other than expose a different interface to what alloc_buffer() already does).
<kdub> alan_g, admittedly its a bit weird... but there's a mc::BufferUsage and an mga::BufferUsage, with the only difference being that mga::BufferUsage has a framebuffer type
<kdub> that android needs to allocate in the android platform, and in the review of the branch, we decided not to put the use_framebuffer type in mc::BufferUsage, because its not relevant to gbm
<alf__> kdub: alan_g: IIRC, the reason was because BufferUsage::framebuffer was not relevant to/needed by the compositor interface, it is an internal Android flag.
<alan_g> kdub: OK, that fine point was eluding me. So the real question then is should we really be extending the mc::GraphicBufferAllocator interface to give us an interface for allocate frame buffers. (Or should that be a different interface.) *Thinks..."
<kdub> oh, also, us bank holiday on monday
<alan_g> kdub: uk too
<alan_g> And the sun has just come out here...
<alf__> hikiko: Hi! Any news about the VT runtime issue we were discussing yesterday? I am curious about what could be going on there.
<alf__> alan_g: The cosmos is telling you to end your week/day ;)
<alan_g> alf__: the cosmos has to wait - I want to get something finished first. ;)
<alf__> alan_g: :)
<hikiko> lol @alan, alf__ sorry i am busy with something this very moment I'll ping you later
<alf__> hikiko: np
<kgunn> kdub: alf ....read the scroll back, just wondering....the reason to create a mga::BufferUsage was to avoid having an android flag in the compositor ?
<kgunn> but conceptually...it just means "this is a frame buffer"
<kgunn> right?
<kdub> right, but gbm doesn't need to make a distinction
<kgunn> kdub: sure....but it doesn't hurt to have that info along for the ride either does it ?
<kgunn> note...you can tell me, too late...don't unearth this :)
<kgunn> just thinking that offscreen & fb's have so much in common...
<kgunn> kdub: back to alan_g 's question about should it have a seperate interface for fb alloc
<kgunn> i suppose to match it should
<alan_g> kgunn: I've already split the interfaces on my WIP - don't think too hard about it.
<kgunn> :)
<kgunn> alan_g: i might hurt myself
<alan_g> kgunn: I hope that's not a threat. ;^)
<alf__> kgunn: the reason for mga::BufferUsage, isn't so much that gbm doesn't need the flag. It's that the compositor interface (which mc::BufferUsage is part of) doesn't need the flag. We would be adding a flag to the external interface just to service an internal need of an unrelated component. Of course, this may change if we want to allow external (to the compositor) entities to ask for framebuffer surfaces.
<alf__> kgunn: (to ask the compositor components for fb surfaces)
<kgunn> alf__: thanks, makes sense.... (you guys prob consider sloppy, but i don't mind having things for "other clients" in api's)
<alan_g> kgunn: it depends on the type of API - here we're defining the *minimum* needs of compositor to minimise coupling.
<kgunn> actually making me think...so would control for going in/out of bypass lie in the unity-mir layer ?
<kgunn> e.g. is the compositor going to be smart (oh you're opaque & full screen)...or dumb (special wm client, you tell me when you want to go straght to fb)
<kdub> off the top of my head, i'd say it wouldn't bypass the unity-mir layer, (be dumb)
<alan_g> kgunn: I don't need to decide that (yet). ;)
<kdub> yeah, we haven't grappled with the question fully
<kdub> yet!
<alan_g> 1. Get a CB mode working  2. Get CB mode switchable 3. Decide how to chose CB mode.
<kgunn> alan_g: ;) sure...i just enjoy topics like this
<alan_g> kgunn: np this is how I get informed before the decision needs to be made
<kgunn> :)
<alan_g> And the sun has just come out here...(again - following dark clouds and heavy rain). Must be time to go.
<alan_g> kdub: kgunn - have a good holiday weekend!
<kdub> you too alan_g|EOW
<kgunn> alan_g|EOW: you too
<kdub> i'm tempted to name this class mir::compositor::SwapperSwapper
<racarr> kdub: For resizing?
<racarr> I thought about a swapperswapper once XD
<kdub> i think SwapperSwitcher is a better name
<racarr> yes probably
<racarr> just drudging through some clean up, resolving little todos I left around on this input branch
<racarr> fixed the race in the acceptance test though, and touch input picking with multiple clients is working well :)
<racarr> :D
<racarr> completely removed the mir::input::android namespace
<racarr> from default server configuration
<racarr> Lunch/laundromat time!
<racarr> My present for all of you to joyfully review come monday: https://code.launchpad.net/~robertcarr/mir/rebuild-input-targeting/+merge/165712 ;)
<kdub> only the runner up to the biggest diff this month :)
<kdub> after glm removal
<racarr> kdub: XD. Besides the acceptance test it's actually
<racarr> pretty balanced in +/-
<racarr> it's just different
<racarr> it just made me giggle when I checked at the end...
#ubuntu-mir 2013-05-26
<thomi> anyone alive in here?
#ubuntu-mir 2014-05-19
<stgraber> is anyone from the mir/unity8 team around?
<stgraber> I'm preparing a demo for Malta and I'd like to know if it's at all possible to get unity8+mir running under kvm?
<stgraber> so far I tried with all video drivers and they all get me an error about some drm operation being unsupported
<stgraber> I can get things working the way I want on bare metal but it's slightly annoying having to reboot every few minutes to get out of Mir and back to X...
<alf_> stgraber: we haven't tried under kvm yet. Actually running under VMs of all kind is a topic for Malta next week.
<alf_> stgraber: Why do you need to reboot to go from Mir to X? Doesn't 'sudo restart lightdm' work for you?
<stgraber> alf_: so the demo I'm preparing is running unity8+mir from utopic inside an LXC container on trusty. I got things to work though once unity8 starts I'm unable to kill it or even VT switch
<stgraber> so far the only way I've found out of it is to use sysrq to physically reboot my machine...
<alan_g> stgraber: I saw an email that might apply (from Friday). Forwarding...
 * ogra_ remembers seeing a bug about Mir not working in virtual envs
<alan_g> But like alf says this is something we're getting to real soon now
<stgraber> cool, that'll be helpful. Until then, how am I expected to get unity8+mir to exit once started? I'm sure there's a way but it's either broken (possibly my fault) or I just haven't found it yet ;)
<anpok> there was a strange ci failure on friday it seems - could someone retrigger https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806/comments/525069
<alf_> anpok: sure
<alan_g> stgraber: "stop unity8"? SIGTERM? Ctrl+Alt+Backspace?
<stgraber> alan_g: stop unity8 or sigterm would probably work if I could get to a shell first (I'm working away from home so just have the one laptop). ctrl-alt-backspace didn't work. VT switching hotkeys didn't either.
 * alan_g thinks if input isn't working... "start unity8 & (sleep 10 && stop unity8)"
<stgraber> well, input seems to work, I can type in unity8 just fine, I just can't figure out the right sequence to get out of it :)
<alan_g> stgraber: is input still working after starting unity8?
<alan_g> "ctrl-alt-backspace didn't work. VT switching hotkeys didn't either"
<stgraber> text input after starting unity8 works fine, it's just the ctrl-alt-* hotkeys that seem entirely ignored
<alan_g> stgraber: so you can start the terminal app?
<alan_g> alf_: I'm tempted by the idea that we should have "slow, clumsy, unreliable, muted" test executable for bad tests rather hiding them as unit/acceptance tests. It would make the problem more visible and provide a focus for any "clean up" drive.
<alf_> alan_g: A lot (all?) of our slow tests are actually stress tests. I would be OK with having a separate stress test category. A problem I see with moving all clumsy/unreliable etc tests to a separate executable is that we would need to (de)duplicate the infrastructure needed for them to run.
<alf_> alan_g: I agree that having a separate executable would increase visibility, but on the other hand it may also reduce the incentive to do so. For example, a mentality of: we have a category for bad tests so it's OK to have a bad test and put it there and forget it
<alf_> alan_g: "reduce the incentive to fix it"
<alan_g> alf_: we'd need a rule "for each new new bad test you write you must remove at least one existing one"
<alan_g> You and I have both proposed DISABLED tests recently...if we'd had to fix an existing test...
<alan_g> alf_: I do agree that having stress tests in mir_unit-tests is misleading at best (as is requiring libumockdev-preload)
 * alan_g hates waiting 30sec for tests to run
<anpok> https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806 any objections against landing this?
<greyback> alf_: just to confirm Compositor::stop should be called on display blank for a nested server?
<alf_> greyback: do you mean as part of the sequence Compositor::stop, reconfigure, Compositor::start?
<alf_> greyback: I think that at the moment only the host server (i.e. unity-system-compositor) does anything about the "power off" event
<stgraber> system-settings: /build/buildd/platform-api-1.1.0+14.10.20140515.1/src/ubuntu/mirserver/ubuntu_application_api_mirserver.cpp:106: UApplicationInstance* u_application_instance_new_from_description_with_options(UApplicationDescription*, UApplicationOptions*): Assertion `surface_coordinator' failed.
<stgraber> any idea what would cause that? ^
<stgraber> it's apparently preventing me from starting any app from unity8 here
<stgraber> (that's still in my weird LXC environment, so I may be missing some env variables or packages)
<alan_g> stgraber: for platform api I usually ask greyback YMMV
<stgraber> greyback: ^
<greyback> stgraber: have you QT_QPA_PLATFORM set in your env?
<greyback> stgraber: for apps, it should be set to "ubuntumirclient"
<stgraber> greyback: ah, that may be the problem then, I have it set to ubuntumirserver in order to start unity8, it may then get picked up for the rest too...
<greyback> stgraber: yeah, ubuntumirserver only for unity8, ubuntumirclient for all apps
<ogra_> stgraber, take a look at /etc/environment on a phone/tablet
<stgraber> greyback: oh, looks like I can drop the export as the upstart job does that for me nowadays
<ogra_> there are a lot of env vars
<greyback> stgraber: it does indeed
<ogra_> (half of them probably obsolete)
<ogra_> QT_SELECT=qt5 .... QT_IM_MODULE=maliitphablet ... QML2_IMPORT_PATH=/usr/lib/arm-linux-gnueabihf/qt5/imports ...
<ogra_> these look relevant
<stgraber> greyback: that did the trick, thanks!
<greyback> stgraber: yw
<ogra_> the QT_SELECT one is needed so that apps start up fine btw ...
<ogra_> else it will try to default to Qt4
<stgraber> ogra_: I'll take a look at those, I still have an issue with libEGL complainig that my platform is unsupported so maybe one of those will fix that (required by at least the webbrowser AFAICT)
<ogra_> ubuntu-touch-session also sets a few ...
<ogra_> in the lightdm bits it ships
<ogra_> (this is all a serious mess we need to clean up beofre RTM)
<racarr__> morning
<anpok> hi
<anpok> hm is there a workaround for the issue with gdb?
<alan_g> anpok: what issue?
<anpok> the current unicorn version crashes when it tries to load the mir_unit_tests
<anpok> https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1319316
<ubot5> Ubuntu bug 1319316 in gdb (Ubuntu) "gdb: Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)" [Undecided,Incomplete]
<alan_g> dunno - I've not got a problem
<anpok> then dont upgrae :)
<kdub_> any other reviews on https://code.launchpad.net/~kdub/mir/post-if-optimizable/+merge/217991 ?
<alan_g> Why would I? ;)
<mterry> racarr__, kdub_, (or others): I'm looking at an issue in split greeter mode.  When sliding the greeter away, the user can see a bit of their session underneath because the greeter is transparent.  This works fine when seeing the unity8 shell underneath.  But if the user session is running an app on top, the surface appears just black, until the session is focused again.  Why might that be?
<racarr__> top approve https://code.launchpad.net/~mir-team/mir/cursor-spike-bonus-phase-correct-gbm-cursor-hide/+merge/219764 ?
<racarr__> mterry: No immediate ideas -.-
<racarr__> turning it over in head though
<mterry> racarr__, I believe the app would be 'lifecycled' during that period
<mterry> I think...
<mterry> But I don't know if the black is expected behavior in that state (I would think not, just keep the last frame, eh? but who knows)
<racarr__> hmm I guess I would expect the last frame too
<racarr__> certainly not black
<greyback> mterry: check if the app surface is hidden when lifecycles. I suspect it might be
<racarr__> ah
<anpok> mterry: is unity8 rendering in that case?
<anpok> while sliding away the greeter.. i mean..
<mterry> anpok, I don't know about active rendering
<mterry> anpok, let me test with something that woulld play animation
<mterry> anpok, yes, active rendering
<racarr__> Just reading mps...
<racarr__> This is the last time I ill bring it up lol but
<racarr__> I really feel we made a mistake with server side window decorations
<racarr__> already there is all this stuff to support them, and various concerns (i.e. even in DPI branch)
<racarr__> and I don't remember any reasons to do server side.
<racarr__> Also kind of feels like we are at MP gridlock again
<racarr__> kgunn: What is the deal on RAOF or someone getting a touchscreen...I've found out whats wrong with desktop touchscreens
<racarr__> but am not totally confident in fixing without doing some experimenting
<kgunn> racarr__: can you purchase one reasonably ?
<kgunn> if so, please do and expense
<kgunn> racarr__: btw, i thot voss wanted "mir" side decorations, but client side not server side ?
<racarr__> Haha theres always an option 3
<racarr__> um...I wasnt aware thats what tvoss wanted, I know its come up before
<racarr__> sounds better than server side to me.
<kgunn> racarr__: yeah...but i can't remember why i'm convinced of that...
<racarr__> but I think since
<racarr__> um
<racarr__> not this last london sprint
<racarr__> but the one before that
<racarr__> everyone has been on the server side decorations boat
 * kgunn wonders if the terms are getting overloaded and not specific enough
<racarr__> also now we have some server side decorations
<racarr__> haha, well you can get more specific
<racarr__> but server side/client side is still meaningful as
<racarr__> rendered by the server or rendered by the client
<racarr__> you could also say "in/out buffer"
<kgunn> right, i think people say "server side"....when they really don't mean the server side
<kgunn> e.g. "client side of mir"
<racarr__> hmm
<kgunn> racarr__: but anyway...its worth bringing up
<racarr__> maybe some people. I dunno
<kgunn> with voss and duflu
<kgunn> maybe even on mir-devel...
<racarr__> I know the shell team is on drawing the decorations server side with qt
<racarr__> because its quite easy and nice...im not sure how much harder it really is on the client though (I dont think it is)
<racarr__> *shrug*
<racarr__> ILl bring it up in malta!
<racarr__> lol
<anpok> i thought there was a discussion to allow both
<racarr__> certainly client side is allowed, I mean you can freestyle window type
<kgunn> anpok: 4th option :)
<racarr__> then draw your own decorations
<anpok> that certain areas were prepared for the client to render ontop of the decoration the server would provide if necessary
<racarr__> oh in a seperate client rendered buffer...
<anpok> i think tvoss shared a drawing some time ago
<anpok> i think so
<anpok> well
<racarr__> I remember that coming up too lol, yes I think that is tvoss's concept
<anpok> separate buffer should be the easiest way to do that
<racarr__> I still cant think of any reasons
<racarr__> to do anything besides client side decorations though
<anpok> :)
<racarr__> which is the simplest
<racarr__> and almost certainly
<racarr__> the most efficient
<racarr__> I guess
<anpok> that way you can easily ensure that each decoration works and looks the same, and if clients are not supposed to draw any decoration it is far more easy to provide the client surfaces without decoration
<anpok> of course you could also let the client draw to one buffer with decoration, and request additional information which parts of the buffer belongs to the decoration and which is the actual content..
<racarr__> but I mean, I dont think we have any cases like
<anpok> we?
<racarr__> this windo has a decoration and then loses it without
<racarr__> client cooperation
<racarr__> what is
<tvoss> racarr__, the real question is: How do you enforce some baseline consistency for the decorations if you only do client side decorations?
<anpok> you mean actively request rerender because you need the client with different decoration configuration?
<racarr__> tvoss: librender_unity_decorations::RenderDecorations(EGLSurface,Context)
<racarr__> in toolkit ports
<anpok> then you are as complex as ssd
<racarr__> anpok: I mean the client doesnt change decoration configuration
<tvoss> racarr__, that's a guideline at best :)
<racarr__> ever unless it changes window type
<racarr__> tvoss: But then why support freestyle surfaces? I mean chromium will want that right, presumably some other things
<racarr__> so there is always going to be a way to do your own window decorations
<tvoss> racarr__, chromium would actually be better off with separate surfaces for decorations
<tvoss> racarr__, sure,but freestyle is really only meant to be reserverd for special cases like vmware fusion mode
<racarr__> tvoss: "thats a guideline at best"
<tvoss> racarr__, sure, but we can guard usage of that surface type with an apparmor hook
<racarr__> That's true
<racarr__> I guess I didn't think we were taking rogue decorating apps that seriously
<tvoss> racarr__, we would like to be able to at least
<racarr__> Mm.
<mterry> greyback, just getting back to you now about the "check if session is hidden when lifecycled" and yes, it is in unity-mir.  Would there be ill-effects if we don't do that?
<greyback> mterry: I don't apps running if the greeter hiding them
<greyback> +is
<mterry> greyback, sorry didn't parse
<greyback> mterry: ill-effects of a hidden session being lifecycled was the topic, no?
<greyback> ah
<mterry> greyback, ill effects if we lifecycle an app but don't hide it
<greyback> mterry: that's fine. No ill effects I can think of anyway. unity-mir does hide surfaces that belong to lifecycled apps, to optimize compositing just that little bit more
<mterry> greyback, I'll try a patch and see if that fixes my black screen behavior
<greyback> mterry: ok. That compositing point above is the only impact not-hiding will have - but I think we did that for a reason, so best not disable it altogether
<mterry> greyback, I'll see if bzr blame gives an explanation
<greyback> mterry: we did it as compositing with multiple apps open got too slow and the frame time went too high, so the UI juddered
<greyback> as the compositor was drawing the bottom surface, then the next one on top, then the next one, and so on
<greyback> which is wasteful as we know only the top surface is actually visible
<mterry> greyback, ah right...  that makes sense for apps hidden underneath
<mterry> greyback, but now I'm interested in just the top app
<mterry> greyback, it would be nice to have a way to suspend but not hide that app
<greyback> mterry: yep. Those operations will need to be de-coupled in unity-mir to fix your problem
<mterry> greyback, maybe it would make sense in this case to just not hide the focusedApp.  unity-mir has enough info to do that itself
<greyback> mterry: yep, that would be fastest option
<mterry> or either stage app I guess
<mterry> greyback, OK will test with that plan and propose an MP if it works for me
<mterry> greyback, thanks!
<anpok> hm we could also at some point stop using rgba buffers when other buffer types are available
<greyback> anpok: +1
<kgunn> AlbertA: i'm testing silo1 with the powerd rework..looks like greeter never returns after the first dismissal
<AlbertA> kgunn: did that make it in? https://code.launchpad.net/~albaguirre/unity8/use-new-display-power-state-interface/+merge/219552
<kgunn> AlbertA: yes, its in the mp list, but...package looks old ish...built on 5/16 ?
<AlbertA> kgunn: what does this say:
<AlbertA> adb shell cat /usr/share/unity8/Shell.qml | grep Powerd.Off
<kgunn> if (status == Powerd.Off && (flags & Powerd.UseProximity) == 0) {
<kgunn> and
<kgunn> if (status == Powerd.Off) {
<AlbertA> yeah it still the old version
<kgunn> AlbertA: ok, lemme rebuild
<kgunn> hmm
<kgunn> yeah...that'll take a while
<racarr__> the more I look at the compiz focus stealing prevention code the more im convinced
<racarr__> its in correct in like 4 places in the same function
<racarr__> ...*puts on blinders*
<mterry> racarr__, I know 2 don't, but surely 4 wrongs make a right?
<racarr__> damnit short email turned in to a small essay again :(
<racarr__> mterry: Lol maybe
<racarr__> rotating in a circle is actually very much like what happens to the truth values in this codepath
<racarr__> ol
<racarr__> ok afk for 20 minutes or so to clear head before I dive in to DDX
<racarr__> compiz code stirred up this whole dormant tree of my brain lol
<racarr__> back
<kgunn> AlbertA: looking good man...powerd stuff
#ubuntu-mir 2014-05-20
<bschaefer> RAOF, hey, how would one force mir to do double buffering? Seeing interesting issues/flashing (looks like the third buffer might be to much?)
<RAOF> bschaefer: I think you need to twiddle with the code to do that.
<bschaefer> RAOF, cool, ill dig into that :). Thanks!
<RAOF> bschaefer: Also, on desktop, bypass *requires* triple buffering. But you don't necessarily care about that if you're just debugging.
<bschaefer> RAOF, yeah, im just checking if its my code, or the apps code
<RAOF> bschaefer: You could also check the age on the buffer, client side, to detect if it's being triple buffered.
<bschaefer> as this is the only time i've seen the need for a frame damage using opengles + sdl
<bschaefer> thats a good idea as well
<bschaefer> RAOF, testing qemu out
<bschaefer> the current image i see: http://i.imgur.com/RZg6uhx.jpg (it only updates the textures on whats changed)
<RAOF> Whee!
<bschaefer> :), it'll be nice to get working haha
<RAOF> Also, maybe tiling?
<RAOF> Hm
<bschaefer> hmm, i think that image is after its freaking out
<bschaefer> when i throw a clear in
<bschaefer> i can see the textures updating only where somethings changed + width of the window
<bschaefer> so each frame, it updates a chunk of the window, but adding in buffers it seems to be flashing
<bschaefer> possibly an alpha issue?
<bschaefer> as i was running into an alpha issue with the pixel format before...
<bschaefer> (as with RGBA8888 selected for the texture + surface, i was getting an empty/grey window)
<bschaefer> forcing RGBX8888 let me see the textures
<RAOF> Hm.
<bschaefer> RAOF, ill show you two pictures of one clearing each frame, and one doing it how it normal is
<bschaefer> RAOF, otherwise ill debug what i can, and show you in malta
<RAOF> Yeah. Yay Malta!
<bschaefer> its going to be to warm :(
<bschaefer> but yay!
<bschaefer> RAOF, glClear before each from being drawn: http://i.imgur.com/MYUcRda.jpg
<bschaefer> RAOF, no Clear:  http://i.imgur.com/J4IiccE.jpg
<bschaefer> but yeah, ill see what i can find out :)
 * bschaefer should have use mir screen cast
<RAOF> :)
<duflu> bschaefer: I see nice screenshots. The gaps could well be Qemu's fault. But also check you're not relying on buffer-age. Just in case...
<bschaefer> duflu, sounds good
<bschaefer> duflu, im not 100% the issue, but ill dig around some more :)
<duflu> bschaefer: Also see if SDL2 on X11 has the same bugs ;)
<duflu> Qemu's SDL2 is new and possibly buggy in damage tracking
<bschaefer> duflu, works fine on X11 :(
<bschaefer> well actually
<bschaefer> i cant get the ubuntu iso install to come up
<bschaefer> possibly a bug there yeah
<duflu> bschaefer: OK then any simple SDL2 demos have similar issues?
<bschaefer> duflu, nope
<bschaefer> only sdl1.2
<bschaefer> with software rendering
<bschaefer> which i fixed with frame damage
<bschaefer> duflu, i also dont know qemu very well or how to use haha
<duflu> bschaefer: BTW if the mouse doesn't interact properly try: qemu -usbdevice tablet
<bschaefer> o nice, i've not even gotten to try the mouse out
<bschaefer> as the keyboard works
<bschaefer> so thats what i've been tessting
<duflu> Running Qemu in tablet mode will avoid it wanting grabs (which Mir lacks)
<bschaefer> yeah, thats something racarr__ brought up :), my main goal was to make pixels look good
<bschaefer> duflu, the only way to get sdl2 running as well is disable gtk and set sdl to 2.0
 * bschaefer hopes its in their damage code
<duflu> bschaefer: You mentioned 1.2... I thought you didn't support 1.2?
<duflu> If you do then Qemu's SDL1.2 support is much more mature
<bschaefer> duflu, i have a branch for it, but they aren't accepting patches :(
<duflu> bschaefer: Oh, fair point
<bschaefer> duflu, another reason, is they are creating a layer to turn 1.2 SDL API to 2,.0
<bschaefer> 2.0
<bschaefer> soo onces that layers there, we'll get all of 1.2 for free :)
<bschaefer> but yeah, i should test it out on 1.2
<RAOF> To the luncheon wagon!
<duflu> ping anpok
<anpok> pong
<anpok> i have the same gdb issue you had
<anpok> or still have?
<duflu> anpok: Yeah, it's annoying but in other news...
<duflu> anpok: Can you check this out? Seems to have only regressed last night: https://bugs.launchpad.net/bugs/1321077
<ubot5> Ubuntu bug 1321077 in Mir "[regression] [input] Scroll events are now always zero: event.motion.pointer_coordinates[0].vscroll" [High,Triaged]
<anpok> oh
<alf_> anpok: alan_g: Have you seen https://bugs.launchpad.net/mir/+bug/1321215 locally?
<ubot5> Ubuntu bug 1321215 in Mir "CI failures in CustomInputDispatcherFixture.custom_input_dispatcher_gets_started_and_stopped" [High,New]
<alan_g> alf_: no. But I've not been looking for it.
<alf_> alan_g: I wasn't looking for it either, it came looking for me :)
 * alan_g thinks CustomInputDispatcherFixture.custom_input_dispatcher_gets_started_and_stopped is a redundant name
<alan_g> alf_: let me grab latest updates and try it
<alan_g> alf_: this is just running on the phone? Or do you see it on desktop too?
<alf_> alan_g: I can reproduce it locally on the desktop 100%
<anpok> alf_: me neither
<alan_g> alf_: I hit it after 232 iterations on desktop
<alf_> alan_g: anpok: thanks, I have started investigating it, stay tuned
<alf_> anpok: when/where is InputDispatcher.start()/stop() supposed to be called ?
<alan_g> alf_: while you're there: CustomInputDispatcher.gets_started_and_stopped would be a better name.
<anpok> alf_: as part of the DisplayServer start and stop proces..
<alf_> alan_g: ack
<anpok> oh it seems to not wait for completion
<anpok> alf_: when I terminate the server process manually it did not fail within 2000 tries (which it did before) but I thougt the text fixture tear down does that already..
<alf_> anpok: I am almost done with an alternative solution, I will ping you
<anpok> oh it still fails
<anpok> just need to have more load
<anpok> ok
<Saviq> hey guys, we seem to have an issue on android with the new Qt 5.3: https://bugs.launchpad.net/unity8/+bug/1321189
<ubot5> Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged]
<Saviq> for some reason ShaderEffectSource, which is a component in QML that is, in essence, creating a texture from a QML element, for consumption in a shader
<Saviq> stopped working
<Saviq> everywhere it's used, it goes black
<Saviq> it's fine on X and on Mir on desktop, but affects all our three android devices
<Saviq> and we're out of our depth on this now
<greyback> Saviq: are any shader errors reported on the console?
<Saviq> greyback, no
<greyback> Saviq: and even a simple qml file using a ShaderEffectSource has this problem?
<Saviq> greyback, yeah http://paste.ubuntu.com/7492386/
<Saviq> greyback, is black instead of red, see https://bugs.launchpad.net/unity8/+bug/1321189/+attachment/4116145/+files/mako.png vs. https://bugs.launchpad.net/unity8/+bug/1321189/+attachment/4116146/+files/mako_good.png
<ubot5> Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged]
<Saviq> fooking barrier
<greyback> Saviq: first step I'd take: capture an API trace - https://github.com/apitrace/apitrace
<greyback> is available in the repos
<alf_> anpok: https://code.launchpad.net/~afrantzis/mir/fix-1321215/+merge/220228
<RAOF> alan_g: Yo! Are you available to talk about 1hz-rendering?
<alan_g> RAOF: If you want me to
<RAOF> I've written a follow-up comment. After you've read that, what would you like to see done?
 * alan_g goes to look
<RAOF> greyback: There'll be a shiny new apitrace 5.0 in the repos soon, too :)
<greyback> RAOF: good, because 4.0 chokes on eglBindAPI :)
<RAOF> greyback: That might be awkward
 * greyback wants to try vogl too
<alan_g> RAOF: I'm not convinced by the abstraction or the naming. But I do like the overall solution. I could just abstain.
<RAOF> alan_g: I'll need to fix the merge conflict anyway (tomorrow); perhaps alf_ could weigh in, also.
<RAOF> alan_g: Adding the last bits of frame dropping policy to FrameDroppingPolicy seems sensible to me, at least.
<alan_g> Maybe SwapStateObserver <- FrameDroppingPolicy <- TimeoutFrameDroppingPolicy?
<RAOF> That would make sense. BufferQueue would still construct a FrameDroppingPolicy from a FrameDroppingPolicyFactory, though. It'd just store it in a std::unique_ptr<SwapStateObserver> rather than std::unique_ptr<FrameDroppingPolicy>
 * RAOF â sleep
<Saviq> greyback, so yeah, it choked here on eglBindAPI
<Saviq> greyback, pointers?
<greyback> Saviq: recompile qtubuntu without that call. Frankly, that call should not be happening on arm
<Saviq> oh ya
<Saviq> y
<Saviq> RAOF, anywhere I could get the 5.0 of apitrace already?
<greyback> Saviq: tried it, chokes there too
<Saviq> grr
<greyback> sorry
<Saviq> ok me builds
<kgunn> alf_: alan_g|lunch AlbertA ... so do i understand it correct on 1hz-rendering-always MP, we seem ok with the approach for putting policy in bufferqueue, but we would want a follow up second effort for shell to be able to override policy ?
<kgunn> sorry if i missed any irc chat on this...but i've been keeping an eye on this one, hoping we'll land it soon (as to put some road mileaage on it before promoting)
<alan_g> kgunn: There's no real objection to separating a "policy" out - just a lack of clarity about what's separated out and how best to name it. (Although IMO separating out a configurable "policy" is premature until we can see what (if anything) needs separating out.)
<kgunn> alan_g: ack
<alan_g> You could have missed some IRC between RAOF and me about 90mins ago: There'll be a new version his "tomorrow". He's got some conflicts to address before it can land, and I'm happy enough with the general approach not to block.
<kgunn> alan_g: thanks
<kgunn> greyback: so when you overrride displaybuffercompositor
<kgunn> will you auto-magically also use hwc ?
<kgunn> or i'm guessing you'll need to "do some effort" there
<kgunn> (which is hopefully a copy paste)
<greyback> kgunn: no, effort needed. bypass might work tho
<kgunn> ah...cool
<kgunn> so we architected it right :)
<mterry> greyback, btw, I filed https://code.launchpad.net/~mterry/unity-mir/dont-hide-focused-apps/+merge/220130 yesterday
<mterry> About the hiding of suspended apps we talked about
<AlbertA> kgunn: not so much sheller but other parts of the system should AUGMENT the policy
<AlbertA> kgunn: meaning the policy should only be activated on display off/occlusion events
<greyback> mterry: I added comment on your MR
<kdub_> greyback, (kgunn) with that convo about getting bypass or hwc to work about 3h ago... would something like this (which works with hwc) get hwc to work for you?
<kdub_> http://bazaar.launchpad.net/~kdub/mir/future-default-display-buffer-compositor/view/head:/src/server/compositor/default_display_buffer_compositor.cpp
<kdub_> thats my integrated hwc-working branch (stuck behind some other branches at the moment)
<kdub_> I also want to rip out that weird lines 60-62 and lines 82-86
<greyback> kdub_: almost, main issue I see is that your use of HWC is an if/else. I'll probably have to render, but also call post_renderables_if_optimizable(renderable_list) - because the scenegraph contains things that are not Renderables
<greyback> e.g. a non-fullscreen app, for iteration one, the panel is not in its own surface, but drawn explicitly with GL calls
<kdub_> greyback, ack, that's the key, is to condense things into renderables where its simple to do so, and use gl where it can't be represented by a RenderableList
<greyback> kdub_: agreed, but this is iteration 1
<kdub_> because that abstracts the hwc stuff away, and the compositor writer just thinks in terms of 'can this be a RenderableList'
<greyback> kdub_: so in time, we can move to using RenderableList as much as possible
<greyback> but we're not going to be there for a while yet
<kdub_> greyback, cool, just checking that its still pulling in a sensible direction
<greyback> kdub_: yep, no objections so far
<RAOF> Saviq, greyback: If you want it, http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/apitrace.git;a=shortlog;h=refs/heads/master is where you can find apitrace 5.0; git buildpackage will know what to do with it.
#ubuntu-mir 2014-05-21
<RAOF> Why, hello there lldb.
<RAOF> You would appear to have a *substantially* more featureful curses UI than gdb.
<RAOF> Also, you don't crash when trying to read debugging symbols from mir_unit_tests, so +1 there, too.
 * alan_g wonders if it should be concerning that he, alf_ and duflu are *all* abstaining on the same large MP.
<duflu> alan_g: I'm just clearing my plate. Already too full to finish everything before July ;)
<alan_g> Ah yes, the familiar whoosh of deadlines going past. ;)
<alf_> alan_g: RAOF: perhaps discussing this in a hangout would help?
<RAOF> alf_: Possibly, but not today; it's dinner time here.
<alf_> RAOF: ok
<alan_g> alf_: Probably not. Perhaps we should land it and see if anything bad happens.
<alan_g> alf_: do you have anything to add to the review? Or a desire to look again?
<alf_> alan_g: Not really. As mentioned I am OK one way or the other.
<duflu> alan_g: If you mean 1hz then land it. That will get us much closer to resolving enough regressions to roll 0.2.0
<duflu> Although, not close enough
<alan_g> duflu: that was my thinking.
<Saviq> greyback, so... I managed to get past eglBindAPI, but now I can't get past eglGetDisplay - I rebuilt qtubuntu with that commented out, but something else must be calling it :|
<greyback> Saviq: hmmm, this definitely used to work
<Saviq> :/
<greyback> Saviq: did you build qtubuntu with debugging on? eglGetDisplay is only a check in an assert call, should not be called in release
<Saviq> greyback, nope, dpkg-buildpackage
<greyback> weird
<Saviq> greyback, that's why I mean something else must be calling it
<Saviq> greyback, Qt, even...
<greyback> now i get you
 * Saviq tries with 5.2
<Saviq> but have to reboot first, phone mount-loop again...
<Saviq> brb
<greyback> Saviq: LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/apitrace/wrappers/egltrace.so:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libGLESv2.so.2  qmlscene redBox.qml --desktop_file_hint=/usr/share/applications/dialer-app.desktop
<greyback> ^^ try that. Seems the order of loading the libraries important for symbol resolving
<greyback> and qtubuntu doesn't link directly to egl, which is suspect
<greyback> (well I don't expect it to cause this fail)
<Saviq> greyback, ok will do in a sec
<greyback> Saviq: here's hte Qt5.2 output anyway: http://pastebin.ubuntu.com/7496692/
<alf_> alan_g: Any reason we are explicitly calling delete_endpoint() in atexit() and SIGINT/SIGTERM? The server should clean up properly on normal shutdown.
<alan_g> alf_: I don't remember a specific reason. Probably from overlapping attempts to avoid stale endpoints.
<alf_> alan_g: ok
<Saviq> hey guys, we'll need your help on https://bugs.launchpad.net/unity8/+bug/1321189
<ubot5> Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged]
<Saviq> we gathered as much info as we knew how to
<Saviq> and will need help going forward
<alf_> Saviq: how can we help?
<Saviq> alf_, between Qt 5.2 and 5.3 QML ShaderEffect component stopped working
<Saviq> alf_, but only on Mir+android
<Saviq> alf_, Mir+desktop and X11 are fine
<Saviq> not sure about SF+android, but I doubt it
<davmor2> sil2100: what image do you want testing and when?
<alf_> Saviq: ok, I will look at the gl traces to see if I can find a hint there. How can I try Qt 5.3?
<Saviq> alf_, see the description
<Saviq> alf_, it's all in ppa:canonical-qt5-edgers/qt5-beta2
<Saviq> alf_, just dist-upgrade from there and you'll see what's happening
<Saviq> alf_, thanks, please let me know if you need any more data from us
<alf_> Saviq: should I use latest devel-proposed image?
<Saviq> alf_, yes
<alf_> Saviq: greyback: Can we in any way change the shaders used by Qt internally?
<Saviq> alf_, for these cases, yes
<Saviq> alf_, http://qt-project.org/doc/qt-5/qml-qtquick-shadereffect.html
<Saviq> alf_, and http://qt-project.org/doc/qt-5/qml-qtquick-shadereffectsource.html
<alf_> Saviq: thanks, I want to try a couple of things to see if it makes a difference
<Saviq> alf_, yeah, just qmlscene http://paste.ubuntu.com/7492386/ and you can change the shader props as you please
<Saviq> alf_, do you need to see the default shaders used?
<alf_> Saviq: I want to change some bits in the default shaders so I guess I need to override them completely
<Saviq> alf_, yeah, but you can see the default shaders in the trace or something?
<Saviq> alf_, if not, you could probably print them:
<greyback> alf_: yeah the shaders that Qt has internally are hardcoded in, but they can be overridden with some work (without patching qt itself)
<Saviq> Console.onCompleted: console.log(vertexShader)
<Saviq> or so
<Saviq> greyback, in our case we're using ShaderEffect anyway
<alf_> Saviq: greyback: I can see them in the apitrace logs, I will print them out to be sure and then override them to try some things
<Saviq> alf_, thanks!
<greyback> Saviq: right, but other shaders are being generated & used by the scenegraph too. Those are harder to change
<Saviq> kgunn, â we stole alf_ to help with https://bugs.launchpad.net/unity8/+bug/1321189
<ubot5> Ubuntu bug 1321189 in Unity 8 "Launcher is black on Qt 5.3" [High,Triaged]
<Saviq> greyback, yeah, but we're not seeing problems with those actually
<kgunn> Saviq: perfect!
<Saviq> greyback, i.e. the only place where we identified an issue are ShaderEffects atm
<Saviq> although now I just saw system settings pages are empty, too, not sure where that comes from
<anpok> Saviq: why is the ubuntu icon visible?
<anpok> it is also part of the launcher?
<anpok> is there are subtle difference like - it has no alpha channel?
<Saviq> anpok, it's not shaded
<Saviq> anpok, the ubuntu icon is just displayed, the other ones are put through a shader
<anpok> ok
<mterry> anpok, poke!  Do you have some minutes to help me profile Mir CPU usage in the split greeter?
 * mterry is unfamiliar with profiling mir like that
<anpok> do you want to come up with some numbers.. or figure out what mir is doing/spending time on?
<mterry> anpok, figure out what mir is spending time on.  I see about 9% idling
<alf_> tsdgeos: Hi! Any hints about building qt components easily for phone debugging? e.g. I want to rebuild lib5QtOpenGL with debug info and custom debugging code to investigate the transition to Qt 5.3 issue
<tsdgeos> alf_: not much hint, i'd say get the qtbase package and then qmake += DEBUG in the opengl folder
<tsdgeos> and make
<tsdgeos> wait a bit
<tsdgeos> and then some LD_LIBRARY_PATH magic
<tsdgeos> and hope it all works :D
<tsdgeos> it's what i usually do so it should work
<alf_> tsdgeos: can I select to build only e.g. lib5QtOpenGL to gain some time?
<alf_> tsdgeos: ah, sorry missed the "in the opengl folder"
<tsdgeos> alf_: that should work yes
<alf_> tsdgeos: thanks
<tsdgeos> if not
<tsdgeos> just configure on the toplevel
<tsdgeos> make for a bit so that qmake and stuff is build
<tsdgeos> and then do enter the opengl dir and make there
<tsdgeos> it's a bit more manual
<tsdgeos> but should also work
<alf_> Saviq: greyback: I am going to investigate the Qt5.3 issue deeper tomorrow, there have been some important changes in the way  Qt5.3 handles gl contexts
<alf_> Saviq: greyback: I will keep you posted
<anpok> mterry: have you already just tried enabling logs/lttng traces
<anpok> if they dont show up things we need to add further reports/traces
<mterry> anpok, I haven't yet no
<mterry> anpok, I'll re-acquaint myself with how  ;)
<anpok> bbiab, whats the silo again? I think I still have it configured
<mterry> anpok, 002
<anpok> ok
<mterry> anpok, yeah if you have time, would love a more knowledgeable look (I think it's Mir-related, but not 100% on that -- I took out everything interesting the greeter was doing and we still spun 10% of cpu)
<greyback> alf_: thanks!
<anpok> mterry: re, grabbing some food now then will have a look too..
<anpok> alf_: hm im seem to be confused by how asio uses timers
<anpok> i tried to reduce timing related problems with the advanceable fake clock - so i run the main loop in a separate thread, schedule timers, then advance the clock, poke on the main loop by enqueing an action
<anpok> but it seems like the timers are handled independent of any posts on the asio io_service
<anpok> i assumed that after a post it would check the amount of time passd since last call and recalc sleep time / execute expired timers..
<anpok> maybe I need to look into a different file for some time
<anpok> mterry: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002/ <- this one?
<anpok> the spinner is gone?
<mterry> anpok, yeah, it'll land separately
<mterry> anpok, you should see almost no visible differences (indicators in greeter will be a little different though)
<anpok> which process is spinning too much?
<mterry> anpok, unity8-greeter
<mterry> anpok, I'm not sure why.  Both it and unity8 have the same basic code.  They are both nested Mir servers
<mterry> anpok, but only the greeter executable has this problem
<mterry> anpok, I tried removing all the qml it loads, same problem
<anpok> ah now i see what you mean it seems to stay with 9% cpu
<anpok> together siwth sensors .. and Binder_2
<mterry> anpok, yeah.  Bounces between 7-10 usually
<mterry> anpok, I assumed those were unrelated, but maybe they aren't...
<anpok> but it did not happen when i first looked .. i mean it started after a few logins
<anpok> ok still behaves like that after reboot
<AlbertA> we need a plan to deal with stale frame content
<AlbertA> during display off/on scenarios
<AlbertA> now that the 1Hz branch has landed
<AlbertA> the old flash of old content issue is back
<kgunn> AlbertA: this proves i didn't understand what its doing
<AlbertA> kgunn: well now the "rendering" rate of a client will be 1Hz after power off
<AlbertA> kgunn: and since the lifecycle kicks in at around 3s
<AlbertA> kgunn: there's only around 3 frames drawn
<AlbertA> kgunn: not enough to show the greeter
<kgunn> but can't we grow the hz to be something more like 10 hz ?
<AlbertA> kgunn: we could yes, but I think we need a plan to properly address the issue
<kgunn> i never understood why we were picking 1 hz
<AlbertA> kgunn: I'm not sure if you can get more granularity out of the timer
<kgunn> its not _that_ much power savings
<AlbertA> kgunn: maybe we can...not sure
<kgunn> AlbertA: we should...i remember whining about this to alf & RAOF
<AlbertA> kgunn: wait we should, 1HZ is a second
<kgunn> e.g. i thot you'd potentially see glitches
<kgunn> for things that are rendering off a clock
<kgunn> or animated
<AlbertA> kgunn: also the volume key during music playback will be a bit laggy
<kgunn> in occluded cases, getting revealed quickly
<kgunn> yes
<AlbertA> kgunn: but I don't know if it was like that before
<kgunn> that was the other thing
<kgunn> no
<kgunn> well
<kgunn> it was totally blocked before :)
<AlbertA> kgunn: I mean with the old solution
<kgunn> AlbertA: no, not laggy at all...e.g. its runnnig off the 60 hz panel vsync effectively
<kgunn> imho, our time should be as close to panel vsynch as possible
<kgunn> AlbertA: and we need to fix that before we promote...that regresses a definite improvement
<AlbertA> kgunn: well the policy is overridable
<kgunn> i'll file a bug
<AlbertA> kgunn: so usc can implement a different timeout
<AlbertA> kgunn: but the right thing is to consider the lowest display refresh rate we are connected to
<AlbertA> kgunn: and only enable the policy during display off/occlusion
<kgunn> yes
<AlbertA> kgunn: unless we want to drop frames due to compositor taking longer than usual (gpu load or whatever)
<AlbertA> kgunn: which we probably don't want
<anpok> mterry: it does not seem to render - still investigating (non invasively)
<mterry> anpok, ok good
<mterry> anpok, I caught it via gdb, which wasn't very helpful backtrace wise, but did show more threads than I expected
<mterry> by caught I just mean I attached to it with gdb
<kgunn> AlbertA: if you wanted to add anymore color
<kgunn> https://bugs.launchpad.net/mir/+bug/1321886
<ubot5> Ubuntu bug 1321886 in Mir "[regression] stale frame on seen on greeter when screen is unblanked" [Critical,New]
<AlbertA> mterry: when you get a chance weigh in in this enhancement:
<AlbertA> mterry: https://bugs.launchpad.net/mir/+bug/1318852
<ubot5> Ubuntu bug 1318852 in Mir "[enhancement] support proper per-pixel alpha for alpha-enabled display framebuffers" [Medium,New]
<mterry> AlbertA, noted
<AlbertA> mterry: have you checked the alpha values you currently get? Because from what anpok and I discussed
<AlbertA> mterry: with the prev version of mir you will get alpha^2 behavior
<mterry> AlbertA, all I've tried to so far is alpha=0
<AlbertA> mterry: I see...
<anpok> AlbertA: i right now only look for load..
<AlbertA> anpok: ?
<anpok> ah ... didnt see your premultiplied alpha MP
<AlbertA> anpok: mterry: did you already check top with the per thread statistics?
<mterry> AlbertA, 'H' mode?  It doesn't seem to provide much insight
<mterry> anpok, memory use seems high too
<mterry> I'm trying to set MIR_SERVER_INPUT_REPORT=log for the greeter, but it doesn't output anything.  Setting it for unity8 woks, but not for the greeter executable.  Does anyone have any idea why that might be?
<mterry> anpok, you still around / any success?
<josharenson> kgunn, if you checkout the glmark spreadsheet (https://docs.google.com/a/canonical.com/spreadsheets/d/1aYbyh3BTVzjcxE1dO2IBEEtFbEDLeaEY-sqopkyM-uQ/edit?usp=sharing) you will see the last tab is graphs of performance over time.. currently filled with sample data
<josharenson> kgunn, I have a script that will run as a cronjob on some ubuntu cloud instance that will pull artifacts from jenkins, parse them, and update those graphs daily (or however often you want)
<josharenson> kgunn, to hold us over till there is a proper website of course....
<anpok> mterry: you have to pipe stdout somewhere ..
<mterry> anpok, it gets saved in /var/log/lightdm/mir-greeter.log
<anpok> mterry: thats what I thought too..
<mterry> anpok, if I choose lttng, where does that logging go?
<anpok> but writing it to a different file worked..
<mterry> anpok, really?
<anpok> yeah
<mterry> anpok, yup..  odd
<anpok> wrt lttng you can create traces with eclipse and it will be stored somewhere in tmp  or you create a session using the lttng tools..
<mterry> anpok, "android-input: [InputDispatcher]Dropping event because there is no focused window or focused application."
<mterry> anpok, does android have its own idea of where input should be focused vs mir's idea?
<racarr__> mterry: Sort of, see: the_input_target_selector
<racarr__> the default focus mechanism, makes the default surface of the focused sessio
<racarr__> n
<racarr__> the input target
<racarr__> (whom then receives all key events)
 * mterry takes a dinner break
<kgunn> josharenson: awesome!
<kgunn> seriously...
<josharenson> kgunn, the data is obviously fake for now... but should be a solid band-aid
<kgunn> josharenson: hey, so for the data you did run...is it right to compare ubuntu-offscreen to the android-onscreen run ?
<josharenson> kgunn, with the frame dropping enabled, it seems fare
<josharenson> fair*
<kgunn> josharenson: so ubuntu-frame-drop vs android-onscreen ?
<kgunn> i mean...yeah
<kgunn> i see that it technically would be the closest thing
<josharenson> kgunn, yes
<kgunn> but wow...
<kgunn> we kick the shit out of surface flinger
<josharenson> I think alberta had a good explination for that...
<kgunn> binder ?
<josharenson> kgunn thats 1 part
<kgunn> wow...binder really creates that much traffic jam?
<kgunn> stil
<josharenson> kgunn, if we are just a few ms faster, it could help substantially
<josharenson> kgunn also
<josharenson> kgunn the compositor
<josharenson> kgunn, thinking.. I know there is something there... the numbers might not actually be so far
<josharenson> fair*
 * josharenson can't spell fair, need more coffee
<kgunn> fare
<kgunn> fair
<kgunn> :)
<kgunn> fart
<kgunn> josharenson: yeah...ok, it does make those tests where SF is "better" then mir come much more into line in terms of comparison
<josharenson> kgunn, I have a good explination logged in my chats somewhere... I'm looking for it
<AlbertA> josharenson: kgunn: right, take 393 vs 292 = 2.54 ms vs 3.42 ms
<AlbertA> josharenson: kgunn: I totally buy that being binder overhead
<josharenson> ^^that
<kgunn> yeah...true...
<kgunn> i forget the massive numbers have an illusion
<kgunn> converting into ms...not so bad
<josharenson> kgunn, I guess the best test is mir vs mir.... 2nd best test is mir vs sf with frame dropping enabled
<josharenson> kgunn, linaro _could_ make android offscreen happen, but, as we've discussed, its not really of value.. just let me know what you want to see in that spreadsheet.. its not so hard to change things...
<kgunn> so i'm in column R & S for you looky loos
<kgunn> josharenson: yeah...i guess the mir w/ frame drop vs SF is as close as we're gonna get
<kgunn> its interesting, they still beat us on a handful
<AlbertA> I'd wager that's our hybris overhead...they are probably gl call heavy
<josharenson> kgunn, also, the current test only shows overall score.... getting all the info from the actual mir test is easy, but putting it all in the spreadsheet would take a little work (hours, not days)
<kgunn> AlbertA: eh, not so sure...
<kgunn> i mean, they beat us on kind of "lower frame rate"
<kgunn> granted gl calling might be higher
 * camako thinks the differences are too big... 
<kgunn> but gpu load itself is higher
<camako> things should be gpu bound, no?
<kgunn> camako: some are
<kgunn> i suspect
<kgunn> like jellyfish, terrain
<camako> so we should get more or less the same framerate
<camako> but CPU, and mem bw should differ by a lot
<kgunn> camako: right...in about 1/2 the cases...the other 1/2 they're beating us by 20%
<AlbertA> kgunn: camako: I suppose it depends on the gl call rate
<kgunn> AlbertA: would hybris really add overhead perse ? isn't it just a function redirect?
<AlbertA> kgunn: camako: could be a combination of decreasing gpu load with hwc + hybris overhead
<kgunn> agreed on the hwc
<kgunn> that could be it
<kgunn> or a portion
<AlbertA> kgunn: right if we had a sense of the gl call rate we could speculate better
<camako> So we don't have hwc fully enabled?
 * kgunn wishes we had something like pvrtune for adreno
<AlbertA> kgunn: that would be higher fps I guess where it would show up
<kgunn> kdub_: ^ anything like that exist? adreno-load-inspector ?
<AlbertA> camako: not currently no
<kdub_> there's a bunch of /sys stuff
<camako> isn't this all going through hwc on Android?
<camako> I mean overlays?
<kgunn> AlbertA: @higher framerate where it would show up...you mean hybris ?
<AlbertA> kgunn: right
<kgunn> AlbertA: right...so its counter the theory :)
<kgunn> we kick the crap out of them
<camako> kgunn, doesn't make sense to me
<camako> they should be beating us by a large margin
<camako> with overlays
<AlbertA> kgunn: heheh.... have you looked at percentages in millisecs?
<AlbertA> camako: well....it's only one surface though...
<AlbertA> camako: so I suppose the recomposite overhead?
<josharenson> camako, yeah I've only ran fullscreen tests
<AlbertA> camako: which surface flinger wouldn't have since it would just send the surface straight to hwc
<AlbertA> camako: we don't do that yet...kdub is working on it :)
<kdub_> camako, right :)
<kdub_> we can see in malta though
 * camako thinks something is not right
<camako> their system is much better optimized..
<kdub_> eh, also like hwc is sometimes power optimized
<AlbertA> oh yeah....
<AlbertA> josharenson: did you fix up the cpu governor for this tests?
<camako> so again why are we seeing higher numbers?
<AlbertA> we could be seeing a case where the cpu was bumped to a higher Hz due to higher load :) and we end up better
<kdub_> well, sometimes its even more than the governor
<camako> AlbertA, cpu shouldn't matter, it's a lot of gpu and mem bw
<camako> or rather, it should be..
<AlbertA> camako: for the high fps it would
<josharenson> alberta, no....
<AlbertA> camako: since they don't seeem particularly gpu bound
<josharenson> alberta, like force max?
<AlbertA> josharenson: usually we set it to performance
<josharenson> albera, that will only help our results
<AlbertA> josharenson: not necessarily, I mean if you have root access on android,
<AlbertA> josharenson: you do the same there
<camako> AlbertA: dunno specifics of these tests but generating gl commands is not CPU intensive... But it could be mem intensive...
<josharenson> alberta, ok I'll rerun at some point... How does out power management policy compare to android?
<AlbertA> josharenson: should be the same kernel
<AlbertA> josharenson: so same governors
<josharenson> cak
<josharenson> ack*
<AlbertA> camako: but it could be in the threshold of switching cpu modes
<AlbertA> camako: i.e. if android has lower cpu usage it could have switching to a lower mode therefore spending more cpu %
<kgunn> AlbertA: thanks for bringing up cpu goveners...totally forgot
<camako> AlbertA: does it make mem bw?
<kdub_> there's a lot of fun switches to push :)
<camako> AlbertA: does it make mem bw higher??
<kgunn> camako: no
<AlbertA> camako: it could there's complex interplay there with the cores
<kgunn> camako: well at least at ti, those were seperate
<AlbertA> camako: not higher
<AlbertA> camako: lower
<kgunn> ok guys...i'm gonna run
<kgunn> family calling...back after a while
<AlbertA> camako: the scenario would be lower clock in android leading to lower total fps
<camako> AlbertA: yes, I meant for us...
<AlbertA> camako: and mir could have higher cpu load leading to slightly higher fps since it's running at a higher clock rate
<AlbertA> camako: we won't know for sure unless we fixed the clock rate on both scenarios
<josharenson> ill run at performance
<camako> AlbertA, cpu is not doing the heavy lifting... so lower/higher doesn't matter...
<AlbertA> camako: I'm not so sure in the cases where we are getting high fps
<camako> cpu can saturate mem and/or gpu very easily at low cpu %
<AlbertA> camako: we are talking about 1ms differences there
<AlbertA> camako: very well could be cpu clock rates
<AlbertA> camako: in the low fps cases...that could be mir's compositor overhead over SF
<camako> AlbertA, I guess I am having a hard time believeing cpu is the bottleneck here
<AlbertA> camako: not a bottleneck but a load low enough that in android it kicked the cpu to a lower state
<camako> AlbertA, now we don't have full hwc, I guess things'll make more sense when it's more apples-to-apples
<camako> AlbertA, to me Android is operating at a much lower mem bandwidth (interconnect freq) than mir
<AlbertA> camako: right we can't make accurate comparison with a dynamic clock rate basically
<camako> A simple mem test should discover any discrepancy
<AlbertA> camako: I mean we saw that all the time in OMAP
<AlbertA> camako: the data doesn't end up making a lot of sense...and sometimes cpu governors are also tied
<AlbertA> to other ip blocks
<camako> I guess it'd make more sense to me if cpu governor does affect mem bw
<kdub_> yeah, it sounds like something I would have seen in the adreno world too
<kdub_> and also, I thought it could hold the mem bw high if its set to performance
<racarr__> kgunn: Hey...so...the deeper I get the more things I find I have to disentangle for glamor....its relatively coupled to GBM/DRM+Client buffer allocation+Mesa EGL...
<racarr__> im developing a plan but I think I would be pretty lucky to get anything working in the next few days
<racarr__> so maybe I should reprioritize?
<kgunn> racarr__: is glamor a hard requirement for libreoffice?
<racarr__> kgunn: No. only for it to not be slow on mobile devices.
<kgunn> racarr__: mmm...i'm being summoned again by the wife...so is doing a demo of libreoffice w/o glamor cheap in terms of effort?
<racarr__> on the desktop yes...unless we want menus to work in hich case it grows in to a bit of
<racarr__> a project
<kgunn> racarr__: might have a chat with RAOF when he's on...i gotta run...i kind of feel like yeah...i mean desktop is the target w/
<kgunn> menus of course
<kgunn> ok...back later
<racarr__> ttyl!
<racarr__> thanks
<racarr__> RAOF: Ping?
<RAOF> racarr__: Yo!
#ubuntu-mir 2014-05-22
<RAOF> kgunn: You rang, m'lud?
<kgunn> RAOF: racarr__ was just sayin' that glamor on mir more coupled than he thot & might not lend itself to doing a demo of libreoffice on mir for next week...wondered if you had thots ?
<kgunn> not sure how much you've looked at glamor
<RAOF> Not a whole lot, although looking at the xf86-video-ati code I thought that the GBM bits were to do with making DRI work rather than 2d.
<kgunn> but then we talked about not using glamor...which sounds like on desktop that'd be ok (on mobile, slow)
<kgunn> but then there's menus
<kgunn> RAOF: so just lookin' for some technical guidance, but my gut thinks go for it w/o glamor and put some work in to get the menus
<RAOF> That seems reasonable.
<kgunn> but willing to listen to reasons why we should focus on glamor, or not put effort in on menus
<RAOF> We don't need glamor for the desktop.
<kgunn> i didn't quite understand why "menus are free with galmor"...or am i reading into what Master Carr is saying ?
<RAOF> You're reading that into what Master Carr is saying.
<RAOF> Menus aren't free; they're the first part of window managment.
<RAOF> Which _is_ a bit of a project :)
<kgunn> so would that work really be the same w/ & w/o glamor?
<RAOF> Yes.
<RAOF> Glamor is merely âdoes it work (with GPU acceleration) on the phoneâ.
<kgunn> right
<kgunn> makes sense
<RAOF> So one track is âsw-only xf86-video-mir that just uses the Mir API and X's software renderingâ â âxf86-video-mir that uses glamor for 2dâ â âxf86-video-mir that uses glamor for 2d and supports 3dâ
<RAOF> Those are all mostly required steps for âfast XMir on the phoneâ
<RAOF> And then there's the âhello, window managementâ track, which gives you - for example - popup menus that popup in the right place :).
<kgunn> ok, tbh, our goal of officelibre on mir is more about unity8 on desktop (not phone)
<kgunn> racarr__: ^
<kgunn> RAOF: so, i got something i don't understand, trying to debug something using mir_demo_client_egltriangle, so i'm doing the VT1 basic server and VT2 demo on my laptop
<RAOF> Ok, sounds good so far.
<kgunn> i modify mir_surface.cpp, make install....i even changed the mir_demo_client_egltriangle as to make it update/install as well
<kgunn> however...when i run
<kgunn> i do not "see the change"
<kgunn> from usr/local/bin installs...
<kgunn> i have to run the demo client directly from the build folder
<kgunn> how come?
<RAOF> Well, that's what I do, because /usr/local installs are a *great* way to get extremely surprised in a month's time :)
<kgunn> :)
<kgunn> ok, so i'll just keep doing that...
<kgunn> no problem
<kgunn> but is there a reason why ?...i mean i really thot the install would take care
<kgunn> also...is there a way to wipe out the local/bin
<kgunn> ?
<kgunn> to avoid that surprise ?
<RAOF> My initial guess as to your problem would be whether or not cmake strips out the RPATH on everything when installing.
<RAOF> kgunn: rm -r /usr/local/bin/* ? :)
<kgunn> ok...
 * RAOF has recently run this, having been surprised by an apitrace install lurking in there.
<kgunn> that easy huh
<RAOF> Unless you've got something you actually *want* in /usr/local, yeah.
<kgunn> cool
<RAOF> You might also want to kill /usr/local/lib, because that little gem is *before* /usr/lib in the library search path.
<kgunn> yep...researched enough to see that...and its first in my path
<racarr__> lol sorry to be confusing about menus
<kgunn> racarr__: you weren't...i was playing the board game "Jump to Conclusions"
<racarr__> unrelated to glamor :)
<racarr__> oh
<racarr__> I prefer candyland.
<kgunn> lol
<AlbertA> kgunn: heh I love those office space references
<RAOF> Mmm. Candy mountain!
<kgunn> AlbertA: just for you :)
<AlbertA> kgunn: I want to file my TPS report now
<kgunn> AlbertA: yeah...i'm gonna need you to come in Saturday....yeah...why don't you just plan on coming in Sunday too
<racarr__> AlbertA: We're gonna have to ask you to come in to malta on a sunday...
<kgunn> lol
<AlbertA> evern funnier because we are
<AlbertA> haha
 * RAOF arrives home Monday morning.
<RAOF> (There will not be any RAOF on Monday or Tuesday after the sprint)
<AlbertA> RAOF: I guess you didn't get the memo
<AlbertA> RAOF: ;)
<kgunn> RAOF: you're next movie watching assignment http://www.imdb.com/title/tt0151804/
<racarr__> RAOF: Im bored. wanna write an X11 window manager?
<RAOF> No, not really :)
<racarr__> lol my real question, is how to turn on rootless X.
<racarr__> I was thinking I would make input work in rootless (seems like there would be something to do) and maybe try and get some basic
<racarr__> infrastructure going.
<RAOF> racarr__: I'm currently resurrecting my rootless X thingy, which seems to have been eaten by git.
<racarr__> Ah
<RAOF> Oh! Yeah, that'll be what I need to actually get windows to display!
<racarr__> ?
<RAOF> Need to tell things that there's a Composite manager.
<RAOF> Otherwise they'll do stupid things, like draw on the root window.
<racarr__> ah. yes they will lol
<mterry> anpok_, you still around by anychance?  The cpu usage thing seems unrelated to mir...
<mterry> anpok_, (copying unity8-greeter on top of unity8, then switching greeter code to run unity8 instead makes cpu usage be normal.  So something is inspecting executable names)
<mterry> anpok_, but I do still need help on the 'volume up/down presses ignored by android-input layer in greeter' issue...
<RAOF> 2nd laptop mode: engage.
<RAOF> Dear Google: any email sent to me written in Mandarin is almost certainly spam. kthxbye.
<anpok_> yay just finished merging devel and making the unit test non-time-depending in my branch
<anpok_> non-time oO
 * duflu high-fives anpok_
<anpok_> hi
<duflu> Hi there
<anpok_> so avoid to time dependency in buffer consumption..
<anpok_> we might need to consume all occuluded buffers (but not by drawing them :)) and provide expose/occlusion events for displays that got powered of
<anpok_> and hope that qt can deal with that
<anpok_> *off
<duflu> anpok_: Hmm, I had proposed a branch that did just that.
<duflu> It got rejected
<duflu> Although it's a good idea
<anpok_> well you proposed drawing occluded buffers
<duflu> anpok_: Different branch
<anpok_> oh
<anpok_> too many branches...
<anpok_> but for this to work we need the client api change ..
<duflu> Ah, crap.
<anpok_> i mean.. we do not make an occlusion test when the compositor off
<anpok_> which we wanted to do anyhow sometime.. maybe today?
<RAOF> Well, that looks like _part_ of libreoffice...
<anpok_> hm lets see how bzr deals with that
<anpok_> duflu: https://bugs.launchpad.net/mir/+bug/1318852 AlbertA is referring to the usage of src_alpha, one_minus_src_alpha as a blending function - which only works when the textures are not premultiplied
<ubot5> Ubuntu bug 1318852 in Mir "[enhancement] support proper per-pixel alpha for alpha-enabled display framebuffers" [Medium,New]
<anpok_> but which does not cause much trouble because we rarely have transparent client buffers
<duflu> anpok_: Depends how often you run "mir_demo_client_egltriangle -b 0" ;)
<anpok_> duflu: well and how often do we verify that resulting rgb and a channels are mathematically correct and follow an additive blending model?
<RAOF> Also, when are we going to support sRGB alpha? :)
<anpok_> duflu: the screencast bug fixed some time ago by applying filters (and I think avoid alpha writes) is caused by the used blending functions
<RAOF> Hah!
<RAOF> mir_surface_is_valid isn't particularly useful :)
<anpok_> we could safely assume premultiplied alpha for any client buffer and used (one, one_minus_src_alpha)
<anpok_> RAOF: hm where are you?
<duflu> anpok_: I hope you're right. Although I can't yet see how this should produce a fragment with alpha != 1.0 ...
<duflu>         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
<RAOF> anpok_: Still in hobart?
<anpok_> hm not makeing much sense, libreoffice valid surface?
<duflu> RAOF: Oh... mir_surface_is_valid(NULL)  ?
<duflu> https://bugs.launchpad.net/mir/+bug/1248474
<ubot5> Ubuntu bug 1248474 in Mir "mir_surface_is_valid(NULL) crashes instead of returning false" [Medium,Triaged]
<anpok_> assume you have an opaque background d_r, d_g, d_b, d_a, and blend a window shadow (s_r,s_g,s_b,s_a) above it with, lets assume a pixel s_a= 0.25 then your resulting alpha = s_a*s_a + d_a*(1-s_a) => 1/8 + 1*(3/4) => 7/8
<RAOF> duflu: Actually mir_surface_is_valid() for any non-surface :)
<duflu> Wow  Oo
<duflu> Awesome. Surfaces everywhere!
<duflu> It's a new paradigm
<anpok_> if you use GL_ONE instead (and make the shadow buffers and window decorations premultiplied)
<anpok_> you get -> 1*s_a + d_a(1-s_a)= 1/4 + 3/4 = 1
<racarr__> Ah, yes, non surfaces are surfaces, 1=0, I see it all so clearly now...*runs off in to the night*
<anpok_> racarr__: see you late
<anpok_> r
<duflu> racarr__: Consider that a good point to have a drink et al
<RAOF> anpok_: Oh, no. I think something is destroying a surface, then X is handling an event that was queued from that surface.
<racarr__> Haha, I just got back from the wine bar and was just checking IRC before sleep :)
<RAOF> So 0x926158 probably _was_ a valid surface, quite recently.
<racarr__> Good indeterminate time all!
<RAOF> But now it's a SIGSEGV
<RAOF> racarr__: Enjoy post-wine!
<duflu> Whee, the handle validation problem
<anpok_> racarr__: apply the advanceable clock mp, it is global, but makes you independent on any extern time source
<duflu> anpok_: OK, I trust you without stopping to check the math. If you have a superior solution in mind propose away :)
<anpok_> duflu: .. maybe i manage today... need to finish my input nightmare
<RAOF> BAH!
<RAOF> What's nulling mir_win->win?
<duflu> RAOF: XMir's still *magic* after all
<RAOF> Ah. And the reason why input isn't working is that nothing hooks it up. Oops!
<RAOF> Wow. Apart from the bit where I've got the rendering offset and the bit where mir_demo_server_shell has issues with alt-tab, libreoffice is surprisingly usable.
<duflu> RAOF: Whoa, that is worthy of celebration/video
<RAOF> I think I'll wait until I've got the rendering correctly offset first :)
<duflu> RAOF: Bah, Compiz never got that right ;)
<RAOF> It got it more right than âbig black box between the top-left corner and where the window wants to beâ
<RAOF> duflu: I'm not sure why you're exposing DPI to clients at all? I thought 100% of what you wanted was correctly-sized decorations, which are done in the server anyway?
<duflu> RAOF: Clients need DPI (or something) to know how big to render text/buttons/etc. And particularly if a client is modifying its titlebar, it needs to agree with the server on the scale.
<RAOF> Oh, they certainly do eventually.
<duflu> But even before that, we want to avoid huge-titlebar-with-tiny-widgets or vice-versa
<duflu> Cos then Mir wouldn't be any better than Unity 7 ;)
 * duflu still thinks Trevinho is awesome
<anpok_> now that the revert of 1hz rendering landed - i guess have to manually merge devel again? Or are we soon reverting the revert again?
<alan_g> anpok_: I don't know that we have a plan for 1hz. But what makes this rev different to any other change to devel?
<alf_> Saviq: greyback: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1321189/+merge/220613
<alf_> Saviq: greyback: please note the lack of extensive testing
<greyback> alf_: fix makes sense, that was my hunch anyway
<Saviq> alf_, awesome
<Saviq> Mirv, can you integrate that into the qtubuntu builds â?
<Saviq> Mirv, it should fix the rendering issues under Qt 53.
<Saviq> 5.3
<anpok_> alan_g: it just touches the alarm tests due to some bsr and I have two branches in that area too
<anpok_> and i am lazy enough to not like conflicts :)
<alan_g> anpok_: I don't see 1hz landing again until we've discussed what went wrong. So plan on your stuff landing before it gets sorted out.
<anpok_> alf_: not sure if you read the irc backlog of last night .. i finnally figured out why my clock improvements did not really improve things.
<alf_> anpok_: I haven't read it... at what time should I look?
<anpok_> oh not important.. 1900 my time .. maybe 2000 yours?
<anpok_> short story
<anpok_> posting actions on a io_service does not make the io_service reevaluate the pending timers
<anpok_> only when I create a new timer it will go and look for a new "now"
<Mirv> Saviq: yes
<Mirv> Saviq: sounds excellent
<Mirv> pushing a build right away
<Mirv> Saviq: note that even that your some output Qt 5.3 was actually using OpenGL ES 3.0, but let's see
<Mirv> (ES 3.0 is now supported in 5.3)
<Mirv> alf_: that was some awesome one-liner
<alf_> Mirv: glad it helped :)
<mterry> anpok_, did you get my message late last night about the cpu issue with the greeter?
<anpok_> mterry: probably not
<mterry> anpok_, ok, so I investigated more
<anpok_> ah at 3:57
<mterry> ah ok
<anpok_> and volome up down still an issue
<mterry> anpok_, yeah both are still issues, I just know more  :)
<anpok_> :)
<anpok_> the other one is already erased
<mterry> anpok_, volume up/down is interesting.  So it's an android-input issue about focus.  But if I run the greeter as the user shell, it works.  So it's not related to the actual code of the greeter either
<mterry> Something about how the greeter environment is set up, versus a user environment apparenlty
<anpok_> hm ok i thought it would be a display off -> no focused surface issue or something
<mterry> anpok_, the problem appears on first boot even before display off
<mterry> Shoot.  Now it's working on my device and I don't know what I did
<anpok_> but you DID something?
<mterry> anpok_, I've been trying lots of things, but it started working, and after undoing what I did most recently it was still working.  So I must have done something last night and not noticed it worked.  I'm going to work backwards now  :)
<anpok_> ok cool all issues erase.. me hurries back into input nightmares
<anpok_> you still might have found a bug
<mterry> anpok_, heh, no I want you on retainer  :)
<anpok_> mterry: meeting the kids -> then I am all yours
<anpok_> *then
<mterry> ricm:)
<mterry> whoops
<mterry> :)
<anpok_> at least I make you think that :)
<AlbertA> kgunn: alf: so I flashed a fresh image
<AlbertA> kgunn: alf: with the current solution (buffer consuming thread) I still see a probably one frame flash
<AlbertA> of old content
<alf_> AlbertA: sure, it depends how fast you do it :)
<AlbertA> kgunn: alf: with 1Hz branch but set to 20Hz timeout I always see it...
<AlbertA> kgunn: alf_: I wonder why
<kgunn> like alf_ said, doesn't it depend on how fast you do it ?
<AlbertA> kgunn: I mean in the 20Hz case, it doesn't matter how slow you do it
<AlbertA> kgunn: 30 seconds later, it still flashes the one frame
<kgunn> AlbertA: oh wait...so, you're cutting the compositor out of the chain in this method right
<kgunn> so we
<kgunn> have left the frames we dumped in there...
<AlbertA> kgunn: right only framedropping
<kgunn> just prior to turning off
<kgunn> so those are what you see
<AlbertA> kgunn: alf_: but that should be similar in the buffer consuming compositor too...I would think
<kgunn> AlbertA: i didn't think so...cause buffer consuming compositor actually rendered to the "display"
<kgunn> so they're gone
<AlbertA> kgunn: I suppose the difference is
<AlbertA> kgunn: it advances the compositor buffer
<AlbertA> kgunn: and in framedropping it doesn't
<kgunn> exactly
<kgunn> dednick: can you retarget https://code.launchpad.net/~nick-dedekind/unity-mir/trusted-sessions/+merge/210775 to unity-mir/devel ?
<kgunn> then i can put it in an existing silo
<kgunn> with https://code.launchpad.net/~mir-team/unity-mir/mir-0.2.0-compatibility-changes/+merge/218734
<kgunn> AlbertA: or should we just merge https://code.launchpad.net/~mir-team/unity-mir/mir-0.2.0-compatibility-changes/+merge/218734
<kgunn> into unity-mir/devel...
<kgunn> and MP unity-mir/devel to unity-mir trunk >
<kgunn> ?
 * kgunn goes to grab sandwich
<AlbertA> kgunn: yeah merge, if unity-mir/devel => means track mir changes it makes sense
<kgunn> dednick: nvmd :)
<kgunn> AlbertA: yes it does
<dednick> kgunn: huh? :)
<kgunn> lol...go back to trusted sessioning
<kdub_> AlbertA, camako: duflu asked for a resubmit on https://code.launchpad.net/~kdub/mir/overlay-gl-program/+merge/220690, so if you could take a look over again, I'd appreciate it :)
<camako> kdub_, will do
<AlbertA> kdub_:sure
<ogra_> moop
<kgunn> ogra_: yep, waiting on jdstrand
<ogra_> yeah
<kgunn> oh crap i gotta run...bbiab
<kgunn> AlbertA: can help with the discussion ogra_
<AlbertA> ?
<jdstrand> ogra_: do you still have /tmp/mir_socket too?
<ogra_> yes
<jdstrand> kgunn: so, there should be two sockets. one for the root process and one for the session. the one for the session has been correctly moved to XDG_RUNTIME_DIR aiui. why is the root one in /tmp? can't it go in /run/mir or something?
<ogra_> jdstrand, kgunn had to run and pointed to AlbertA ... i guess we need to summmarize for him
<ogra_> AlbertA, so according to the landings 0.1.9 should hav abstracted the socket name for mir_socket but we still see mir_socket for system-compositor as well as the session Mir
<ogra_> and both even with 666 permissions
<ogra_> seemingly https://code.launchpad.net/~mir-team/mir/utopic r1185 was supposed to change that
<ogra_> but it looks like it didnt
<ogra_> (teh secutity team would like to have abstract socket names ... jdstrand can probably elaborate)
<jdstrand> kgunn: plus, why is /tmp/mir_socket writable by world?
<jdstrand> ah, I missed that he ran
<jdstrand> so, /tmp/mir_socket is 777 and /run/user/32011/mir_socket is 775
<jdstrand> if we are using a named socket, I would expect 700 for both and /tmp/mir_socket to be in fome root owned directory (eg /run/mir)
<jdstrand> s/fome/some/
<ogra_> i think the session needs to be able to talk to it
<ogra_> not sure about the architecture here though
<jdstrand> if so, then still could use a root-owned dir
<jdstrand> the one in /run seems to lenient though
<AlbertA> ogra_: we decided not to go for abstract socket names since the security team said at the time apparmor did not mediate them
<jdstrand> too*
<jdstrand> ah, well, that will be this cycle
<jdstrand> jj has most of it ready
<jdstrand> AlbertA: ok, what about 775 for the one in XDG_RUNTIME_DIR? could that be 700?
<ogra_> jdstrand, does that matter ? the dir is already 700
<jdstrand> actually, that doesn't really matter, /run/user/32011 is 700
<alan_g> Shouldn't the filesystem endpoint be suppressed on the system compositor anyway?
<ogra_> :)
 * ogra_ thinks the session socket is all fine ... but the system one looks worrying
<AlbertA> jdstrand: at least a group no?
<jdstrand> AlbertA: ok, so, the perms on the one in XDG_RUNTIME_DIR are weird, but not a security issue since a parent dir is 700. could we move /tmp/mir_socket to /run/mir (or something-- some root-owned dir)?
<AlbertA> jdstrand: because we need mir clients to be able to connect to it
<jdstrand> AlbertA: if you need the root owned socket to be 777, that's fine, but can it be put in a non worldwritable directory?
<AlbertA> alan_g | EOD: but then how do you get the fd to connect to?
<jdstrand> /run/mir_socket would even be fine
<AlbertA> jdstrand: not sure who makes it 777...I suppose unity-system-compositor is changing the perms
<ogra_> but can user processes then write to it ?
<ogra_> sounds like that is needed
<AlbertA> jdstrand: but sure it doesn't have to be /tmp
<AlbertA> ogra_: the way I see it
<AlbertA> ogra_: the nested mir server (unity8 process) needs to talk to it...so that could just be a group permission
<ogra_> which the user is in
<ogra_> which in turn makes it fully user writable
<jdstrand> it may not necessarily be a security issue depending on how it opens the file and handles failure modes correctly. but putting it in /run makes sure it won't ever be
 * jdstrand notes that confined apps cannot connect to /tmp/mir_socket now, nor /run/mir_socket. they do have access to /run/user/32011/mir_socket
<ogra_> but in the split greeter world also the greeter needs to be in that group ... (the lightdm user) ... not sure what the security implications of that are
<AlbertA> ogra_: in any case the socket file name/path is configurable so it just a matter of setting the right option when launching unity-system-compositor
<ogra_> right
<ogra_> mterry, ^^^
<ogra_> can lightdm start u-s-c with a socket in a root owned dir ?
<ogra_> instead of tmp ?
<mterry> ogra_, so we need a world-accessible place for tjhe USC socket?
<ogra_> well, jdstrand would like to see it in /run
<mterry> ogra_, yeah, but the client sessions need to be able to access it
<jdstrand> I would be surprised if it didn't work...
<mterry> ogra_, both lightdm and USC are run as root, so I don't see a problem then
<ogra_> hmm, where do we set the var currently ...
 * ogra_ cant find it in usc-wrapper or ubuntu-touch-session 
<ogra_> i know we had $MIR_SOCKET once
<ogra_> or is that dead
<jdstrand> fyi, when we have abstract socket mediation in apparmor it opens the possibility to lock this down even more (eg, should be able to disallow any connections from unconfined and only allow connections from a particularly confined process-- eg, the session compositor)
<jdstrand> we don't have to do that now or anything, just saying
<AlbertA> ogra_: it's MIR_SERVER_FILE
<ogra_> AlbertA, right, but i dont see it being set anywhere .. we used to export that var in one of the start scripts before
<AlbertA> ogra_: ah I see
<ogra_> (not a  Mir thing :) )
<jdstrand> ogra_: so, it being in /tmp isn't a mir thing? I just did 'stop lightdm ; touch /tmp/mir_socket ; start lightdm' and was able to prevent lightdm from starting
<ogra_> jdstrand, no that var isnt a mir thing
<ogra_> jdstrand, ignore that ... i was looking at bending the var to make it use /run for a test
<ogra_> but i cant find where we set it anymore
<jdstrand> I'd like to file a bug, but don't know where...
<ogra_> unity-system-compositor creates the socket on startup now i think
<jdstrand> http://ubuntu-codesearch.surgut.co.uk/ didn't help me
<jdstrand> ./src/system_compositor.cpp:        return the_options()->get("file", "/tmp/mir_socket");
<jdstrand> (unity-system-compositor)
<ogra_> yeah
<AlbertA> ogra_: yes if it's not set, mir will create a default socket in /tmp/mir_socket
<AlbertA> I mean if MIR_SERVER_FILE is not set
<ogra_> right
<jdstrand> fyi, bug #1322300
<ubot5> bug 1322300 in unity-system-compositor (Ubuntu) "Please move /tmp/mir_socket to /run/mir_socket (or similar)" [Undecided,New] https://launchpad.net/bugs/1322300
<jdstrand> perhaps that should be retargeted to mir. feel free to do so
<jdstrand> AlbertA: is the protocol for talking to the mir_socket defined somewhere?
<AlbertA> yeah in mir
<AlbertA> jdstrand: it's essentially google protobuf messages over the socket
<jdstrand> thanks
<kgunn> AlbertA: thanks, sorry had to run...back now, read the scrollback...so end result is to change /tmp/mir_socket default in mir? or in usc ?
<AlbertA> kgunn: usc
<kgunn> via MIR_SERVER_FILE got it
<jdstrand> kgunn: not sure if you saw it, but I filed bug #1322300
<ubot5> bug 1322300 in unity-system-compositor (Ubuntu) "Please move /tmp/mir_socket to /run/mir_socket (or similar)" [Undecided,New] https://launchpad.net/bugs/1322300
<kgunn> jdstrand: yep...
<kgunn> just makin' sure i understood...if we were fixing it in usc or in mir
<kgunn> mterry: meant to follow up with you and anpok_ , did you guys have luck in determining where the high cpu load was coming ?
<kgunn> (and mem?)
<mterry> kgunn, no...  anpok_ pointed me at ricmm who said we have some code to disable sensors for unity8 (which may be related because sensors also take high CPU in this case), but didn't mention where.  I've been distracted by the volume button bug in meantime though
<mterry> kgunn, I'm trying to follow up with ricmm, but maybe he's EOD or something
<ogra_> mterry, he's sick
<mterry> ogra_, oh poor guy
<ogra_> he was around for a split second from his rrom earlier
<jdstrand> kgunn: I think the priority is higher than Opinion fwiw
<jdstrand> it is perhaps 'low' in practice, but I can easily prevent mir from starting without privs if I can create a file in /tmp before mir starts
<anpok_> re
 * kdub_ grumbles about our recomposite signalling
<kgunn> jdstrand: per discussion above with AlbertA, seems we want to fix it in USC....i only tied it to mir as "opinion" so it doesn't get lost
<kgunn> make sense?
<jdstrand> kgunn: oh, I missed that it was against the mir task. sorry
<AlbertA> kdub_: heh... but you are making it better now...:)
<jdstrand> kgunn: yeah, that makes sense
<kgunn> mterry: ricmm is in malta this week with kidney stones i hear ...wonder if rsalveti might know how/where code is to turn off sensors
<mterry> rsalveti, poke about your knowledge of any turning-off-sensors-for-unity8 code we have?
<kdub_> AlbertA, yeah, lucky me :)
<rsalveti> qtubuntu-sensors?
<kdub_> but really, this isn't 'rewire the recomposition signalling' its 'make it possible to replace the compositor easily'
<rsalveti> mterry: not sure if we have an easy way to disable it, Saviq would know
<rsalveti> but the bridge is in qtubuntu-sensors afaik
<mterry> rsalveti, hrm, a quick grep doesn't see the string unity8 in there
<mterry> rsalveti, (I'm trying to solve a problem that is apparently some piece of code examining the process name for 'unity8')
<rsalveti> no, that would be the just for qt, that implements the bridge between qml and platform-api
<rsalveti> hm, weird
<rsalveti> yeah, guess ricmm would be your guy
<dandrader> mterry, what sensor are you talking about?
<greyback> mterry: you sure it's unity8? Or just something that loads the ubuntumirserver QPA plugin?
<mterry> dandrader, sensors.qcom and whatever Binder_2 both stay at ~10% CPU (along with the greeter).  ricmm said we had some code to disable sensors for unity8, which I'm guessing is related?
<greyback> mterry: have you profiled the process to see what method is being called so much?
<mterry> greyback, I tried to use callgrind, but that slowed it down enough (even on lowest settings) that lightmd killed it.  I haven't gotten to the point of recompiling lightdm with larger timeouts
<greyback> mterry: try "perf"
<mterry> greyback, oh yeah?  Lighter weight?
<greyback> mterry: *much*
<mterry> greyback, OK, will do
<greyback> mterry: this is a note I have on how to get/use it, hope it helps: http://pastebin.ubuntu.com/7502908/
<greyback> important to install the linux-*-tools package that suits the kernel
<mterry> greyback, OK thanks!
<dandrader> mterry, well, there's platforms/ubuntu/ubuntucommon/screen.cc:127:"void QUbuntuScreen::toggleSensors(bool enable) const {" in qtubuntu that I think is used by both ubuntumirserver (unity8) and ubuntumirclient QPAs, if that's any help
<greyback> dandrader: looking at the same :)
<mterry> dandrader, qtubuntu does check for "unity8" as a process name, but it doesn't seem to be used anywhere!  I added debugging output and changed the check to look for unity8-greeter too, but no go
<mterry> greyback, just filed https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718 for the volume up/down issue I've been seeing
 * mterry is now laser focused on cpu bug
<greyback> mterry: no, it does no such thing. Unity8 loads the server plugin supplied by qtubuntu. qtubuntu does listen for orientation events somehow
<mterry> greyback, grep qtubuntu for unity8, it does do a check.  But I've been told that is dead code?
<mterry> SurfaceFlinger support I guess
<greyback> mterry: well I'm surprised. Yes it's checking the process name, and disabling sensors if it is unity8
<mterry> greyback, so while I think that's dead code, I'm worried that code got copied to some other component and is the source of my current problems
<greyback> mterry: that piece of code is very much being used still.
<mterry> greyback, !  I must be crazy then, because I put a qDebug() line in there and couldn't see it
<greyback> mterry: I must be mistaken. qtubuntu code a maze
<mterry> let me double check
<greyback> mterry: sorry to divert, but could you please link a bug to https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718
<mterry> greyback, done
<greyback> mterry: thanks!
<robert_ancell> What are edge_flags from MirMotionEvent?
<robert_ancell> RAOF, are you getting loads of Cyrillic spam too?
<kdub_> just went to launchpad.net and expected to see the mir homepage
<kdub_> we should look into fixing that
<kdub_> :P
<RAOF> robert_ancell: Dunno, but MirMotionEvent will probably be significantly different once we've worked out what we want in it :)
<robert_ancell> ha!
<RAOF> robert_ancell: Not too much Cyrillic spam, no.
<robert_ancell> I get tonnes of Cyrillic spam to my Canonical account
<RAOF> This is the stuff that makes it through the filters, right? I've not checked my Spam folder for the Canonical account in forever.
<robert_ancell> No, the filters catch it all
<robert_ancell> but I get enough false positives that I have to check the spam folder
#ubuntu-mir 2014-05-23
<RAOF> Hm. Keyboard input is not _quite_ correct :)
<robert_ancell> RAOF, there's no way in Mir to get a surface to render to that's not visible is there? i.e. surfaces are always mapped
<robert_ancell> or duflu ^
<robert_ancell> actually duflu. I was wondering why your Mir client examples render into a malloc'd buffer before copying into the one returned from mir_surface_get_graphics_region
<robert_ancell> why not just rendering in mir_surface_get_graphics_region?
<robert_ancell> why not just render into mir_surface_get_graphics_region I mean
<duflu> robert_ancell: Buffers are not preserved. At least not unless guaranteed by buffer_age semantics. And if you do use buffer age then you still have to track N different buffers yourself in the toolkit/client
<duflu> Also, when I wrote fingerpaint, software clients were GPU-backed, not SHM. So reading back from a buffer was slower than it is now.
<robert_ancell> duflu, mir_surface_get_graphics_region returns a new buffer right? And that is valid until mir_surface_swap_buffers is called?
<duflu> robert_ancell: Sounds right...?
<duflu> robert_ancell: Also, fingerpaint does that copy so it can remain dumb and not handle resizing :)
<robert_ancell> ok
<duflu> .. whilst not deleting your painting
<robert_ancell> the names are really confusing - get_backend seems to imply that you're getting some singleton and swap buffers implies there are two buffers
<duflu> robert_ancell: Given single-buffering support, fingerpaint wouldn't need that second malloc'd buffer
<robert_ancell> duflu, so what happens in swap_buffers when you're single buffered?
<duflu> robert_ancell: The latter issue is unfortunately a feature of OpenGL and many other graphics systems
<duflu> robert_ancell: It would just tell the server to start displaying a new frame, and you pray (or time it carefully) to minimize client drawing at the same time. It would tear, but in some clients like fingerpaint not visibly
<robert_ancell> and there'd be no swapping :)
<duflu> On the other hand, fingerpaint would still need the copy/other buffer to resize as well as it does now
<duflu> robert_ancell: Yes, "swap" as a verb is misleading in the world of 3 or more buffers. But that's a common misnomer of OpenGL and all modern graphics systems
<robert_ancell> in the case of buffers != 2
<duflu> Yes single too
<robert_ancell> you should stop propogating the madness via the API...
<robert_ancell> duflu, so my initial problem was GTK+ wants to start rendering before it's shown the window - is the only way to do this to rendering into some malloc'd memory (like in fingerpaint) and copy that into the graphics region once the window is shown?
<duflu> robert_ancell: It was discussed, but no one has a better verb in mind. Particularly since the word "swap" is already known to graphics programmers
<robert_ancell> finish?
<robert_ancell> post?
<robert_ancell> mark_ready?
<duflu> robert_ancell: Actually there is a "hide" flag in the server. We presently lack client API to access it :)
<robert_ancell> duflu, any reason not to expose it?
<duflu> robert_ancell: Also, the compositor won't show your window till you've finished the frame (swapped)... so no problem?
<robert_ancell> ah, ok
<duflu> robert_ancell: It's always hidden till one whole frame is finished
<robert_ancell> duflu, we're double buffered by default right?
<duflu> robert_ancell: Triple, everywhere
<duflu> I'm working to re-enable double, but it requires lots of smarts to switch on demand
<robert_ancell> so I shouldn't be able to add any flickering
<robert_ancell> as long as my buffer contents are correct
<duflu> robert_ancell: No, flickering/tearing is impossible (tm)
<robert_ancell> I like that
<duflu> ... because the client is always drawing to a different buffer to that which is on screen
<robert_ancell> duflu, do you get events on a surface before the first frame is drawn?
<robert_ancell> duflu, and the triple buffer is so you can swap at any time without getting caught when the CRTC is reading out
<RAOF> duflu: That's not _strictly_ accurate; misbehaving clients can tear, because they can keep a reference to the buffer they've submitted and continue drawing to it.
<RAOF> But they need to go to quite some lengths to do that :)
<robert_ancell> RAOF, yeah, there's no API to hold onto a reference is there?
<RAOF> Well, you can get the current buffer package, which contains (among other things) the fd for the current buffer and then use that fd whenever you want.
<robert_ancell> yeah, I'm not going to do that
<RAOF> But you can't easily draw to that fd :)
<duflu> It would require a lot of madness, similar to XMir :)
<robert_ancell> any ideas on if events get delivered to surfaces that haven't been shown?
<duflu> robert_ancell: I think a surface could get events immediately before it is composited. But I'm not sure what events...
<robert_ancell> I supose it could get resized
<duflu> Yes, the server/shell is free to resize at will. And the client has no choice
<duflu> for now
<robert_ancell> for ever
<robert_ancell> You hope the shell is well behaved but it can do anything right?
<duflu> robert_ancell: Maybe forever, don't know. Some clients might want to specify resize hints like "increments of a character" (terminal apps) or "fixed aspect ratio" (video)
<robert_ancell> RAOF, is buffer age only supported on some backends? Why is it part of NativeBufferPackage and not in the main client API?
<RAOF> buffer age should be supported for all backends.
 * RAOF looks.
<robert_ancell> I was expecting something like mir_surface_get_buffer_age ()
<robert_ancell> Hmm, I was assuming that NativeBuffer is not something you'd use for "normal" clients. Is that not the case?
<robert_ancell> yes, because it would be something entirely different on Android
<RAOF> Well, for normal clients you'd use EGL, and we'd expose buffer age that way.
<RAOF> (Note: We do not yet expose buffer age through EGL_EXT_buffer_age âº)
<robert_ancell> ha!
<RAOF> Bargh.
<RAOF> Why is INPUT_RECEIVER_REPORT=log going nowhere?
<robert_ancell> See y'all in Malta
<RAOF> Ok. So, that's correct rendering and inputish, but I need to deal with the âreceives swap_complete events for dead surfacesâ thing.
<racarr__> RAOF: Rootless X?!
<RAOF> racarr__: Indeed.
<racarr__> yay
<RAOF> It's hacked up at the moment, so uuugly (and has probably broken rooted mode)
<RAOF> But I should learn how to mir_screencast
<RAOF> ;)
<duflu> RAOF: I think the actual making video instructions are buried in email threads somewhere
<duflu> which I can't access as I am busy transferring to the laptop
<duflu> RAOF: https://lists.ubuntu.com/archives/mir-devel/2014-February/000650.html
<RAOF> Good, good. Making mir_surface_is_valid unconditionally return false does make some tests fail.
<alf_> anpok: @unregister-fd-handler, I wonder if using the main loop mechanism to handle the FDs for input is the way to go. Do we need total serialization of the messages?
<alf_> anpok: I could imagine using a more focused class for this purpose (but I am not familiar with the details)
<alf_> anpok: are these going through the server main loop, or will we have a different object?
<anpok> alf_: they do not have to go through the server main loop
<anpok> alf_: https://code.launchpad.net/~andreas-pokorny/mir/unregister-fd-handler/+merge/220571/comments/528020
<mterry> greyback, got several related branchs for split I would love a review on today:  https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718  https://code.launchpad.net/~mterry/qtubuntu/greeter-is-shell/+merge/220543  and https://code.launchpad.net/~mterry/unity-mir/dont-hide-focused-apps/+merge/220130
<greyback> mterry: I'm just about to head to airport, I'll try to review while in the lounge
<racarr__> hmm
<racarr__> the dithering is wrong
<racarr__> in unity8-mir on my new
<racarr__> laptop
<racarr__> or
<racarr__> something
<racarr__> insane banding
#ubuntu-mir 2015-05-18
<alan_g> racarr: https://code.launchpad.net/~mir-team/mir/unify-pointer-button/+merge/259148/comments/648194
#ubuntu-mir 2015-05-19
<tsdgeos>  sudo touch /userdata/.adb_onlock
<alan_g> racarr: is the lp:~mir-team/mir/touch-validating-client MP missing a prerequisite?
<racarr> alan_g: Haha whoops no I pushed a giant composite branch I was using for testing
<alan_g> racarr: you should read through your on MPs before lettings us see them.
<alan_g> *own
<racarr> Fixed. Thanks.
<racarr> alan_g: Yeah sorry things are a little chaotic here.
<racarr> also I guess I gave up reviewing my own mps I used to review them all every line
<racarr> but noticed it made no difference in review time/comments
<racarr> received
<racarr> so ti doesnt seem I can
<racarr> effectively review my own code
<racarr> lol
<racarr> anyway sorry for wasting time
<alan_g> at least it ensures we're reviewing what you intend to propose.
<racarr> yes sorry lol
<alan_g> I find that scanning the MP diff before setting status "Needs Review" catches a lot of debug & experimental code. (And some bzr weird stuff.)
<mterry> RAOF, where did you get your copy of ubuntu-clock-app?  The ones in the daily coreapps ppa are ftbfs
<RAOF> mterry: I got the trusty version :)
<mterry> RAOF, hrm
<mterry> RAOF, guh it's ftbfs because it uses online sites during tests
 * mterry builds locally
<alan_g> alf__: https://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/33/consoleFull
<alan_g> alf__: https://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/33/consoleFull
<alan_g> alf__: ClientLibraryThread.does_not_interfere_with_client_signal_handling
<mterry> RAOF, after a long time fighting with getting to the point of seeing the clock-app failure, I've determined it's something inside the Ubuntu.Components plugin.  Digging deeper
<RAOF> mterry: Thanks
#ubuntu-mir 2015-05-20
<racarr_> http://hintjens.com/blog:85 was an interesting but kind of wordy read while waiting for branch to compile "As I've explained, a living software product will usually deliver a mix of draft, stable, legacy, and retired contracts. Rather than try to assign a "major.minor.patch" version number to the overall mix, to indicate stability and maturity, it is more sensible to list the contracts explicitly in th
<racarr_> e living code (on git master)."
<alan_g> greyback: the spike we spoke about: https://code.launchpad.net/~alan-griffiths/qtmir/spike-using-WindowManager
<tedg> kgunn, <infinity> tedg: Can you ask a Mirish person where the source for test_data/lib$(arch).so is?
<tedg> racarr_, Do you by chance know? ^
#ubuntu-mir 2015-05-21
<seb128> hey there
<seb128> does the u-s-c errors on http://paste.ubuntu.com/11263708/ is something known around?
<seb128> "Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
<seb128> std::exception::what: Couldn't clear output LVDS-1 (drmModeSetCrtc = -13)"
<seb128> would that be a Mir bug?
<seb128> I guess that with people are the sprint not many watch irc? or just not having a clue about the error?
<alan_g> kdub: looks like your "Needs Fixing" is addressed: https://code.launchpad.net/~mir-team/mir/touch-validating-client/+merge/259436
<mterry> RAOF: FYI, https://bugs.launchpad.net/mir/+bugs?field.tag=snap is where and I were tracking issues with the Snappy version of Mir
<RAOF> Wicked.
<mterry> RAOF, one of them is with the in-tree version, two of them are with the deb2snap version
<RAOF> seb128: Sorry, not watching IRC at 8am :)
<mterry> RAOF, nothing important really.  Just a heads up that the snap tag even exists
<seb128> RAOF, oh, I though it was later than that in texas ;-)
<seb128> RAOF, good morning!
<RAOF> seb128: Good morning!
<RAOF> seb128: errno 13 == EACCESS. What were you doing? (For example, had you VT switched back to X at some point?)
<seb128> chrisccoulson, ^
<seb128> RAOF, I'm just fwding chrisccoulson's log
<RAOF> Ah, ta.
<seb128> he said he was trying to open an unity8 desktop-next session
<seb128> on a vivid laptop docked
<seb128> but has similar issues when undocked
<chrisccoulson> RAOF, yeah, I VT switched back to my X session after logging in to Unity 8 and getting a black screen
<seb128> so maybe different issues
<seb128> could be that unity8 doesn't start because of the wrong platform being loaded (you had xcb errors)
<chrisccoulson> brb
<alan_g> camako: I tried adding 011 to my mako, but didn't get a Mir update
<racarr> alan_g: http://pastebin.ubuntu.com/11267001/
<racarr> alan_g: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+packages
<RAOF> alan_g: https://code.launchpad.net/~raof/mir/document-our-random-test-binary-data/+merge/259798
<RAOF> chrisccoulson: Oh! Did you happen to have multiple displays plugged in?
#ubuntu-mir 2015-05-22
<posix4e> How hard is it to port something from X11 to mir
<alan_g> it depends on the something
<RAOF> Short answer: it depends.
<RAOF> posix4e: *Mostly* it depends on: Are you using GTK or Qt (or, indeed, SDL)?
<RAOF> If the answer to that question is âyesâ, then porting to Mir is roughly equivalent to âtry running itâ.
<posix4e> i'm looking at servo
<posix4e> it's the new firefox in rust
<posix4e> https://github.com/servo/servo
<posix4e> https://www.irccloud.com/pastebin/KrtAb4Ib
<RAOF> posix4e: Oh, yeah. It doesn't use a toolkit, so will need to be actually ported.
<posix4e> RAOF: that probably makes more sense for something like a webbrowser anyway
<posix4e> anything i can look at to get started?
<RAOF> posix4e: Acutally, does servo use X11 at all?
<RAOF> IIUC it's the rendering engine, not the frontend?
<posix4e> RAOF: indeed
<posix4e> but it has a frontend
<posix4e> which is some new version of something from firefox
<posix4e> hence my original question about people porting firefox
<posix4e> Thanks for being helpful btw
<posix4e> I know this is a weird train of thought, ubuntu and mozilla being mortal enemies and all
<RAOF> Ah, right.
<RAOF> ???
<RAOF> So, the way to start would be... let me think...
<posix4e> RAOF: kidding about the enemies thing, but i think they hook up to opengl
<RAOF> Heh. One option would be to create a chroot without any X11 libraries, install Rust in there, and try running âcargo buildâ :)
<posix4e> so it shouldn't be bad right?
<RAOF> Indeed.
<RAOF> Well, I guess it depends if they hook up to GLX or EGL.
<posix4e> *nod
<RAOF> GLX would require more effort, because it's intrinsically tied to X.
<RAOF> If they use EGL it would basically be a matter of passing a different type in (a MirConnection rather than a Display, a MirSurface rather than a Window) and everything else would work without effort.
<posix4e> so basically the android servo uses egl
<posix4e> that's probably what we want anyway for the tablet
<RAOF> Yup.
<RAOF> So, basically I'd guess what you need to do is grep for XOpenDisplay, and replace the things that start with that codepath. :)
<posix4e> neat
<posix4e> what do i do to get things into the marketplace
<posix4e> actually
<posix4e> i'll bug ubuntu-touch for the rest of my queries
<posix4e> You guys rock!
<posix4e> huh
<posix4e> logs.glob.uno/?c=mozilla%23servo&s=13+May+2015&e=13+May+2015&h=mir#c211813
<RAOF> Yeah, dmabuf solves their texture sharing problems.
<RAOF> *If* they can get the relevant fd out of the libEGL, of course :)
<posix4e> mwhaha
<chrisccoulson> posix4e, are we going to have a servo-powered web browser on Ubuntu phone?
<chrisccoulson> That would be awesome
<chrisccoulson> no pressure ;)
<posix4e> I am thinking about it
<posix4e> doesn't look like it's that bad
<chrisccoulson> hey RAOF, isn't it the weekend for you already?
<RAOF> chrisccoulson: Not in Dallas, no.
<RAOF> Hah! IRC bouncer resync.
<chrisccoulson> RAOF, you're not in the part of the world that I thought you were ;)
#ubuntu-mir 2016-05-24
<zzarr> hello!
<RAOF> Hi!
<zzarr> now I'm here again, new thoughts and ideas how to possibly solve my problem
<zzarr> Mir on ASUS Chromebook Flip that is
<zzarr> I know this is a hypothetical question or a theoretical maybe, but do you think I will be able to use the binary blob with libhybris now when Google enables Android apps on Chromebooks?
<RAOF> Possibly?
<zzarr> (not just a few apps, all of them)
<RAOF> It depends on how they do their EGL layer.
<zzarr> I know that it has a lot to do with how they solve the rendering
<RAOF> They may well not expose HWC, which would mean ânoâ.
<zzarr> RAOF, what is EGL?
<RAOF> The cross-platform bind-a-GLish-API-to-a-native-window API.
<RAOF> The abstraction of GLX, WGL, AGL, etc.
<zzarr> okey, I'm a bit lost, I confess but I do have a clue
<zzarr> I have a feeling that is the way they may solve it
<RAOF> They probably *won't* expose HWC (which we need), because that's only needed for implementing SurfaceFlinger, and isn't exposed to Android apps AFAIK.
<RAOF> What doesn't work on the Chromebook Flip, by the way?
<zzarr> RAOF,could you specify "doesn't work"?
<RAOF> What are you trying to do, and what's preventing you from doing it?
<zzarr> RAOF, I wish to run an GPU accelerated Mir/Unity8 but it's not possible
<RAOF> Why not?
<zzarr> no drivers
<RAOF> What GPU does it have?
<zzarr> it's powered by a Rockchip RK3288 which have a Mali 764
<zzarr> there are drivers for Android and for X11
<zzarr> it's a bit sad, the Chromebook flip and Unity8's ability to change between desktop and tablet GUI is as made for each other
<RAOF> If there are already drivers for android, why can't you use those?
<zzarr> don't they require me to build the kernel for android?
<RAOF> Yes.
<zzarr> how do I do that?
<RAOF> The Android OSP should have docs on that.
<RAOF> I've not done it myself.
<zzarr> okey, do you know if I can keep the rest of the drivers or if I need drivers for the touch, wifi, bluetooth and so on?
<RAOF> You'll probably need android-userspace drivers for some of that.
<RAOF> Hm, or maybe not.
<RAOF> I'd expect touch, wifi, and bluetooth to all be kernel-only and happy with Ubuntu userspace.
<zzarr> as it is now they work with Ubuntu
<zzarr> RAOF, do you know how to configure the lid? (closed, open or over 180 degrees)
<RAOF> No, sorry.
<zzarr> okey
<greyback> hey folks, in mesa, there is the big egl-platform-mir patch. But I don't see it actually creating a Mir platform, along side the GBM/X11/Wayland platforms.
<greyback> e.g. there is no EGL_EXT_platform_mir
<greyback>  hey folks, in mesa, there is the big egl-platform-mir patch. But I don't see it actually creating a Mir platform, along side the GBM/X11/Wayland platforms.
<greyback>  e.g. there is no EGL_EXT_platform_mir
<anpok> greyback: yes. As far as I know support for such an extension does not exist yet.
#ubuntu-mir 2016-05-25
<greyback> hey, who here could give me some advice about EGL?
<greyback> http://pastebin.ubuntu.com/16677510/ is a backtrace for a crash in a trivial Qt app on an Atom machine
<greyback> note I have to run that with EGL_PLATFORM=mir, as otherwise EGL tries to conenct to X: libEGL warning: DRI3: xcb_connect failed
<anpok_> aeh and does qteglchooser connect to a mir server?
<anpok_> it looks like the diplay it receives is not right one
<anpok_> +the
<anpok_> greyback: ^
<greyback> anpok_: that is quite possible yeah. I've just deduced the same :)
<greyback> I wasn't aware that connecting to mir was a requirement for getting and egl context
<anpok_> hm well having a EGLDisplay thing is a requirement
<greyback> so eglGetDisplay(EGL_DEFAULT_DISPLAY) won't just return something useful?
<greyback> you need to connect to mir, get the native display first, and then use that
<anpok_> not sure what mesa does in that case - I would assume that it tries dri devices directly, but it seems that x is the fallback
<anpok_> so in a post mir domination age it might.. return something more usefyl
<anpok_> *useful
<greyback> ok
<greyback> I had thought we'd patched egl to try connect to mir in the background
<greyback> which wouldn't be a bad fallback
 * anpok_ looks at the patch
<greyback> my thinking not based on any actual factual evidence, just a hunch
<anpok_> nope we really did not.. but we could do that
<anpok_> cemil currently cleans that up.. but he thinks it might still take a while
<greyback> hey folks, I've taken the eglinfo tool (prints all EGL configs and their data) and added Mir support
<greyback> what surprised me is that on some devices, e.g. Atom, only a subset of configs are available
<greyback> http://pastebin.ubuntu.com/16686113/
<greyback> lp:~gerboland/+junk/eglinfo/ to try it for yourself
<robert_ancell> kgunn, did you get chatter running fine on your non-arm device?
#ubuntu-mir 2016-05-26
<kgunn> robert_ancell: i did no problem, thanks!
<robert_ancell> kgunn, awesome
<duflu> robert_ancell: In case it matters, I'm halfway through a focus handling enhancement in Xmir. Don't release what's there (half done)...
<robert_ancell> duflu, ack
<duflu> Ta
<cppGreen> I was reading over /mir/cppguide/index.html#Friends, in a section it reads - Friend declarations should always be in the private section,...    its does not exactly why this should be the case. C++  mentions that friend enhances encapsulation. friend grants selective access to members, just like protected does. so I am curious as to why?  the declarations should always be in the private section???
#ubuntu-mir 2016-05-27
<duflu> bschaefer: I finished focus tracking in Xmir yesterday. Just need someone who knows how to package it...
<bschaefer> duflu, sweet! Thank you for doing that
<duflu> No problem
<bschaefer> duflu, i guess vivid + overlay is trunk pretty much sooo it shouldnt be hard to get there at lease
<duflu> bschaefer: The feature is active for either -rootless or -title @, and Unity8 uses the latter right now
<duflu> In future it should use the former
<bschaefer> duflu, cool, if branch is linked to bug ill test it out tomorrow
<bschaefer> would be nice ot get the full feel for the phone
<duflu> bschaefer: It's on trunk :)
<duflu> In git
<bschaefer> duflu, sweet!
<duflu> I couldn't see any other event types we might have forgotten to implement
<duflu> Not sure
<bschaefer> yeah i didnt hit any that ... i could think of
<duflu> It's correct to implement focus tracking for -rootless. For non-rootless not correct, but we already have the '-title @' hack in place that's kind of rootless for non-rootless while Unity8 catches up. So that gets it too
 * bschaefer gets so confused on all the wm stuff in place at
<bschaefer> atm :)
#ubuntu-mir 2017-05-22
<alan_g> greyback: hi, good break?
<greyback> alan_g: hi, yes, just not long enough :)
<alan_g> Be careful what you wish for!
<greyback> :D
<alan_g> greyback: got time to take a look at this? https://code.launchpad.net/~albaguirre/qtubuntu/use-mir-rs-api/+merge/321627
<greyback> Sure
 * alan_g hates it when he spends a day debugging test stubs! They shouldn't be so complicated!!
<anpok_> hm
#ubuntu-mir 2017-05-23
<RAOF> Yes!
<Son_Goku> eh?
<RAOF> The test stubs should indeed not be so complicated.
