[05:16] <RAOF> You know what I *really* want to do while dog tired? Start writing an X window manager.
[05:16] <RAOF> That'll be awesome.
[07:04] <RAOF> duflu: Oh, is client initiated window resize implemented?
[07:04] <duflu> RAOF: No. That depended on the attribute thing, which half the team disliked
[07:05] <RAOF> Ah, ok. So worrying about how to handle resize in xmir-rootless is somewhat premature :)
[07:15] <duflu> RAOF: There's still time. Technically we haven't released 0.1.3 which is the first release with MirResizeEvent
[07:16] <RAOF> Well, it doesn't particularly matter to me if it's not available in 0.1.3
[07:51] <duflu> RAOF: I mean I told Gerry the resize event design might change in 0.1.3/0.1.4. And having not released 0.1.3 yet we have lots of freedom still
[07:52] <RAOF> Ah, cool.
[07:52] <RAOF> Well, I don't particularly care about the events as such; I can pull that data from the buffer.
[07:52] <RAOF> I care about the ability to resize from the client, though.
[07:55] <anpok_> is that something the shell still could deny?
[07:59] <RAOF> Yes
[08:04] <duflu> ... in theory. Not implemented yet because nothing beyond the shell /can/ resize surfaces yet :)
[08:04] <duflu> It's just a virtual function the shell could override I think
[08:04] <RAOF> Well, ye.
[08:21] <duflu> Hmm, didn't expect that. I just noticed clients only get input events iff the gesture started inside the client surface
[08:22] <duflu> I guess that's correct
[08:23] <duflu> Hmm, and only if it starts inside the client's creation size. That's wrong.
[09:56] <duflu> alf_: Shall I merge the fix manually?
[09:57] <alf_> duflu: I was about to do it (almost done)
[09:57] <duflu> alf_: OK, thanks. I shall vanish then
[09:57] <alf_> duflu: Enjoy!
[10:07] <alan_g> alf_: does that resolve the remaining CI issues?
[10:08] <alf_> alan_g: duflu's fix?
[10:09] <alan_g> alf_: I'm still catching up - it looked as though it was related to your fix failing
[10:11] <alf_> alan_g: No, duflu's MP updates our cross compilation tools for a change in upstream packaging
[10:13] <alan_g> alf_: OK, I'd noticed that you MP had failed for "E: Couldn't find these debs: android-platform-headers" and wondered if we were nearly there yet.
[10:13] <alan_g> *your
[10:25] <ogra_> alan_g, alf_, the package was renamed (upstream) to "android-headers"
[10:25] <ogra_> (update your build deps)
[10:26] <alan_g> ogra_: ogra_ that's what alf_ is merging (above)
[10:27] <ogra_> oh
[10:28] <alf_> ogra_: alan_g: Actually the fix was to remove the dependency completely from our cross tools, since it turned out we didn't actually need it
[10:29] <alan_g> alf_: Yeah, that's the best sort of "update". ;)
[10:29] <ogra_> :)
[10:32] <alf_> alan_g: @test-framework-wait-for-server-startup, it resolves some of our CI problems (and improves our pass rate), but it seems there are still other issues not addressed by the MP. I would like to get this MP merged (even manually if needed), so that when we get failure we at least know it's some other problem
[10:33] <alan_g> alf_: I'm happy with that approach. (I guess you want me to change my vote?)
[10:34] <alf_> alan_g: Only if you are happy with the handling of the shutdown tests
[10:35] <alan_g> alf_: that's what I'm looking at. ;)
[10:39] <alf_> alan_g: http://paste.ubuntu.com/6588244/ is a minimal example to exercise the valgrind behavior which was worked around in the last commit
[10:44] <alf_> alan_g: wait_for_server_process_to_finish() ?
[10:46] <alan_g> alf_: terminate_server_and_wait_for_shutdown()?
[10:48] <alf_> alan_g: so, shutdown_server_process => terminate_server_and_wait_for_shutdown , wait_for_shutdown_server_process => wait_for_server_shutdown ?
[10:50] <alf_> alan_g: anyway, as you said, this is for later...
[10:50] <alan_g> alf_: I can't think of anything better. But I don't quite feel convinced. :(
[10:55] <tvoss> greyback, ping
[10:55] <greyback> tvoss: pong
[11:13] <xnox> hello again.
[11:13] <xnox> what's equivalent to figuring out screen size / resolution under mir?
[11:14] <xnox> are there mir API docs?
[11:23] <RAOF> xnox: There are; http://unity.ubuntu.com/mir/
[11:24] <xnox> RAOF: excellent. and are there any command-line utility that exposes/prints MirDisplayInfo width & height?
[11:24] <RAOF> xnox: http://unity.ubuntu.com/mir/mir__client__library_8h.html is the client API
[11:25] <RAOF> xnox: mir_demo_client_display_config is a demo client that'll do that.
[11:27] <alan_g> alf_: @http://paste.ubuntu.com/6588244/ - the lack of a join() is likely a licence for inconsistent behaviour.
[11:39] <nic-doffay> Hey everyone, I'm looking to get an FPS count from mir, can anyone give me any tips?
[11:45] <alan_g> nic-doffay: some of the demo apps outout an fps count to the console. Is that what you need?
[11:51] <nic-doffay> alan_g, I'd like to output the frames somewhere in unity8.
[11:58] <alan_g> nic-doffay: I'm not sure where unity8 calls mir_surface_swap_buffers() (I assume it is in platform-api) - but those are the calls you'd need to count.
[11:59] <anpok_> and then maybe extrapolating the frame delay would be also of interest
[12:04] <nic-doffay> alan_g, should I just grep that call?
[12:12] <alan_g> nic-doffay: I guess you could also detect the unity8 client server-side and intercept the calls there. C.f. http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/surfacefactory.cpp (although that just identifies the unity8 surface, it doesn't intercept the call you want to count)
[12:13] <nic-doffay> alan_g, I'll the first approach I think.
[12:14] <alf_> alan_g: sure in a normal situation, but it shouldn't matter in the case since the process aborts (join() wouldn't be called anyway in this scenario)
[12:19] <alan_g> alf_: rephrasing: I'm not sure how well the C++ memory model copes with posix signals - there could well be dragons around here.
[12:19] <alf_> alan_g: ok
[12:22] <nic-doffay> greyback, ^
[12:28] <nic-doffay> Saviq, is qt client FPS enough for our purposes?
[12:29] <Saviq> nic-doffay, probably, yeah
[12:36] <nic-doffay> Saviq, could this just be done from Qt?
[12:36] <Saviq> nic-doffay, yeah of course
[12:36] <Saviq> nic-doffay, only place it can be done, really, if we want it cross-display-server
[12:37] <nic-doffay> Saviq, I mean look for something in the scenegraph. I was pointed towards QML_RENDERER_TIMING
[12:37] <Saviq> nic-doffay, yes
[12:51] <xnox> So i've pushed mir_demo_client_display_config to the phone, yet all it says "Can't get connection" whilst unity8 is running.
[12:51] <xnox> how can I get display size from the running unity8/mir ?
[12:59] <anpok_> xnox: how do you start it?
[12:59] <alf_> xnox: You need to connect to the server that unity8 connects to (or to the system compositor)
[13:00] <xnox> anpok_: ./mir_demo_client_display_config from adb shell.
[13:00] <xnox> alf_: how do I do that?
[13:01] <xnox> hm, is mir socket a well-known value?
[13:01] <alf_> xnox: you can pass -f
[13:02] <kgunn> xnox: also...can you retarget your mp from lp:mir to lp:mir/devel ?
[13:03] <xnox> kgunn: why is lp:mir the default merge proposal target then on the lp-project?
[13:03] <xnox> kgunn: how would I know that you are using custom series for development....?
[13:03] <xnox> kgunn: shouldn't there instead be stable series and lp:mir the devel one?
[13:06] <alf_> xnox: @mir socket, are you running as root?
[13:06] <alf_> xnox: if os try as phablet
[13:06] <xnox> kgunn: I followed http://unity.ubuntu.com/mir/md__h_a_c_k_i_n_g.html
[13:06] <xnox> alf_: fails with both phablet & sudo user. let me try -f
[13:07] <alf_> xnox: -f requires the path
[13:07] <xnox> ..
[13:07] <alf_> xnox: try /var/run/user/[userid]/mir_socket
[13:09] <xnox> i am running android emulator, and i want to find out the current screen resolution & DPI.
[13:09] <xnox> /var/run is  a symlink to /run/ ;-)
[13:11] <xnox> using mir_socket as root or as phablet user still gives me Can't get connection.
[13:12] <alf_> xnox: I don't know if you need special permissions (e.g. given by starting to upstart) to be able to connect to unity8
[13:13] <alf_> xnox: ...given by starting through upstart...
[13:13] <xnox> ... i have root & have apparmor disabled.
[13:13] <xnox> is only one client at the time supported?
[13:14] <alf_> xnox: not that I know of
[13:14] <xnox> alf_: I installed fbset and it gets the the framebuffer resolution and i'm happy with that for now =)
[13:15] <alf_> xnox: ok
[13:15] <xnox> alf_: but i would want to get the screen size & dpi from mir/unity, such that i know what mir/unity8 thinks it is.
[13:15] <xnox> either by connecting to unity8's mir_socket or somehow talking to unity8 asking it to export that information.
[13:16] <xnox> e.g. in the unity8 logs I see "creating surface at (0, 0) with size (480, 800) with title 'Qml Phone Shell'"
[13:16] <greyback> xnox: client will be denied connection unless it called with "--desktop_file_hint=dialer-app"
[13:16] <xnox> but i really do not want to get that via API of a sorts, instead of parsing logs which might not be there.
[13:18] <xnox> greyback: (a) that's a .desktop file lauching hack of the qmlscene apps (b) i'm launching mir_demo_client_display_config from command-line (c) i'm not use upstart-app-launch (d) mir_demo_client_display_config obviously does not have such a flag
[13:18] <xnox> greyback: so how do I hint / get the connection to the running instance of unity8/mir?
[13:18] <greyback> xnox: for (a) it's for /any/ app that connects to mir/unity8, not just qmlscene apps
[13:19] <xnox> hm, ok.
[13:19] <xnox> greyback: i don't actually want to run anything =/ only print / retrieve resolution & dpi. Maybe mir_demo_client_display_config is too much for that task?
[13:19] <greyback> xnox: flag is not actually for the client application, it should be ignored by the client. unity8 is the thing that cares about that flag
[13:20] <greyback> xnox: unity8 does have a basic dbus interface to get screen size right now (not dpi though)
[13:21] <xnox> greyback: ah, that's better =) let me check it out.
[13:21] <greyback> xnox: check out com.canonical.Unity.Screen
[13:21] <xnox> greyback: excellent!
[13:21] <xnox> greyback: thanks a lot =)
[13:22] <greyback> xnox: oh no, it was actually removed
[13:22] <greyback> xnox: it could be restored. Why do you need it?
[13:24] <xnox> greyback: at the moment autopilot hard-codes the screen resolution based on device codenames, emulator can run with any resolution / dpi therefore we actually need to query it at runtime to figure out the right resolution/dpi and it must match what mir/unity8 will think it is.
[13:24] <xnox> greyback: i'm actually not sure if unity8/mir is running when autopilot starts up, if it doesn't we can surely start mir/unity8 just to query that.
[13:25] <xnox> greyback: here is the current "resolution" detection http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/display/_upa.py
[13:26] <alf_> kgunn: alan_g|lunch: the latest errors at https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/100/console , especially the failure of Process.a_successful_exit_function_succeeds, looks very suspicious. It makes me think that there is a problem (race?) in our test process handling code...
[13:26] <xnox> greyback: autopilot simulates the touch events based on resolution hence it needs to know the geometry.
[13:26] <alf_> kgunn: alan_g|lunch: that is causing all the remaining issues we are seeing
[13:26] <greyback> xnox: gotcha. What solution would you prefer? dbus interface? Or a simple Mir client that can read the display info itself?
[13:30] <xnox> greyback: not sure. i think a simple mir client would be useful beyond just autopilot, and easy enough to itegrate.
[13:30] <xnox> greyback: i'll ping thoami to see if he'll prefer a dbus api as well / in addition / or just that.
[13:31] <greyback> xnox: ok
[13:31] <xnox> greyback: e.g. at the moment autopilot cannot change the resolution at runtime, but clearly unity8/mir can and so can the android emulator.
[13:32] <xnox> greyback: in the perfect world that mir client would query running instance if there is one, otherwise start-dummy-mir and query that and exit/clean-up. such that one can query "current or the probably would be" resolution.
[13:33] <greyback> alf_ any ideas on how that could be done?
[13:37] <alf_> greyback: xnox: mir clients/servers don't have any knowledge of existing servers, that should be handled externally in a script tailored for the specific scenario (e.g., check if unity8 is running and connect a client to its socket, otherwise start a mini server)
[13:38] <xnox> alf_: that should be ok. so it's just the mir client that needs to connect to an  existing server and query info from it.
[13:41] <kgunn> xnox: fair....i'll followup to change that
[14:24] <alan_g> alf_: It is possible. I remember we had some problems in the shutdown code that I never really dug into.
[17:54] <racarr> bregma: https://code.launchpad.net/~robertcarr/mir/nested-internal-egl-on-mesa-with-caveat/+merge/199329
[17:54] <racarr> this should work for you with no multimonitor
[17:54] <racarr> if you have a second monitor you probably needtoliterally unplug it
[17:55] <bregma> racarr, sweet, multimonitor is not (yet) a requirement
[17:55] <racarr> it shouldbe fixed sooner than later anyway just some sort of bug
[17:56] <bregma> I'll play with it today, when my test rig gets freed up again
[17:56] <racarr> I haven't tested unity8/usc yet...
[17:56] <racarr> ok great!lemme know
[17:56] <racarr> all the appropriate demos work now so it should work but I reinstalled my machine and don't feel like rebuilding the entire unity8stack at this exaaaaccct
[17:57] <racarr> moment
[17:57] <racarr> but will soon haha
[19:43] <bregma> racarr, that seemed to do the trick: now U8 crashes trying to connect to the phone sensors (because the desktop is not a phone and does not have sensors) ... which means your fix worked, all you need to do is get it committed
[19:45] <bregma> now the question is, can Mir be tuned so it doesn't try to connect to the Android accelerometer when it's not running on an Android kernel, or at least not crash?
[19:47] <bregma> at least this problem is not in Mir itself, so not your problem
[20:15] <racarr> bregma: problem is in platform APII guess
[20:15] <racarr> need stub sensors build on desktop?
[20:41] <bregma> racarr, my current problem is in libqubuntumirserver.so, there are a lot of confusingly named libraries involved, I think every combination of 'ubuntu' 'mir' and 'server' is used by every project involved in the Unity8 stack
[20:51] <racarr> bregma: That'sbecause that's the qt platform integration plugin
[20:51] <bregma> yep
[20:51] <racarr> there is qtubuntumirserver (for unity8) and qubuntumirclient/qubuntusurfaceflinger (just called qubuntu)
[20:51] <racarr> but they get sensors from platform API
[20:51] <racarr> so it should be fixed at that level,
[21:37] <tvoss> bregma, can you file a bug against the platform api to fallback gracefully if sensors are not available?
[21:38] <bregma> tvoss, should it be the platform_api or the qtubuntu_sensors that falls back gracefully?
[21:38] <tvoss> bregma, hmmm, I think it really should be platform api
[21:39] <bregma> OK, I'll file the bug against it
[22:06] <tvoss> bregma, thanks