[00:07] <thomi> I wonder if any of the mir developers are GLSL experts? I need to pick someone's brain on the subject at Oakland... maybe RAOF or kdub?
[00:15]  * RAOF is in no way a GLSL expert
[00:16]  * kdub knows how to write glsl
[00:17] <thomi> kdub: you'll, do, I'll swap you some alcohol for advice :)
[01:27] <thomi> robert_ancell: hey - autolanding and ci for lp:lightdm/mir has been deployed - would be good to test it, if you have some code that needs merging
[01:28] <duflu> RAOF: What's the correct state for this bug? https://bugs.launchpad.net/mir/+bug/1102762
[02:01] <kgunn> duflu: thanks for mp'ing your surface state work!
[02:02] <duflu> kgunn: No problem. I have not got to looking at it or any MPs yet. But have allocated the rest of the day/week to it
[02:03] <kgunn> duflu: cool....felt good to see dma buff, in process egl & your stuff mp'd...
[02:04] <duflu> kgunn: Yeah the number of line-items is significant :)
[02:50] <robert_ancell> thomi, do you know why Jenkins hasn't built https://code.launchpad.net/~andrzejtp2010/lightdm/lightdm-trunk-xephyr-multiseat/+merge/120286?
[02:51] <thomi> robert_ancell: let me see...
[02:51] <robert_ancell> thomi, also https://code.launchpad.net/~agateau/lightdm/move-to-sbin/+merge/89146
[02:52] <thomi> robert_ancell: yeah, for the first MP it's because the proposing user isn't a canonical employee. The CI server builds the proposed branches, so we have apolicy of not building branches from outside, since you can make debian/rules do anything you want, including evil things. However, this shouldn't be a concern any more, since we build inside chroots these days
[02:53] <thomi> robert_ancell: there's a way you can force it, I think, but I can't remember the details
[02:53] <thomi> robert_ancell: it may be that autolanding will still run, once you approve the MPs
[02:53] <robert_ancell> thomi, ah, that's an annoying limitation for lightdm as one of the devs is not a Canonical employee. It would be great if we could remove that limitation
[02:54] <thomi> robert_ancell: I'll send an email to the people who maintain the CI infrastructure and get back to you on that
[02:54] <robert_ancell> thanks
[02:54] <thomi> robert_ancell: I think it's mostly a historical limitation from the days where we built things on the CI server itself :-/
[05:49] <mardy> hi all! Will Mir support embedding another process's window into one's own?
[05:50] <tvoss> mardy, we haven't decided on that, yet.
[05:50] <mardy> tvoss: OK, then the most important question is whether it's technically feasible or not (or just extremely difficult)
[05:51] <tvoss> mardy, I think both holds true, and I think there are better approaches to include rendered content within an apps surface. I would think it depends on the actual use-case. So what are you trying to solve?
[05:52] <mardy> tvoss: https://wiki.ubuntu.com/OnlineAccounts#phone-settings (see the bottom of the page, that "WebView" square comes from another process)
[05:52] <mardy> tvoss: but the design is in its early stages, and we can affect it, I think
[05:53] <tvoss> mardy, what's the technology we want to use for the webpage? is it webkit?
[05:53] <mardy> tvoss: what about window reparenting (that is, making it look like a window is part of this process, while it comes from another one)?
[05:53] <mardy> tvoss: yes, webkit
[05:54] <tvoss> mardy, that's the same as embedding isn't it? @webkit: it's multi-process by default, isn't it?
[05:55] <tvoss> mardy, so that being said: what would prevent us from just embedding a webview in process for your use-case?
[05:55] <mardy> tvoss: no, maybe I didn't use the correct term; I mean, something like http://www.gtk.org/api/2.6/gtk/GtkWindow.html#gtk-window-set-transient-for
[05:56] <mardy> tvoss: that is, the window is entirely drawn by the same process, but the WM places it on top of another process's window
[05:58] <tvoss> mardy, it's not possible right now, and we have been talking about embedding/setting other applications transient multiple times. However, I wonder what prevents us from just using a browser component within the same process?
[05:59] <mardy> tvoss: about webkit, the problem is that the flow is: client application -> signond (via D-Bus) -> signon-ui (host of the webkit)
[06:00] <mardy> tvoss: I don't think it's impossible to embed webkit in the client, but it would be a lot of work, and I don't like it from a security and performance POV
[06:01] <mardy> (signon-ui exits after some seconds of inactivity, and in the future Mir could provide some special decorations to it to tell the user that it's a trusted window)
[06:01] <tvoss> mardy, can you make sure that the requirement is noted down in the design spec?
[06:02] <mardy> tvoss: you mean the wiki page I pointed you at, or some Mir document?
[06:02] <tvoss> mardy, the wiki page first, it will bubble up from there :)
[06:02] <mardy> tvoss: will do, thanks
[06:03] <tvoss> mardy, cool, thanks
[07:39] <Ranomier> http://www.phoronix.com/scan.php?page=news_item&px=MTM0OTE
[07:39] <Ranomier> whooo
[07:39] <Ranomier> huuu
[07:43] <Ranomier> Im done with mir everything will be supported by wayland, there is no reason to use mir. Kde, Gnome (and with it lxde xfce), Enlightenment, Android drivers, Qt, if nvidia and/or ati write their driver for wayland then ... xD
[07:43] <Ranomier> Thank u mir, for pushing wayland devs in their seats :D
[07:44] <Stskeeps> Ranomier: i wrote that blog post and it's not cool to troll other people's development channels.
[07:45] <Ranomier> Yeah u right, sry for that. My whole body want it to say that^^ I could not stop it.
[07:48] <RAOF> That's not actually very surprising - Wayland on Android was first demoed quite some time ago :)
[07:49] <tvoss> RAOF, yup :) however, good work :)
[07:50] <RAOF> Indeed. There's generally substantial work between "here's a demo of $X" and "and now $X works" :)
[07:50] <tvoss> RAOF, agreed :)
[08:01] <Ranomier> So pleeease, canonical, work upstream with wayland and share your attained
[08:01] <duflu> OK, let the potential trolling end there. I think we would all like both Wayland (plus a real display server if not Weston) and Mir to succeed. Competition is a good thing
[08:01] <Stskeeps> indeed - people have different goals and methods
[08:02] <duflu> And having multiple options in the open source world is a very good thing
[08:03] <duflu> It's only fragmentation if the parts began as a whole. I'm not so sure they really did. So don't call it fragmentation. Call it competition :)
[08:07] <duflu> Morning katie... Was there any movement on the "edge" discussion?
[08:08] <Ranomier> I think it is very important to have a basis that all linux distros share, it is ok to make multible Desktop Environments and multible Programs that do the same, BUT it is not ok to touch that basics
[08:08] <duflu> Ranomier: So you don't like Android because it is Linux with a very different DE?
[08:09] <Ranomier> No use it, but i think i dont like becouse it uses surfaceflinger and another c libary
[08:10] <Ranomier> sry *i use it   From freedesktop.org: "freedesktop.org is building a base platform for desktop software on Linux and UNIX"
[08:11] <Ranomier> I want to start any graphical programm under linux, that is writen for linux
[08:12] <katie> Hi duflu.. not after the email
[08:12] <Ranomier> i can install qt and gtk at the same time, but mir and wayland?
[08:12] <Ranomier> and use it at the same time
[08:13] <duflu> Ranomier: Yes I think you will be able to have Mir and Wayland installed simultaneously. In fact Mesa will link dynamically to both. But only one can occupy the graphics hardware at a time
[08:13] <Ranomier> Yeah thats my problem
[08:13] <Ranomier> i cant start wayland and mir
[08:13] <Ranomier> it breaks that basis.
[08:14] <RAOF> It's highly likely that you *will* be able to use a Wayland compositor inside Mir, and visa-versa.
[08:14] <katie> duflu, I shoud get to it today, and let you know when I change any docs
[08:14] <katie> should
[08:14] <duflu> RAOF: Yeah I thought as much. Just possibly with performance for one being limited?
[08:15] <RAOF> duflu: No, not really, any more than running Mir under Mir-system-compositor hinders performance.
[08:15] <tvoss> RAOF, Ranomier it's essentially a cascaded compositor approach, leaving aside how certain nodes in the tree are called, isn't it?
[08:16] <Ranomier> Sry, i dont understand this.
[08:17] <duflu> katie: Ta. Though I probably wouldn't implement anything till Monday. It's almost end of the week
[08:18] <Ranomier> At the moment, i can install awesome and then i start a kde programm, and then a qt only programm, then a gnome programm and then a enlightenment programm.
[08:18] <Ranomier> everything ontop one basis.
[08:19] <tvoss> Ranomier, sure, which is X at the moment, isn't it?
[08:19] <Ranomier> Yeah
[08:20] <tvoss> Ranomier, well, that is going to go away anyways, no matter which other competitive display server you are considering :)
[08:20] <Ranomier> And that have to work later too! With android programm, with qt programms, with Unity programms usw
[08:21] <RAOF> And it's reasonably likely to work later (except without the awesome bit, because neither Mir nor Wayland support external window managers)
[08:23] <Ranomier> AND it has to be performant and easy programable! Thats two reason why we dont want X. If we have wayland and mir and surfaceflinger, we have the old proplem we have to care for each of those and it has to be performant.
[08:24] <RAOF> By and large you shouldn't. Unless you're writing a game and trying to wring the last 5% of performance out.
[08:25] <duflu> Funny thing about performance is that except for obvious visible bugs, people only care about performance if you give them numbers. Without numbers (and without bugs) most people are happy
[08:26] <Ranomier> Yeah the people that us it are happy but not the developer!
[08:26] <Ranomier> use*
[08:29] <Ranomier> im learning coding from a friend, hand he is saying performance is importand, but if ur idee of the code and the code are not clean and clear u never get that performance and bugfree programm.
[08:30] <Ranomier> Do it right from the beggining.
[08:30] <Ranomier> idea not idee*
[08:31] <duflu> Sure, you need to keep performance in mind right from the design. You don't want to implement an algorithm that is slow by design. But a lot of performance improvement comes after the initial implementation
[08:31]  * tvoss notes that premature optimization without hard numbers is the source of all evil
[08:32] <Ranomier> Yeah thats right! But i u have wayland AND mir there is no clear basis to optimize, there a two documentations there are two apis and and and
[08:33] <Ranomier> i = if
[08:33] <duflu> tvoss: I mean err on the side of low complexity by big-Oh notation. That's something you do from the beginning
[08:33] <tvoss> duflu, yup :) I was referring to the final 5% :)
[08:33] <duflu> But don't waste time measuring performance early on
[08:35] <tvoss> Ranomier, in almost all cases, a developer will and should not know what display server technology to develop against. A developer either works in terms of a toolkit or in terms of egl/gl(es). And both Wayland and Mir provide client side egl integration as well as accelerated gl to clients/developers
[08:35] <Ranomier> From ground up there have to be ONE well defined API for graphical Programms and DEs.
[08:36] <Ranomier> If i write a game i dont use a toolkit and our company have his own little toolkit.
[08:38] <Ranomier> And the devoloper of the toolkit have that problem, it is no solution to say: u dant have care about the display server.
[08:38] <tvoss> Ranomier, cool, even better. If you are doing games, I'm assuming that you are doing egl/gl(es)?
[08:39] <Ranomier> I dont know im learning programming, i dont now how to write a game, im a coding bigginner.
[08:40] <tvoss> Ranomier, perhaps you can find out, but I'm pretty sure that egl/gl(es) is what you are using. Any pointers to your company's website, or the abstraction layers they use? Are you using SDL (2.0)?
[08:41] <Ranomier> No im using nothing^^ Im learning coding at the moment with the basics libs of c++
[08:43] <tvoss> Ranomier, you might want to look into Mir's code then, it's using c++, too and it leverages/illustrates a lot of modern c++ techniques
[08:49] <Ranomier> Yeah i know buts wrong about c?
[08:49] <Ranomier> linux is mostly written in c
[08:50] <tvoss> Ranomier, linux as in? what's wrong with c++? you are learning it yourself?
[08:51] <Ranomier> because wayland is written in c , nothing is wrong about c++ or c
[08:52] <tvoss> Ranomier, I think I don't understand your argument. Wayland is written in C, fine. Mir is written in C++. It's an implementation detail, nothing more
[08:52] <Ranomier> sry i missunderstood u
[08:59] <Ranomier> Ok i have to go to work now, i think it is not good to fragment the basics of linux. i think it is important to be compatible with one standart. See http://en.wikipedia.org/wiki/Freedesktop.org
[09:00] <Ranomier> after X
[09:00] <Ranomier> bye for now
[09:08] <katie> tvoss, duflu could we just have a quick hangout to discuss the edges. I think that'd be easier than me writing another email..
[09:09] <katie> (doesn't have to be now, could be on Monday morning)
[09:10] <duflu> katie: Yes, but no. May hangout the other day failed because my audio is totally broken. Let me see if it's fixed since upgrading/rebooting
[09:10] <duflu> -May +My
[09:11] <duflu> katie: On the other hand, I've already expressed my opinion (which is not changing). I'm happy to let you fight/discuss with tvoss :)
[09:11] <tvoss> katie, duflu I'm fine with Monday, too
[09:12] <duflu> It's such a minor change to add another enum and test cases. We don't need to make an issue of it. Just let me know which way to implement it. And no rush
[09:13] <tvoss> duflu, ack and thx :) you should be in the weekend now, shouldn't you?
[09:13] <duflu> tvoss: Not quite yet. But I should start thinking about dinner soon
[09:13] <katie> duflu.. ok :)
[09:14] <smspillaz> duflu: dinner? I only just had lunch :(
[09:14] <duflu> smspillaz: Enjoy student-hood. But I'll refrain from suggesting these are the best years of your life
[09:15] <smspillaz> duflu: there is a certain number of times you hear the words "your research assignment is due"
[09:15] <smspillaz> before it starts to take out on your social life
[09:15] <smspillaz> and / or sanity
[09:15] <smspillaz> aha.
[09:15] <katie> tvoss, do you have time for a quick catchup hangout?
[09:15] <katie> now
[09:16] <katie> ?
[09:20] <tvoss> katie, is in 45 minutes fine for you? would like to finish a document and a mail
[09:21] <katie> tvoss, sure
[09:21] <tvoss> katie, cool, thx :)
[10:10] <mardy> tvoss: I edited the page (added one paragraph): https://wiki.ubuntu.com/OnlineAccounts#preview
[10:10] <mardy> tvoss: please let me know if/how I should take this further
[10:11] <tvoss> mardy, ack, let me take a look. I will make sure that kgunn knows about it, too
[10:33] <katie> hey tvoss, time for a chat now?
[10:34] <tvoss> katie, sure, let me grab headset
[10:54] <ogra_> tvoss, (you aret in -touch, so i'm pinging here)  ... seems the latest changes to platform-api break the android builds ... https://code.launchpad.net/~ogra/platform-api/fix-config-generation/+merge/158560 should fix that i think
[10:54] <ogra_> (you approved the breaking change apparently)
[10:54] <tvoss> ogra_, hmmm, as jenkins signalled all good :)
[10:54] <tvoss> ogra_, but thanks for pointing out
[10:54] <ogra_> yeah, its weird
[10:55] <ogra_> it made the andrpidn image builds fail which jenkins didnt catch either
[10:55] <ogra_> (todays touch image builds only consist of a rootfs and jenkins considered that a good build)
[10:55] <tvoss> okay, that's a weird fix
[10:55] <ogra_> i'm not a cmale pro :) but all docs i find use it capitalized
[10:55] <ogra_> *cmake
[10:56] <ogra_> if you have a better idea why there is no config.h in the end, please apply that one instead :)
[10:57] <ogra_> we apparenlty end up without that file
[10:57] <tvoss> let me check again
[10:57] <tvoss> ogra_, ^
[10:57] <ogra_> yup
[11:02] <tvoss> kgunn, ping
[11:03] <kgunn> tvoss: pong
[11:04] <tvoss> kgunn, good morning :) had a conversation with mardy earlier on about "embedding" surfaces, I asked him to note down the req. in https://wiki.ubuntu.com/OnlineAccounts
[11:04] <kgunn> tvoss: good one....like embedded video in dash
[11:06] <tvoss> kgunn, which could be solved differently. I'm not sure an embedded surface is the best way to model/implement htis
[11:09] <kgunn> tvoss: guess it depends on what your definitions/assumptions about embedded surf is...what are you thinking? (or what's the concern?)
[11:10] <tvoss> kgunn, for me, the dash reasoning in terms of a texture, that a video decoder streams to is a better abstraction.
[11:11] <kgunn> tvoss: ok, you mean, dash is just a client app to the video engine? (vs dash actually interacting w video app)
[11:12] <kgunn> tvoss: but then you might be duplicating effort for VCR controls, time bar...unless you have common widgets
[11:12] <tvoss> kgunn, ack, the dash uses the decoding service, and receives a decoded image stream as a result
[11:13] <tvoss> kgunn, agreed, but think about the user scrolling the dash while playing the video
[11:14] <tvoss> kgunn, if the surface should really be embedded, the compositor would need to know about that
[11:14] <kgunn> tvoss: mmm, don't see why that would be a problem? (unless you're pointing to compositing synch where you have the video window lagging)
[11:14] <kgunn> tvoss: true
[11:15] <tvoss> kgunn, which breaks encapsulation to a certain degree. A surface is atomic to the compositor
[11:16] <kgunn> tvoss: right...back to orig ques, assumptions on "what means embedded"
[11:16] <kgunn> tvoss: you could truly have a seperate surf...e.g. it just appears embedded
[11:16] <tvoss> kgunn, right. if the preview is just an overlay, all good. If it should be seamlessly embedded into the dash, it is way more difficult
[11:17] <kgunn> tvoss: and actually...that's when you see "weirdness" in video it when the fmwk is trying to "cut a hole" in the scene graph somehow to stream video in
[11:17] <tvoss> kgunn, and as I see it on the wiki, we are talking about truly embedded for the use-case at hand
[11:18] <tvoss> kgunn, exactly. If it is a texture, and dash composites its content, things are way easier
[11:18] <kgunn> tvoss: ok, yeah....you have a +1 here for "embedded" just meaning another surface composited on top
[11:18] <tvoss> kgunn, we should clarify with design, especially for the signon-ui use-case
[11:18] <kgunn> tvoss: w/ eglimages (aka texture stream)....i think the perf will be high enough....
[11:19] <kgunn> tvoss: in the past we always got into weird bypass mechanisms for video
[11:19] <tvoss> kgunn, I would think so too, plus priv
[11:19] <kgunn> tvoss: that never were quite right :)
[11:20] <kgunn> tvoss: yes, another reason, drm
[11:20] <tvoss> kgunn, exactly, and performance with the android approach of relying on http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt is performing really well on Ubuntu Touch right now
[11:20] <kgunn> tvoss: yep
[15:07] <alf_> status: mostly reviewing
[15:07] <kdub> good morning, status, mp'd my changes to the android display
[15:08] <kdub> thanks for the review alf_ :)
[15:14] <alf_> kdub: it's not done yet, but my mind has been fried today by too much reviewing :)
[15:34] <kgunn> kdub: ...that had to feel good to get that sucker in mp shape...nice job
[15:38] <kdub> thanks kgunn, it does feel good to give it some air
[15:39] <alf_> kdub: racarr: kgunn: btw, please try the VT switching (in trunk, don't forget to run it with root priveleges!), and let me know if you have any issues. I haven't had the chance to try it on many systems yet.
[15:45] <kdub> kgunn, should make our android display story much more flexible... we even have a primitive layer list for hwc now!
[15:47] <tvoss> kdub, did you have a chance to measure performance, yet?
[15:51] <kdub> tvoss, not in a quantified way
[15:56] <tvoss> kdub, and in a totally subjective way?
[15:57] <kdub> well, for the qml demo yes, with the mir_egl* demo's they seem to run at vsync rate
[16:02] <tvoss> kdub, okay
[16:25] <kdub> annoying how nicemocks don't work with noexcept very well
[16:47] <alf_> quick update on vt switching: The basic use case (running mir and switching from/to VT) works, as long as we don't have new clients trying to connect or requesting things from the server. We will need to block this at at the communicator level, that is, when we are paused we will need to accept but block all client requests.
[16:47] <alf_> kgunn: ^^
[17:09] <racarr> reading the C++14 papers is eird
[17:09] <racarr> weird*
[17:14] <kgunn> alf_: ack
[17:15] <kgunn> alf_: so basically don't be launching/closing apps in the midst of swithing
[17:15] <kgunn> ?
[17:25] <racarr> kdub: I feel like you and I love bzr commit the most
[17:25] <racarr> when I see things like rev 659 from jenkins
[17:25] <racarr> im like oh thats me or kdub
[17:26] <kdub> racarr, haha, indeed :)
[20:32] <kgunn> kdub: hey....we don't have bypass comp do we ?
[20:32] <kdub> kgunn, nope
[20:33] <kdub> there's a blueprint entry for it though
[20:33] <kgunn> kdub: or...well...do we if we say "hey hwc1.1 here's 1 layer"....then it says "oh, i can do that"
[20:33] <kgunn> kdub: right...we don't have it for "gpu as fallback path"
[20:34] <kdub> kgunn, i don't see how all those comments relate :)
[20:34] <kdub> we have the gpu fallback path (if the hwcomposer.<platform>.so is missing)
[20:36] <kdub> and hwc at the moment just works on one layer
[20:39] <kgunn> kdub: right...i'm cheating
[20:40] <kgunn> i just know that "most" platforms use HWC to be the bypass composition
[20:40] <kgunn> kdub: its kind of irrelevant....the gpu comp path is the one  that matters to me....
[20:40] <kgunn> ....more planning :|~
[20:54] <kdub> if a bug on lp is a potential duplicate, what's the right state to put it in?
[21:06] <kgunn> kdub: isn't duplicate a potential state ?
[21:07] <kgunn> kdub: at least i always put a note in each w/ the respective dups' link in it....then pick one to work & mark the other dup
[21:07] <kdub> no, seems 'incomplete' with a comment about duplication is the way most people do it
[21:07] <kgunn> kdub: otherwise verbalize its a dup & state can be reject
[21:08] <kgunn> kdub: ah...there you go
[21:08] <kgunn> weird choice....but....a convention at least :)