[00:37] <greyback__> racarr_: hey, install cmake-extras - it has the gmock module that qtmir uses
[00:37] <racarr_> o
[00:37] <racarr_> greyback__: Does that have the EnableCoverageReport stuff that I proposed in another mp too?
[00:37] <greyback__> racarr_: yes
[00:38] <racarr_> Ah :)
[00:38] <racarr_> cool
[00:38] <racarr_> greyback__: Thanks :)
[00:38] <greyback__> no worries
[10:02] <duflu> Should it be possible that clang generates code that yields SIGILL??!
[10:04] <duflu> Oh, apparently clang does emit this invalid instruction intentionally sometimes. Wonder why gcc works
[10:07] <alan_g> targetting the wrong processor?
[10:08] <Kaleo> hey guys
[10:08] <duflu> alan_g: No, it's the right architecture. But apparently clang sometimes uses invalid instructions like an abort()
[10:08] <duflu> Kaleo: Hello
[10:08] <Kaleo> is there any difference in MIR's rendering or behaviour whether the phone is plugged on USB or not/charging or not?
[10:09] <duflu> Kaleo: Not explicitly in Mir but the driver could (and likely would) use a lower power mode on battery alone
[10:09] <Kaleo> right
[10:09] <duflu> Kaleo: You see such things?
[10:09] <Kaleo> duflu, one thing I notice for example
[10:09] <Kaleo> duflu, is that the lock screen's background sometimes takes time to be displayed
[10:10] <Kaleo> duflu, probably for the texture to be uploaded or rendered
[10:10] <Kaleo> duflu, only on battery
[10:10] <duflu> Kaleo: Yeah lower power mode is noticeably slow
[10:11] <duflu> It gets worse... if you're careful with your efficiency then the phone thinks it's in low power mode and can clock down too much, causing stuttering
[10:11] <Kaleo> duflu, interesting
[10:11] <duflu> It drives graphics people crazy
[10:11] <Kaleo> duflu, can you think of any reliable way to trigger that mode?
[10:12] <duflu> Kaleo: No, it's driven by how little you stress the GPU
[10:13] <Kaleo> duflu, does the low power mode impact CPU perf as well?
[10:13] <duflu> Kaleo: I think so..?
[10:13] <Kaleo> k
[10:13] <Kaleo> duflu, I believe this all relates to https://bugs.launchpad.net/camera-app/+bug/1398436
[10:14] <duflu> Kaleo: There could be other bugs at play in our code, always. I'm reminded of this talk where I think John Carmack discusses the same issue driving him crazy: https://www.youtube.com/watch?v=nqzpAbK9qFk
[10:15] <Kaleo> duflu, ok
[10:15] <Kaleo> duflu, concretely what happens is that after locking and unlocking the phone the camera app's rendering is not happening for a few seconds
[10:15] <duflu> Kaleo: Oooh, you don't have framedropping (eglSwapInterval(0)) do you?
[10:15] <Kaleo> duflu, I don't have anything outside of the pristine RTM image
[10:16] <duflu> Kaleo: If a client has set eglSwapInterval(0) (which I think is unlikely) then we do have buffer scheduling bugs that will appear as a freeze
[10:16] <duflu> (fixed in Mir 0.10)
[10:16] <Kaleo> duflu, is MIR 0.10 in vivid?
[10:16] <duflu> Kaleo: No, it's future
[10:16] <Kaleo> duflu, ok
[10:17] <Kaleo> duflu, I don't recall the app setting eglSwapInterval(0)
[10:17] <duflu> Kaleo: There is one additional bug that will trigger such a freeze, but it's only known to happen in cases that the phone won't trigger
[10:17] <duflu> Still, I expect both to be fixed in 0.10
[10:19] <duflu> Kaleo: I'll grep the camera-app source in case
[10:20] <Kaleo> duflu, done that, no match
[10:20] <Kaleo> duflu, but there is something more
[10:20] <duflu> Kaleo: Also, we only know that Android overlays are highly unstable with eglSwapInterval(0). This does not guarantee they're always going to be stable with the default eglSwapInterval(1), just moreso
[10:21] <Kaleo> duflu, for the duration of the freeze, the app is not notified it is focused/active (Qt.application.active is still false)
[10:21] <Kaleo> duflu, even though the process has been correctly resumed
[10:23] <duflu> Kaleo: To absolutely verify it's not another overlays bug, try running with env MIR_SERVER_DISABLE_OVERLAYS=true
[10:23] <Kaleo> duflu, ok, trying that
[10:23] <duflu> ... for USC
[10:23] <duflu> Kaleo: And then I must go for the week ...
[10:23] <Kaleo> USC?
[10:23] <duflu> Kaleo: Only unity-system-compositor will use the hardware overlays
[10:24] <duflu> So the environment needs setting for that
[10:24] <Kaleo> duflu, I can set it in /etc/environment no?
[10:24] <duflu> Kaleo: Yes, but make sure it sticks after rebooting (/proc/<pid>/env)
[10:24] <Kaleo> duflu, yep
[10:26] <duflu> Kaleo: Please also double-check the whole stack of projects to ensure nothing is triggering eglSwapInterval(0)
[10:26] <Kaleo> duflu, I grepped it all and only qtubuntu sets it
[10:26] <Kaleo> duflu, if an env var is set
[10:26] <duflu> ... or creating a GL context with zero
[10:26] <Kaleo> otherwise it defaults to 0
[10:27] <Kaleo> duflu, bug still happens with MIR_SERVER_DISABLE_OVERLAYS=true
[10:27] <duflu> Interesting
[10:27] <duflu> Kaleo: I think the clock-down power management stuff is a big offender but that will only cause you to miss a frame or two in my experience
[10:28] <Kaleo> k
[10:28]  * duflu forgets what the kernel features are that stop it from happening. It's something Linux has inherited from Android recently-ish but is not yet widely used
[10:28] <Kaleo> duflu, note the rest of unity8 behaves normally during the freeze
[10:28] <Kaleo> duflu, everything is fluid and responsive
[10:28] <duflu> Kaleo: I'm out of ideas
[10:28] <Kaleo> duflu, ok
[10:28] <duflu> and the work week
[10:28] <Kaleo> duflu, thank you
[10:29] <duflu> No worries...