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