[01:15] <RAOF> Ok, that's a bit annoying. gdb now segfaults trying to read debugging symbols from mir_unit_tests
[02:33]  * RAOF heads due luncheon
[03:05] <kgunn> ok, realized i've never done this...if i run mir_demo_server_basic on vt1 and i want to kill it, how would i do that?
[03:05] <kgunn> duflu: RAOF ^ ?
[03:06] <duflu> kgunn: Firstly, server_shell is much cooler :) Secondly remember to sudo or else Mir doesn't have input (quit) support - https://bugs.launchpad.net/mir/+bug/1286252
[03:07] <duflu> kgunn: Once you have input support it's Ctrl+Alt+Backspace
[03:08] <kgunn> duflu: ah, i did sudo....
[03:09] <duflu> That reminds me, I wanted to move some common logic like that into the server library and let shells override it. It's annoying every demo shell should have to re-implement something as basic as quitting
[03:09] <duflu> (because mir_demo_server_minimal is unquitable, I think)
[03:14] <duflu> Oops. Quit the wrong shell?
[05:03] <RAOF> anpok_: Are you planning to try and land https://code.launchpad.net/~andreas-pokorny/mir/add-timer-to-main-loop/+merge/216881 anytime soon, or should I un-depend-upon it in 1Hz-rendering?
[06:14] <RAOF> Oooh! Oooh! Oooh! There's a new button on Launchpad reviews, “Show inline comments”!
[06:21] <duflu> Wha?!
[06:21] <RAOF> There's no ability to comment inline yet, but the first parts of that series are landing.
[06:21] <RAOF> Yay!
[06:22] <duflu> RAOF: Heh, yeah I was trying to figure out how to make one
[06:23] <duflu> What would also be really nice is side-by-side diffs
[06:23] <duflu> In my experience they're much better for code review
[06:31] <RAOF> Hm. Dumping the diff into meld would be pretty cool, yeah.
[06:35] <RAOF> That would probably be pretty easy to do, actually.
[06:42] <anpok> RAOF: i thought about doing so now, but havent started workin on that
[06:51] <RAOF> anpok: Well, sometime would be nice, as 1Hz-rendering depends on it.
[07:24] <duflu> RAOF: (1) Happy weekend. else (2) Please check again: https://code.launchpad.net/~vanvugt/mir/simplify-BufferQueue/+merge/218794
[07:24] <RAOF> duflu: Doing so :)
[07:28] <RAOF> duflu: It seems that the uniqueness constraint could be satisfied in a less invasive way.
[07:28] <duflu> RAOF: You mean more exhaustive? I'd rather simplify and shrink the code before reconsidering unnecessary micro-optimizations
[07:31] <RAOF> I don't suppose you've got a test for this?
[07:32] <duflu> RAOF: It can't really be tested. The symptom is memory bloat of a private member... that is never leaked
[07:32] <duflu> You can observe and test it externally, obviously
[07:33] <duflu> I'll do another alt fix proposal
[07:34] <duflu> I've come to not expect anything to land, so I work on many different things at once :)
[07:34] <RAOF> You could measure memory use over thousands of compositor_acquire/compositor_release cycles, if nothing else :)
[07:40] <duflu> RAOF: fprintf tells me the vector is huge... I don't really need any more info
[07:40] <duflu> Hmm, a "smaller" fix actually isn't working
[07:40] <RAOF> But you can't run an fprintf test on every commit :)
[07:42] <duflu> RAOF: I don't intend to. Very few performance bugs get regression tests in general. Although I did manage with a bunch of SwitchingBundle issues before...
[07:42] <duflu> Also memory bloat is an issue most programmers never consider. They think not leaking is enough... but really you need to do real external system testing
[07:44] <RAOF> I'm still not sure why this isn't a proper target for an automated test?
[07:44] <duflu> RAOF: Hmm, could just set a time limit on the existing test and fail I guess
[07:45] <duflu> That would do it, but only on a small subset of system
[07:45] <duflu> Heh. I never intended to fix any bugs with this proposal
[07:45] <duflu> It just happened
[07:47] <RAOF> Parse /proc/self/status, check RSS isn't increasing over thousands of compositor cycles? :)
[07:50] <alan_g> Put a "reasonable" limit on the size and assert? Or add a query to report the queue sizes that can be checked in unit test?
[07:51] <duflu> alan_g: I think that's a case of testing the known cause, when a fix would eliminate the test. I'm trying for a different test that would remain valid regardless of the implementation
[07:52] <alan_g> duflu: I know but lacking a generic option it is better than no test.
[07:53] <duflu> alan_g: I might have a generic options. On the other hand, I don't think any or all memory bloat problems have internal testing. It's really an external thing usually
[07:53] <RAOF> Parsing /proc/self/smaps would get you a pretty good “am I using more memory by doing this thing over and over” test.
[07:54] <RAOF> This sounds like something that might be good for mir_test{,_framework}, actually.
[07:54] <alan_g> RAOF: that sort of thing is probably more appropriate in the acceptance/stress/performance tests
[07:54] <alan_g> yes
[08:00] <RAOF> Anyway, EOW for me!
[08:45] <alan_g> dednick: do you approve https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218629?
[08:46] <alan_g> Or are there still problems using it?
[08:47] <dednick> alan_g: got it working with trust sessions after you left last night. just approved
[08:47] <alan_g> Great!
[09:37] <duflu> alan_g: I'm seeing it too now. If you want to take over this, please do: https://bugs.launchpad.net/mir/+bug/1317801
[09:37] <alan_g> duflu: ack - not sure I'll get to it this week though
[09:38] <duflu> alan_g: Sure. Just mentioning in case you do. Otherwise my Monday comes sooner
[09:39] <alf__> duflu: I may be able to take it over today, I will reassign is so
[09:40] <alf__> s/is/if/
[09:40] <duflu> alf__: That would be good too
[09:43] <duflu> I got way too ambitious in the number of fixes I could get landed
[09:43] <duflu> Need to share the love a bit more
[10:06] <duflu> On the upside, not making progress gives me a clean slate for the weekend. Till next time...
[13:28] <anpok> AlbertA: any reason why you wrote for-loops instead of auto pos = find(begin(..),end(..),item).. in the buffer queue?
[13:28] <anpok> I mean was that based on the profilings?
[13:31] <AlbertA> anpok: yeah they did better in profiling and std::find and iterators
[13:31] <anpok> ok, i assumed those would be identical for somehing like vector
[13:31] <AlbertA> anpok: there's a small overhead when constructing iterators at least on gcc/glibc
[13:33] <AlbertA> anpok: so since the number of elements is small - the overhead in comparison is significant
[14:44] <seb128> hey Mir team
[14:44] <seb128> I've a dell inspiron 11 laptop, which has a touch screen, testing unity8/Mir on trusty ... things run fine but the touch screen doesn't work
[14:45] <seb128> is that a known issue/limitation?
[14:48] <racarr__> Morning
[14:49] <seb128> hey racarr__, how are you?
[14:51] <alan_g> seb128: racarr__ probably knows that part of the stack best.
[14:54] <racarr__> seb128: Oh pretty good! You?
[14:54] <seb128> I'm good thanks!
[14:54] <racarr__> re: the touch screen...hmm...no one has one
[14:54] <racarr__> so its hard to say
[14:54] <racarr__> its not exactly expected to ork in that anyone has tried it
[14:55] <racarr__> but I dont know why it wouldn't work...
[14:55] <racarr__> someone has used a laptop touchscreen with success
[14:55] <racarr__> maybe olli
[14:56] <racarr__> so there must just be some sort of quirk or something
[14:56] <racarr__> seb128: If you want to dig deeper MIR_SERVER_LEGACY_INPUT_REPORT=log MIR_SERVER_INPUT_REPORT=log could have something
[14:56] <seb128> k
[14:56] <racarr__> (export them as env variables in the environment unity system compositor is in)
	seb128, your hardware may need to be defined as an Android touch device for Mir to recognize it properly
	all of mine work out of the box now, but initially I had to create a file somewhere with hexadecimal device IDs in the title, can;t recall the details....
	I'll need to dig that up
[14:57] <seb128>  
[14:57] <seb128> is that what I've been told yesterday
[14:57] <seb128> so I figured that you guys might know more about that ;-)
[14:58] <racarr__> seb128: yes there are these ".idc" files
[14:58] <racarr__> I  have never touched the code or one though so im not sure...
[14:58] <racarr__> thats a good idea though
[14:58] <bregma> yeah, .idc files, that's it
[14:58] <racarr__> some community guy porting a device...that was his f
[14:58] <racarr__> ix
[14:59] <racarr__> when his touchscreen didnt work
[14:59] <racarr__> um I can look in to it after standup. or you can probably find one on your phone
[14:59] <seb128> I'm fine hacking it locally
[14:59] <bregma> some touchscreens are not recognized as such because, well, hardware is flaky, so they need an IDC file to force the issue
[14:59] <seb128> but that would be nice if those stuff were working out of the box
[14:59] <seb128> normal users are not going to go figure that out
[15:00] <seb128> well, the touchscreen is working fine under Xorg/unity7
[15:00] <seb128> so somehow it's recognized correctly
[15:00] <seb128> just not by Mir
[15:04] <tedg> Do we get a compose key for free in Mir, or is that something we'll have to do ourselves?
[15:06] <racarr__> I dunno, we might get it for free from XKB
[19:23] <AlbertA> anpok: so assuming we change to pre-multiplied alpha
[19:23] <anpok> AlbertA: where are we using the suspicious masking - or rather
[19:23] <anpok> why does the issue not occur on the framebuffer?
[19:23] <anpok> is the blending function for a normal display buffer different than for screen casing?
[19:23] <anpok> *casting
[19:24] <AlbertA> anpok: no it's the same
[19:24] <AlbertA> anpok: but assuming we change the blending function -
[19:24] <anpok> ah the scanout fixes it..
[19:24] <AlbertA> anpok: there's still the issue that nested servers
[19:25] <anpok> hm but over-blending with premultiplied should be associative
[19:25] <AlbertA> anpok: would like to specify the final alpha value in the framebuffer
[19:25] <anpok> well the initial one has to be zero
[19:25] <AlbertA> anpok: for per-pixel alpha transitions between sessions
[19:26] <anpok> hm you mean the nested session want to do direct alpha writes?
[19:26] <anpok> *wants
[19:27] <AlbertA> anpok: well somehow...the main thing is supporting per-pixel alpha transition effects
[19:27] <anpok> i thought for our use cases we start with zero and just combine blend one over the other..
[19:28] <anpok> could you explain more
[19:29] <AlbertA> anpok: what do you mean start with zero
[19:29] <AlbertA> anpok: alpha zero as background you mean?
[19:29] <anpok> clear the frame buffer on usc, and every nested session that has an alpha channel to rgba=0,0,0,0
[19:29] <anpok> yes
[19:30] <AlbertA> anpok: ok, yeah that's what we kinda do
[19:31] <anpok> so if the the normal blend mode (1,1-alpha) is not enough, we might have to extend the api
[19:31] <anpok> so I think (alpha,1-alpha) is just wrong
[19:32] <anpok> i mean we could extend the api to override the normal blending with other modes
[19:36] <anpok> ah something like nv_blend_equation_advanced
[19:37] <AlbertA> anpok: I suppose that in the nested case the resulting surface will have pre-multiplied rgb components
[19:37] <anpok> yes
[19:37] <AlbertA> anpok: and I suppose the QT renderer will produce the same as well
[19:37] <AlbertA> anpok: so yeah I can see we need to assume pre-multiplied alpha
[19:38] <anpok> hm we have to places, the demo_renderer and the gl_renderer
[19:38] <AlbertA> anpok: right
[19:38] <anpok> looking forward to the review :)
[19:39] <anpok> we even have a test case that requires current behavior
[19:39] <AlbertA> anpok: what do you mean?
[19:39] <anpok> the test case of gl_renderer is kind of .. odd
[19:40] <anpok> whenever you change something there you have to update the test case
[19:40] <anpok> i mean, you cannot change it without breaking the unit test
[19:41] <anpok> ah with review - i meant that I expect further comments with regard to alpha usage in gernal
[19:44] <anpok> hm the round corners of the window decoration look strange now
[19:45] <AlbertA> anpok: ummm, actually now that I think about it...you can change the surface global alpha
[19:45] <AlbertA> anpok: which means we can't assume pre-multiplied either
[19:45] <racarr__> gonna top approve https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-2-resubmit/+merge/217685
[19:46] <racarr__> soon
[19:46] <AlbertA> anpok: I suppose we could change the shader to make it so...but doesn't seem right
[19:46] <racarr__> unless anyone else wants to weigh in on MirCursor v. MirCursorConfiguration
[19:46] <anpok> racarr__: text conflicts?
[19:47] <racarr__> damn
[19:47] <racarr__> so close
[19:48] <anpok> AlbertA: hm i think we have to
[19:48] <racarr__> ok fixing
[19:48] <racarr__> I honestly cant believe how dumb merge algorithms are
[19:48] <racarr__> I mean
[19:48] <racarr__> I can because they are very easy to understand
[19:48] <racarr__> its just annoying
[19:49] <anpok> there is a project that tries to provide a more semantic merge
[19:49] <racarr__> I have seen some lately (Though only proprietary)
[19:50] <racarr__> im really excited
[19:50] <anpok> does the merge on a whole program representation
[19:50] <racarr__> yeah
[19:50] <anpok> i.e. the one i read about was limited to c# for now
[19:50] <AlbertA> anpok: yeah I see if we need to support correct alpha values in the framebuffer (for nested) I don't see a way
[19:50] <AlbertA> anpok: around pre-multiplied assumption
[19:50] <anpok> yes
[19:50] <anpok> AlbertA: if we dont do that we will be haunte by porte&duff
[19:50] <anpok> *porter
[19:51] <anpok> *haunted
[19:51] <AlbertA> right
[19:51] <AlbertA> :)
[19:51] <racarr__> it would be a really fun problem to hack on (semantic merge)
[19:52] <anpok> hm we have clang now
[19:52] <anpok> and there is a python libclang wrapper
[19:53] <anpok> and you could make it learn from existing merges in the history of the project..
[19:53] <racarr__> haha. thats an even more fun problem
[19:53] <anpok> i.e. if dev a integrates code of dev b and there is conflict
[19:53] <racarr__> I was thinking you could jut come up with
[19:53] <anpok> always take dev a.. or something..
[19:53] <racarr__> lots of hardcoded scenarios
[19:53] <racarr__> that would solve most dumb problems
[19:53] <anpok> ok
[19:53] <racarr__> i.e. a class definition gains
[19:54] <racarr__> two method declarations
[19:54] <racarr__> at the same line
[19:54] <racarr__> isnt a conflict :p
[19:54] <racarr__> its just two people adding a method to a class
[19:54] <anpok> but in different order
[19:55] <racarr__> well right, somethings the order does matter, whereas if two developers put a method definition in a class
[19:55] <racarr__> at the same time
[19:55] <racarr__> its probably just fine to put the one that was added latter (in terms of timestamp) on the line after
[19:55] <racarr__> sometimes*
[19:59] <anpok> AlbertA: ah that would just be frag*alpha in the shader
[19:59] <anpok> it looks like someone did that on purpose the way it is done now
[19:59] <anpok> and thats good
[19:59] <AlbertA> anpok: right the issue is how do you know which sources are pre-mutiplied already
[20:00] <AlbertA> anpok: and which ones aren't
[20:01] <AlbertA> anpok: what's in the shader currently is only to handle global alpha
[20:01] <anpok> hm right now all our client surface are.. but most of them have alpha=1 so we do not notice the difference
[20:02] <AlbertA> anpok: :) he yeah I guess if we look at it that way...
[20:03] <anpok> if fingerpait would bitblt an rpba png image wihout telling lpng to premultiply
[20:03] <anpok> i guess then we would have that case
[20:04] <anpok> (can libpng do that?)
[20:04] <AlbertA> anpok: not sure...
[20:04] <AlbertA> anpok: but yeah I guess we don't change the shader
[20:04] <AlbertA> anpok: or rather
[20:04] <anpok> why not?
[20:05] <AlbertA> anpok: I mean yeah change the shader but correctly compute the global alpha and just assume
[20:05] <anpok> ah o
[20:05] <anpok> k
[20:05] <AlbertA> anpok: the source is already pre-multiplied
[20:06] <rsalveti> kgunn: glmark2 just got approved
[20:06] <rsalveti> should be migrated soon
[20:06] <kgunn> \o/ thanks much rsalveti ... josharenson ^
[20:07] <anpok> AlbertA: do you understand how the top decorations are drawn in the demo renderer
[20:10] <AlbertA> anpok: the title bar?
[20:10] <anpok> yeah, hm the part that should be cut off just started to get shine in the colors of the rainbow
[20:11] <anpok> -to get
[20:11] <anpok> there is something wrong
[20:11] <AlbertA> anpok: oh really? I'm not seeing that...you mean with the tip of mir devel?
[20:15] <anpok> if you swith to porter&duff over blending, then the top  corners of the window are not properly cut off
[20:15] <AlbertA> ahhh...
[20:15] <anpok> but thats an error in the code that draws the decoration
[20:15] <AlbertA> saturation?
[20:15] <AlbertA> or maybe overflow
[20:15] <AlbertA> wrapping around
[20:16] <anpok> it does if(at corner) { if(in above cricle) { cancel } }  if(cy<y) { shade )
[20:16] <anpok> but it should be
[20:16] <anpok> it does if(at corner && (in above cricle) { cancel } else  if(cy<y) { shade )
[20:17] <anpok> demo_renderer.cpp:98
[20:18] <anpok> hm still strange
[20:20] <anpok> ah yes it is a wonderful case of non premultiplied
[20:21] <anpok> as it only sets the alpha value but does not multiply it to the rgb
[20:25] <anpok> AlbertA: will you create an MP?
[20:29] <josharenson> yes thanks rsalveti... So I can look for it in universe in a few days?
[20:30] <rsalveti> josharenson: yeah, probably later today
[20:30] <rsalveti> https://launchpad.net/ubuntu/+source/glmark2
[20:30] <rsalveti> once it migrates from proposed to release
[20:32] <anpok> racarr__: you mean you need someone to top approve?
[20:33] <racarr__> anpok: Ah well I was going to do so
[20:33] <racarr__> I just wanted to
[20:34] <racarr__> submit the suggestion to the academy before doing so
[20:34] <racarr__> :p
[20:36] <anpok> heh
[20:37] <anpok> discussion there seems to be at a dead end
[20:37] <anpok> agreement about an overall disagreement..
[20:39] <anpok> in any case you might want to look at https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806
[20:39] <anpok> since you are browsing right now..
[20:42] <anpok> maybe i should wait for monday
[20:52] <racarr__> anpok: Ill try and look in just a few min
[21:22] <tedg> Is there an API for the trusted sessions somewhere?
[21:29] <AlbertA> anpok: yeah I will create it...right now I'm mostly concerned about getting unity8 just to work right
[21:30] <AlbertA> anpok: I could propose later to fix the support for transparent frame buffers
[21:36] <AlbertA> anpok: because switching to porter/duff is practically only applicable to nested usecase
[21:36] <AlbertA> anpok: where corrrect alpha is needed
[21:36] <AlbertA> anpok: in all other cases including screencasting there's no need
[21:37] <anpok> AlbertA: hmm... right now we do apply the alpha channel twice
[21:38] <AlbertA> anpok: but as you said, right now unity8 is rendering with alpha 1.0 so it doesn't matter
[21:38] <anpok> yes
[21:38] <AlbertA> anpok: it only matters in the demo shell I suppose
[21:39] <anpok> and potential transparency effects in the greeter some day
[21:39] <AlbertA> anpok: right
[21:40] <AlbertA> anpok: so maybe for now my initial fix of rendering an opaque background is enough (so that unity8 renders correctly)
[21:40] <AlbertA> anpok: then we can open the alpha can-of-worms
[21:40] <AlbertA> anpok: :)
[21:46] <anpok> first or second one?
[21:46] <anpok> confused
[21:47] <AlbertA> anpok: I think https://code.launchpad.net/~albaguirre/mir/render-opaque-background/+merge/218712
[21:47] <AlbertA> anpok: is the simples solution for now for both the transparent screencast issue and the unity8 rendering issue
[21:48] <AlbertA> anpok: and then we need a discussion on supporting transparent framebuffers properly
[21:49] <AlbertA> anpok: I think probably an attribute of the DisplayBuffer so we can change
[21:49] <AlbertA> anpok: blening modes in the renderer could be the solution
[21:49] <AlbertA> anpok: maybe an opaqueness attribute
[21:50] <AlbertA> anpok: that the compositor can pass to the GLRenderer
[22:03] <anpok> ack
[22:05] <AlbertA> anpok: yeah an opaqueness attribute makes sense to me...that way we say non-opaque on the nested display buffer
[22:05] <AlbertA> anpok: and everything else opaque
[22:06] <AlbertA> anpok: i.e. the platform's display buffer and the screencast display buffer
[22:06] <anpok> well we have the pixel format
[22:06] <AlbertA> anpok: true but for some reason
[22:07] <AlbertA> anpok: the platforms are returning one with alpha support
[22:07] <anpok> ah yes
[22:07] <AlbertA> anpok: dunno why...and the nested display buffer just replicates that
[22:07] <anpok> and independent of that if the clients of the nested session make use of transparency we still have to blend properly
[22:10] <AlbertA> anpok: right which we haven't seen since nobody is rendering with per-pixel alpha at the mir level
[22:11] <AlbertA> anpok: it's all done by Qt...I wonder how they blend
[22:11]  * AlbertA goes to check
[22:20] <AlbertA> anpok: glBlendFunc(GL_SRC_ALPHA, GL_ONE);
[22:21] <AlbertA> anpok: which I suppose makes sense, always make the destination opaque
[22:22] <AlbertA> anpok: well I'm not sure that's what they use---just found some hints here and there
[22:22] <anpok> thats odd
[22:25] <AlbertA> anpok: no nevermind one of the comments alludes to
[22:25] <AlbertA> glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)
[22:26] <AlbertA> in qsgrendernode.cpp
[22:26] <AlbertA> all makes sense now
[22:26] <AlbertA> :)
[22:29] <anpok> http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]] -- So anyway, yeah, premultiplied alpha. Use it, love it, pass it on. Then maybe we'll only take another 20 years til everyone's doing this stuff correctly.
[22:29] <anpok> good
[23:08] <josharenson> kgunn, it appears as though you cannot run glmark2 offscreen on android