/srv/irclogs.ubuntu.com/2014/03/05/#ubuntu-mir.txt

=== robert_ancell_ is now known as robert_ancell
RAOFduflu_: 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
RAOFduflu_: 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 that03:51
=== duflu_ is now known as duflu
RAOFduflu: Cool. Shouldn't be hard, except for the annoying bit where $CWD/../../bin/udev_recordings needs to resolve.03:52
RAOFrobert_ancell: Good afternoon my good man!03:53
robert_ancellRAOF, sup03:53
RAOFrobert_ancell: You know, the same. Reviews, SRU processing, chasing stupid threading bugs...03:53
robert_ancellexciting stuff :)03:53
RAOFYo fine self?04:01
robert_ancellyep04:17
dufluHeh, we might need to find people to do Mir code reviews full time :)04:18
RAOFAh, memtest. Time to make lunch!05:32
duflumemtest86? MemCheck?06:13
dufluApplies to both really06:13
dufluAlbertA: Awesome that you found the Nexus4 GLSL bug. Did you know of that limitation or just discover it?06:20
AlbertAduflu: I got annoyed by it :)06:20
AlbertAduflu: as I was doing some changes in screencasting06:20
AlbertAduflu: I like to use the eglplasma example + egltriangle on top06:21
dufluAlbertA: Even more impressive you diagnosed the bug in the hardware shader. Something like that could go years without people figuring it out06:21
AlbertAduflu: :)06:22
dufluAlbertA: Only Mako right?06:23
AlbertAduflu: nexus 7 too, I didn't test nexus 10...let me see06:23
dufluOdd06:23
AlbertAwell nexus 7 2013, which is still qualcomm06:26
dufluThat makes sense. Qcom-only bug06:26
dufluThe 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:35
AlbertAduflu: I'm seeing the slowdown in n10 as well...weird06:36
dufluAlbertA: Doing manual testing now...06:36
AlbertAduflu: and gone with the fix proposed06:36
AlbertAduflu: though it makes some sense as you start giving away precision as you move to bigger and bigger float numbers06:38
dufluAlbertA: Yeah, but I don't think they're "big" for floats06:38
AlbertAduflu: It just happens sooner than I think it should06:38
dufluAlbertA: I think it was probably only happening in the thousands. That's just a GPU bug06:39
AlbertAduflu: in mako at least, it was happening06:39
AlbertAduflu: after about 32.0f06:39
AlbertAduflu: which seemed to soon for me06:40
dufluYep, seems to be running fine now06:40
dufluIf the function is implemented in hardware, I don't suppose there's much value in reporting it to Qualcomm06:44
dufluAlthough it would help if they stopped producing new chips with the bug06:44
AlbertAduflu: well but it's happening with Mali too though06:45
AlbertAduflu: n1006:45
* duflu wonders if fmod is an O(N) operation06:46
dufluIt shouldn't be06:46
AlbertAduflu: it may be that mediump in opengl es is not 32-bit06:46
dufluLess?06:47
AlbertAduflu: probably06:47
AlbertAduflu: that's the only thing that makes sense06:47
AlbertAduflu: I'll take a look at the spec later06:47
dufluYeah mediump looks low. It could run out of bits after a few thousand06:48
AlbertAduflu: quick google searches suggest it's 10-bit06:50
AlbertAduflu: that would kinda explain why it's starts happening around angle of 32.0f06:50
duflu32 is only 6 bits...?!06:51
AlbertAduflu: but it's floating point06:52
AlbertAduflu: make more sense to assign more precision down the normalized range06:52
dufluYeah, so once you get that high you could start losing decimal places at the other end06:53
tvosso/07:29
=== rpadovani is now known as WebbyIT
=== RAOF_ is now known as RAOF
=== ogra_` is now known as ogra
=== WebbyIT is now known as rpadovani
alan_gduflu: 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
duflualan_g: I don't have an opinion on it as yet. And am logging off momentarily10:37
=== 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
mterryHello!  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 happen14:41
mterryalan_g, you've been looking at buffer stuff  :)  ^14:41
mterryspeaking of, I should test your branch14:41
alan_gmterry: turning on the screen every time any client posts a buffer? Sounds expensive.14:42
mterryCode says:14:43
mterry    // We ensure the client has not powered down the outputs, so that14:43
mterry    // swap_buffer will not block indefinitely, leaving the client14:43
mterry    // in a position where it can not turn back on the14:43
mterry    // outputs.14:43
mterryalan_g, ^14:43
alan_gmterry: please do. (kgunn just top approved it)14:43
alan_gAh. That sounds like a different issue. I'm trying to recall the details...14:45
alan_gAs 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:50
alan_gBut as I've stopped next_buffer blocking this may no longer be an issue.14:51
alan_gmterry: ^ do you have an easy way to reproduce?14:51
mterryWhoops, got disconnected14:54
mterryLast saw "Ah. That sounds like a different issue. I'm trying to recall the details..."14:54
alan_g<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:55
alan_g<alan_g> But as I've stopped next_buffer blocking this may no longer be an issue.14:55
alan_g<alan_g> mterry: ^ do you have an easy way to reproduce?14:55
mterryalan_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.  Reliably14:57
mterryalan_g, you want me to try to reproduce with your branch and commenting out the ensure_display_powered line?14:57
mterryWell, commenting out the line for sure will make the bug go away14:57
mterryBut test something else maybe that indicates we can safely delete that line?14:58
alan_gmterry: 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:02
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:15
alf_alan_g: not in detail, I remember it was racarr that first explained it15:17
alan_gmterry: 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_galf_: thanks15:18
mterryracarr_, poke when you're around, will try again later15:19
mterryalan_g, thanks15:19
alan_gyw15:24
=== 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
racarr_mterry: pong17:35
racarr_mterry: That code exits because of xmir17:35
racarr_but in general its sort of required the problem is17:35
racarr_as it stands we only process one message at a time from a client17:35
racarr_in order17:35
racarr_one message per client per time that is17:35
racarr_we may be processing multiple messages in parallel17:35
racarr_ok so the problem is if the client calls17:35
racarr_Turn off display17:36
racarr_then calls swap buffers17:36
racarr_the client will block for foreer17:36
racarr_adn cant do anything about it17:36
mterryracarr_, well my use case is this:17:36
mterryracarr_, 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 again17:37
mterryracarr_, the way Mir is written now, the screen will turn back on by itself because greeter session opened17:37
racarr_I thought it was only if17:37
racarr_the greeter is the one that requeste17:37
racarr_turnign of the screen17:37
mterryracarr_, hmm?  didn't follow17:38
racarr_mterry: I mean, the way the logic was intended to be17:39
racarr_is a client swapping buffers only turns the screen on17:39
racarr_if it was that client which turned it off17:40
mterryracarr_, I don't *think* that's how it works today?17:41
mterryracarr_, 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 info17:42
racarr_mterry: XMir17:43
racarr_will turn it off17:43
racarr_um17:43
mterryracarr_, I guess I don't know enough about XMir17:44
racarr_ill look in to it or you :)17:44
racarr_sounds like its broken today17:44
mterryracarr_, thanks!  if you need me to test something or need more info about the code path I'm hitting, let me know17:45
racarr_mterry: Maybe. Thanks! The first thing I will do17:58
racarr_is write an acceptance test client_swapping_buffers_only_enables_display_if_said_client_reuested_display_off17:59
racarr_or something lol17:59
racarr_and maybe the behavior is just broken17:59
racarr_and its just a bug17:59
mterryracarr_, OK, sure.  I believe in this case USC is turning screen off.  So that might make sense18:03
racarr_mm18:04
racarr_excellent18:04
racarr_ok. me -> coffee -> emacs18:05
racarr_I hate this threading but im dealing with right now so I will look at it18:05
racarr_now!18:05
mterry:)18:05
=== alan_g is now known as alan_g|EOD
kdubracarr_, in SessionMediator?18:23
racarr_kdub: Err. if you mean my last sentence there was a missing word18:23
racarr_I hate this threading issue I am dealing with now (not in session mediator)18:23
kdubah, okay18:24
racarr_this is a little in session mediator18:24
racarr_in that it calls DisplayChanger::ensure_display_powered or whatever18:24
racarr_but I guess the logic is there18:24
racarr_mterry: Err. so I lost track during my detour to chromium world is the greeter a nested mir atm?18:29
mterryracarr_, yes18:30
mterryracarr_, basically just another unity8 session18:31
racarr_mterry: Ok. Great.18:32
racarr_I think the nested code is configuring the display18:32
racarr_and thus getting the client in to the list of clients who are configuring the display18:33
racarr_and messing up this code18:33
racarr_but....uh18:33
racarr_well, it still doesnt entirely make sense18:33
racarr_but I have a plausible code path to investigate18:33
racarr_mterry: How many monitors are you testing with18:38
mterryracarr_, mako18:38
mterryso 118:38
racarr_haha ok18:38
* mterry keeps getting unity8 crashes with latest mir18:47
mterryEither I miscompiled something or I'm missing a merge18:47
mterrykgunn, is there a branch I need for unity8 for Mir 0.1.6?18:48
kgunnnot for unity818:49
kdubunity-mir maybe18:49
kgunnmterry: but for unity-mir18:49
mterrykgunn, I have the one that lets it compile18:50
mterrykgunn, but is there a subtler change I need?18:50
kgunnmterry: to be specific do you mean mir-devel or 0.1.618:51
kgunnthere are differences from the tag to the tip18:52
mterrykgunn, I was building from scratch lp:mir/devel18:52
=== dandrader is now known as dandrader|afk
kgunnah...tip18:52
mterryshould have specified18:52
mterrykgunn, is there ongoing drama in tip?18:52
kgunnmterry: well...so configure_output got removed....18:52
mterrykgunn, yeah, I've made those changes.  Maybe poorly, but it seemed simple enough18:53
kgunnmterry: oh...in usc ?18:53
mterrykgunn, and unity-mir I think18:53
kgunnmterry: well unity-mir you should include your drop dbus screen brnach18:54
kgunnwhich takes care that way...18:54
mterrydid that, but it also has some other change, maybe which was in 0.1.6 anyway18:54
kgunnand then for u-s-c you can grab18:54
mterryanyway.  Sounds like nothing crazy...  But maybe I should go back down to 0.1.6 for safety's sake18:54
* mterry just doesn't like re-compiling things again18:54
kgunnhttps://code.launchpad.net/~kgunn72/unity-system-compositor/usc-mir-0.1.6/+merge/20882118:54
kgunnmterry: ^ that one should make tip happy18:55
kgunnthere were some config option changes that were needed along with it...cherry picked beyond 0.1.618:55
mterrykgunn, I was using lp:~mir-team/unity-system-compositor/staged-next-rev18:55
kgunnmterry: ah...yeah...that's for the ppa i'm trying to get rolling...18:57
kgunni might not have updated it yet18:57
kgunnwith the https://code.launchpad.net/~kgunn72/unity-system-compositor/usc-mir-0.1.6/+merge/20882118:57
kgunnlatest changes18:57
mterrykgunn, this is a crash in unity8 not usc that I'm seeing though18:58
mterryso probably in unity-mr18:58
mterryor platform-api or some such18:58
kgunnmterry: oh, so you've built ok ?18:58
mterrykgunn, yeah18:58
mterrykgunn, unity8 just keeps crashing18:58
kgunnsorry dude...i thot you were having build issues18:58
kgunnmterry: crashing when ? on startup?....or specific action ?18:59
mterryon startup18:59
kgunnmterry: hope i won't see the same thing when i attempt to land18:59
mterrykgunn, well presumably those branches are already tested together?19:00
kgunnmterry: which unity-mir are you using ?19:00
mterryFigured it was something unique to me and/or my split branches19:00
=== marlinc_ is now known as Marlinc
kgunnmterry: well...those branches i shared in the other channel are building together now...but not done building yet, so...untested atm19:00
mterrykgunn, 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 is19:01
kgunnmterry: 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_output19:04
mterrykgunn, alright.  For better help to you folks and my own sanity, I'll downgrade to 0.1.6 and the branches in the landing silo19:05
kgunnlol19:05
* mterry recompiles a bunch more19:05
kgunnmterry: yeah maybe...what are you after exactly ?19:05
mterrykgunn, testing some alan_g changes to Mir that I want19:05
mterryhaven't landed yet19:06
* kdub had to do the same thing as mterry this week19:06
mterrykdub, did you test tip or 0.1.6?19:06
kgunnmmm....yeah... mterry so you'll have to do 0.1.6 tag revision from mir-devel...then merge on top the alang changes19:06
kdubi tried tip yesterday,  i had a problem19:06
mterrykdub, perfect19:07
mterrykdub, well you know  :)19:07
kdubit might have been crashing, or not starting19:07
kdubso today, i'll try the stuff going in the silo19:07
* kgunn is now worried19:07
racarr_ok wait I think this bug is easy lol19:11
racarr_it has nothing to do with the swap buffers powere enabling logic19:11
racarr_but rather, just the nested display configuration19:11
racarr_USC turns off the display, greeter starts19:12
racarr_NestedDisplay makes mir_connection19:12
racarr_applies default display coniguration policy19:12
racarr_which turns the screen back on19:12
racarr_USC says ok19:12
racarr_screen is back on lol19:12
racarr_so either the nested display in the case of the greeter shouldnt mess with the display configuration policy19:12
racarr_or USC should deny19:12
racarr_configuration requests from19:13
racarr_everyone except...xmir and other special things that exist later19:13
racarr_probably both of those19:13
mterryracarr_, hah, sorry if I put you on the wrong track19:13
racarr_mterry: No!19:13
racarr_plus we got a free acceptance test out of it19:13
racarr_actually im not sure how the word free19:13
racarr_applies here19:13
racarr_but anyway19:13
racarr_:p19:13
mterry:)19:13
racarr_mterry: OK you will be around for another few hours yeah?19:14
mterryracarr_, yeah19:14
mterryracarr_, you say " the nested display in the case of the greeter shouldnt mess with the display configuration policy"19:14
mterryracarr_, why just the greeter?19:14
racarr_well nested in the case of the19:15
racarr_user session compositor19:15
racarr_does want to apply the session display configuration19:15
racarr_or whatever19:15
AlbertAracarr_: we just discussed this today19:16
racarr_oh?19:17
mterryracarr_, 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 confis19:17
AlbertAracarr_: the display state will be ripped out of powerd19:17
racarr_Great :D19:17
AlbertAracarr_: and the sessions will now be in control of initiating display state changes19:17
racarr_this is just a simpler issue though.19:17
racarr_here its ust the greeter is requesting something it doesnt want19:17
racarr_or maybe USC is allowing something it shouldnt19:17
racarr_mterry: Not as far as USC is concerned19:17
racarr_but as far as what they want19:18
racarr_the unity8 nested session, does have some sort of19:18
racarr_display configuration policy right19:18
mterryk19:18
racarr_I mean right now its the same as the USC display configuration whcih is just19:18
racarr_turn all the displays to native mode19:18
racarr_but hypothetically its like19:18
racarr_you start up this user session and this users19:18
racarr_configuration applys19:18
racarr_etc19:18
AlbertAracarr_: well in android devices is all driven by powerd19:18
AlbertAracarr_: not sure in desktop19:18
racarr_AlbertA: This is the dpms mode which is seperate from the19:18
racarr_early suspend logic19:18
racarr_and also not really DPMS on android :p19:19
racarr_MirPowerMode19:19
=== dandrader|afk is now known as dandrader
racarr_mterry: You see what I mean? So the thing is just19:19
racarr_the greeter isnt interested in this, so we need to make it possible to change that19:19
racarr_default behavior19:19
racarr_the greeter just wants to take the display configuration from USC19:19
mterryracarr_, fair enough19:19
racarr_mterry: Anyway im going to mull it over lunch...I think the greeter just needs to not use the DefaultDisplayConfiguration19:22
racarr_Policy19:22
racarr_but also perhaps19:22
racarr_USC should be19:22
racarr_denying this request19:22
mterryracarr_, sounds like you know what's up.  Enjoy lunch!  Don't mull too much, unless it's cider19:23
racarr_:D Back soon19:23
racarr_mterry: Ok where does greeter live these days?20:34
racarr_is it using Unity-Mir?20:34
mterryracarr_, well....  in unity8 source.  But it's not split out yet.  I still have a separate branch for that20:35
mterryracarr_, yes20:35
mterryracarr_, basically just a copy of unity8, running different Qml20:35
racarr_so there is no seperate binary?20:36
racarr_mterry:20:36
mterryracarr_, there is in my branch, but not in trunk20:36
racarr_ok20:36
racarr_bug is easiest to fix in that context so it that enough?20:37
racarr_is*20:37
racarr_mterry: ^20:54
mterryracarr_, in which context?20:54
racarr_mterry: I mean if we fix it in your branch with21:02
racarr_the seperate binary21:02
racarr_is that fine?21:02
mterryracarr_, oh yeah!21:02
mterryracarr_, I only care about my stuff  ;)21:02
mterryracarr_, branch is lp:~mterry/unity8/split21:02
mterryracarr_, if you want to propose a change I can make it21:02
racarr_mterry: ok21:03
racarr_thanks :D21:03
racarr_mterry: It looks like its still the same binary? i.e. the same main.cpp is loading21:05
racarr_Greeter.qml vs Shell.qml21:05
mterryracarr_, yeah.  But there is a #define for greeter compile if you need to #if on it21:05
mterrylet me see...21:06
racarr_I see #if !UNITY8_SHELL21:07
mterryracarr_, the poorly named UNITY8_SHELL21:07
racarr_:D21:07
racarr_ok should have something for you soon21:07
mterrykgunn, did you ever test your 0.1.6 PPA?21:34
kgunnmterry: struggle bus21:35
kgunntrying to sort out an arm unit test failure21:36
mterrykgunn, 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 something21:37
kdubmterry, kgunn my build has unity8 crashing with the 0.1.6 stuff too23:57
mterry:(23:58
kdubbut interestingly, unity8 alone works okay23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!