[09:11] <alan_g> greyback: @MirBlob I get the impression that we're not quite in sync but I'm not yet sure where the differences are. Should we resolve in MP comments/IRC/hangout?
[09:27] <greyback> alan_g: no need, am satisfied
[09:27] <greyback> sorry, that thread keeps popping out of my mind
[09:28] <alan_g> greyback: thanks. (I still have that niggling feeling - but that's for the future.)
[09:28] <greyback> ack
[10:03] <duflu> greyback: Actually I don't know how to connect clients to USC. It's the trust magic... and even when I get a connection the client exits immediately
[10:04] <anpok> clients have to be fullscreen on all outputs..
[10:06] <duflu> Opening session egldemo
[10:06] <duflu> Mir chose pixel format 3.
[10:06] <duflu> Using pixel format 4.
[10:06] <duflu> Current active output is 1920x1200 +0+0
[10:06] <duflu> Can't create a surface
[10:06] <duflu> Closing session egldemo
[10:10] <greyback> duflu: set MIR_SERVER_NAME=session-0
[10:10] <duflu> greyback: K, ta
[10:17] <alan_g> duflu: FWIW you can also use --debug-without-dm --debug-active-session-name <session you want to connect> for tests with USC
[10:40] <greyback> alan_g: what does debug-without-dm do?
[10:41] <duflu> Nope, still no luck
[10:41] <alan_g> Stubs out the display manager related logic
[10:41] <duflu> And it's getting late
[10:42] <duflu> alan_g: You need to pass those to USC or the nested server?
[10:42] <alan_g> duflu: USC
[10:42] <duflu> alan_g: Yeah, no luck
[10:42] <duflu> Same failures
[10:43] <duflu> But I did just implement Xmir rootless resizing on desktop and phone. So that's something
[10:43] <duflu> Fullscreen solitare
[10:43] <duflu> FTW
[10:44] <alan_g> duflu: if you're running demo server the default debug-active-session-name of "nested-mir@:/run/user/1000/mir_socket" is what you need
[10:44] <duflu> alan_g: Can you email me a full working set of command lines?
[10:44] <duflu> I need to start finishing up
[10:45] <greyback_> MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket MIR_HOST_SERVER_FILE=$XDG_RUNTIME_DIR/mir_socket mir_proving_server &
[10:45] <greyback_> that tends to work for me
[10:45] <alan_g> duflu: I'll have to do that later. (Don't have a working USC built at the moment)
[10:45] <duflu> alan_g: No problem. I'm using the default wily install
[10:45] <alan_g> Me too
[10:46] <alan_g> Guess I should just install USC
[10:47] <anpok> duflu: oh xmir is now happy with the color formats on phone?
[10:47] <duflu> anpok: Trunk git Xmir :)
[10:47] <duflu> I guess we can do a build next week-ish
[10:48] <anpok> duflu: cairo would need that happiness too
[10:56] <alan_g> Hmm I used to be able to run USC with "sudo unity-system-compositor --debug-without-dm --arw-file" but now it tries (and fails) to access dbus.
[11:01] <alan_g> duflu: I think that "feature" of USC is broken today
[11:06] <greyback_> alf_: with display configuration, is "clone" mode something it can express?
[11:07] <alf_> greyback_: yes, the (x,y,w,h) of the two displays in the virtual coordinate space just need to overlap
[11:10] <greyback_> alf_: aha yes
[11:10] <greyback_> thanks
[11:23] <duflu> greyback_: clone mode is not always ideal though. More modes are possible that we don't have names for yet... https://bugs.launchpad.net/mir/+bug/1395416
[11:23]  * duflu -> weekend
[11:23] <greyback_> duflu: ack
[11:23] <greyback_> enjoy weekend!
[11:23] <duflu> o/
[14:55] <tsdgeos> guys, any idea what can cause http://paste.ubuntu.com/12449481/ on the desktop?
[14:57] <alan_g> tsdgeos: not having root?
[14:57] <tsdgeos> alan_g: i am root
[14:58] <tsdgeos> error is
[14:58] <tsdgeos> argument is not valid
[14:58] <tsdgeos> or somethning like that when i translate back to enlgis
[14:58] <tsdgeos> h
[14:59] <alan_g> alf_: ^^?
[15:00] <tsdgeos> greyback_ suggests i need to tear down lightdm?
[15:01] <tsdgeos> back in aminute
[15:01] <alf_> tsdgeos: are you running from a VT?
[15:03] <alf_> tsdgeos: also, what exactly are you running? Is this a demo server or USC or unity8 or ...?
[15:03] <tsdgeos> alf_: unity8
[15:09] <tsdgeos> ok, greyback_ brought me a bit forward
[15:09] <tsdgeos> i get unity8 to segfault at least :D
[15:09] <tsdgeos> segfaults in mir+X11 :S
[15:10] <tsdgeos> http://pastebin.ubuntu.com/12449639/
[15:11] <tsdgeos> alf_: ↑
[15:13] <alf_> tsdgeos: Can you install libmirserver33-dbsym?
[15:13] <tsdgeos> on it
[15:16] <tsdgeos> alf_: http://pastebin.ubuntu.com/12449714/
[15:17] <tsdgeos> want me to install the dbgsym for egl and xcb too?
[15:18] <greyback_> tsdgeos: could you start unity8 with MESA_DEBUG=1 EGL_LOG_LEVEL=debug - in case they print anything useful
[15:18] <tsdgeos> sure
[15:19] <tsdgeos> greyback_: nothing interesting i'd say http://pastebin.ubuntu.com/12449736/
[15:20] <greyback_> libEGL debug: Native platform type: x11 (autodetected)  <- that's wrong
[15:20] <greyback_> tsdgeos: (guess) unset DISPLAY ?
[15:21] <tsdgeos> it's not set
[15:21] <greyback_> yeah, was bit of a gamble that
[15:21] <tsdgeos> greyback_: what should it say? kms?
[15:23] <greyback_> libEGL debug: Native platform type: drm (autodetected)    <- what I get
[15:23] <alf_> tsdgeos: can you please pastebin the whole log
[15:23] <tsdgeos> alf_: that's the whole log :D
[15:23] <tsdgeos> last line == segmentation fault
[15:23] <greyback_> EGL_PLATFORM=drm
[15:24] <alf_> tsdgeos: doesn't unity8/mir print anything else before crashing?
[15:24] <tsdgeos> nope
[15:24] <greyback_> tsdgeos: does that env var help?
[15:24] <tsdgeos> greyback_: it now says drm, but still crashes :/
[15:25] <greyback_> ouch
[15:25] <greyback_> tsdgeos: what graphics chipset has this machine?
[15:25] <tsdgeos> intel+nvidia monster
[15:26] <alf_> tsdgeos: what's the output of ls /usr/lib/x86_64-linux-gnu/mir/server-platform ?
[15:26] <tsdgeos> unity8@xps:~$ ls /usr/lib/x86_64-linux-gnu/mir/server-platform
[15:26] <tsdgeos> graphics-mesa-kms.so.3  graphics-mesa-kms.so.4  server-mesa-x11.so.4
[15:27] <alf_> tsdgeos: can you move server-mesa-x11.so.4 temporarily out of there please and try again
[15:27] <tsdgeos> same thing
[15:27] <alf_> tsdgeos: move graphics-mesa-kms.so.3 ?
[15:28] <tsdgeos> same thing
[15:28] <alf_> tsdgeos: does a demo server work?
[15:29] <tsdgeos> usc is running
[15:29] <tsdgeos> is that enough?
[15:30] <alf_> tsdgeos: yes, although I would like to try a pure demo server in nested configuration to see if we can get more info
[15:30] <tsdgeos> alf_: what do i run?
[15:30] <alf_> tsdgeos: stop lightdm
[15:31] <alf_> tsdgeos: do you have ssh access to that machine?
[15:31] <alf_> tsdgeos: actually you don't need to stop lightdm
[15:31] <alf_> tsdgeos: just switch to a VT
[15:32] <tsdgeos> i'm in via ssh already
[15:32] <tsdgeos> lighttdm stopped
[15:32] <alf_> tsdgeos: ok, then switch to a VT
[15:32] <alf_> tsdgeos: sudo bin/mir_demo_server
[15:33] <alf_> tsdgeos: did you get a cursor ?
[15:33] <alf_> tsdgeos: (which you can move)
[15:33] <tsdgeos> yes
[15:34] <alf_> tsdgeos: ok, from another ssh session: sudo mir_demo_server --host-socket /tmp/mir_socket -f /tmp/mir_nested
[15:34] <alf_> tsdgeos: and from a third ssh session: sudo mir_demo_client_egltriangle -m /tmp/mir_nested
[15:34] <tsdgeos> is that second thing supposed to return?
[15:35] <alf_> tsdgeos: not immediately, did it output anything?
[15:35] <tsdgeos> http://pastebin.ubuntu.com/12449924/
[15:36] <tsdgeos> it's crashing the same as unity8
[15:36] <tsdgeos> just doesn't say
[15:36] <tsdgeos> but if run in gdb i get the same bt
[15:36] <alf_> tsdgeos: can you please paste the log from the first mir_demo_server (the host)
[15:37] <tsdgeos> where do i get it? the VT has the mouse
[15:37] <tsdgeos> is it logged somewhere?
[15:37] <tsdgeos> or should i kill it and start it with &> ?
[15:37] <alf_> tsdgeos: no, use ctrl-alt-backspace to quit
[15:38] <alf_> tsdgeos: then also start it from an ssh session (just be sure a VT is active in the target computer)
[15:38] <tsdgeos> alf_: http://pastebin.ubuntu.com/12449956/ this is the first command output
[15:47] <alf_> tsdgeos: ok, so could you get the backtrace of the second (nested) demo server, with egl debug symbols if possible
[15:48] <tsdgeos> alf_: do i force drm with  EGL_PLATFORM=drm ?
[15:48] <alf_> tsdgeos: no, let it run normally
[15:49] <tsdgeos> alf_: http://pastebin.ubuntu.com/12450102/
[15:49] <tsdgeos> one with xcb symbols coming
[15:50] <alf_> tsdgeos: thanks
[15:50] <tsdgeos> alf_: http://pastebin.ubuntu.com/12450115/
[15:51] <tsdgeos> forcing drm http://pastebin.ubuntu.com/12450115/
[15:52] <tsdgeos> forcing drm + valgrind http://pastebin.ubuntu.com/12450137/
[15:53] <tsdgeos> and now with more symbols
[15:53] <tsdgeos> http://pastebin.ubuntu.com/12450161/
[15:54] <greyback_> any idea if your intel or your nvidia chip is the one being used?
[15:55] <tsdgeos> in theory the intel one
[15:58] <alf_> tsdgeos: is this latest wily?
[15:58] <tsdgeos> alf_: no vivid+overlay
[15:59] <tsdgeos> fwiw the egltriangle client has the same problem
[16:00] <alan_g> FWIW the simplest client that shows anything is multiwin
[16:00] <alf_> bregma: Does dual landing copy the packages from wily to vivid, or does it rebuild them from source for wily?
[16:01] <alf_> bregma: sorry, I meant rebuild them from source for vivid
[16:01] <bregma> alf_, it tweaks the wily changelog and rebuilds against vivid+overlay
[16:01] <alan_g> alf_: nothing would work without rebuilding
[16:01] <bregma> so, it's GCC-5 safe
[16:02] <alf_> alan_g: yeah, I just wanted to make sure ...
[16:02] <bregma> better to be sure
[16:03] <alf_> tsdgeos: is there a reason you want vivid+overlay?
[16:04] <tsdgeos> alf_: becuase is what we release products on
[16:04] <tsdgeos> i have a wily chroot
[16:04] <tsdgeos> but i'm getting
[16:04] <tsdgeos> std::exception::what: Failed to find platform for current system
[16:04] <tsdgeos> when running the demo_server
[16:05] <alf_> tsdgeos: @products, well, not for the desktop (i think) :)
[16:05] <tsdgeos> i guess it missses some stuff
[16:06] <alan_g> tsdgeos: tried updating mir-graphics-drivers-desktop?
[16:07] <tsdgeos> yeah
[16:08] <tsdgeos> has anyone ever run mir in a chroot?
[16:08] <mhall119> camako: I can't seem to get qmlscene to connect to the mir socket from mir_demo_server, any idea what I'm doing wrong?
[16:08] <alan_g> I think I saw that at the PD sprint
[16:08] <mhall119> mhall@mhall-thinkpad:~/projects/uReadIt/work$ MIR_SOCKET=/tmp/mir_socket QT_QPA_PLATFORM=ubuntumirclient qmlscene Main.qml --
[16:08] <mhall119> Loading module: 'libubuntu_application_api_desktop_mirclient.so.3.0.0'
[16:08] <mhall119> UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
[16:08] <mhall119> running, and the correct socket is being used and is accessible. The shell may have
[16:08] <mhall119> rejected the incoming connection, so check its log file
[16:09] <mhall119> do I need a compositor like Unity running in between mir_demo_server and qmlscene?
[16:10] <camako> mhall119, default location for mir socket is the XDG_RUNTIME_DIR
[16:10] <alan_g> mhall119: no. but the client needs access to the socket
[16:11] <tsdgeos> ok, got it to run from the chroot
[16:11] <tsdgeos> let¡s try the ohter thing
[16:11] <alan_g> if you run the server as root the socket is /tmp/mir_socket (but you need --arw-file on the server to make it globally accessible)
[16:12] <mhall119> camako: I specified --file /tmp/mir_socket when launching mir_demo_server
[16:12] <tsdgeos> alf_: wooooohooo, it works
[16:12] <mhall119> alan_g: I ran the server as my user
[16:12] <tsdgeos> so mir is broken in vivid+overlay for my configuration
[16:12] <mhall119> srwxrwxr-x 1 mhall mhall    0 Sep 18 12:06 /tmp/mir_socket
[16:12] <tsdgeos> works in wily
[16:13] <alf_> tsdgeos: given that it is the same version, something mesa has changed
[16:13] <alf_> tsdgeos: in mesa ..
[16:13] <tsdgeos> :/
[16:13] <camako> mhall119, how about mir demo apps, do they work ok?
[16:14] <mhall119> camako: ah ha, they didn't at first, but after installing mir-client-platform-mesa3 they do
[16:14] <mhall119> and now my qmlscene app doesn't segfault either, but still doesn't display
[16:15] <camako> mhall119, is this under x?
[16:16] <camako> mhall119, does the qmlscene work with the mesa-kms platform, and fail with mesa-x11?
[16:16] <mhall119> camako: I'm running Unity 7, so yes under X, I don't know which mesa-* qmlscene is using
[16:17] <mhall119> when I run the qmlscene app, it shows a white horizontal bar in the Mir on X window, like at hte top of the multiwin demo windows
[16:18] <alan_g> mhall119: that's Mir's "title bar"
[16:18] <camako> mhall119, it's the server using the platform not the app... Can you try your experiment by running the demo server in a vt?
[16:19] <camako> mhall119, to rule out/confirm that it's mir-on-x
[16:19] <camako> causing the problem
[16:19] <mhall119> camako: how do I do that?
[16:19] <alan_g> camako: could this be the intel/mesa extension that got fixed in Wily?
[16:19] <camako> provide a '--vt 1' option to the demo server and run as sudo
[16:20] <camako> alan_g, yeah that's what I'm thinking
[16:20] <mhall119> camako: Unknown command line options: --vt 1
[16:21] <camako> ??
[16:21] <alan_g> mhall119: you need to specify --platform-graphic-lib /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.4
[16:21] <tsdgeos> alf_: oh well, now i know i need wily, monday more
[16:21]  * tsdgeos waves
[16:21] <alan_g> (Or equivalent)
[16:27] <mhall119> alan_g: camako: it kind of works on vt 1
[16:27] <mhall119> lots of flickering, but I can see the app's content
[16:28] <camako> mhall119, I think it is due to the gles mesa extension that got fixed recently
[16:28] <camako> mhall119, does your system use intel GPU?
[16:29] <camako> You want to update your system to latest wily
[16:31] <mhall119> camako: yes, intel
[16:31] <mhall119> camako: I'm on vivid + operlay PPA
[16:32] <camako> mhall119, yeah I don't think vivid has that fix
[16:32] <mhall119> camako: do you know what version of the package has the fix?
[16:35] <camako> mhall119, I don't exactly know what package the fix was in... some intel gpu and/or display driver.
[16:36] <mhall119> camako: ok
[16:37] <camako> mhall119, lemme look up the extension and then we can google it
[16:37] <mhall119> is this what's causing it not to display the window on X11?
[16:37] <camako> yes
[16:37] <mhall119> ok
[16:54] <camako> mhall119, I am pretty sure the fix is in the libegl1-mesa package... My version is libegl1-mesa:
[16:54] <camako>   Installed: 10.6.3-1ubuntu1
[16:55] <camako> mhall119, but for vivid, it's 10.5.* where this fix doesn't exist
[17:18] <mhall119> camako: yup, I have 10.5.9, any chancce of 10.6.* going into the vivid overlay ppa?
[17:19] <camako> mhall119, I don't know how these kinds of decisions are taken
[18:02] <Guest30724> :( Xmir is not working for me on wily
[18:02] <Guest30724> Xmir :2 --desktop_file_hint=geany.desktop
[18:03] <Guest30724> oh well :(
[18:03] <Guest30724> at least i get a black window :P
[18:08] <anpok> -damage
[18:09] <anpok> some improvements are on xmir git
[18:30] <bkchr> Hi, kgunn are you online? I compiled mir on my phone, but it still doesn't work. I think that I need to compile the platform-api for my device?
[18:30] <kgunn> bkchr: hey
[18:30] <kgunn> bkchr: what exactly did you compile ?
[18:31] <kgunn> like a different branch ?
[18:32] <kgunn> or did you compile the src associate with the image you're using ?
[18:32] <bkchr> ahh I see if taken the compile for pc tutorial :(
[18:33] <bkchr> No, I switched the image to a newer one
[18:33] <bkchr> To one from yesterday
[18:33] <bkchr> I used this guide http://unity.ubuntu.com/mir/building_source_for_pc.html
[18:33] <kgunn> bkchr: ah...inclding the bzr branch lp:mir bit ?
[18:33] <kgunn> so that's actually our devel....
[18:34] <kgunn> instead, what you might want to do is either use lp:mir/0.15 (cause that's what's in the current image)
[18:34] <kgunn> rc-proposed that is
[18:34] <bkchr> Running mir_demo_server I got the following http://pastebin.com/amEReypq
[18:34] <kgunn> (stable would be lp:mir/0.14)
[18:35] <kgunn> otherwise you could grab the src from the appropriate ppa
[18:35] <kgunn> rc-proposed uses
[18:36] <anpok> bkchr: runnig as root?
[18:36] <bkchr> You think that switching the source would help me? :D Do
[18:36] <bkchr> Yeah it's running as root
[18:36] <kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5379893/+listing-archive-extra
[18:37] <kgunn> you'd need to download
[18:37] <kgunn> mir_0.15.1+15.04.20150903-0ubuntu1.diff.gz (52.8 KiB)
[18:37] <kgunn> mir_0.15.1+15.04.20150903-0ubuntu1.dsc (4.4 KiB)
[18:37] <kgunn> mir_0.15.1+15.04.20150903.orig.tar.gz (1.6 MiB)
[18:37] <anpok> bkchr: which device?
[18:37] <kgunn> and build it from that
[18:37] <kgunn> or if you're on stable
[18:37] <kgunn> you'd get it from stable-snapshot
[18:38] <anpok> kgunn: hm looks like hwc problem.. or broken implementation hwc set returning -1.. if that happens with lp:mir i would assume it might also happen with 0.15
[18:38] <kgunn> ah
[18:39] <anpok> at least that part hasent seen a lot of changes since 0.14
[18:39] <bkchr> anpok: oneplus one
[18:39] <kgunn> anpok: but i think bkchr is sstill mixing and matching mir's there...and gonna leat to other probs with needing to rebuild qtmir/u-s-c etc
[18:39] <anpok> yes
[18:40] <anpok> bkchr: here it would be interesting what parameters are passed to hwc prepare and hwc set .. because it is odd that prepare went fine and set fails..
[18:40] <anpok> i guess kdub and AlbertA would be the best candidates for remote debugging
[18:44] <kgunn> and actually, kdub might know how to just do a trick to skip hwc
[18:44] <kgunn> and rely on gles alone
[18:45] <kdub> nah, we always go through hwc these days
[18:45] <kdub> unless bkchr's phone is really really old
[18:45] <kdub> although, if you want to try a deprecated backup, move hwcomposer.*.so out of /system/lib/hw so mir can't find it, maybe the fb module will work
[18:51] <bkchr> kgunn, so I should use either the 0.15 branch or the packages you proposed?
[18:53] <kgunn> bkchr: are you on an image which is from rc-proposed ? or stable ?
[18:54] <kgunn> bkchr: do system-image-cli -i
[18:54] <bkchr> rc-proposed
[18:54] <kgunn> ah nice
[18:54] <kgunn> yeah lp:mir/0.15 will do it
[18:54] <kgunn> same instructions for building otherwise
[18:54] <bkchr> k
[18:55] <bkchr> it's building
[18:55] <kgunn> bkchr: sorry for confusion, i swear we're not trying to be difficult on purpose, that's all on accident ;-P
[18:58] <bkchr> no problem^^ It already was a mess to get everything working so far.
[19:18] <kgunn> i bet
[19:57] <mhall119> camako: is it possible to use mirscreencast to get a screenshow of mir_demo_server?
[19:58] <camako> mhall119, yes
[19:59] <mhall119> I can't seem to get it to work
[19:59] <mhall119> [1442605661.898312] <ERROR> MirBufferStreamAPI: Caught exception at client library boundary (in mir_buffer_stream_get_graphics_region): /build/mir-Xfl1I9/mir-0.15.1+15.04.20150903/src/platforms/mesa/client/client_buffer.cpp(63): Throw in function {anonymous}::ShmMemoryRegion::ShmMemoryRegion(const std::shared_ptr<mir::client::mesa::BufferFileOps>&, int, const mir::geometry::Size&, mir::geometry::Stride, MirPixelFormat)
[19:59] <mhall119> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
[19:59] <mhall119> std::exception::what: Failed to mmap buffer
[19:59] <mhall119> 13, "Permission denied"
[20:00] <mhall119> or sometimes just "Failed to create screencast" with no other output
[20:00] <bschaefer> mhall119, you need to make sure you are using software buffer
[20:00] <bschaefer> when you create the surface
[20:00] <mhall119> how do I do that?
[20:00] <bschaefer> o thats screencast?
[20:00] <bschaefer> mhall119, are you writing a mir client atm? or just using screencast?
[20:00] <mhall119> bschaefer: it's mirscreencast with -n1
[20:00] <bschaefer> IIRC screencast was broken...
[20:01] <bschaefer> but *should* have been fixed
[20:01] <mhall119> just trying to take a picture of what it's doing
[20:01] <bschaefer> but i dont remember what version fixed it :(
[20:01] <bschaefer> yeah
[20:01] <mhall119> bschaefer: I'mstill on vivid, maybe it's fixed in wily
[20:01] <bschaefer> yeah i think duflu fixed in in 0.15 (i think?)
[20:03] <mhall119> yet another reason to upgrade I guess