[04:38] <RAOF> Ah, of course. *That's* why you don't do a compile in an actual armhf chroot.
[06:41]  * RAOF apparently has an xorgRootess
[06:43] <duflu> RAOF: +l ?
[06:44] <RAOF> No; typo :)
[06:44] <duflu> +Mir ?
[06:44] <RAOF> But it seemed like a funny typo.
[06:44] <RAOF> This *should* work, and be rootless...
[07:24] <penk> hello, I'm installing unity-system-compositor & xmir on amd64 trusty, everything seems running fine under /var/log/lightdm, but the screen is blank.. any idea?
[07:26] <penk> # tarball of log https://mega.co.nz/#!hMxD1ArC!e7AevxbOyidBBaZZAlXP7SoZdkMlT8b7Qzi3dDel2OI
[07:30] <duflu> penk: I can't see any reason in those logs. Could you please "ubuntu-bug unity-system-compositor" ?
[07:30] <penk> duflu: sure I'll get to that
[07:31] <duflu> penk: Everything works without unity-system-compositor?
[07:31] <penk> duflu: yes, with radeon driver
[07:31] <duflu> Hmm, I should revive my radeon machine and update it
[07:31] <penk> duflu: I can hear the lightdm sound, but the screen is black
[07:32] <duflu> penk: Is the monitor LED showing it's asleep (like orange instead of green)?
[07:32] <penk> duflu: I'm pretty sure the screen & system is awake
[07:33] <duflu> penk: So you can see the backlight is on, but pixels are black?
[07:33] <penk> duflu: exactly
[07:34] <duflu> penk: When you can, please try "Ctrl+Alt+F1". Can you reach the VT that way? Also please try installing mir-demos and running "mir_demo_client_egltriangle". Does it appear on top of the blackness?
[07:35] <penk> duflu: vt switching is working
[07:35] <penk> duflu: sometimes the compositor gives me VT I/O error though
[07:35] <penk> duflu: I'll try mir-demos later
[07:35] <duflu> That's probably not cool
[07:52] <penk> duflu: I see mir_demo_client_egltriangle running on the screen
[07:53] <duflu> penk: Cool. Then the bug is just XMir. Please log it against that project
[07:53] <penk> duflu: got it, thx
[09:08] <duflu> Now showing in a browser near you: http://timvideos.us/wool
[09:24] <anpok> duflu: what is shown next?
[09:24] <duflu> anpok: Too late I think ... http://linux.conf.au/programme/schedule
[09:25] <anpok> oh zero copy composition
[09:26] <anpok> kdub: I could not reproduce the error, but hey got a different one instead - mir_integration_tests fails to create a fb
[09:27] <duflu> That's OK. Keith being Keith only talked about X. And when asked about something other than X (Wayland) he said he wasn't interested. And had nothing to say
[09:27] <anpok> hehe
[09:50] <alan_g> duflu: @bug 1239955 on CI - have we asked #ubuntu-ci-eng if they can poke the hardware?
[09:52] <duflu> alan_g: Assuming it's the same cause. There might be other triggers...
[09:54] <anpok> on n10 that test always fails for me
[09:54] <anpok> but with a different exception
[09:57] <anpok> here gralloc is queried for a framebuffer_device_t, a pixel format is taken from that structure
[09:57] <anpok> the pixel format is RGBA_8888
[09:57] <anpok> but the no EGLConfig that is querried matches that visual id
[09:58] <anpok> the most similar one is BGRA_8888
[09:59] <anpok> the other thing I noticed was that whenver i run the tests in order the display is turned off around that test..
[09:59] <anpok> seems like the tests before that one cause that in some way?
[10:04] <anpok> forget the last two statements - just some buffers are flipped where two of the three are black. display is not turned off..
[10:21] <alan_g> duflu: it isn't just the one device. The difference seems to be they moved to trusty-proposed 119 today. Gonna try that here.
[10:21] <duflu> Fair enough. We don't have much device-specific code
[12:42] <alan_g> alf__: I'm not sure what to try next with bug 1239955 (which is blocking CI) - any suggestions before I MP disabling the test?
[12:44] <alf__> alan_g: @"Initially I saw intermittent failures if unity8 wasn't stopped", is unity8 not being stopped while running our tests in CI?
[12:44] <alan_g> alf__: it is stopped - I've checked
[12:47] <alf__> alan_g: does "sudo powerd-cli display on bright &" make any difference locally?
[12:48] <alan_g> alf__: yes. Seems to work as well as the power button
[12:51] <alan_g> alf__: revise that - still failing intermittently
[12:53] <alf__> alan_g: no more ideas off the top of my head
[12:57] <alan_g> alf__: OK I'll MP disabling the test as a workaround.
[13:41] <anpok> alf__: do you have a nexus10?
[13:41] <alf__> anpok: yes
[13:41] <alf__> anpok: ?
[13:42] <anpok> do the integration tests run for you on the device?
[13:42] <alf__> anpok: haven't tried recently... do you want me to?
[13:43] <anpok> it would be nices
[13:43] <anpok> -s
[13:43] <anpok> because I dont think that my issues are hardware related
[13:43] <alf__> anpok: ok
[13:44] <anpok> I believe that the egl config selection needs a different logic
[13:50] <alf__> anpok: ok, so should I just run the integration tests from development-branch or do you need some special branch/config?
[13:50] <anpok> just that
[13:50] <anpok> or even just limit to the AndroidGPUDisplay.* tests
[14:01] <alf__> anpok: I get "could not select EGL config for use with framebuffer"
[14:01] <alf__> anpok: for gpu_display_ok_with_gles
[14:01] <anpok> me too
[14:03] <anpok> it happens because we try to select an egl config with the same "visual id" as the one mentioned in the framebuffer_device_t
[14:09] <alf__> anpok: I am not familiar with what visual id means for Android, but on the desktop it's not directly related to a pixel format
[14:10] <anpok> hm it seems like on android it matches the pixel format integer found in system/graphics.h
[14:12] <anpok>     HAL_PIXEL_FORMAT_RGBA_8888          = 1,
[14:12] <anpok>     HAL_PIXEL_FORMAT_RGBX_8888          = 2,
[14:13] <alf__> anpok: it seems because our code checks for it or because you found some reference of that fact elsewhere? :)
[14:16] <anpok> our code checks for it :)
[14:16] <anpok> .. and the values seem to make sense
[14:16] <anpok> so docs would be awesome :)
[14:17] <alf__> anpok: if a print out the id values I get: http://paste.ubuntu.com/6720922/ (which supports this)
[14:17] <anpok> yes
[14:19] <alf__> anpok: so we are looking for RGBA8888 but nexus 10 provides BGRA8888
[14:20] <anpok> or RGBX for the frame buffer
[14:21] <anpok> I wonder if is necessary to have an exact match here
[14:23] <anpok> I guess that code path is only used in the unit tests..
[14:23] <anpok> s/unit/integration
[14:30] <anpok> hm the android gl_context could also make use of the surfaceless context class
[14:37] <alf__> anpok: the framebuffer_device_t reports that it uses RGBA8888 but Nexus 10 doesn't seem able to render to it. As you said this is the fallback (non-HWC) path, which Nexus 10 probably won't ever need to use.
[15:03] <anpok> ok if a different one is picked posting silently just fails
[15:49] <kgunn> racarr: anyway...the more i thot about the autopilot input prob thomi & Saviq were talking about....
[15:49] <kgunn> i got confused..
[15:49] <kgunn> is it really the at the events go missing ?
[15:50] <racarr> it soundslike the device
[15:50] <kgunn> or is it just that the restart causes mir to get confused b/c the "rules" aren't realy changed...even thos inotify says ok?
[15:50] <racarr> doesntget probed properly
[15:50] <kgunn> ...or are there really 2 problems both there
[15:50] <kgunn> racarr: ok...so more that latter
[15:50] <racarr> mm I think so
[15:51] <kgunn> someone (i think thomi) was scaring me that we had a 2nd prob of events going missing (even after proper probing)
[15:58] <alf__> racarr: is something "eating" your spaces and apostrophes or it it just quick typing?
[15:58] <alf__> is it
[16:00] <kgunn> i'm quessing an old tea spill on the space bar
[16:03] <racarr> alf__: Space key eaten mostly
[16:04] <racarr> via tea yes lol
[16:22] <kdub> robotfuel, where can i find the script that sets up the phone on CI?
[16:23] <robotfuel> kdub: pulling it up now...
[16:25] <kdub> thanks
[16:25] <robotfuel> kdub: lp:~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins
[16:26] <robotfuel> kdub: http://s-jenkins.ubuntu-ci:8080/view/Mir/job/mir-mediumtests-runner-mako/configure if you need more info
[16:37] <kgunn> kdub: fyi...i was gonna try the fab-4 integration tests...since its now in archive, will likely ressurect the kill surfflinger topic as soon as i have confidence
[16:38] <kdub> not sure what that means :)
[16:39] <kdub> like, remove sf from the image?
[16:41] <kgunn> kdub: well...at least stop having it available for unity8....only as a tool for bringup
[16:41] <kgunn> meaning, we won't be putting effort in maintaining unity8 code
[16:41] <kgunn> which enables surf flinger
[16:41] <kgunn> to be reliably used
[16:43] <ogra_> kdub, mainly drop the ability to run it
[16:43] <ogra_> as i understood (as a plumber)
[16:46] <kdub> right, sounds okay to me
[17:56] <brainwash_> is it possible to enable hardware cursor manually when using XMir? why is it still not supported, any reasons?
[18:01] <kgunn> alf__: ^ if you're on
[18:02] <brainwash_> I really would love to use XMir, but a slow/laggy mouse cursor is a no-go
[18:03] <kgunn> brainwash_: right, thanks for trying xmir and using...just a matter of effort really, we've shifted our focus towards
[18:04] <kgunn> building out features around tablet/unity8 shell
[18:04] <kgunn> since xmir didn't make it in by default...the way
[18:04] <kgunn> scheduling lines up wrt releases etc
[18:04] <brainwash_> so XMir gets abandoned slowly?
[18:04] <kgunn> it makes more sense for us to pour it on for unity8-mir & "rootless" x on unity8-mir
[18:05] <brainwash_> rootless like xwayland, right?
[18:05] <kgunn> brainwash_: not abandoned per se, but feature stagnant
[18:05] <kgunn> brainwash_: rootless will leverage a lot of what was done in mir
[18:06] <kgunn> oops/mir/xmir
[18:06] <brainwash_> alright, but I'm still interested if hardware cursor support is possible :)
[18:06] <kgunn> brainwash_: was trying to hail someone smarter than me :)
[18:07] <kgunn> brainwash_: depending on your timezone...if you pop in say in about 8 hours or so...you'd get a better answer
[18:07] <kgunn> when the australs come onlien
[18:07] <kgunn> online even
[18:08] <brainwash_> alight, I'll setup my server then and rejoin with my irc bouncer, so I'll don't miss the answer, thanks :)
[18:08] <kgunn> brainwash_: sorry i wasn't better help...
[18:08] <kgunn> again thanks for trying out xmir
[19:21] <mterry_> ricmm_, poke about libhybris
[20:51] <ricmm_> mterry_: wip
[21:48]  * kgunn hugs ricmm_ 
[21:50] <kdub> rsalveti, are you okay with https://code.launchpad.net/~kdub/mir/less-3rd-party/+merge/199851
[21:50] <kdub> basically making mir a dependency of android-headers
[21:50] <rsalveti> hm, lemmecheck
[21:53] <rsalveti> kdub: looks good
[21:53] <kdub> cool, thanks!
[21:54] <kdub> *making mir depend-on android-headers, rather
[22:12] <RAOF> brainwash_: Yeah, HW cursor support is possible & needed.
[22:12] <RAOF> brainwash_: It'll get done before we're done, but with phone/tablet being the current focus for Mir development it's understandably lower importance :)
[22:13] <RAOF> brainwash_: On the other hand, it could get done sooner if you wanted to do it :)
[22:14] <brainwash_> RAOF: so it's not a trivial thing :/
[22:14] <RAOF> Oh, it's reasonably simple.
[22:14] <brainwash_> on top of that, I lack the knowledge to implement this
[22:39] <RAOF> For those not watching #wayland, http://www.anandtech.com/show/7641/amd-demonstrates-freesync-free-gsync-alternative-at-ces-2014, is super-cool.
[22:50] <kgunn> yeah.. RAOF that is pretty cool
[22:50] <kgunn> and giving it away...hmmm
[22:51] <RAOF> Apparently available on all recent AMD GPUs, too.