=== robert_ancell_ is now known as robert_ancell | ||
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:51 |
=== duflu_ is now known as duflu | ||
RAOF | duflu: Cool. Shouldn't be hard, except for the annoying bit where $CWD/../../bin/udev_recordings needs to resolve. | 03:52 |
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 :) | 03:53 |
RAOF | Yo fine self? | 04:01 |
robert_ancell | yep | 04:17 |
duflu | Heh, we might need to find people to do Mir code reviews full time :) | 04:18 |
RAOF | Ah, memtest. Time to make lunch! | 05:32 |
duflu | memtest86? MemCheck? | 06:13 |
duflu | Applies to both really | 06:13 |
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:20 |
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:21 |
AlbertA | duflu: :) | 06:22 |
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:23 |
AlbertA | well nexus 7 2013, which is still qualcomm | 06:26 |
duflu | That makes sense. Qcom-only bug | 06:26 |
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:35 |
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:36 |
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:38 |
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:39 |
AlbertA | duflu: which seemed to soon for me | 06:40 |
duflu | Yep, seems to be running fine now | 06:40 |
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:44 |
AlbertA | duflu: well but it's happening with Mali too though | 06:45 |
AlbertA | duflu: n10 | 06:45 |
* 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:46 |
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:47 |
duflu | Yeah mediump looks low. It could run out of bits after a few thousand | 06:48 |
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:50 |
duflu | 32 is only 6 bits...?! | 06:51 |
AlbertA | duflu: but it's floating point | 06:52 |
AlbertA | duflu: make more sense to assign more precision down the normalized range | 06:52 |
duflu | Yeah, so once you get that high you could start losing decimal places at the other end | 06:53 |
tvoss | o/ | 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_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 | 10: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 | ||
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:41 |
alan_g | mterry: turning on the screen every time any client posts a buffer? Sounds expensive. | 14:42 |
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:43 |
alan_g | Ah. That sounds like a different issue. I'm trying to recall the details... | 14:45 |
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:50 |
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:51 |
mterry | Whoops, got disconnected | 14:54 |
mterry | Last 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 |
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:57 |
mterry | But test something else maybe that indicates we can safely delete that line? | 14:58 |
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: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 it | 15:17 |
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:18 |
mterry | racarr_, poke when you're around, will try again later | 15:19 |
mterry | alan_g, thanks | 15:19 |
alan_g | yw | 15: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: 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:35 |
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:36 |
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:37 |
mterry | racarr_, hmm? didn't follow | 17:38 |
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:39 |
racarr_ | if it was that client which turned it off | 17:40 |
mterry | racarr_, I don't *think* that's how it works today? | 17:41 |
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:42 |
racarr_ | mterry: XMir | 17:43 |
racarr_ | will turn it off | 17:43 |
racarr_ | um | 17:43 |
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:44 |
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:45 |
racarr_ | mterry: Maybe. Thanks! The first thing I will do | 17:58 |
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 | 17:59 |
mterry | racarr_, OK, sure. I believe in this case USC is turning screen off. So that might make sense | 18:03 |
racarr_ | mm | 18:04 |
racarr_ | excellent | 18:04 |
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:05 |
=== alan_g is now known as alan_g|EOD | ||
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:23 |
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:24 |
racarr_ | mterry: Err. so I lost track during my detour to chromium world is the greeter a nested mir atm? | 18:29 |
mterry | racarr_, yes | 18:30 |
mterry | racarr_, basically just another unity8 session | 18:31 |
racarr_ | mterry: Ok. Great. | 18:32 |
racarr_ | I think the nested code is configuring the display | 18:32 |
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:33 |
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:38 |
* mterry keeps getting unity8 crashes with latest mir | 18:47 | |
mterry | Either I miscompiled something or I'm missing a merge | 18:47 |
mterry | kgunn, is there a branch I need for unity8 for Mir 0.1.6? | 18:48 |
kgunn | not for unity8 | 18:49 |
kdub | unity-mir maybe | 18:49 |
kgunn | mterry: but for unity-mir | 18:49 |
mterry | kgunn, I have the one that lets it compile | 18:50 |
mterry | kgunn, but is there a subtler change I need? | 18:50 |
kgunn | mterry: to be specific do you mean mir-devel or 0.1.6 | 18:51 |
kgunn | there are differences from the tag to the tip | 18:52 |
mterry | kgunn, I was building from scratch lp:mir/devel | 18:52 |
=== dandrader is now known as dandrader|afk | ||
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:52 |
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:53 |
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:54 |
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:55 |
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:57 |
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:58 |
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 | 18:59 |
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 |
=== marlinc_ is now known as Marlinc | ||
kgunn | mterry: well...those branches i shared in the other channel are building together now...but not done building yet, so...untested atm | 19:00 |
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:01 |
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:04 |
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:05 |
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:06 |
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:07 | |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
AlbertA | racarr_: we just discussed this today | 19:16 |
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:17 |
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:18 |
racarr_ | and also not really DPMS on android :p | 19:19 |
racarr_ | MirPowerMode | 19:19 |
=== dandrader|afk is now known as dandrader | ||
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:19 |
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:22 |
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 | 19:23 |
racarr_ | mterry: Ok where does greeter live these days? | 20:34 |
racarr_ | is it using Unity-Mir? | 20:34 |
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:35 |
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:36 |
racarr_ | bug is easiest to fix in that context so it that enough? | 20:37 |
racarr_ | is* | 20:37 |
racarr_ | mterry: ^ | 20:54 |
mterry | racarr_, in which context? | 20:54 |
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:02 |
racarr_ | mterry: ok | 21:03 |
racarr_ | thanks :D | 21:03 |
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:05 |
mterry | let me see... | 21:06 |
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:07 |
mterry | kgunn, did you ever test your 0.1.6 PPA? | 21:34 |
kgunn | mterry: struggle bus | 21:35 |
kgunn | trying to sort out an arm unit test failure | 21:36 |
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 | 21:37 |
kdub | mterry, kgunn my build has unity8 crashing with the 0.1.6 stuff too | 23:57 |
mterry | :( | 23:58 |
kdub | but interestingly, unity8 alone works okay | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!