=== chihchun is now known as chihchun_afk === renato_ is now known as Guest11141 [02:51] robert_ancell: Hey I'm still catching up after vacationing. What's the state of GTK-Mir? [02:51] duflu, hey [02:52] duflu, it's in the archive now. The patch is pretty basic, the main feature we're blocked on from Mir is support for multiple windows [02:52] The main blocker in Unity is allowing GTK+ applications to be launched without editing the .desktop files (probably using a hard-coded whitelist for now) [02:53] robert_ancell: Yeah that's a Unity8 thing. I'm just wondering about the packages. So standard utopic gtk3 supports Mir? [02:53] yes [02:53] Awesome [02:53] Very nice [02:53] I shall have to play [02:53] We'll just update the debian patch from GNOME Git when we change it there [02:53] robert_ancell: Got a list of "pure" apps that work without recompiling? [02:54] duflu, I've been playing with gedit, gnome-calculator, simple-scan as test cases [02:54] Just set X-Ubuntu-Touch=true in the .desktop files to show then in Unity [02:54] robert_ancell: Straight from utopic archive? [02:54] just with the above change [02:54] robert_ancell: How about demo shell? [02:55] They run in there fine [02:55] Handy [02:55] You just need to set MIR_SOCKET and permissions appropriate [02:55] I didn't see any news about this milestone. But I also didn't read news during June [02:55] fine = as well as we currently have support for [02:55] in the public? [02:56] Yeah [02:56] http://www.omgubuntu.co.uk/2014/06/ubuntu-devs-demo-gtk-apps-running-mir-unity-8 [02:57] I haven't mentioned it's all in the archive now because it's not much use until Unity 8 shows the apps by default [03:07] robert_ancell: What's underneath? Is it cairo on GL? cairo on software? [03:07] duflu, cairo on software [03:07] robert_ancell: Oh so we have a cairo port [03:07] ? [03:07] duflu, no, cairo just renders to the surface memory [03:08] it has no idea about mir [03:08] robert_ancell: Ah, right. Cairo just uses pointers to memory [03:08] We can't have cairo on GL because that requires libGL to be linked to it and nvidia libGL would use crazy amounts of memory [03:08] cairo on GL also slower in some cases still [03:09] robert_ancell: Well Cairo on GL is completely unnecessary for use cases where your surfaces are pre-generated [03:09] (don't change much) [03:09] yeah [03:10] robert_ancell: Did you encounter many gnome apps with X linkage? [03:11] not very many, and they've mostly been fixed because Wayland has the same issues [03:11] We had a couple of GTK+ plugins for Ubuntu that were assuming X, but we just disable them if not under X and they work fine [03:13] Heh. Nothing like supporting multiple platforms to improve code quality [03:16] oh, you also have to unset DISPLAY because GDK tries the X11 backend before the Mir one [03:20] robert_ancell: OK. I'll try to get through all the un-fun tasks today and then try it [03:47] How exactly am I involved in 2/3rds of all code reviews already? [03:47] I need to close my eyes more [06:28] duflu: What would you like as an overview for RPC work? [06:29] RAOF: I guess just more description of what the goal/advantages are [06:29] It's shinier and you'll lose 10kg [06:29] (tm) [06:29] Buy now [06:35] duflu: Description updated for you :) [06:36] RAOF: Mostly curious. I have no immediate plans to do an in-depth review or block it [06:36] Ah. [06:40] Basically, it makes us more awesome. [06:48] Boo! I was using test_file_descriptors! [06:49] Although all those reasons for its removal are perfectly true. The split-rpc-transport branch has some better tests for fd passing, too. [06:50] RAOF: "removes our current serialisation of reads/writes" ... we don't lose ordering guarantees of messages like events do we? [06:50] No. It means “writes are no longer serialised with reads” [06:51] RAOF: Cool. And "expose manual event dispatch" ... what's that? [06:51] Handing a file descriptor out to GTK that, when it becomes readable, GTK can call mir_connection_dispatch() and have all the processing happen there. [06:52] ie: threading only when you want it.. [06:54] Sounds nice [06:57] RAOF: I was about to try benchmarking the protocol change and see if it's different... but can't build [06:57] Maybe later [06:57] duflu: Indeed. See above, “I was using test_file_descriptors!” :) [06:58] I lacked the context back then [06:58] Time to fix dednick's tests then [06:59] Eh, I can just use a different message. [07:06] duflu: There we go, now builds again. [08:13] BAH! [08:13] Next time we're sprinting, can we please have a session on profiling? :) [08:13] Anyway, EOD here. [10:35] mzanetti: http://paste.ubuntu.com/7764887/ please try [10:35] anpok_: hey cool, thanks. will try. [10:35] trying to understand the comment... [10:37] without that the system thinks that only the first pointer is pressed or released [11:42] anpok_: confirming that your patch works. Thanks a bunch! [11:49] cool [11:53] anpok_: thank you! === alan_g is now known as alan_g|lunch === renato_ is now known as Guest99235 === greyback is now known as greyback|away === alan_g|lunch is now known as alan_g === greyback|away is now known as greyback === alan_g is now known as alan_g|tea [14:33] AlbertA: hi! [14:33] AlbertA: have you been able to make any progress on https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1337481 ? [14:33] Ubuntu bug 1337481 in mir (Ubuntu) "Crash in libmirclient on app exit on phone" [Undecided,Confirmed] [14:34] dobey: I was out for us holidays...but I'm back now, I will resume looking at this [14:35] AlbertA: ok, thanks === alan_g|tea is now known as alan_g [15:06] Morning [15:47] AlbertA: I think I've a working deadlock free observers implementation. I am cleaning up the code (too much implementation in the wrong place). But you're welcome to preview: lp:~alan-griffiths/mir/spike-deadlock-free-observers [15:47] alan_g: cool I'll check it out [15:51] I think we may have some memory fragmentation issues... [15:51] My system got all swappy and slow [15:51] so I went to a VT... [15:51] where I realized I had been running [15:51] mir and a demo client for like [15:51] well since friday [15:52] then I killed Mir and everything got better [15:52] I wish I had thought to check some things but I had literally just gotten out of bed lol [15:53] alan_g: on cursor-spike-phase-7 were you just talking about the whitespace? (https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242) [15:53] racarr: reads like a mem leak too [15:53] racarr: I was [15:54] alan_g: We have a seperate C style? [15:54] I couldn't find it in the style guide... [15:54] I'm talking practice not documentation [15:54] AlbertA: Yeah... [15:54] alan_g: ? [15:54] a quick peek at the files shows both are [15:54] used [15:55] Then never mind [15:55] :) [15:56] the wording of your comment made me paranoid that there was some strange different meaning of char const* const in C that I had forgotten [15:56] lol === Guest99235 is now known as renato__ [15:58] racarr, while we're on the topic of spike-7 [15:58] I guess, once we support the custom uploading can we remove the names? [16:00] racarr: hey you reviewed https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320 - you had 2 main issues. One was that a comment (about the event struct conversion) was removed, which I put back. What was the other? I can't find it in my logs now [16:02] kdub_: I don't think so...where would the client get the system cursor images then? [16:02] kdub_: I mean we could replicate the system under X where you use an external library and a strange undocumented series of names [16:02] to load ARGB data for you [16:03] well, I was going to say the external library, without the undocumented/strange stuff [16:04] We would have to make this library though, because xcursor is strange [16:04] so why not have it in mir? [16:04] like, it seems strange to me that mir just helps with the theming for cursors [16:05] maybe I'm just asking whats the plan for how much theming mir will be responsible for [16:05] like the same issue exists for window borders [16:05] and stuff like that [16:05] mm [16:06] it seems (since mir is a library) that those concerns are different enough that a theming sort of helper library would be justified [16:06] the cursor theme is a little different [16:06] like it could even be libmirtheming.so and live in tree [16:06] unlike the initial proposals...you see how its landed [16:06] (talking past the immediate branch here) [16:06] we dont actually expose any theming [16:06] its just [16:06] a set of cursors with different meanings [16:07] and then we have an intree implementation that loads the default xcursor theme because thats something lots of shells may be interested in doing [16:07] but the actual themeing, i.e. choosing a theme or something is basically the shells responsibility [16:08] I mean...I guess if we did end up with more themeing stuff espescially borders, etc (can't imagine all the way atm) [16:08] libmirtheming would make sense [16:08] I think of the cursor names as more like the surface state enum though [16:08] if that makes any sense... [16:09] +1 for separate library from me. I don't see why core Mir should do anything more than have a method which lets a shell set an image as the cursor. Then the shell can use this helper library to get that image if it wants [16:09] well 1 because USC [16:09] should probably set the cursor in most configurations ... [16:09] I mean I guess USC could have the XCursor loader [16:09] not everyone will want to use USC [16:10] this isnt what the cursor names solve though...its just [16:10] right so if either USC or unity8 may need to load the cursors [16:10] the code should be in mir -.- [16:10] the names is just though [16:10] right, I guess I'm talking at the next-step level [16:10] how does the client request [16:10] a "busy" (for example) [16:10] cursor [16:10] the "spike-7" branch is okay, but I think that the next step should drive at chasing the specific cursor images out of the mir core [16:11] meh, maybe [16:11] I mean I thought about it right because [16:11] its obviously ugly [16:11] and obviously incorrect an always will be [16:11] i.e. there is no "This is the correct list of cursor names" [16:11] like, the interested client can link to libmirtheming.so and use that, or if they are very interested in developing their own theme system, they can link to something else [16:12] this doesnt prevent that though [16:12] you could replace the_cursor_images with something [16:12] that themes as you want [16:12] but you can still interpret mir_cursor_default [16:12] as the default cursor from your theme [16:12] sure, it doesn't prevent it, but it does make mir provide more [16:12] yes [16:13] I guess I just figured...I mean some part of ubuntu has to provide it [16:13] right, and by 'mir' i really mean 'core mir' [16:14] maybe... [16:14] sure, I agree... I just think its something that core mir shouldn't have (it can be in-tree under a different helpful theming stuff) [16:14] where to draw the line? [16:14] like "i want to set a cursor image" or "this is my default image" seems generic [16:14] I mean, a shell is free to ignore surface states and implement its own system. [16:15] so should there be libmirshellstates [16:16] I think there should be some sort of shell scratchpad, but I think that's a bit different topic [16:16] lol [16:16] :D [16:18] im not really against some sort of mirtheming seperate thing I guess...just as far as I imagine it so far I think [16:18] I would rather just have it in mir (because its pretty harmless...) rather than have [16:18] a new thing with a name that has to be remembered and thought about [16:18] lol [16:18] greyback: Sorry um the [16:18] other thing was [16:19] greyback: l427 [16:19] is a strange but I guess justified choice (danmdrader explained) [16:19] but it should maybe come with a comment about how that whole block only makes sense for tablet/phone (i.e. using maximized as restored) [16:20] racarr, yeah, but really, people don't want what's in mir when it gets too specific [16:20] like, 'here's a compositor for you, isn't it nice?' gets met with 'no, sorry, want to do my own thing' [16:20] just seems 'cursor images' is something like that [16:20] racarr: it's an initial state that's overwritten before used? I guess it could be U_UNKNOWN_STATE [16:21] kdub_: Mmm...yeah its possible... [16:21] ill continue thinking [16:21] greyback: Yeah I think so... [16:22] greyback: ERr...unless windows [16:22] start on maximized [16:22] err [16:22] as minimized [16:22] before they are shown [16:22] and line 445 [16:23] depends on it [16:23] * kdub_ just keeps thinking of the decorations/compiz situation :P [16:23] I feel like its fine with a comment that maximized is only the default for tablet or phones or something [16:23] racarr: you're right. Code bit clunky. Comment will do [16:24] :) thanks [16:24] besides that [16:24] it all looked good and left a comment on launchpad as thus [16:26] gosh I am so happy today [16:26] I bought a memory foam pillow [16:26] and slept the best ive slept in like a month [16:26] been having growing insomnia again [16:27] racarr: ok comment pushed [16:27] glad you're sleeping better [16:27] insomnia can be horrible, I suffered it a few years ago [16:27] Mm...I had it really bad as a kid and finally got it under control a few years ago so it was frustrating to see it return [16:28] I think in this case it was just back stuff though [16:28] and a better pillow will help a lot...maybe a new mattress [16:28] ...better office chair -.- [16:29] racarr: if you're happy, please mark approved [16:29] greyback: Oh hmm one more thing [16:29] racarr: omg an iWatch! [16:30] not sure of the deal with platform-api but [16:30] iWatch? [16:30] does it require [16:30] an soname bump or [16:30] some version must have to change right [16:30] sorry, bad apple "one more thing" jke [16:30] oh lol [16:30] just because its API change [16:30] ABI [16:30] change [16:31] soname should bump yeah, good catch. Should match package version really [16:32] I think THEN we are good though [16:35] uhhh...what happened to mir trunk? [16:35] it's gone... [16:35] camako: ^ [16:35] lol [16:35] kgunn: ^ [16:36] oh no [16:36] mterry_: https://code.launchpad.net/~afrantzis/unity-system-compositor/grand-refactoring-first-steps/+merge/226000 [16:36] AlbertA: seems its still there....maybe series funny biz [16:36] but this is there [16:36] https://code.launchpad.net/~mir-team/mir/utopic [16:37] racarr: pushed [16:37] ok, I guess we had an alias before? lp:mir => lp:mir/utopic ? [16:38] mterry_: please check whether the session switching tests I introduced match the expectations we have for USC [16:38] alf_: Sounds grand [16:38] AlbertA: yeah...we need to link lp:mir-team/mir/utopic to lp:mir [16:38] weird... [16:38] ;) [16:40] greyback: Looks good...approve on launchpad [16:40] racarr: thank you [16:40] alf_: yey tests in USC ! [16:41] brb more breakfast [16:42] AlbertA: only unit tests for one component (although central), but it's a start [16:43] AlbertA: do you get emails about USC MPs? [16:43] * alf_ wonders if I should add mir-team to the reviewers [16:43] alf_: nope [16:54] alan_g: ok, so if I understand correctly in the deadlock free branch, observers are now a linked list of ListItems and a custom lock that allows multiple concurrent readers but only one writer at any one time... [16:55] alan_g: and allows a reader to become a writer if it's in the same thread context [16:55] AlbertA: that's the idea [16:56] Also the linked list is a "grow only" structure (nodes are only deleted on destruction) [17:00] alan_g: ok, to avoid allocation overhead? [17:01] AlbertA: to avoid the "current" node being removed or repurposed [17:02] alan_g: ahh [17:02] AlbertA: hang on - I'm pushing a cleaner version of the code. [17:02] nice technique...:) [17:04] AlbertA: I'm at EOD - if you want to grab the code and run with it feel free. If you don't have time I'll get back to it tomorrow. [17:06] alan_g: sure === alan_g is now known as alan_g|EOD [17:12] kgunn, AlbertA, yea the alias is not right [17:12] any more [17:13] kgunn, we (duflu/Alan_g/others) want lp:mir to point to devel [17:13] camako: ack...i won't touch a thing.... [17:13] kgunn, and want the distro to pull from lp:~mir-team/mir/utopic [17:13] kgunn, dunno if this is possible [17:14] camako: right...i was going to say, you might need to talk to "someone"....that used to be didrocks...but he's since moved away from that job [17:14] sil2100 would be the next person i would speak to... [17:14] but i thikn their machinary needs lp:mir to be trunk...(this is an ancient problem) [17:17] * kgunn realizes we're overdue for our quarterly "can't we have trunk not be distro target" discussion [17:17] discussion...or inquistition [17:17] kgunn, we should let duflu loose on 'em [17:18] exactly [17:19] kgunn, currently lp:mir is an alias to the "development focus" branch [17:19] which is now mir/0.5 [17:19] but it has no corresponding branch [17:20] so it's difficult to set up the branches in a way that makes sense [17:20] for our development [17:20] yeah [17:20] which is why it was the way it was [17:22] * camako thinks we'll deal with it in the next release [18:48] is there now power management in Mir 0.4? [18:50] Lunnch [18:55] bregma, not in mir, although iirc, that has shifted to USC recently [18:55] AlbertA can probably give better dates around when that happened [18:56] hmm, well, it's crept in somewhere and requires I reboot the desktop every 5 minutes because there's no wake support in the Unity 8 shell. [18:57] greyback, were you able to get xmir working? [18:58] bschaefer: nope. I gave up and logged a bug https://bugs.launchpad.net/mir/+bug/1339001 [18:58] Ubuntu bug 1339001 in Mir "XMir not working with nouveau" [Undecided,New] [18:58] greyback, good idea :) [18:58] bschaefer: things work on my intel machine, so guess it's nouveau issue [18:58] ahh, the power button works like on the phone, a little unexpected on a desktop system [18:58] greyback, yeah, sounds like a nouveau issue then ... strange has to be have been a recent push [18:58] bregma, like, holding the button to turn it on? [18:59] bschaefer, yes, just like the phone [18:59] and, the power-down timeout is seems like about 30 seconds [18:59] also a little unexpected on a desktop [18:59] o wow, thats a long time to hold it [18:59] yeah [18:59] (at lease on a desktop) [19:00] no, you just tap the power button, the screen shuts off with no activity in 30 seconds [19:01] also, the second time you press the power button it just shuts down the whole machine ☹ [19:01] * bschaefer does not know how phones work [19:01] my phone i have to hold the power button for ~30 seconds to shut it down [19:01] bschaefer, not shut down, wake up [19:01] otherwise it locks the screen [19:01] i see yeah [19:16] bregma: I updated USC to disable power key and inactivity handling with xmir [19:16] bregma: bu tthis is with unity 8 desktop? So it still uses usc wrapper to start up unity-system-compositor? [19:17] what is usc wrapper? [19:17] in touch [19:17] usc-wrapper is the one that lightdm will call to startup unity-system-compositor [19:18] for xmir, there's another wrapper which lives in tree in unity-system-compositor [19:18] that's new to me [19:18] I modified that last thursday to avoid the power key/inactivity stuff for xmir [19:18] what's with the sudden support for xmir? who uses it? [19:19] bregma: so do you know how usc get's started for unity8 desktop? [19:19] lightdm starts u-s-c: if there have been mods to have it do something special for the phone they didn't get publicized on the channels i follow [19:20] bregma: directly? no wrapper script or anything? [19:20] that's the way it used to do it [19:21] this is what will be used for ubuntu-desktop-mir: [19:21] http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/debian/unity-system-compositor.sleep [19:21] http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/debian/10-unity-system-compositor.conf [19:22] what is ubuntu-desktop-mir and how does it relate to the stuff currently in use in the Unity 8 desktop? [19:22] bregma: I don't know how it relates, I just know we use that for xmir [19:23] i.e. you install ubuntu-desktop-mir and you get xmir with unity7 [19:23] what is xmir used for? [19:23] adventure [19:23] we do not support Unity 7 running that way [19:23] its "available for testing" [19:26] all I know is if you installed ubuntu-desktop-mir it would break OpenGL and my team would have to spend time supported people with broken systems [19:26] bregma: ok let's get back to the core issue [19:27] bregma: Is it unity8-desktop-session that has the lightdm confs? [19:29] AlbertA, yes indeed [19:30] bregma: I don't see unity-system-compositor there though... [19:32] AlbertA, no, because lightdm knows how to configure it automatically ... although if I can add a wrapper, I'd be happy [19:33] bregma: oh I see...well all we need is to set the cmd line arg: --disable-inactivity-policy=true [19:33] evidently the ability has been there for a while, now I look through the code [19:33] I shall play with this until usability is restored [19:34] bregma: well actually...usc may need more changes, [19:35] bregma: we need different policies I guess [19:35] bregma: because I assume you still need inactivity to take effect [19:35] bregma: but wakeups should occur with mouse or keyboard events, not power key [19:36] AlbertA, that will require support from the Shell, and it's not on the near-term radar [19:36] bregma: ok [19:38] bregma: well ping me if I can help further... [19:38] sure thing [20:53] the cursor renderable needs to support padding the image if the cursor buffer is larger than the image [20:53] i.e. on some gbm where its always 64x64 [20:53] like mgm::Cursor does now [20:53] the thing is...it should also support multiple pixel formats now. [20:54] I guess I am just wondering if its appropriate to link in pixman [20:54] groan [20:54] :) [20:54] nothing against pixman :) [20:55] but once we do that... why not libjpeg and and libpng [20:57] hm recently saw a patch that allows fantastic 128x128 for kaveri gpus.. [20:57] I probably wouldn't mind libmirhelpfultheming.so linking to things like that though [20:58] lol [20:58] anpok: Yes hence most. the thing is just that the cursor renderable buffer may not be the same size [20:58] as the cursor [20:59] nvm im dumb. for some reason I thought I was going to have to specialize the padding code for different [20:59] pixel formats [20:59] but [20:59] transparent [20:59] is the same everywhere... [20:59] *facepalm* === xnox is now known as xnox_ === xnox_ is now known as Eisbrecher === Eisbrecher is now known as Eisbrecher_xnox === renato_ is now known as Guest83027