[00:13] bschaefer, you can confirm it works for you? [00:13] i.e. get into XMir? [00:31] robert_ancell, yeah [00:32] robert_ancell, i had the cursor, and the process was up and running [00:34] bschaefer, awesome, thanks [00:34] robert_ancell, np :) [00:47] thanks RAOF [00:50] ARGH! [00:50] 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] I was sure I fixed the signals-plus-threads-equal-pain problem before. [01:02] Pressing alt+left reliably makes my desktop mir session freeze (alt+f1 fixes though) [01:10] Not sure if that's bug 1102756 or something else [01:10] bug 1102756 in Mir "System compositor input events passed to console (particularly troublesome for Alt+Fn and Alt+Left/Right)" [High,Triaged] https://launchpad.net/bugs/1102756 [01:11] 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] mterry: It gets set by the client, though once the shell (and the system compositor too) implement the session authorizer [01:12] it can be trusted. [01:12] the key off param.name is a bit of a hack. we should have a better way to [01:12] sort o tag it... [01:14] 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] racarr, so both sessions and surfaces have names, it seems [01:14] * mterry is still getting used to how Mir works [01:57] mterry: Yup, that's bug 1102756 - what's happening is the kernel is interpreting + as a VT switch. [01:57] bug 1102756 in Mir "System compositor input events passed to console (particularly troublesome for Alt+Fn and Alt+Left/Right)" [High,Triaged] https://launchpad.net/bugs/1102756 [01:59] mterry: Well right now it is set by the client but hte basic path is [01:59] 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] then when the client tries to connect the shell will be told hey [02:00] thi PID is connecting is that ok [02:00] perhaps surface name should be title [02:00] and session name should be application-id [02:03] racarr: Did we ever work out how that is meant to interact with fork() [02:03] ? [02:11] 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] -state +static [02:28] RAOF: Perhaps it's not [02:28] Is forking and opening new mir connections something clients are allowed to do? [02:28] I'm not sure [02:28] not on the phone or the system compositor [02:28] perhaps for the desktop we will need [02:29] a more complex mechanism [02:29] i.e. DBus API in the shell [02:42] 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] racarr: I can't think of a sensible use case for us to worry about forking clients yet... === asac` is now known as asac [03:52] That's odd. I don't remember doing updates but EGL Mir clients are broken again [03:52] * duflu updates again [03:59] RAOF: Ping (hopefully I won't drop out like yesterday) [04:00] :) [04:00] duflu: Pong. [04:01] 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] Hah! [04:01] Docs? [04:01] Hah! [04:02] Confirmed in folklore even? [04:03] 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] But holding it creates a world of deadlock pain I'm working through [04:06] 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] RAOF: Yes, that agrees with my findings [04:08] You *should* be able to do any form of bookkeeping you want on it, though; unreffing it should work. [04:08] It also confirms the buffer really is scanout. And any premature unsynced changes will give me tearing [04:08] Oh, yes. [04:08] That's rather the point, isn't it? [04:08] Yup [04:33] bschaefer: just to double check...did you try the ppa from a "purged state" ? [04:35] 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] did an upgrade and then the intel driver was being loaded correctly, and xmir and x11 started working correctly [04:37] kgunn, would you like me to try purge my ppa and test it out? [04:37] purging* [04:37] 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] bschaefer: hey thanks...good to get a second data point [04:38] kgunn, yup, hmm it could be that libmirserver was updated in the ppa recently [04:38] * bschaefer goes to check [04:39] kgunn, do you also have the mir staging ppa? [04:41] bschaefer: nope [04:42] ...but double checking for stupid mistakes [04:42] hmm strange, have you also pined the unity system compositors ppa? [04:43] * bschaefer was unaware of this until yesterday [04:43] from : http://www.olli-ries.com/running-mir/ [04:43] bschaefer: oh yes...altho, when i purged...i unpinned & removed the deb ref to -testing [04:44] rebooted into x no prob etc [04:45] but yes...i repinned just now [04:45] kgunn, so you have a working lightdm still, and mir isn't working? [04:45] or is it uninstalled? [04:45] yeah, re-pinning should help downgrade your packages :) [04:46] ligthdm yep & yep.....installed [04:46] checking all my versions now against -testing [04:47] cool, cause usually when I ran into broken packages it would uninstall my lightdm :( [04:47] so xmir *should* be working hmm [04:48] As far as I can tell u-s-c in -testing *should* be installable from testing. [04:50] well...it seems that all the versions look ok, except lightdm is one behind [04:51] what is your apt-cache policy on it? [04:51] I've got: Installed: 1.7.5bzr1634saucy0 [04:51] from: 1002 http://ppa.launchpad.net/mir-team/system-compositor-testing/ubuntu/ saucy/main i386 Packages [04:54] bschaefer: what the command there "sudo apt-cache -p lightdm" ? [04:54] kgunn, "apt-cache policy lightdm" should do it [04:54] no need for sudo :) [04:54] bschaefer: ta [04:54] np! [04:55] right...Installed: 1.7.4-0ubuntu1 [04:55] strange! hmm have you missed an update? [04:55] candidate is 1.7.5....however if i attempt to install...it complains [04:56] about unmet deps on u-s-c [04:56] which in turn complains about libmirserver0 [04:57] mind pasting the error :) [04:57] What version of mirserver0 is it complaining of? [04:57] Because the version in -testing depends on = 0.0.6bzr832saucy0, which is the version in the PPA. [04:58] Depends: libmirserver0 (= 0.0.6bzr831saucy0) but 0.0.6bzr832saucy0 is to be installed [04:58] I suspect you may need to apt-get update? [04:58] The deb that I downloaded from the PPA just now depends on 832 [04:58] i have a few times [04:59] hmmm...might repurge and try again [04:59] apt-cache policy ubuntu-system-compositor? [05:01] none installed...but again, that's because of the whinging about libmirserver0 [05:01] kgunn, unity-system-compositor [05:01] hmm strange still [05:02] bschaefer: yeah ;) i corrected it...i knew [05:02] kgunn, what is the versions Candidate? [05:02] for u-s-c? [05:03] Candidate: 0.0.1bzr33saucy0.144 should be yours? [05:04] one moment...got impatient, repurged, trying again.... [05:04] cause your libmirserver0 is the correct version, but for some reason u-s-c wants a lower version? [05:04] :), good luck! [05:06] ...i think it worked...rebooting [05:09] bschaefer: RAOF ...hooray! never so happy to see my annoying friend "extra mouse cursor" [05:09] kgunn, awesome :) [05:10] :) [05:10] not sure what happened...i'm sure it was due to my futzing around earlier today [05:10] kgunn: It's a /watermark/ to tell you Mir is working ;) [05:11] duflu: yes....serious investment in that "feature" [05:11] good morning :) [05:11] kind reminds me of bob the paperclip [05:12] Intentional or not, it's very useful [05:12] tvoss_: ditto [05:12] tvoss_, Hi [05:12] guys, I need some help as lightdm from the ppa won't install its configuration file [05:13] tvoss_, which config file? [05:13] robert_ancell, I don't see the 10-unity-system-compositor in /etc/lightdm/lightdm.conf.d [05:13] tvoss_, did you delete it previously? [05:14] robert_ancell, might well be, yeah :) [05:14] 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] "debian remembers if you delete stuff in /etc" [05:17] tvoss_, or failing that just make it yourself [05:21] robert_ancell: Or dpkg --purge then reinstall. [05:28] didrocks: morning [05:28] hey kgunn! it's quite late for you, isn't it? [05:29] didrocks: or early...yes. [05:29] :) [05:37] Rule of thumb: If you're talking to Australia then you probably should not be awake :) [05:38] Unless it's only early evening... [05:38] Or you're in Europe [05:38] Or you're in Asia [05:38] RAOF, https://bugs.launchpad.net/mir/+bug/1195811 - this is because XMir doesn't limit frame rate from X clients right? [05:38] Ubuntu bug 1195811 in Mir "Abnormally high FPS (no vsync) on natively mir testing demo-clients. Ubuntu 13.10" [Undecided,New] [05:39] robert_ancell: It's a driver-specific bug (nouveau). I have not got around to doing manual testing on nouveau yet [05:39] nouveau has a long history of not vsync'ing [05:39] duflu, but I believe no X client in XMir vsyncs right? [05:40] 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] robert_ancell: Yes compiz enforces vsync for everything on the screen, except when it's full screen and bypassed [05:41] 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] I have two nvidia cards. I guess I should install one to keep the room warm during winter [05:50] I should get my netbook bootable again so I can use it's BLAZING FAST geforce 9300 [05:51] You mean blazing (hot) ? [05:51] * duflu wonders how Mir would go on the old N270 netbook [05:53] Hm. Trunk doesn't build for me? [05:56] 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] kgunn: hum, no, I mean we can leave it unresolved for daily release into a ppa [05:56] not for universe [05:57] 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] 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] kgunn: well, I spent an extensible amount of time updating to latest gmock [05:57] and updating all components (mir included) to use that distro version [05:57] the only remaining piece is nux [05:58] kgunn, RAOF, duflu, racarr, kdub_, meeting [05:58] didrocks: ah....thanks...its clear now [05:58] 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] thomi, too if your internet got solved :) [05:58] didrocks: thanks...tvoss had his name there...but i'll pester bregma tomorrow [06:01] kgunn: the most important one is the armhf tests failing (some needs to be separated in autopilot tests I guess) [06:03] didrocks: again, i understand bregma is going to disable valgrind tests for arm [06:03] kgunn: but they should be run as part of autopilot tests, right? [06:04] so that we run them in the phone image [06:04] with the actual hardware, and so on [06:04] didrocks: right, i believe it was qemu failing...but mobile hw ok [06:05] 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] didrocks: thanks for pointing that out...i'll followup with bregma [06:06] yw! [06:25] Huh. Mir lttng fails to build with -std=c99 [06:36] good morning === ubuntu is now known as Guest92882 === Guest92882 is now known as tvoss [07:24] 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] tvoss: The shell has no context switches at all. [07:24] As long as it's in-process. [07:25] RAOF, yup, I will add that to the answer :) [07:25] If it's not in-process, then, again, it's one context-switch per frame. [07:28] 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] So 4 threads with a single client [07:28] 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] duflu, sure, but still: let's wait for hard numbers until we start optimizing that part [07:31] tvoss: Yeah I have no evidence that waking up hundreds of times per second like Mir does, is affecting frame rates yet [07:31] Only power consumption that's not ideal for sure [07:32] Several years ago, several-year-old hardware managed 20,000 context switches/sec. We're not going to be dropping framerate : [07:32] duflu, that reminds me: I need to log a bug about some build time flags that we introduced to satisfy the buildds [07:32] Yeah, it's just the modern day race to zero watts :) [07:32] We do want to stop waking up to save power, though. [08:13] didrocks, ping [08:15] tvoss_: pong [08:15] didrocks, good morning :) how goes? [08:15] tvoss_: I'm fine, thanks! Ensuring that the temperature remains hot with building nux :p [08:15] and you? [08:16] :D [08:16] didrocks, looking through the list of open bugs [08:21] tvoss_: FYI, nux package doesn't build, there seems to be a PREFIX override [08:21] didrocks, *sigh* [08:22] tvoss_: seems like people don't try to bzr bd :/ [08:22] (it's easy though :/) [08:22] didrocks, looking into disabling tests on powerpc now [08:23] tvoss_: no need anymore [08:23] tvoss_: I've disabled powerpc builds [08:23] didrocks, oh, do we have a branch? [08:23] didrocks, okay [08:23] as per the discussion [08:23] didrocks, okay, mind closing the bug? [08:23] tvoss_: doing so :) [08:23] didrocks, thx [08:25] RAOF, mind giving me a quick status on the system-compositor-testing ppa before you eod? [08:47] hey guys! So you publish your docs to http://unity.ubuntu.com/mir/ [08:47] how can I do the same with my library? [08:47] pete-woods, talk to mhall119 [08:48] tvoss_, cool, thanks! [08:48] pete-woods, yw [08:48] tvoss_: As far as I'm aware, system-compositor-testing is ready to roll. [08:49] RAOF, ack, so nothing to be copied over right now? [08:49] RAOF, rolling fine on my machine :) [08:49] Nothing particularly to be copied over, no. [08:49] RAOF, ack, thanks [08:49] 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] hikiko: alan_g: Have time for a nested mir sync/chat? [08:52] 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] alf__: hikiko 8 mins? [08:52] pete-woods, not yet [08:53] hey [08:53] sorry [08:53] okay, thanks for the info [08:53] alan_g, alf__ sure can you wait for 5 mins? [08:53] I have to go downstairs to collect something brb in 5mins alan_g alf__ [08:54] alan_g: hikiko: sure, I will create the hangout, join when ready [08:55] alan_g: hikiko: https://plus.google.com/hangouts/_/1c0bb852740e0eb0560f57be1e1c793df9897a89?hl=en [08:58] alan_g, alf__ back [09:05] RAOF, ping [09:05] tvoss_: Pong. [09:05] 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] 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] alan_g, ping [09:53] tvoss_: ? [10:08] RAOF, okay, not an issue with xfce === hikiko is now known as hikiko|lunch [10:32] alf__: Can you point me to where in the server the client's choice of swapinterval is implemented? [10:33] duflu: src/server/compositor/switching_bundle.cpp [10:34] alf__, thanks [10:34] Oh, I forgot the terminology changes to "frame dropping" [10:34] Of course [10:41] 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] alf__: Yep thanks. I'm trying to figure out what I've done to make synchronous clients hang. Something is deadlocked [10:42] And I think it might be too late in the day to continue [10:43] alf__: I did notice this, but it doesn't seem related to my problem now... https://bugs.launchpad.net/mir/+bug/1199717 [10:43] Ubuntu bug 1199717 in Mir "BufferSwapperMulti::in_use_by_client counter drops below zero" [Undecided,New] [10:43] duflu: thanks, I will take a look === 6JTAA2M02 is now known as tvoss [11:14] Is mir going to get AppArmor support? [11:14] dandrader, sure, you mean in terms of having a SecurityManager server-side? === hikiko|lunch is now known as hikiko| === hikiko| is now known as hikiko [11:16] 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] dandrader, yes, that's not there, yet, though [11:18] tvoss, sure, but the plan is to have it implemented with AppArmor, right? [11:20] (sounds like I'm repeating the same question with different words but I do like to have it made clear :) ) [11:25] dandrader, might have lost some of your messages [11:25] tvoss, sure, but the plan is to have it implemented with AppArmor, right? [11:25] (sounds like I'm repeating the same question with different words but I do like to have it made clear :) ) [11:25] tvoss_, ^ [11:25] dandrader, right our technology of choice is apparmor === alan_g is now known as alan_g|afk [11:27] ok, thanks (because in the e-mail discussion I've suggested discretionary access control) [11:28] dandrader, I think we need mandatory access control, too [11:30] yeah, that's more powerful === alan_g|afk is now known as alan_g === dandrader is now known as dandrader|afk === greyback is now known as greyback|lunch === pete-woods is now known as pete-woods-away [12:32] bregma: give me a sign once you will win over the PREFIX override for nux :) [12:33] didrocks, I fixed that last night, MP should be OK now [12:33] bregma: ah, you just didn't push it in the previous MP then? [12:33] bregma: let me rebuild the package then [12:34] bregma: thanks for taking the opportunity for -X.la btw ;) [12:35] 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 === pete-woods-away is now known as pete-woods [12:38] bregma: beautifully build! [12:39] tvoss_: kgunn: ok, so pushing new google-mock snapshot to distro [12:39] once published, switching all MP to approved [12:39] thanks bregma for nux! :) [12:40] bregma: didrocks \o/ [12:40] kgunn: already awake? really really short night :) [12:40] didrocks: zzzzzz, huh? [12:41] ;) [12:41] heh [12:45] * bregma slurps yet another mug of coffee [12:45] bregma: another? it's not your first? :-) [12:46] no chat or email until at least the second mug or I always regret it [12:46] ahah [12:50] bregma: .....a wise man === dandrader|afk is now known as dandrader === greyback|lunch is now known as greyback === zoktar_ is now known as zoktar === pete-woods is now known as pete-woods-lunch [13:46] 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] greyback, where is the unity8 branch that uses mir? [14:00] greyback, oh, nm: lp:~unity-team/unity/unity8-integrate-mir/ [14:00] mterry: yep that's it. Any luck with mir? [14:01] 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] mterry: ok. Look up ua_ui_window_properties_set_titlen [14:03] mterry: that's used in the qtubuntu plugin, which sets the surface name that shell will get [14:03] greyback, ah, OK [14:03] thanks [14:03] is in platform-api. yw === pete-woods-lunch is now known as pete-woods [14:15] 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] 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? === zoktar_ is now known as zoktar === Cimi_ is now known as Cimi === mzanetti_ is now known as mzanetti_sa === mzanetti_sa is now known as mzanetti [14:39] greyback, about mir+unity on nexus4, do you know if there's a bug about the black screen issue? [14:41] mterry: no I don't. You'd need to talk with ricmm about it, since I guess you're using his images [14:42] mterry: quick question: what version of "ubuntu-touch-session" is on the image you've installed? [14:42] greyback, hm, ok [14:43] greyback, 0.57 (though 0.56+mir2 is available and unused... seems bad) [14:43] mterry: switch to the mir package and reboot [14:43] mterry: I think that's hte culprit [14:45] greyback, yup, that fixed it for me [14:45] 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] excellent! [14:45] ricmm_: ^^ [14:46] greyback: mterry yup, setting up a recipe for that now [14:48] alf__: ping [14:48] kgunn: pong [14:55] Morning [14:58] Afternoon === yofel_ is now known as Guest48668 === Debolaz is now known as Guest98373 === kgunn is now known as Guest40271 [15:07] alf__, ping [15:07] tvoss_: pong [15:16] alf__: your patches for google-mock was for clang build? [15:18] didrocks: no, for g++ 4.7 (but it could be that clang needs them too) [15:18] didrocks: issues? [15:19] alf__: yeah, with the google-mock version I pushed today in distro (so the snapshot without your patch), I see: [15:20] alf__: http://paste.ubuntu.com/5861927/ [15:20] is that what your patch would prevent? [15:20] alf__: this issue doesn't seem to appear with gcc [15:21] (at least, it's at 72%, passed that point) [15:21] didrocks: that shouldn't be relevant to my patch [15:22] 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] right [15:24] kdub_: I'm afraid I'll need help on that one then :) [15:27] hopefully clang just goes through :) [15:27] 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] 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] probably needed a revamp [15:30] 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] 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] 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] didrocks, might be, but I know there were other patches too, potentially [15:40] * didrocks loves it: [15:40] dpkg-deb: building package `mir-build-deps' in `../mir-build-deps_1.0_amd64.deb'. [15:40] Attention, the package has been created in the current directory, [15:40] not in ".." as indicated by the message above! === sfeole` is now known as sfeole === Guest48668 is now known as yofel [16:23] kdub_: hum, in your script, you even don't install the packages, just extract them in random dir? [16:23] add_subdirectory given source "/usr/src/gmock" which is not an existing [16:23] is what I get [16:23] didrocks, yeah, just enough to provide headers and linking [16:24] kdub_: do you have a generic way of dealing with this hacked path then? [16:24] in cmake? [16:25] we use cmake's cross compilation system [16:26] kdub_: hum, I will try something to point to the google-mock usr/ path [16:26] but doesn't sounds sane TBH ;) [16:33] greyback_: Anything I can do to be helpful on application module? [16:33] kind of inbetween tasks [16:33] so have to pick something new up [16:35] 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] greyback_: Is it a trap? :( [16:39] the way you phrase it makes it sound like a trap [16:40] buillding [16:40] racarr: gah, foiled again! [16:42] segfault, probably [16:42] abi mismatch [16:42] on my machine [16:42] i.e. can't even start it [16:42] I think I need a mesa upgrade [16:42] will be a ew minutes [16:44] greyback_: I don't see any calls to set_input_region [16:45] so how would you be able to interact with an app? [16:46] racarr: aha, that's what I was missing [16:46] yes, stupid me [16:46] how did I completely forget that?? [16:47] forgetting is easy! [16:47] XD [16:47] how will that bit work? [16:48] I've been wondering about the least troublesome way to wire that up [16:53] Yeah me too. I'd love to define InputRegions that shell should accept, and all other regions the input passes through [16:53] I've idea how to do it, is next on the list [16:54] whee [17:00] 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] so please put those together and check everything works [17:01] but right now, I'm away :) Talk later [17:03] greyback_: Excellent. Thanks [17:03] see you === tvoss_ is now known as tvoss|dinner === thomi_ is now known as thomi [19:04] 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] binding the output video buffers as textures to the surfaces (for egl streaming) [19:05] ah, haven't read yet [19:05] so its most likely a backend to gstreamer (which ends up being a native mir client....like qmir) [19:06] ah...i'll give you a chance [19:07] btw....per session mode setting still more important than that discussion ;) === yofel is now known as Guest395 === kgunn is now known as Guest55003 === Guest395 is now known as yofel === Guest55003 is now known as kgunn === kgunn is now known as Guest77008 [22:01] 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] 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] These people have lots of listeners, so if it is indeed a misunderstanding, I hope it gets rectified asap. [22:05] 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] jono, they seem to have interpreted that as "extremely unlikely". [22:06]