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