[03:51] <RAOF> duflu_: How would you feel about a script that just sets up the appropriate environment for you (ie: that you'd run on the device)?
[03:51] <RAOF> duflu_: That has the slight drawback of needing to be run in a special directory because ctest, though.
[03:51] <duflu_> RAOF: Working on one myself, which will make the whole issue moot and unblock my review of that
[03:52] <RAOF> duflu: Cool. Shouldn't be hard, except for the annoying bit where $CWD/../../bin/udev_recordings needs to resolve.
[03:53] <RAOF> robert_ancell: Good afternoon my good man!
[03:53] <robert_ancell> RAOF, sup
[03:53] <RAOF> robert_ancell: You know, the same. Reviews, SRU processing, chasing stupid threading bugs...
[03:53] <robert_ancell> exciting stuff :)
[04:01] <RAOF> Yo fine self?
[04:17] <robert_ancell> yep
[04:18] <duflu> Heh, we might need to find people to do Mir code reviews full time :)
[05:32] <RAOF> Ah, memtest. Time to make lunch!
[06:13] <duflu> memtest86? MemCheck?
[06:13] <duflu> Applies to both really
[06:20] <duflu> AlbertA: Awesome that you found the Nexus4 GLSL bug. Did you know of that limitation or just discover it?
[06:20] <AlbertA> duflu: I got annoyed by it :)
[06:20] <AlbertA> duflu: as I was doing some changes in screencasting
[06:21] <AlbertA> duflu: I like to use the eglplasma example + egltriangle on top
[06:21] <duflu> AlbertA: Even more impressive you diagnosed the bug in the hardware shader. Something like that could go years without people figuring it out
[06:22] <AlbertA> duflu: :)
[06:23] <duflu> AlbertA: Only Mako right?
[06:23] <AlbertA> duflu: nexus 7 too, I didn't test nexus 10...let me see
[06:23] <duflu> Odd
[06:26] <AlbertA> well nexus 7 2013, which is still qualcomm
[06:26] <duflu> That makes sense. Qcom-only bug
[06:35] <duflu> The next challenge is to reduce the number of trig functions. 20 years ago I could write more efficient and prettier plasma than that. But I forget...
[06:36] <AlbertA> duflu: I'm seeing the slowdown in n10 as well...weird
[06:36] <duflu> AlbertA: Doing manual testing now...
[06:36] <AlbertA> duflu: and gone with the fix proposed
[06:38] <AlbertA> duflu: though it makes some sense as you start giving away precision as you move to bigger and bigger float numbers
[06:38] <duflu> AlbertA: Yeah, but I don't think they're "big" for floats
[06:38] <AlbertA> duflu: It just happens sooner than I think it should
[06:39] <duflu> AlbertA: I think it was probably only happening in the thousands. That's just a GPU bug
[06:39] <AlbertA> duflu: in mako at least, it was happening
[06:39] <AlbertA> duflu: after about 32.0f
[06:40] <AlbertA> duflu: which seemed to soon for me
[06:40] <duflu> Yep, seems to be running fine now
[06:44] <duflu> If the function is implemented in hardware, I don't suppose there's much value in reporting it to Qualcomm
[06:44] <duflu> Although it would help if they stopped producing new chips with the bug
[06:45] <AlbertA> duflu: well but it's happening with Mali too though
[06:45] <AlbertA> duflu: n10
[06:46]  * duflu wonders if fmod is an O(N) operation
[06:46] <duflu> It shouldn't be
[06:46] <AlbertA> duflu: it may be that mediump in opengl es is not 32-bit
[06:47] <duflu> Less?
[06:47] <AlbertA> duflu: probably
[06:47] <AlbertA> duflu: that's the only thing that makes sense
[06:47] <AlbertA> duflu: I'll take a look at the spec later
[06:48] <duflu> Yeah mediump looks low. It could run out of bits after a few thousand
[06:50] <AlbertA> duflu: quick google searches suggest it's 10-bit
[06:50] <AlbertA> duflu: that would kinda explain why it's starts happening around angle of 32.0f
[06:51] <duflu> 32 is only 6 bits...?!
[06:52] <AlbertA> duflu: but it's floating point
[06:52] <AlbertA> duflu: make more sense to assign more precision down the normalized range
[06:53] <duflu> Yeah, so once you get that high you could start losing decimal places at the other end
[07:29] <tvoss> o/
[10:37] <alan_g> duflu: do you want to have you an opinion on https://code.launchpad.net/~alan-griffiths/mir/nested-sessions-dont-post-buffers-until-something-happens/+merge/209107?
[10:37] <duflu> alan_g: I don't have an opinion on it as yet. And am logging off momentarily
[14:41] <mterry> Hello!  I'd love to talk to someone about mf::SessionMediator::next_buffer turning on the screen, when someone gets a chance.  I'd very much like it to not happen
[14:41] <mterry> alan_g, you've been looking at buffer stuff  :)  ^
[14:41] <mterry> speaking of, I should test your branch
[14:42] <alan_g> mterry: turning on the screen every time any client posts a buffer? Sounds expensive.
[14:43] <mterry> Code says:
[14:43] <mterry>     // We ensure the client has not powered down the outputs, so that
[14:43] <mterry>     // swap_buffer will not block indefinitely, leaving the client
[14:43] <mterry>     // in a position where it can not turn back on the
[14:43] <mterry>     // outputs.
[14:43] <mterry> alan_g, ^
[14:43] <alan_g> mterry: please do. (kgunn just top approved it)
[14:45] <alan_g> Ah. That sounds like a different issue. I'm trying to recall the details...
[14:50] <alan_g> As I recall it being explained to me we (somewhere) serialize processing of client messages, which meant we didn't listen for a new power on message while processing next buffer. I don't remember it being addressed (but I'm fallible)
[14:51] <alan_g> But as I've stopped next_buffer blocking this may no longer be an issue.
[14:51] <alan_g> mterry: ^ do you have an easy way to reproduce?
[14:54] <mterry> Whoops, got disconnected
[14:54] <mterry> Last saw "Ah. That sounds like a different issue. I'm trying to recall the details..."
 As I recall it being explained to me we (somewhere) serialize processing of client messages, which meant we didn't listen for a new power on message while processing next buffer. I don't remember it being addressed (but I'm fallible)
 But as I've stopped next_buffer blocking this may no longer be an issue.
 mterry: ^ do you have an easy way to reproduce?
[14:57] <mterry> alan_g, yeah sort of.  If you install branches for split mode, when the display turns off, the greeter session starts and turns the backlight back on.  Reliably
[14:57] <mterry> alan_g, you want me to try to reproduce with your branch and commenting out the ensure_display_powered line?
[14:57] <mterry> Well, commenting out the line for sure will make the bug go away
[14:58] <mterry> But test something else maybe that indicates we can safely delete that line?
[15:02] <alan_g> mterry: The original problem that this was a workaround for was that a client with a blocked call to swap_buffers() couldn't request the screen turning on. (But I can't remember who explained it to me or how to reproduce - let me dig a bit...)
[15:15] <alan_g> ...can't find it. alf_ ^^ can you remember the scenario that caused us to turn on the display whenever a buffer is posted?
[15:17] <alf_> alan_g: not in detail, I remember it was racarr that first explained it
[15:18] <alan_g> mterry: I suggest you try the effect of removing the offending code and, if you don't see anything obvious check with racarr.
[15:18] <alan_g> alf_: thanks
[15:19] <mterry> racarr_, poke when you're around, will try again later
[15:19] <mterry> alan_g, thanks
[15:24] <alan_g> yw
[17:35] <racarr_> mterry: pong
[17:35] <racarr_> mterry: That code exits because of xmir
[17:35] <racarr_> but in general its sort of required the problem is
[17:35] <racarr_> as it stands we only process one message at a time from a client
[17:35] <racarr_> in order
[17:35] <racarr_> one message per client per time that is
[17:35] <racarr_> we may be processing multiple messages in parallel
[17:35] <racarr_> ok so the problem is if the client calls
[17:36] <racarr_> Turn off display
[17:36] <racarr_> then calls swap buffers
[17:36] <racarr_> the client will block for foreer
[17:36] <racarr_> adn cant do anything about it
[17:36] <mterry> racarr_, well my use case is this:
[17:37] <mterry> racarr_, assume split greeter.  Then you lock user session.  Screen turns off, greeter session starts up in order to be ready for use when screen is turned on again
[17:37] <mterry> racarr_, the way Mir is written now, the screen will turn back on by itself because greeter session opened
[17:37] <racarr_> I thought it was only if
[17:37] <racarr_> the greeter is the one that requeste
[17:37] <racarr_> turnign of the screen
[17:38] <mterry> racarr_, hmm?  didn't follow
[17:39] <racarr_> mterry: I mean, the way the logic was intended to be
[17:39] <racarr_> is a client swapping buffers only turns the screen on
[17:40] <racarr_> if it was that client which turned it off
[17:41] <mterry> racarr_, I don't *think* that's how it works today?
[17:42] <mterry> racarr_, do clients even put screen-on holds into Mir?  I thought everything was proxied through powerd, which then asks USC to turn on/off.  So USC (the compositor) doesn't even have that info
[17:43] <racarr_> mterry: XMir
[17:43] <racarr_> will turn it off
[17:43] <racarr_> um
[17:44] <mterry> racarr_, I guess I don't know enough about XMir
[17:44] <racarr_> ill look in to it or you :)
[17:44] <racarr_> sounds like its broken today
[17:45] <mterry> racarr_, thanks!  if you need me to test something or need more info about the code path I'm hitting, let me know
[17:58] <racarr_> mterry: Maybe. Thanks! The first thing I will do
[17:59] <racarr_> is write an acceptance test client_swapping_buffers_only_enables_display_if_said_client_reuested_display_off
[17:59] <racarr_> or something lol
[17:59] <racarr_> and maybe the behavior is just broken
[17:59] <racarr_> and its just a bug
[18:03] <mterry> racarr_, OK, sure.  I believe in this case USC is turning screen off.  So that might make sense
[18:04] <racarr_> mm
[18:04] <racarr_> excellent
[18:05] <racarr_> ok. me -> coffee -> emacs
[18:05] <racarr_> I hate this threading but im dealing with right now so I will look at it
[18:05] <racarr_> now!
[18:05] <mterry> :)
[18:23] <kdub> racarr_, in SessionMediator?
[18:23] <racarr_> kdub: Err. if you mean my last sentence there was a missing word
[18:23] <racarr_> I hate this threading issue I am dealing with now (not in session mediator)
[18:24] <kdub> ah, okay
[18:24] <racarr_> this is a little in session mediator
[18:24] <racarr_> in that it calls DisplayChanger::ensure_display_powered or whatever
[18:24] <racarr_> but I guess the logic is there
[18:29] <racarr_> mterry: Err. so I lost track during my detour to chromium world is the greeter a nested mir atm?
[18:30] <mterry> racarr_, yes
[18:31] <mterry> racarr_, basically just another unity8 session
[18:32] <racarr_> mterry: Ok. Great.
[18:32] <racarr_> I think the nested code is configuring the display
[18:33] <racarr_> and thus getting the client in to the list of clients who are configuring the display
[18:33] <racarr_> and messing up this code
[18:33] <racarr_> but....uh
[18:33] <racarr_> well, it still doesnt entirely make sense
[18:33] <racarr_> but I have a plausible code path to investigate
[18:38] <racarr_> mterry: How many monitors are you testing with
[18:38] <mterry> racarr_, mako
[18:38] <mterry> so 1
[18:38] <racarr_> haha ok
[18:47]  * mterry keeps getting unity8 crashes with latest mir
[18:47] <mterry> Either I miscompiled something or I'm missing a merge
[18:48] <mterry> kgunn, is there a branch I need for unity8 for Mir 0.1.6?
[18:49] <kgunn> not for unity8
[18:49] <kdub> unity-mir maybe
[18:49] <kgunn> mterry: but for unity-mir
[18:50] <mterry> kgunn, I have the one that lets it compile
[18:50] <mterry> kgunn, but is there a subtler change I need?
[18:51] <kgunn> mterry: to be specific do you mean mir-devel or 0.1.6
[18:52] <kgunn> there are differences from the tag to the tip
[18:52] <mterry> kgunn, I was building from scratch lp:mir/devel
[18:52] <kgunn> ah...tip
[18:52] <mterry> should have specified
[18:52] <mterry> kgunn, is there ongoing drama in tip?
[18:52] <kgunn> mterry: well...so configure_output got removed....
[18:53] <mterry> kgunn, yeah, I've made those changes.  Maybe poorly, but it seemed simple enough
[18:53] <kgunn> mterry: oh...in usc ?
[18:53] <mterry> kgunn, and unity-mir I think
[18:54] <kgunn> mterry: well unity-mir you should include your drop dbus screen brnach
[18:54] <kgunn> which takes care that way...
[18:54] <mterry> did that, but it also has some other change, maybe which was in 0.1.6 anyway
[18:54] <kgunn> and then for u-s-c you can grab
[18:54] <mterry> anyway.  Sounds like nothing crazy...  But maybe I should go back down to 0.1.6 for safety's sake
[18:54]  * mterry just doesn't like re-compiling things again
[18:54] <kgunn> https://code.launchpad.net/~kgunn72/unity-system-compositor/usc-mir-0.1.6/+merge/208821
[18:55] <kgunn> mterry: ^ that one should make tip happy
[18:55] <kgunn> there were some config option changes that were needed along with it...cherry picked beyond 0.1.6
[18:55] <mterry> kgunn, I was using lp:~mir-team/unity-system-compositor/staged-next-rev
[18:57] <kgunn> mterry: ah...yeah...that's for the ppa i'm trying to get rolling...
[18:57] <kgunn> i might not have updated it yet
[18:57] <kgunn> with the https://code.launchpad.net/~kgunn72/unity-system-compositor/usc-mir-0.1.6/+merge/208821
[18:57] <kgunn> latest changes
[18:58] <mterry> kgunn, this is a crash in unity8 not usc that I'm seeing though
[18:58] <mterry> so probably in unity-mr
[18:58] <mterry> or platform-api or some such
[18:58] <kgunn> mterry: oh, so you've built ok ?
[18:58] <mterry> kgunn, yeah
[18:58] <mterry> kgunn, unity8 just keeps crashing
[18:58] <kgunn> sorry dude...i thot you were having build issues
[18:59] <kgunn> mterry: crashing when ? on startup?....or specific action ?
[18:59] <mterry> on startup
[18:59] <kgunn> mterry: hope i won't see the same thing when i attempt to land
[19:00] <mterry> kgunn, well presumably those branches are already tested together?
[19:00] <kgunn> mterry: which unity-mir are you using ?
[19:00] <mterry> Figured it was something unique to me and/or my split branches
[19:00] <kgunn> mterry: well...those branches i shared in the other channel are building together now...but not done building yet, so...untested atm
[19:01] <mterry> kgunn, I'm using unity-mir with dropdbus and manual changes for configure_output change (there is one other place where it is called in unity-mir)
[19:01] <mterry> *unity-mir tip that is
[19:04] <kgunn> mterry: ah...ok...and actually not exactly what i am testing....we took on some of the mir server cfg changes...but not the removal of configure_output
[19:05] <mterry> kgunn, alright.  For better help to you folks and my own sanity, I'll downgrade to 0.1.6 and the branches in the landing silo
[19:05] <kgunn> lol
[19:05]  * mterry recompiles a bunch more
[19:05] <kgunn> mterry: yeah maybe...what are you after exactly ?
[19:05] <mterry> kgunn, testing some alan_g changes to Mir that I want
[19:06] <mterry> haven't landed yet
[19:06]  * kdub had to do the same thing as mterry this week
[19:06] <mterry> kdub, did you test tip or 0.1.6?
[19:06] <kgunn> mmm....yeah... mterry so you'll have to do 0.1.6 tag revision from mir-devel...then merge on top the alang changes
[19:06] <kdub> i tried tip yesterday,  i had a problem
[19:07] <mterry> kdub, perfect
[19:07] <mterry> kdub, well you know  :)
[19:07] <kdub> it might have been crashing, or not starting
[19:07] <kdub> so today, i'll try the stuff going in the silo
[19:07]  * kgunn is now worried
[19:11] <racarr_> ok wait I think this bug is easy lol
[19:11] <racarr_> it has nothing to do with the swap buffers powere enabling logic
[19:11] <racarr_> but rather, just the nested display configuration
[19:12] <racarr_> USC turns off the display, greeter starts
[19:12] <racarr_> NestedDisplay makes mir_connection
[19:12] <racarr_> applies default display coniguration policy
[19:12] <racarr_> which turns the screen back on
[19:12] <racarr_> USC says ok
[19:12] <racarr_> screen is back on lol
[19:12] <racarr_> so either the nested display in the case of the greeter shouldnt mess with the display configuration policy
[19:12] <racarr_> or USC should deny
[19:13] <racarr_> configuration requests from
[19:13] <racarr_> everyone except...xmir and other special things that exist later
[19:13] <racarr_> probably both of those
[19:13] <mterry> racarr_, hah, sorry if I put you on the wrong track
[19:13] <racarr_> mterry: No!
[19:13] <racarr_> plus we got a free acceptance test out of it
[19:13] <racarr_> actually im not sure how the word free
[19:13] <racarr_> applies here
[19:13] <racarr_> but anyway
[19:13] <racarr_> :p
[19:13] <mterry> :)
[19:14] <racarr_> mterry: OK you will be around for another few hours yeah?
[19:14] <mterry> racarr_, yeah
[19:14] <mterry> racarr_, you say " the nested display in the case of the greeter shouldnt mess with the display configuration policy"
[19:14] <mterry> racarr_, why just the greeter?
[19:15] <racarr_> well nested in the case of the
[19:15] <racarr_> user session compositor
[19:15] <racarr_> does want to apply the session display configuration
[19:15] <racarr_> or whatever
[19:16] <AlbertA> racarr_: we just discussed this today
[19:17] <racarr_> oh?
[19:17] <mterry> racarr_, how are those two sessions really any different as far as the USC is concerned?  Shouldn't USC just apply display config and nested should stay out of it?   But I don't know much about display confis
[19:17] <AlbertA> racarr_: the display state will be ripped out of powerd
[19:17] <racarr_> Great :D
[19:17] <AlbertA> racarr_: and the sessions will now be in control of initiating display state changes
[19:17] <racarr_> this is just a simpler issue though.
[19:17] <racarr_> here its ust the greeter is requesting something it doesnt want
[19:17] <racarr_> or maybe USC is allowing something it shouldnt
[19:17] <racarr_> mterry: Not as far as USC is concerned
[19:18] <racarr_> but as far as what they want
[19:18] <racarr_> the unity8 nested session, does have some sort of
[19:18] <racarr_> display configuration policy right
[19:18] <mterry> k
[19:18] <racarr_> I mean right now its the same as the USC display configuration whcih is just
[19:18] <racarr_> turn all the displays to native mode
[19:18] <racarr_> but hypothetically its like
[19:18] <racarr_> you start up this user session and this users
[19:18] <racarr_> configuration applys
[19:18] <racarr_> etc
[19:18] <AlbertA> racarr_: well in android devices is all driven by powerd
[19:18] <AlbertA> racarr_: not sure in desktop
[19:18] <racarr_> AlbertA: This is the dpms mode which is seperate from the
[19:18] <racarr_> early suspend logic
[19:19] <racarr_> and also not really DPMS on android :p
[19:19] <racarr_> MirPowerMode
[19:19] <racarr_> mterry: You see what I mean? So the thing is just
[19:19] <racarr_> the greeter isnt interested in this, so we need to make it possible to change that
[19:19] <racarr_> default behavior
[19:19] <racarr_> the greeter just wants to take the display configuration from USC
[19:19] <mterry> racarr_, fair enough
[19:22] <racarr_> mterry: Anyway im going to mull it over lunch...I think the greeter just needs to not use the DefaultDisplayConfiguration
[19:22] <racarr_> Policy
[19:22] <racarr_> but also perhaps
[19:22] <racarr_> USC should be
[19:22] <racarr_> denying this request
[19:23] <mterry> racarr_, sounds like you know what's up.  Enjoy lunch!  Don't mull too much, unless it's cider
[19:23] <racarr_> :D Back soon
[20:34] <racarr_> mterry: Ok where does greeter live these days?
[20:34] <racarr_> is it using Unity-Mir?
[20:35] <mterry> racarr_, well....  in unity8 source.  But it's not split out yet.  I still have a separate branch for that
[20:35] <mterry> racarr_, yes
[20:35] <mterry> racarr_, basically just a copy of unity8, running different Qml
[20:36] <racarr_> so there is no seperate binary?
[20:36] <racarr_> mterry:
[20:36] <mterry> racarr_, there is in my branch, but not in trunk
[20:36] <racarr_> ok
[20:37] <racarr_> bug is easiest to fix in that context so it that enough?
[20:37] <racarr_> is*
[20:54] <racarr_> mterry: ^
[20:54] <mterry> racarr_, in which context?
[21:02] <racarr_> mterry: I mean if we fix it in your branch with
[21:02] <racarr_> the seperate binary
[21:02] <racarr_> is that fine?
[21:02] <mterry> racarr_, oh yeah!
[21:02] <mterry> racarr_, I only care about my stuff  ;)
[21:02] <mterry> racarr_, branch is lp:~mterry/unity8/split
[21:02] <mterry> racarr_, if you want to propose a change I can make it
[21:03] <racarr_> mterry: ok
[21:03] <racarr_> thanks :D
[21:05] <racarr_> mterry: It looks like its still the same binary? i.e. the same main.cpp is loading
[21:05] <racarr_> Greeter.qml vs Shell.qml
[21:05] <mterry> racarr_, yeah.  But there is a #define for greeter compile if you need to #if on it
[21:06] <mterry> let me see...
[21:07] <racarr_> I see #if !UNITY8_SHELL
[21:07] <mterry> racarr_, the poorly named UNITY8_SHELL
[21:07] <racarr_> :D
[21:07] <racarr_> ok should have something for you soon
[21:34] <mterry> kgunn, did you ever test your 0.1.6 PPA?
[21:35] <kgunn> mterry: struggle bus
[21:36] <kgunn> trying to sort out an arm unit test failure
[21:37] <mterry> kgunn, I'm getting unity8 crashes still with the 0.1.6 branches.  I didn't grab every single branch in the silo, so maybe I just missed something
[23:57] <kdub> mterry, kgunn my build has unity8 crashing with the 0.1.6 stuff too
[23:58] <mterry> :(
[23:59] <kdub> but interestingly, unity8 alone works okay