[00:13] <robert_ancell> bschaefer, you can confirm it works for you?
[00:13] <robert_ancell> i.e. get into XMir?
[00:31] <bschaefer> robert_ancell, yeah
[00:32] <bschaefer> robert_ancell, i had the cursor, and the process was up and running
[00:34] <robert_ancell> bschaefer, awesome, thanks
[00:34] <bschaefer> robert_ancell, np :)
[00:47] <jono_> thanks RAOF
[00:50] <RAOF> ARGH!
[00:50] <thomi> robert_ancell: I believe marking ubuntu-desktop as required would do what you want, but would likely be viewed rather poorly by some people :)
[00:50] <RAOF> I was sure I fixed the signals-plus-threads-equal-pain problem before.
[01:02] <mterry> Pressing alt+left reliably makes my desktop mir session freeze (alt+f1 fixes though)
[01:10] <mterry> Not sure if that's bug 1102756 or something else
[01:11] <mterry> racarr, heyo!  So I looked at the surface builder override example you provided, thanks.  It keys off params.name, but I'm not certain where that gets set originally.  Is that something that any client can set, or is that controlled by other parts of the system compositor?
[01:12] <racarr> mterry: It gets set by the client, though once the shell (and the system compositor too) implement the session authorizer
[01:12] <racarr> it can be trusted.
[01:12] <racarr> the key off param.name is a bit of a hack. we should have a better way to
[01:12] <racarr> sort o tag it...
[01:14] <mterry> racarr, sorry, I'm a bit confused.  You say it can be set by the client, and it can be trusted, but there's an unwritten authorizer in between that lets us actually trust it?
[01:14] <mterry> racarr, so both sessions and surfaces have names, it seems
[01:14]  * mterry is still getting used to how Mir works
[01:57] <RAOF> mterry: Yup, that's bug 1102756 - what's happening is the kernel is interpreting <alt>+<left> as a VT switch.
[01:59] <racarr> mterry: Well right now it is set by the client but hte basic path is
[01:59] <racarr> the shell starts the clients (say through upstart and gets hey I just launched 'application-id' (i.e. session->name()) as PID pid
[02:00] <racarr> then when the client tries to connect the shell will be told hey
[02:00] <racarr> thi PID is connecting is that ok
[02:00] <racarr> perhaps surface name should be title
[02:00] <racarr> and session name should be application-id
[02:03] <RAOF> racarr: Did we ever work out how that is meant to interact with fork()
[02:03] <RAOF> ?
[02:11] <duflu> fork is such a great idea, and a bad one. Bad because there's often a little slice of time between fork() and exec() and you can have state/global objects as well as threads go nuts in that time.
[02:12] <duflu> -state +static
[02:28] <racarr> RAOF: Perhaps it's not
[02:28] <racarr> Is forking and opening new mir connections something clients are allowed to do?
[02:28] <racarr> I'm not sure
[02:28] <racarr> not on the phone or the system compositor
[02:28] <racarr> perhaps for the desktop we will need
[02:29] <racarr> a more complex mechanism
[02:29] <racarr> i.e. DBus API in the shell
[02:42] <RAOF> racarr: An “application” being a shell script that sets some environment and then calls the real binary is a very common idiom; not all of those are going to exec.
[02:43]  * RAOF heads to lunch.
[02:47] <duflu> racarr: I can't think of a sensible use case for us to worry about forking clients yet...
[03:52] <duflu> That's odd. I don't remember doing updates but EGL Mir clients are broken again
[03:52]  * duflu updates again
[03:59] <duflu> RAOF: Ping (hopefully I won't drop out like yesterday)
[04:00] <RAOF> :)
[04:00] <RAOF> duflu: Pong.
[04:01] <duflu> RAOF: drmModePageFlip ... appears to require the DRM FB ID to remain valid and the buffer unchanged for the duration of the following frame. Is this confirmed in docs anywhere?
[04:01] <RAOF> Hah!
[04:01] <RAOF> Docs?
[04:01] <RAOF> Hah!
[04:02] <duflu> Confirmed in folklore even?
[04:03] <duflu> RAOF: Because if I don't keep the DRM FB alive and untouched for the duration of the frame I get tearing. So I assume I have to hold it.
[04:03] <duflu> But holding it creates a world of deadlock pain I'm working through
[04:06] <RAOF> duflu: My expectation would be that the fb id you send to drmModePageFlip will need to be unchanged between the call to drmMode and the page flip event for the *next* fb you page flip.
[04:07] <duflu> RAOF: Yes, that agrees with my findings
[04:08] <RAOF> You *should* be able to do any form of bookkeeping you want on it, though; unreffing it should work.
[04:08] <duflu> It also confirms the buffer really is scanout. And any premature unsynced changes will give me tearing
[04:08] <RAOF> Oh, yes.
[04:08] <RAOF> That's rather the point, isn't it?
[04:08] <duflu> Yup
[04:33] <kgunn> bschaefer: just to double check...did you try the ppa from a "purged state" ?
[04:35] <bschaefer> kgunn, hmm no, I just had a broken system, ie. my intel driver was failing to load due, and I was running unity in software mode
[04:35] <bschaefer> did an upgrade and then the intel driver was being loaded correctly, and xmir and x11 started working correctly
[04:37] <bschaefer> kgunn, would you like me to try purge my ppa and test it out?
[04:37] <bschaefer> purging*
[04:37] <kgunn> so just because i'm crazy i purged first....took system back to "default"....and now, i'm hitting "broken" packages....lightdm not updated, due to u-s-c, due to libmirserver
[04:38] <kgunn> bschaefer: hey thanks...good to get a second data point
[04:38] <bschaefer> kgunn, yup, hmm it could be that libmirserver was updated in the ppa recently
[04:38]  * bschaefer goes to check
[04:39] <bschaefer> kgunn, do you also have the mir staging ppa?
[04:41] <kgunn> bschaefer: nope
[04:42] <kgunn> ...but double checking for stupid mistakes
[04:42] <bschaefer> hmm strange, have you also pined the unity system compositors ppa?
[04:43]  * bschaefer was unaware of this until yesterday
[04:43] <bschaefer> from : http://www.olli-ries.com/running-mir/
[04:43] <kgunn> bschaefer: oh yes...altho, when i purged...i unpinned & removed the deb ref to -testing
[04:44] <kgunn> rebooted into x no prob etc
[04:45] <kgunn> but yes...i repinned just now
[04:45] <bschaefer> kgunn, so you have a working lightdm still, and mir isn't working?
[04:45] <bschaefer> or is it uninstalled?
[04:45] <bschaefer> yeah, re-pinning should help downgrade your packages :)
[04:46] <kgunn> ligthdm yep & yep.....installed
[04:46] <kgunn> checking all my versions now against -testing
[04:47] <bschaefer> cool, cause usually when I ran into broken packages it would uninstall my lightdm :(
[04:47] <bschaefer> so xmir *should* be working hmm
[04:48] <RAOF> As far as I can tell u-s-c in -testing *should* be installable from testing.
[04:50] <kgunn> well...it seems that all the versions look ok, except lightdm is one behind
[04:51] <bschaefer> what is your apt-cache policy on it?
[04:51] <bschaefer> I've got:   Installed: 1.7.5bzr1634saucy0
[04:51] <bschaefer> from: 1002 http://ppa.launchpad.net/mir-team/system-compositor-testing/ubuntu/ saucy/main i386 Packages
[04:54] <kgunn> bschaefer: what the command there "sudo apt-cache <what> -p lightdm" ?
[04:54] <bschaefer> kgunn, "apt-cache policy lightdm" should do it
[04:54] <bschaefer> no need for sudo :)
[04:54] <kgunn> bschaefer: ta
[04:54] <bschaefer> np!
[04:55] <kgunn> right...Installed: 1.7.4-0ubuntu1
[04:55] <bschaefer> strange! hmm have you missed an update?
[04:55] <kgunn> candidate is 1.7.5....however if i attempt to install...it complains
[04:56] <kgunn> about unmet deps on u-s-c
[04:56] <kgunn> which in turn complains about libmirserver0
[04:57] <bschaefer> mind pasting the error :)
[04:57] <RAOF> What version of mirserver0 is it complaining of?
[04:57] <RAOF> Because the version in -testing depends on = 0.0.6bzr832saucy0, which is the version in the PPA.
[04:58] <kgunn> Depends: libmirserver0 (= 0.0.6bzr831saucy0) but 0.0.6bzr832saucy0 is to be installed
[04:58] <RAOF> I suspect you may need to apt-get update?
[04:58] <RAOF> The deb that I downloaded from the PPA just now depends on 832
[04:58] <kgunn> i have a few times
[04:59] <kgunn> hmmm...might repurge and try again
[04:59] <RAOF> apt-cache policy ubuntu-system-compositor?
[05:01] <kgunn> none installed...but again, that's because of the whinging about libmirserver0
[05:01] <bschaefer> kgunn, unity-system-compositor
[05:01] <bschaefer> hmm strange still
[05:02] <kgunn> bschaefer: yeah ;) i corrected it...i knew
[05:02] <bschaefer> kgunn, what is the versions Candidate?
[05:02] <bschaefer> for u-s-c?
[05:03] <bschaefer>   Candidate: 0.0.1bzr33saucy0.144 should be yours?
[05:04] <kgunn> one moment...got impatient, repurged, trying again....
[05:04] <bschaefer> cause your libmirserver0 is the correct version, but for some reason u-s-c wants a lower version?
[05:04] <bschaefer> :), good luck!
[05:06] <kgunn> ...i think it worked...rebooting
[05:09] <kgunn> bschaefer: RAOF ...hooray! never so happy to see my annoying friend "extra mouse cursor"
[05:09] <bschaefer> kgunn, awesome :)
[05:10] <RAOF> :)
[05:10] <kgunn> not sure what happened...i'm sure it was due to my futzing around earlier today
[05:10] <duflu> kgunn: It's a /watermark/ to tell you Mir is working ;)
[05:11] <kgunn> duflu: yes....serious investment in that "feature"
[05:11] <tvoss_> good morning :)
[05:11] <kgunn> kind reminds me of bob the paperclip
[05:12] <duflu> Intentional or not, it's very useful
[05:12] <kgunn> tvoss_: ditto
[05:12] <duflu> tvoss_, Hi
[05:12] <tvoss_> guys, I need some help as lightdm from the ppa won't install its configuration file
[05:13] <robert_ancell> tvoss_, which config file?
[05:13] <tvoss_> robert_ancell, I don't see the 10-unity-system-compositor in /etc/lightdm/lightdm.conf.d
[05:13] <robert_ancell> tvoss_, did you delete it previously?
[05:14] <tvoss_> robert_ancell, might well be, yeah :)
[05:14] <robert_ancell> tvoss_, it's provided by unity-system-compositor and debian remembers if you delete stuff - see http://serverfault.com/questions/82801/linux-how-to-restore-config-file-using-apt-get-aptitude
[05:15] <robert_ancell> "debian remembers if you delete stuff in /etc"
[05:17] <robert_ancell> tvoss_, or failing that just make it yourself
[05:21] <RAOF> robert_ancell: Or dpkg --purge then reinstall.
[05:28] <kgunn> didrocks: morning
[05:28] <didrocks> hey kgunn! it's quite late for you, isn't it?
[05:29] <kgunn> didrocks:  or early...yes.
[05:29] <didrocks> :)
[05:37] <duflu> Rule of thumb: If you're talking to Australia then you probably should not be awake :)
[05:38] <duflu> Unless it's only early evening...
[05:38] <duflu> Or you're in Europe
[05:38] <duflu> Or you're in Asia
[05:38] <robert_ancell> RAOF, https://bugs.launchpad.net/mir/+bug/1195811 - this is because XMir doesn't limit frame rate from X clients right?
[05:39] <duflu> robert_ancell: It's a driver-specific bug (nouveau). I have not got around to doing manual testing on nouveau yet
[05:39] <duflu> nouveau has a long history of not vsync'ing
[05:39] <robert_ancell> duflu, but I believe no X client in XMir vsyncs right?
[05:40] <RAOF> robert_ancell: Yeah, what duflu said. You're correct that XMir doesn't do vsync yet, but that bug appears to be about native Mir clients, which *should* vsync
[05:40] <duflu> robert_ancell: Yes compiz enforces vsync for everything on the screen, except when it's full screen and bypassed
[05:41] <duflu> Umm, that's a misleading statement I made. The point is that our custom GL for nouveau is failing to vsync in clients even when it should
[05:43] <duflu> I have two nvidia cards. I guess I should install one to keep the room warm during winter
[05:50] <RAOF> I should get my netbook bootable again so I can use it's BLAZING FAST geforce 9300
[05:51] <duflu> You mean blazing (hot) ?
[05:51]  * duflu wonders how Mir would go on the old N270 netbook
[05:53] <RAOF> Hm. Trunk doesn't build for me?
[05:56] <kgunn> didrocks: did i understand right that we were going to leave our version of gmock in mir tree ? just want to make sure this is the plan (to get into universe)
[05:56] <didrocks> kgunn: hum, no, I mean we can leave it unresolved for daily release into a ppa
[05:56] <didrocks> not for universe
[05:57] <kgunn> didrocks: so what's the mandate ?  as i understand it, we actually use features in the latest gmock...not available via the version used in ubuntu today
[05:57] <didrocks> kgunn: knowing that I spent a day making most of the stuff, the only remaining one for making the gmock transition is nux to be adapted
[05:57] <didrocks> kgunn: well, I spent an extensible amount of time updating to latest gmock
[05:57] <didrocks> and updating all components (mir included) to use that distro version
[05:57] <didrocks> the only remaining piece is nux
[05:58] <robert_ancell> kgunn, RAOF, duflu, racarr, kdub_, meeting
[05:58] <kgunn> didrocks: ah....thanks...its clear now
[05:58] <didrocks> kgunn: bregma was asked to do nux 2 days ago, not sure what's the status (he told me he would do it yesterday)
[05:58] <robert_ancell> thomi, too if your internet got solved :)
[05:58] <kgunn> didrocks: thanks...tvoss had his name there...but i'll pester bregma tomorrow
[06:01] <didrocks> kgunn: the most important one is the armhf tests failing (some needs to be separated in autopilot tests I guess)
[06:03] <kgunn> didrocks: again, i understand bregma is going to disable valgrind tests for arm
[06:03] <didrocks> kgunn: but they should be run as part of autopilot tests, right?
[06:04] <didrocks> so that we run them in the phone image
[06:04] <didrocks> with the actual hardware, and so on
[06:04] <kgunn> didrocks: right, i believe it was qemu failing...but mobile hw ok
[06:05] <didrocks> kgunn: can we ensure they are not just disabled but converted to AP tests? loosing possibly valuable tests isn't good for quality (nobody is running tests manually on the long term ;))
[06:05] <kgunn> didrocks: thanks for pointing that out...i'll followup with bregma
[06:06] <didrocks> yw!
[06:25] <RAOF> Huh. Mir lttng fails to build with -std=c99
[06:36] <dholbach> good morning
[07:24] <tvoss> RAOF, thanks for your answer :) I was thinking that we actually have less context switches for the shell when linking against libmirserver, right?
[07:24] <RAOF> tvoss: The shell has no context switches at all.
[07:24] <RAOF> As long as it's in-process.
[07:25] <tvoss> RAOF, yup, I will add that to the answer :)
[07:25] <RAOF> If it's not in-process, then, again, it's one context-switch per frame.
[07:28] <duflu> I'm pretty sure libmirserver has ~3 basic threads +N (number of clients up to the thread limit ~10), hence context switches a fair bit
[07:28] <duflu> So 4 threads with a single client
[07:28] <duflu> It would be really nice if the number of wakeups per second matched the frame rate, but that's not an immediate goal
[07:31] <tvoss> duflu, sure, but still: let's wait for hard numbers until we start optimizing that part
[07:31] <duflu> tvoss: Yeah I have no evidence that waking up hundreds of times per second like Mir does, is affecting frame rates yet
[07:31] <duflu> Only power consumption that's not ideal for sure
[07:32] <RAOF> Several years ago, several-year-old hardware managed 20,000 context switches/sec. We're not going to be dropping framerate :
[07:32] <tvoss> duflu, that reminds me: I need to log a bug about some build time flags that we introduced to satisfy the buildds
[07:32] <duflu> Yeah, it's just the modern day race to zero watts :)
[07:32] <RAOF> We do want to stop waking up to save power, though.
[08:13] <tvoss_> didrocks, ping
[08:15] <didrocks> tvoss_: pong
[08:15] <tvoss_> didrocks, good morning :) how goes?
[08:15] <didrocks> tvoss_: I'm fine, thanks! Ensuring that the temperature remains hot with building nux :p
[08:15] <didrocks> and you?
[08:16] <tvoss_> :D
[08:16] <tvoss_> didrocks, looking through the list of open bugs
[08:21] <didrocks> tvoss_: FYI, nux package doesn't build, there seems to be a PREFIX override
[08:21] <tvoss_> didrocks, *sigh*
[08:22] <didrocks> tvoss_: seems like people don't try to bzr bd :/
[08:22] <didrocks> (it's easy though :/)
[08:22] <tvoss_> didrocks, looking into disabling tests on powerpc now
[08:23] <didrocks> tvoss_: no need anymore
[08:23] <didrocks> tvoss_: I've disabled powerpc builds
[08:23] <tvoss_> didrocks, oh, do we have a branch?
[08:23] <tvoss_> didrocks, okay
[08:23] <didrocks> as per the discussion
[08:23] <tvoss_> didrocks, okay, mind closing the bug?
[08:23] <didrocks> tvoss_: doing so :)
[08:23] <tvoss_> didrocks, thx
[08:25] <tvoss_> RAOF, mind giving me a quick status on the system-compositor-testing ppa before you eod?
[08:47] <pete-woods> hey guys! So you publish your docs to http://unity.ubuntu.com/mir/
[08:47] <pete-woods> how can I do the same with my library?
[08:47] <tvoss_> pete-woods, talk to mhall119
[08:48] <pete-woods> tvoss_, cool, thanks!
[08:48] <tvoss_> pete-woods, yw
[08:48] <RAOF> tvoss_: As far as I'm aware, system-compositor-testing is ready to roll.
[08:49] <tvoss_> RAOF, ack, so nothing to be copied over right now?
[08:49] <tvoss_> RAOF, rolling fine on my machine :)
[08:49] <RAOF> Nothing particularly to be copied over, no.
[08:49] <tvoss_> RAOF, ack, thanks
[08:49] <RAOF> Xserver 1.14 is in there, with the xmir changes to not hate hybrid.
[08:49]  * tvoss_ wonders if putting that information in the channel title would make sense
[08:52] <alf__> hikiko: alan_g: Have time for a nested mir sync/chat?
[08:52] <pete-woods> tvoss_: are you guys in any kind of dialogue with vmware, parallels, etc to get them to think about Mir drivers for their virtualisation tech?
[08:52] <alan_g> alf__: hikiko 8 mins?
[08:52] <tvoss_> pete-woods, not yet
[08:53] <hikiko> hey
[08:53] <hikiko> sorry
[08:53] <pete-woods> okay, thanks for the info
[08:53] <hikiko> alan_g, alf__ sure can you wait for 5 mins?
[08:53] <hikiko> I have to go downstairs to collect something brb in 5mins alan_g alf__
[08:54] <alf__> alan_g: hikiko: sure, I will create the hangout, join when ready
[08:55] <alf__> alan_g: hikiko: https://plus.google.com/hangouts/_/1c0bb852740e0eb0560f57be1e1c793df9897a89?hl=en
[08:58] <hikiko> alan_g, alf__ back
[09:05] <tvoss_> RAOF, ping
[09:05] <RAOF> tvoss_: Pong.
[09:05] <RAOF> pete-woods: I've been in contact with a VMWare developer; all that's needed there is dma-buf support for their mesa driver. It's basiacally the free stack.
[09:07] <pete-woods> ROAF, that sounds pretty cool. It's a shame things like the Parallels stuff is more restrictively licensed. Although if 13.10 does have Mir on by default (or maybe even an option) I guess they will have lots of users nagging them to support it!
[09:53] <tvoss_> alan_g, ping
[09:53] <alan_g> tvoss_: ?
[10:08] <tvoss> RAOF, okay, not an issue with xfce
[10:32] <duflu> alf__: Can you point me to where in the server the client's choice of swapinterval is implemented?
[10:33] <alf__> duflu: src/server/compositor/switching_bundle.cpp
[10:34] <duflu> alf__, thanks
[10:34] <duflu> Oh, I forgot the terminology changes to "frame dropping"
[10:34] <duflu> Of course
[10:41] <alf__> duflu: the path on the server side is mf::SessionMediator::configure_surface() -> msh::Surface::configure() -> msh::Surface::allow_framedropping() and propagates down to the buffer_bundle
[10:42] <duflu> alf__: Yep thanks. I'm trying to figure out what I've done to make synchronous clients hang. Something is deadlocked
[10:42] <duflu> And I think it might be too late in the day to continue
[10:43] <duflu> alf__: I did notice this, but it doesn't seem related to my problem now... https://bugs.launchpad.net/mir/+bug/1199717
[10:43] <alf__> duflu: thanks, I will take a look
[11:14] <dandrader> Is mir going to get AppArmor support?
[11:14] <tvoss> dandrader, sure, you mean in terms of having a SecurityManager server-side?
[11:16] <dandrader> tvoss, in term of a call mir_surface_set_type(mySurface, mir_surface_type_inputmethod) failing (i.e., server reports back failure) if the client is not allowed to have an input method surface
[11:17] <tvoss> dandrader, yes, that's not there, yet, though
[11:18] <dandrader> tvoss, sure, but the plan is to have it implemented with AppArmor, right?
[11:20] <dandrader> (sounds like I'm repeating the same question with different words but I do like to have it made clear :) )
[11:25] <tvoss_> dandrader, might have lost some of your messages
 tvoss, sure, but the plan is to have it implemented with AppArmor, right?
 (sounds like I'm repeating the same question with different words but I do like to have it made clear :) )
[11:25] <dandrader> tvoss_, ^
[11:25] <tvoss_> dandrader, right our technology of choice is apparmor
[11:27] <dandrader> ok, thanks (because in the e-mail discussion I've suggested discretionary access control)
[11:28] <tvoss_> dandrader, I think we need mandatory access control, too
[11:30] <dandrader> yeah, that's more powerful
[12:32] <didrocks> bregma: give me a sign once you will win over the PREFIX override for nux :)
[12:33] <bregma> didrocks, I fixed that last night, MP should be OK now
[12:33] <didrocks> bregma: ah, you just didn't push it in the previous MP then?
[12:33] <didrocks> bregma: let me rebuild the package then
[12:34] <didrocks> bregma: thanks for taking the opportunity for -X.la btw ;)
[12:35] <bregma> well, what actually happened was I kicked off a local build to verify it and went to bed, then pushed the branch up to LP when I woke up, but MP should be good now
[12:35]  * didrocks builds, with ccache, should be quick now
[12:38] <didrocks> bregma: beautifully build!
[12:39] <didrocks> tvoss_: kgunn: ok, so pushing new google-mock snapshot to distro
[12:39] <didrocks> once published, switching all MP to approved
[12:39] <didrocks> thanks bregma for nux! :)
[12:40] <kgunn> bregma: didrocks \o/
[12:40] <didrocks> kgunn: already awake? really really short night :)
[12:40] <kgunn> didrocks: zzzzzz, huh?
[12:41] <kgunn> ;)
[12:41] <didrocks> heh
[12:45]  * bregma slurps yet another mug of coffee
[12:45] <didrocks> bregma: another? it's not your first? :-)
[12:46] <bregma> no chat or email until at least the second mug or I always regret it
[12:46] <didrocks> ahah
[12:50] <kgunn> bregma: .....a wise man
[13:46] <didrocks> tvoss_: can I get 2 quick acks for https://code.launchpad.net/~didrocks/libusermetrics/build-new-gmock/+merge/173945 and https://code.launchpad.net/~didrocks/mir/remove-local-google-mock/+merge/173946? (I didn't propose them for merging apparently previously)
[13:59] <mterry> greyback, where is the unity8 branch that uses mir?
[14:00] <mterry> greyback, oh, nm: lp:~unity-team/unity/unity8-integrate-mir/
[14:00] <greyback> mterry: yep that's it. Any luck with mir?
[14:01] <mterry> greyback, I haven't tried reflashing my nexus4 in a couple days.  But now I'm investigating how surfaces will get assigned names
[14:02] <greyback> mterry: ok. Look up ua_ui_window_properties_set_titlen
[14:03] <greyback> mterry: that's used in the qtubuntu plugin, which sets the surface name that shell will get
[14:03] <mterry> greyback, ah, OK
[14:03] <mterry> thanks
[14:03] <greyback> is in platform-api. yw
[14:15] <mterry> racarr, so in that surfacebuilder example you gave me yesterday, I assumed that "Window 1" was just some testing name.  But it seems that qtubuntu actually does use that title for all its windows.
[14:15] <mterry> racarr, is there an easy way to change that name on a per-window basis, so that I can actually treat the greeter window differently?
[14:39] <mterry> greyback, about mir+unity on nexus4, do you know if there's a bug about the black screen issue?
[14:41] <greyback> mterry: no I don't. You'd need to talk with ricmm about it, since I guess you're using his images
[14:42] <greyback> mterry: quick question: what version of "ubuntu-touch-session" is on the image you've installed?
[14:42] <mterry> greyback, hm, ok
[14:43] <mterry> greyback, 0.57 (though 0.56+mir2 is available and unused...  seems bad)
[14:43] <greyback> mterry: switch to the mir package and reboot
[14:43] <greyback> mterry: I think that's hte culprit
[14:45] <mterry> greyback, yup, that fixed it for me
[14:45] <greyback> I didn't realise it until last last night when I was slowly building a working stack of Mir+Platform-api+qtubuntu, that when I updated that package, the crash happend. That package seems to configure things inside the android chroot, maybe also the graphics
[14:45] <greyback> excellent!
[14:45] <greyback> ricmm_: ^^
[14:46] <ricmm_> greyback: mterry yup, setting up a recipe for that now
[14:48] <kgunn> alf__: ping
[14:48] <alf__> kgunn: pong
[14:55] <racarr> Morning
[14:58] <alan_g> Afternoon
[15:07] <tvoss_> alf__, ping
[15:07] <alf__> tvoss_: pong
[15:16] <didrocks> alf__: your patches for google-mock was for clang build?
[15:18] <alf__> didrocks: no, for g++ 4.7 (but it could be that clang needs them too)
[15:18] <alf__> didrocks: issues?
[15:19] <didrocks> alf__: yeah, with the google-mock version I pushed today in distro (so the snapshot without your patch), I see:
[15:20] <didrocks> alf__: http://paste.ubuntu.com/5861927/
[15:20] <didrocks> is that what your patch would prevent?
[15:20] <didrocks> alf__: this issue doesn't seem to appear with gcc
[15:21] <didrocks> (at least, it's at 72%, passed that point)
[15:21] <alf__> didrocks: that shouldn't be relevant to my patch
[15:22] <didrocks> alf__: let's wait for the gcc build to finish, but then, I think CI will reject it if it doesn't build with clang, right?
[15:22] <kdub_> right
[15:24] <didrocks> kdub_: I'm afraid I'll need help on that one then :)
[15:27] <kdub_> hopefully clang just goes through :)
[15:27] <didrocks> kdub_: I'm pushing the fix first to add the missing build-deps to setup-partial-armhf-chroot.sh (this script should really take build-deps from the packaging)
[15:29] <kdub_> didrocks, oh, thanks! that script was just kinda 'kevin's first way to get mir armhf running' that evolved into 'everyone use just this thing'
[15:29] <kdub_> probably needed a revamp
[15:30] <didrocks> kdub_: I'll give it a shot for grabbing the build-deps from the packaging. In exchange, let's hope someone can help on clang :p
[15:32] <kdub_> i can help get it going, but if its a large compilation failure requiring a fair amount of gtest fixes, don't know if i have the time to sort through it
[15:32] <didrocks> kdub_: it's working with the inline version, right? so it should be a patch you pushed to it that I need to put in the distro gmock, right?
[15:34] <kdub_> didrocks, might be, but I know there were other patches too, potentially
[15:40]  * didrocks loves it:
[15:40] <didrocks> dpkg-deb: building package `mir-build-deps' in `../mir-build-deps_1.0_amd64.deb'.
[15:40] <didrocks> Attention, the package has been created in the current directory,
[15:40] <didrocks> not in ".." as indicated by the message above!
[16:23] <didrocks> kdub_: hum, in your script, you even don't install the packages, just extract them in random dir?
[16:23] <didrocks>   add_subdirectory given source "/usr/src/gmock" which is not an existing
[16:23] <didrocks> is what I get
[16:23] <kdub_> didrocks, yeah, just enough to provide headers and linking
[16:24] <didrocks> kdub_: do you have a generic way of dealing with this hacked path then?
[16:24] <didrocks> in cmake?
[16:25] <kdub_> we use cmake's cross compilation system
[16:26] <didrocks> kdub_: hum, I will try something to point to the google-mock usr/ path
[16:26] <didrocks> but doesn't sounds sane TBH ;)
[16:33] <racarr> greyback_: Anything I can do to be helpful on application module?
[16:33] <racarr> kind of inbetween tasks
[16:33] <racarr> so have to pick something new up
[16:35] <greyback_> racarr: Hey, lp:~gerboland/+junk/qml-demo-shell/ - please open an app (using buttons at the bottom) and then try to interact with the app
[16:39] <racarr> greyback_: Is it a trap? :(
[16:39] <racarr> the way you phrase it makes it sound like a trap
[16:40] <racarr> buillding
[16:40] <greyback_> racarr: gah, foiled again!
[16:42] <racarr> segfault, probably
[16:42] <racarr> abi mismatch
[16:42] <racarr> on my machine
[16:42] <racarr> i.e. can't even start it
[16:42] <racarr> I think I need a mesa upgrade
[16:42] <racarr> will be a ew minutes
[16:44] <racarr> greyback_: I don't see any calls to set_input_region
[16:45] <racarr> so how would you be able to interact with an app?
[16:46] <greyback_> racarr: aha, that's what I was missing
[16:46] <greyback_> yes, stupid me
[16:46] <greyback_> how did I completely forget that??
[16:47] <racarr> forgetting is easy!
[16:47] <racarr> XD
[16:47] <racarr> how will that bit work?
[16:48] <racarr> I've been wondering about the least troublesome way to wire that up
[16:53] <greyback_> Yeah me too. I'd love to define InputRegions that shell should accept, and all other regions the input passes through
[16:53] <greyback_> I've idea how to do it, is next on the list
[16:54] <racarr> whee
[17:00] <greyback_> racarr: if you want to look at my app manager code, you're welcome to it. ATM I've #ifdef'd in Qt manually starting the processes, not upstart. I'm also not using the session authorizer still
[17:01] <greyback_> so please put those together and check everything works
[17:01] <greyback_> but right now, I'm away :) Talk later
[17:03] <racarr> greyback_: Excellent. Thanks
[17:03] <racarr> see you
[19:04] <kgunn> kdub_: did you read  Jim Haddops mail ? i'm wondering if he's highlighting a "new" requirement....e.g. if the intent is to get rid of surface flinger, then something would need to take care of
[19:05] <kgunn> binding the output video buffers as textures to the surfaces (for egl streaming)
[19:05] <kdub_> ah, haven't read yet
[19:05] <kgunn> so its most likely a backend to gstreamer (which ends up being a native mir client....like qmir)
[19:06] <kgunn> ah...i'll give you a chance
[19:07] <kgunn> btw....per session mode setting still more important than that discussion ;)
[22:01] <jo-erlend> there is a discussion going on at the Elementary OS mailing list following a chat with jono.. They seem to be under the impression that Canonical does not intend to create a GTK+ backend for Mir and unless the community does it, eventually you won't be able to run GTK apps in Ubuntu. Surely, this must be the result of some confusion?
[22:02] <jo-erlend> I know Ubuntu SDK does not support GTK+ and that's kinda reasonable from the arguments I've heard. But not making sure the display server supports one of the big toolkits around, seems almost unthinkable.
[22:05] <jo-erlend> These people have lots of listeners, so if it is indeed a misunderstanding, I hope it gets rectified asap.
[22:05] <jono> jo-erlend, I mentioned that I didn't know if we were creating a GTK backend, and that I would get back to them
[22:05] <jo-erlend> jono, they seem to have interpreted that as "extremely unlikely".
[22:06] <jono> jo-erlend, I will weigh in, I am on the list
[22:06] <jo-erlend> great. :)
[22:07] <jo-erlend> jono, but wasn't this talked about in the Mir interview? That things would be written, but that you couldn't be sure it'd be accepted upstream? Perhaps I misunderstood.
[22:07] <racarr> We've always said that we were creating a GTK  backend
[22:07] <racarr> but it's behind anything for the phone or the system compositor of course :)
[22:08] <jo-erlend> racarr, good to hear. It seemed very strange to me that anyone writing a display server would neglect GTK support.
[22:10] <racarr> robert_ancell: So the thing is, I think we need to move to a model where the Shell sets the 'Application-id' or session name
[22:10] <racarr> rather than relying on the client to provide it, and verifying
[22:10] <racarr> because if there are two clients starting up at the same time (say one trying to impersonate another), just PID isnt enough to verify
[22:11] <racarr> so instead of, say like bool SessionAuthorizer::is_allowed_to_connect(pid_t)
[22:11] <racarr> it's like std::string SessionIdentifier::identify_session(pid_t) throws-exception
[22:12] <racarr> or some such
[22:12] <racarr> and I just wanted to know how this affects the system compositor
[22:12] <racarr> i.e. is this easy to accomodate
[22:13] <robert_ancell> racarr, currently lightdm picks the IDs, then tells XMir to use a given ID, then lightdm tells u-s-c to switch sessions based on id
[22:13] <robert_ancell> racarr, potentially we could switch the id with a PID, but there's no current convention that the PID the display manager launches is the process that connect back (e.g. there are often shell scripts in between)
[22:13] <racarr> ok, so instead of lightdm telling xmir, it just needs to tell u-s-c
[22:14] <racarr> PID blabla is XMir
[22:14] <robert_ancell> but only if there's no forking
[22:14] <racarr> mm
[22:14] <robert_ancell> It feels like there must be something nicer we can use than just the pid of the process lightdm forked, something that will propogate down
[22:15] <robert_ancell> Perhaps some sort of cgroup thing
[22:16] <racarr> hmm
[22:16] <robert_ancell> racarr, note, these are logind sessions that are connecting to u-s-c, so they should be identifiable. That is a different case to applications within a session though where they are all in the same logind session
[22:16] <racarr> mm
[22:16] <robert_ancell> mmm
[22:16] <robert_ancell> bacon
[22:16] <racarr> its a different kind of case for u-s-c, the thing is its difficult
[22:16] <racarr> to let unity act as
[22:17] <robert_ancell> racarr, yeah. I'm treating the ID as a kind of secret at the moment, which is reasonably* secure
[22:17] <racarr> this "SessionIdentifier" and pick all the application-id's
[22:17] <racarr> without removing
[22:17] <racarr> client provided session names completely
[22:17] <robert_ancell> racarr, what does an application-id mean then>
[22:17] <robert_ancell> ?
[22:17] <robert_ancell> is this the .desktop association?
[22:18] <racarr> Yeah
[22:18] <robert_ancell> racarr, ok, if the client session names remain then that should be sufficient for u-s-c I think. We can just ignore the application-ids since they don't mean anything at the system compositor layer
[22:18] <racarr> oh well
[22:18] <racarr> I was thinking session->name basically becomes session->application_id
[22:18] <robert_ancell> and the client session names might become unnecessary if we can use logind
[22:18] <racarr> I dunno, it's tricky
[22:19] <robert_ancell> racarr, it can have a different meaning for unity-shell than in u-s-c right?
[22:19] <racarr> because session->name doesn't have any meaning for unity8 really
[22:19] <racarr> but application_id doesn't really have
[22:19] <racarr> any meaning for system compositor
[22:19] <racarr> yeah
[22:19] <racarr> at this point I am just thinking about names :)
[22:19] <robert_ancell> racarr, and unity-shell implements the application id assigner and u-s-c leaves it stubbed
[22:20] <racarr> ...the name or the name member
[22:20] <robert_ancell> or vice versa
[22:21] <racarr> Mm ok.
[22:21] <racarr> Ill take a crack at it in the next week or so, the current solution is sufficient for now (just the shell can only let one app be int he launching state at a time)
[22:21] <racarr> thanks :)
[22:21] <racarr> for...exactly now, I think I am going to the bakery.
[22:38] <kgunn_> bregma: wrt disabling the arm valgrind tests on qemu, are you going to also ensure they'll run via autopilot on real mobile hw ??
[22:38] <kgunn_> this was a didrocks query...and i wanted to make sure if you _weren't_ doing it...that we got you some help to do so
[22:39] <kgunn_> robert_ancell: ^ was this the integrated AP tests you were speaking about in the other testing thread....or were you thinking of other tests
[22:40] <robert_ancell> kgunn_, not sure what you're referring to
[22:40] <kgunn_> robert_ancell: the "what's keeping us from saucy" thread....with olli
[22:41] <robert_ancell> kgunn_, As I understand it these are unit-tests that are failing on build. So if there're disabled it wont affect autopilot
[22:42] <thomi> robert_ancell: could I get you to take a look at this MP please? https://code.launchpad.net/~thomir/mir/remove-close-fd-workaround/+merge/174071
[22:43] <kgunn_> robert_ancell: right...but didrocks was saying we should move those tests to ap for arm
[22:43] <kgunn_> ...i'll let you look at that mp
[22:43] <kgunn_> we can catch up later
[22:43] <thomi> robert_ancell: also, I'm still able to reproduce this bug: https://bugs.launchpad.net/mir/+bug/1195089 - I wonder if we could bump the priority of that bug?
[22:43] <robert_ancell> thomi, higher than critical?
[22:43] <thomi> ....
[22:43] <thomi> yeah :)
[22:43] <thomi> ok, so maybe bump the status
[22:44] <robert_ancell> thomi, that bug is driving me insane :)
[22:44] <robert_ancell> oh, I thought it should be in progress
[22:44] <thomi> Confirmed -> In Progress would be nice :)
[22:44]  * robert_ancell fixes
[22:44] <thomi> cool - I hadn't realised you were looking at it
[22:44] <robert_ancell> done and done
[22:44] <thomi> robert_ancell: anything I can do to help you fix it?
[22:44] <robert_ancell> thomi, find the problem? :)
[22:44] <thomi> heh
[22:45] <thomi> I'll fire up valgrind and see if I can get anything sensible from it
[22:45] <robert_ancell> I can reproduce it reliably, but really lost trying to find out where the problem is occurring
[22:45] <robert_ancell> the stack traces seem to change over time and they're not pinpointing the problem
[22:45] <thomi> hmmmm
[22:46] <thomi> is the stack constant to a certain point? I wonder if we're corrupting the stack somehow
[22:46] <robert_ancell> thomi, it definitely seems to be a threading issue when releasing the surface
[22:47] <racarr> robert_ancell: Oh I found and fixed one of those I think
[22:47] <kdub> racarr was talking about something like htat
[22:47] <kdub> right :)
[22:47] <racarr> in client-focus-notifications let me find it
[22:47] <robert_ancell> racarr, yeah, I've been seeing a number of fixes in that area, but none are fixing the problem for me :(
[22:47] <robert_ancell> racarr, is there a new fix on a branch somewhere?
[22:47] <racarr> robert_ancell: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440 at 253
[22:47] <racarr> and
[22:47] <racarr> 264
[22:47] <racarr> well
[22:47] <robert_ancell> racarr, ta, I'll try that
[22:48] <racarr> hmm I don't know if it can actually crash
[22:48] <racarr> it was a deadlock in my case
[22:57] <robert_ancell> RAOF, can you check https://code.launchpad.net/~robert-ancell/mir/mesa-xorg-docs/+merge/174073 for accuracy
[22:57] <robert_ancell> kgunn_, you might also be interested
[23:20] <robert_ancell> kgunn_, aha, I knew I'd missed something :)
[23:26] <RAOF> robert_ancell: Looks good, let me double check.
[23:26] <robert_ancell> kgunn_, can you re-review
[23:27] <RAOF> Heh, cool. Glyph cache corruption. It's been a while!
[23:28] <racarr> RAOF: http://en.wikipedia.org/wiki/Peak_experience
[23:28] <racarr> :p
[23:28] <racarr> I love glyph cache corruption
[23:29] <RAOF> robert_ancell: You've misspelt “--enable-xmir” in that doc; you've got “--with-xmir”, which doesn't work.
[23:30] <robert_ancell> RAOF, fixe
[23:30] <robert_ancell> d
[23:30] <RAOF> Să̜ͪ̃̀̀v̧̞̭͊͊ͦ̏ͭ͂ề̬̭̹̣ͣ̈́̓̚ ̫͕͔͔̰̬̐͛̈ͤͭ̽c̶̘̿͗͒ͤh̯̤äͥ̾̒͒͞n͉̗̆ͪ͟g̰̙̗͇̺̻̅e̩͖̫̤͌͢s͜ ͦ͏̲t̯̪̂͒o̬ ̶̃͆̀̑ͦͫX̰̙͚̉͐ͤ̾̄ͩ̀oͭ̿͝r̙̼̳̣̠̼ͪ͊̍̌́͋̊g̣.̥̯͍̤͗͒̈́͒̐ͧ0̛̝̫̰̮̝̝̮̍ͮͨ̍̎ͨ̎.̢̣̯̯̩ͯ̒͊͆͌́̚l͒ͦ̈́͂͡o̮͎̹͌ͤͪ̈̌̒g͇̺̞̯̰ͬ̓ͬ̌̏̆̊ͅ?̬̺̲ͮͭ̀ͮ
[23:32] <robert_ancell> !
[23:32] <robert_ancell> how many bytes is that string
[23:33] <robert_ancell> 395 :)
[23:43] <robert_ancell> kgunn_, woah, that's a lot of critical bugs :)
[23:47] <robert_ancell> RAOF, if you're happy with https://code.launchpad.net/~robert-ancell/mir/mesa-xorg-docs/+merge/174073, can you put your stamp on it? thanks
[23:47] <kgunn_> robert_ancell: yeah...critical means need to address for 13.10
[23:47] <robert_ancell> kgunn_, yep, I agree, just scary to see so much red
[23:55] <RAOF> robert_ancell: Doing a build of both xserver and mesa to check that those instructions really really really work.
[23:56] <robert_ancell> RAOF, thanks. I did them to the configure stage but no futher
[23:58] <RAOF> Oh - you should probably say at least “--with-egl-platforms=mir,drm”. If someone configures mesa with only --with-egl-platforms=mir then Mir won't run, because it needs the drm platform.
[23:58]  * kdub has always put the wayland platform in the mesa config
[23:59] <kdub> i remember once it tried to link to something in there