[14:46] <bregma> tjaalton, Xmir branch at https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/?h=xmir-1.19 now builds and tests cleanly on Zesty if you can find the time to integrate into xorg-server
[14:56] <tjaalton> bregma: sweet, thanks! will do that next week when I'm back
[15:16] <greyback> alf_: On https://bugs.launchpad.net/mir/+bug/1667001   I think repowerd is innocent, suspect Mir/kms
[15:17] <greyback> I've attached the log you requested
[15:17] <alf_> greyback: thanks
[15:18] <greyback> alf_: the machine is by me if there's anything else I can offer you
[15:20] <alf_> greyback: if you are willing to recompile repowerd we may get some more hints about what's going wrong
[15:20] <greyback> alf_: Sure. I know it's not a high priority bug though, so only if you want
[15:21] <alf_> greyback: sure, let's do it now that it's hot :)
[15:21] <alf_> greyback: git clone lp:repowerd (assuming you have set the lp: shortcut for git)
[15:21] <greyback> I have
[15:23] <alf_> greyback: build repowerd the usual cmake way (no special options needed)
[15:23] <alf_> greyback: get the deps first of course
[15:25] <alf_> greyback: ... "sudo systemctl stop repowerd" to stop the system one, and from the build dir run the git version with 'sudo REPOWERD_LOG=console bin/repowerd'
[15:25] <alf_> greyback: make sure it works and you can see the same issue as before
[15:25] <greyback> ok
[15:28] <greyback> alf_: my build machine != my test machine, can I just copy over the repowerd binary, or do I need the tools too?
[15:29] <alf_> greyback: not yet, perhaps later depending on the results of our experiments
[15:32] <greyback> alf_: repowerd binary is 10mb!
[15:42] <greyback> alf_: http://pastebin.ubuntu.com/24053613/ <- any idea?
[15:45] <alf_> greyback: do you have repowerd-2017.02 installed on that system?
[15:45] <greyback> alf_: no 2016.12+17.04.20161212.1-0ubuntu1
[15:46] <alf_> greyback: ok, then update (and stop the system repowerd again)
[15:46] <greyback> ok
[15:55] <greyback> alf_: http://pastebin.ubuntu.com/24053671/
[15:55] <greyback> same issue with the newer repowerd
[15:56] <alf_> greyback: good
[15:57] <alf_> greyback: one thing to change to see if it makes a difference: make the turn_on() call to USC synchronous
[15:57] <alf_> greyback: so in src/adapters/unity_display.cpp
[15:58] <dandrader> alan_g, how do I get the top-left position of a miral::WindowInfo?
[15:58] <alan_g> dandrader: wi.top_left()
[15:58] <greyback> alf_: done, trying
[15:59] <alf_> greyback: in ::turn_on() change the dbus call to _sync and remove one "nullptr,"
[15:59] <greyback> alf_: already done ;)
[15:59] <alf_> greyback: ack
[15:59] <greyback> I am still surprised how big the binary is
[16:00] <dandrader> alan_g, ah, you mean windowIndo.window().top_left()
[16:00] <dandrader> *windowInfo
[16:00] <alan_g> dandrader: oh, right. yes
[16:00]  * alan_g isn't a good autocomplete function
[16:00] <greyback> alf_: yes it seems to block on that TurnOn dbus call, as the screen flickers
[16:02] <alf_> greyback: It's all the debug info I guess? The released binary is much smaller (~700kb)
[16:02] <greyback> alf_: yeah probably
[16:03] <alf_> greyback: ok, so this strongly indicates that repowerd is not doing anything strange, but let's experiment a bit more
[16:04] <alan_g> c++ debug symbols are BUG
[16:04] <alf_> greyback: with the screen on stop repowerd (ctrl-c)
[16:05] <alf_> greyback: i.e. I want the backlight to stay on
[16:06] <greyback> yep
[16:07] <alf_> greyback: now just turn USC rendering on/off manually to see what behavior you get: sudo gdbus call --system --dest com.canonical.Unity.Display --object-path /com/canonical/Unity/Display --method  com.canonical.Unity.Display.TurnOff "all"
[16:08] <greyback> alf_: I've actually gone further. A while ago I made this tool: https://code.launchpad.net/~gerboland/+git/display-configurator
[16:08] <greyback> alf_: just extending the mir display config tool, adding display power on/off stuff
[16:09] <greyback> alf_: if I ask mir to turn off the display, and then on, the on causes the same flicker
[16:09] <alf_> greyback: ok, just wanted to test if the backlight state affects this at all
[16:09] <alf_> greyback: it seems not
[16:09] <greyback> alf_: ack
[16:10] <alf_> greyback: ok, so repowerd is out... anything interesting in /var/log/lightdm/unity-system-compositor.log
[16:12] <alf_> greyback: or in /var/log/syslog for that matter? Any drm kernel messages?
[16:20] <greyback> alf_: I tore it down to the simplest elements: mir_demo_server_basic and my test client. From Mir: http://pastebin.ubuntu.com/24053776/
[16:20] <greyback> there's a small complaint from kms about invalid argument for Gamma setting
[16:20] <greyback> but I see nothing at all relevant in syslog or dmesg
[16:22] <greyback> actually I get the flicker when I turn off the display too
[16:24] <greyback> and setting mir power mode to 1 (on) does not enable the display again
[16:24] <greyback> I have to kill the client to get the display to turn back on
[16:29] <alan_g> greyback: I just submitted a QtMir MP that ran into LTTng errors that seem unrelated. Is there a known problem?
[16:29] <greyback> alan_g: news to me
[16:29] <greyback> dandrader|afk: ^^
[16:31] <alan_g> Hmm, seems to be just my MP.
[16:32]  * alan_g can't ignore it
[16:38] <alf_> greyback: I am out of easy-to-test ideas. I guess next step would be to check if something wrong is going on at the Mir platform/backend level, and if everything is fine there, too, then it's probably a driver or hardware issue.
[16:41] <greyback> alf_: ack. I'm updating the bug with all I've found, but I expect it's driver/hardware
[17:12] <alan_g> greyback: not sure what the cause is, but after "apt update" it is happening locally on a clean lp:qtmir. :(
[17:13]  * greyback trying