[00:50] <thiagoandrade> I can see the work items on launchpad, but how should I proceed in case I want to help some specific work item? Should I talk to the responsible for it or what?
[00:51] <bryce> thiagoandrade, yes.  Or if you're not sure who to talk to, ask robert or thomas for guidance.
[06:11] <llstarks> why mir? why not smithers?
[06:20] <RAOF> Why not Zoidberg?
[06:44] <duflu> "Zoidberg ate my windows" sounds plausible
[06:53] <tvoss> good morning :)
[07:14] <llstarks> RAOF, don't let #wayland get under your skin. mir actually works. i've never seen a working wayland environment outside of rebecca black
[07:14] <llstarks> or weston
[07:20] <RAOF> Well, I got to roughly the point that we're currently at with respect to a system compositor some 6 months or so ago with weston :)
[08:23] <llstarks> RAOF, can you rephrase that? i interpreted that as "mir is where weston was 6 months ago"
[08:24] <llstarks> i'm probably just too tired to think straight
[08:34] <RAOF> llstarks: Well, it's not so much "mir is where weston was 6 months ago" as "weston could do this thing, 6 months ago, that mir does now".
[08:36] <tvoss> RAOF, admittedly focusing on the desktop form-factor, right?
[08:36] <RAOF> tvoss: Indeed.
[08:36] <RAOF> And it's not much help *weston* being able to do something, because weston isn't actually intended to be used.
[08:37] <RAOF> It's more a testbed.
[08:37] <tvoss> RAOF, yup
[10:00] <testi> Will Applications compiled for Mir run natively without compatibility layer (protocol translation, additional context switches) on Wayland Compositors? Does that apply for the other direction too? By application I mean anything not deeply integrated with the system, especially games, because under no circumstances I want Mir to introduce any delay (context switch, protocol translation) only because some game developer has chosen Mir as targ
[10:00] <testi> Is Mir capable of reliable bypass offscreen on fullscreen? (also in order to reduce delays)?
[10:01] <testi> in my last tests compiz is not reliable in that, while kwin does a good job
[10:05] <tvoss> testi, for your app related question: It's a question of the toolkit integration. So the integration work with the compositor normally happens on the toolkit layer (Qt/GTK/XUL...), so apps talk the native language of the compositor
[10:06] <tvoss> testi, for non-composited fullscreen: yes, we are working on that. Any specific use-case apart from fullscreen games/apps you have in mind?
[10:07] <testi> tvoss: and by a strongly-propaged default any toolkit will be compiled with both mir and wayland support?
[10:08] <tvoss> testi, toolkits normally have a platform abstraction layer that is pluggable at runtime. Qt for example allows you to switch the actual backend implementation by setting an environment variable
[10:08] <tvoss> testi, I'm not sure about the exact mechanism for GTK3, but I think it should support that
[10:08] <testi> I actually just have games in mind. That's all I care and I just want them to make the shortest path from input to screen, no matter what compositor I use.
[10:09] <testi> except for X11 I'd accept an external wrapper-server and protocol translation
[10:10] <tvoss> testi, @games: sure, we will optimize unredirected fullscreen and optimize for cases where pixel-type of a surface is xrgb and a surface is fullscreen
[10:11] <tvoss> testi, any specific game-engine you have in mind?
[10:12] <testi> tvoss: Unigine, ioquake3, warsow, xonotic, any wined3d game, any wine opengl game, Source Engine, Doom3
[10:13] <tvoss> testi, that's a comprehensive list :) I hope I could answer your question?
[10:15] <testi> tvoss: I just wonder what happens when a game supports wayland only - will there be a wrapper-server, or will it be an in-process module of the Display-Server without any wrapping, in other words equally short paths, no additional context switch
[10:17] <tvoss> testi, right now, if a game only supports wayland, it will not run against mir. However, a wrapping approach would be one way to solve it, essentially allowing the game to talk wayland to Mir, and then switching to unredirected fullscreen.
[10:18] <llstarks> tvoss, what will wayland/mir-enabled video players be like on ubuntu touch? for example, mplayer2 and mpv support wayland. if they support mir in the future, would i be able to compile or use an armhf binary and run it on the phone?
[10:18] <testi> but then wayland is not translated to Mir? it directly reports to the inner agnostic core? And there is no delay because of that? And mir is basically a Display Server which speaks 2 languages and Mir is only offically but not physically the main protocol?
[10:19] <tvoss> llstarks, sure. Again, most of the applications will rely on a toolkit and we will work towards enabling them for Mir
[10:20] <tvoss> testi, right, think about the protocol as a bridge to a certain degree. Almost all of the rendering is anyway done via the (e)gl(es) drivers, i.e., the actual buffer content is not transmitted via any protocol
[10:21] <testi> tvoss: I know, but input events are
[10:22] <tvoss> testi, sure, those would need to be translated
[10:22] <testi> tvoss: translated into Mir?
[10:23] <tvoss> testi, from Mir into Wayland, to be picky here, but yes
[10:23] <testi> tvoss: of course
[10:25] <testi> tvoss: but why? It doesn't need to talk "Mir" if it ends up in a wayland client.
[10:26] <tvoss> testi, at some point, things from the core need to be mapped to a protocol/communication layer, that's where the translation happens. That's server-side though, not client side
[10:27] <testi> tvoss: but then it's not mapped from protocol to protocol, but from the core directly to wayland?
[10:27] <tvoss> testi, yup
[10:28] <testi> tvoss: Well okay - if these are the goals, I'm fine - I'm a bit a latency/performance fanatic
[10:29] <tvoss> testi, fair enough, we all are :) we are working to put quite extensive benchmarking in place, too
[10:29] <tvoss> testi, for the ubuntu touch demos, we used highspeed cameras twice to check on our actual frame rate and responsiveness to input
[10:33] <testi> :-)
[11:35] <xnox> Can I run raring unity on mir on amd64?
[11:35] <xnox> If so, where and how? =)
[11:40] <alan_g> xnox: soon (I'm not sure of exact status - some packages were missing)
[11:40] <alf_> xnox: You can run unity3d (i.e. the current unity) on X11 on xmir. We are in the process of setting up detailed instructions for that (and other things).
[11:40] <alan_g> xnox: And instructions
[11:40] <alan_g> alf_: snap
[11:41] <xnox> ok. I'm fine with early breakge and stuff. Cause i work on upstart usersessions, so I'd like to see if I can be monitoring / respawning mir with upstart user session support.
[11:41]  * xnox is running current ubuntu session like that, we are planning on merging and landing upstart1.7 soon.
[11:42] <tvoss|food> xnox, you might want to talk to robert_ancell, too
[11:42] <tvoss|food> xnox, he is offline, currently
[11:42] <xnox> tvoss|food: is he usually in this channel?
[11:43]  * xnox ponders about pointing to "juju deploy znc" ;-)
[11:50] <tvoss|food> xnox, yup
[13:47] <pete-woods1> irc://irc.canonical.com:6697/#ubuntu-uds-client-2
[13:47] <pete-woods1> d'oh
[13:47] <pete-woods1> :-$
[13:56] <tvoss> pete-woods, :)
[15:25] <thiagoandrade> Following the instructions in HACKING.md I get errors in the command mk-build-deps and it simply states 'dpkg call error'
[15:26] <thiagoandrade> How should I proceed to build?
[15:28] <thiagoandrade> Ok, managed it. There was an error in the command.
[15:29] <alan_g> thiagoandrade: what was the error?
[15:32] <thiagoandrade> alan_g, I forgot a dash in the tool option
[15:32] <thiagoandrade> Just realized after.
[15:32] <alan_g> thiagoandrade: ok. Thanks
[16:12] <kdub> bumping to g++4.7!
[16:24] <kdub> alan_g, do you think i should doc the android stuff in HACKING.md or on the wiki?
[16:24] <kdub> i'm leaning towards HACKING.md
[16:25] <alan_g> kdub: Is there enough to be  HACKING-android.md?
[16:26] <kdub> yeah, there is... i'll do that
[16:26] <alan_g> kdub: but I favour the source tree. (We should be getting the make doc output up on a webserver.)
[16:26] <bryce> kdub, principle documentation should ship with the code
[16:27] <kdub> yeah, i was just about to say... would be nice if the HACKING.md files ended up on a webpage
[16:46] <AlanBell> what kind of configurations will mir support? dual screen? multiple screens? orientation changes? different colour depth screens like an e-ink screen on the back of a regular screen etc?
[16:50] <bryce> AlanBell, long term, yes to all
[16:51] <bryce> last I checked a couple weeks ago, it does clone mode on dual-head ok (as set up by drm), but not hotplugging or anything fancy
[16:52] <bryce> the configuration dialog will probably be more minimal than the current one, but we expect to have some advanced settings tool.
[17:02] <mmrazik> thomi: we would need the output of make doc to appear on some public site for mir :)
[17:02] <mmrazik> thomi: so I thought you are the right person for it :)
[17:03] <thomi> mmrazik: good thing we now have a nice way to do that
[17:03] <thomi> mmrazik: will fil a bug & assign it to me so I don't forget
[17:03] <mmrazik> thomi: but we still need some special user on some server, etc, right?
[17:03] <mmrazik> thomi: cool
[17:03] <mmrazik> alan_g: ^^
[17:03] <thomi> mmrazik: yeah - will talk to is
[17:03] <alan_g> alf_: ^^
[17:04] <thomi> all: do you have any ideas about where you'd like it?
[17:04] <alf_> alan_g: \o/
[17:04] <thomi> perhaps somewhere on unity.ubuntu.com?
[17:04] <thomi> unity.ubuntu.com/mir/ ?
[17:05] <AlanBell> woot mir runs today \o/
[17:05] <thomi> or rather:
[17:05] <thomi> unity.ubuntu.com/mir/api/ for the API docs
[17:05] <AlanBell> so, I have a green box with a scrolly bacteria or something in it
[17:05] <alan_g> thomi: works for me
[17:05] <thomi> sweetbix
[17:05] <AlanBell> how do I do something more interesting with it?
[17:07] <alf_> thomi: the plan is to have the whole project site be part of the docs, so the information is always up to date, but we will see how that turns out
[17:08] <thomi> alf_: for autopilot, we just finished configuring it so the docs get uploaded at the end of the autolanding  process
[17:09] <thomi> alf_: I assume something similar for mir would work well
[17:09] <alan_g> AlanBell: what are you interested in? At the moment mir is a body waiting for a brain (the unity shell)
[17:09] <alan_g> thomi: that would be great
[17:10] <alf_> thomi: alan_g: Yes, it would work great. The question that needs answering on our side, is whether the docs will be used for the whole mir "site" or just for the API reference.
[17:10] <AlanBell> alan_g: dunno really, can I put a QML surface in it and poke about with phone apps?
[17:12] <thomi> alf_: right, that will determine if we want the /api/ suffix or not
[17:12] <thomi> alf_: I guess I can push them to .../api/ and we can always change it later
[17:12] <alf_> thomi: sure
[17:13] <AlanBell> or can I implement windows 7 on it http://xkcd.com/528/
[17:13] <alan_g> thomi: alf_ that's probably easiest. We'd need to pull content in to make it the main page.
[17:16] <thomi> ok, rt filed.
[17:20] <alf_> alan_g: thomi: hmm, looking at unity.ubuntu.com, I don't think that the contents we want to put into mir/ will fit with the rest of the design. I am not sure how much of a problem this is.
[17:21] <thomi> alan_g: all those sections have a /api/ section as well
[17:21] <thomi> for example:
[17:21] <thomi> unity.ubuntu.com/autopilot/api/
[17:21] <kdub> AlanBell, thats a space station, not scrolly bacteria :)
[17:21] <alan_g> AlanBell: Sorry, trying to find someone that can advise on details
[17:21] <thomi> actually, that's a bad example, since we don't have a non-api section :)
[17:21] <thomi> alan_g: but you see what I mean, hopefully :)
[17:21] <AlanBell> kdub: ah, my scale was out slightly
[17:22] <kdub> AlanBell, phone demos on the desktop, a tricky to set up
[17:22] <kdub> not sure if anyone's done it yet
[17:22] <AlanBell> well, I am trying to do anything with it really
[17:22] <alf_> thomi: yes, thanks, I was mostly concerned about the visual differences but it seems it's not a problem (e.g. http://unity.ubuntu.com/autopilot/ is very different too)
[17:23] <kdub> AlanBell, i live mostly in the world of android headaches, not sure what precisely is possible on desktop these days...
[17:24] <thomi> alf_: yeah. We can always move things around if we need
[17:24] <kdub> racarr might be able to advise how to get those qml demos going
[17:24] <alf_> AlanBell: you need to get qmir from launchpad.net/qmir and build it (you need qt5)
[17:24] <alan_g> alf_: thomi there's quite a bit of tailoring we can do to L&F of doxygen output
[17:25] <thomi> yeah
[17:25] <alan_g> thomi: alf_ let's do the simplest thing (get what we have up) and iterate
[17:26] <thomi> agreed
[17:26] <AlanBell> alf_: oh, cool thanks
[17:26] <kdub> thanks alf_
[17:26] <alf_> AlanBell: then under mir you can run (m)any of the example qt5 applications by passing the "-platform mir" option to the qt app
[17:27] <alf_> AlanBell: note: no input yet
[17:27] <AlanBell> ok, so I can't make the eyes flash on ctrl+alt+del :(
[17:29] <AlanBell> no readme or makefile or anything in the qmir branch
[17:31] <alf_> AlanBell: unfortunately no, we are working on organizing the documentation as you may have noticed from the conversations here...
[17:54] <racarr> Met with Katie, nailing down focus concepts, "application focus" (for menu bar, launcher pips, etcs...) "window focus" and "stage focus" (input focus)
[17:54] <racarr> and "display focus" for shell components
[17:55] <racarr> very similar to how on the whiteboard in London but we wrote it down this time
[18:58] <FunnyLookinHat> Any talk regarding hybrid graphics with Mir?  Last I checked we were on the goal-line with using the X Stack ( ideally for a 13.10 support of Optimus w/ Binary Blobs ) -
[18:59] <bryce> there won't be a 13.10.
[19:00] <bryce> FunnyLookinHat, I don't know what you mean by on the goal-line, but we decided not to pursue hybrid support on the X side, aside from whatever comes from upstream.  There has been talk for how to  support it in Mir, and the design accounts for multi-gpu / multi-head / multi-hotplugging situations
[19:02] <FunnyLookinHat> bryce, Right right - I meant looking forward before all of the RR talk.
[19:02] <FunnyLookinHat> bryce, but that answers my question ( i.e. accounting for multiple gpu / head / hotplug ) - thanks :)
[19:34] <UbuPhillup> Question: will I be able to run Virtualbox full screen in Mir? Will the input handling stop the HUD stealing my alt key?
[19:37] <bryce> UbuPhillup, virtualization came up at yesterday's Mir talk, although I don't think it got a detailed answer (I'm not sure I could articulate what the answer is, at least).
[19:39] <UbuPhillup> bryce: thanks i will watch at the talk
[19:39] <bryce> regarding input handling, well we're looking at an entirely different stack.  But HUD behavior is going to be a shell  thing, so that might not be a question for Mir as much.
[19:40] <bryce> there's a long list of input issues which I gather folks hope Mir can give us better solutions
[19:41] <UbuPhillup> ;)
[19:50] <thiagoandrade> I'm following the instructions under HACKING.md and when I run 'cmake ..' I get a message "Cannot enable coverage targets because neither lcov nor gcovr are found. Configuring incomplete, errors occurred!"
[19:51] <thiagoandrade> Is there any other dependency I should install that is not covered in that document?
[20:06] <AlanBell> are you on raring thiagoandrade?
[20:07] <thiagoandrade> AlanBell, no
[20:07] <thiagoandrade> I'm on 12.04
[20:07]  * AlanBell is on raring, it worked eventually
[20:08] <AlanBell> don't recall seeing that error message, but I had some problems which were my system's fault
[20:10] <AlanBell> is there going to be a new window manager to run in mir?
[20:10] <thiagoandrade> It's strange to me because there is a "Getting dependencies" step that didn't got all the dependencies. And there is nothing telling that I need to be on raring to make Mir work.
[20:10] <AlanBell> to do the window decoration, title bar, borders etc
[20:11] <AlanBell> thiagoandrade: I dunno, you might be fine on 12.04 if you install the patched mesa from today
[20:12] <AlanBell> but raring is fine, I have been using it daily for months (even with raring-proposed accidentally enabled) and it is fine
[20:17] <TheMuso> AlanBell: As far as I understand things at this point, the unity shell in combination with MIR will do window management...
[20:17] <TheMuso> Somewhat similar to how GNOME shell integrates with mutter to handle window management.
[20:17] <TheMuso> Although probably more integrated.
[20:38] <bryce> TheMuso, btw Mir should not be all-caps.  (MIR might get confused with Main Inclusion Request).
[20:39] <TheMuso> bryce: Sorry, its party a typo,a dn party a habbit.
[20:39] <TheMuso> gah typing == bad.
[20:39] <TheMuso> Its partly a typo and partly a habbit.
[20:40] <bryce> habit?  ;-)
[20:44] <TheMuso> Yeah, dunno why, but it is. Probably from having to deal with main inclusion reports. :)
[20:45] <TheMuso> And writing the shorthand for that.
[23:36] <thiagoandrade> robertcarr, What can I do to help you with in process EGL work item?