[00:50] 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] thiagoandrade, yes. Or if you're not sure who to talk to, ask robert or thomas for guidance. [06:11] why mir? why not smithers? === tvoss|eod is now known as tvoss [06:20] Why not Zoidberg? [06:44] "Zoidberg ate my windows" sounds plausible [06:53] good morning :) [07:14] 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] or weston [07:20] 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] RAOF, can you rephrase that? i interpreted that as "mir is where weston was 6 months ago" [08:24] i'm probably just too tired to think straight [08:34] 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] RAOF, admittedly focusing on the desktop form-factor, right? [08:36] tvoss: Indeed. [08:36] And it's not much help *weston* being able to do something, because weston isn't actually intended to be used. [08:37] It's more a testbed. [08:37] RAOF, yup [10:00] 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] Is Mir capable of reliable bypass offscreen on fullscreen? (also in order to reduce delays)? [10:01] in my last tests compiz is not reliable in that, while kwin does a good job [10:05] 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] 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] tvoss: and by a strongly-propaged default any toolkit will be compiled with both mir and wayland support? [10:08] 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] testi, I'm not sure about the exact mechanism for GTK3, but I think it should support that [10:08] 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] except for X11 I'd accept an external wrapper-server and protocol translation [10:10] 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] testi, any specific game-engine you have in mind? [10:12] tvoss: Unigine, ioquake3, warsow, xonotic, any wined3d game, any wine opengl game, Source Engine, Doom3 [10:13] testi, that's a comprehensive list :) I hope I could answer your question? [10:15] 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] 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] 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] 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] llstarks, sure. Again, most of the applications will rely on a toolkit and we will work towards enabling them for Mir [10:20] 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] tvoss: I know, but input events are [10:22] testi, sure, those would need to be translated [10:22] tvoss: translated into Mir? [10:23] testi, from Mir into Wayland, to be picky here, but yes [10:23] tvoss: of course [10:25] tvoss: but why? It doesn't need to talk "Mir" if it ends up in a wayland client. [10:26] 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] tvoss: but then it's not mapped from protocol to protocol, but from the core directly to wayland? [10:27] testi, yup [10:28] tvoss: Well okay - if these are the goals, I'm fine - I'm a bit a latency/performance fanatic [10:29] testi, fair enough, we all are :) we are working to put quite extensive benchmarking in place, too [10:29] testi, for the ubuntu touch demos, we used highspeed cameras twice to check on our actual frame rate and responsiveness to input === tvoss is now known as tvoss|food [10:33] :-) [11:35] Can I run raring unity on mir on amd64? [11:35] If so, where and how? =) [11:40] xnox: soon (I'm not sure of exact status - some packages were missing) [11:40] 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] xnox: And instructions [11:40] alf_: snap [11:41] 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] xnox, you might want to talk to robert_ancell, too [11:42] xnox, he is offline, currently [11:42] tvoss|food: is he usually in this channel? [11:43] * xnox ponders about pointing to "juju deploy znc" ;-) [11:50] xnox, yup === tvoss|food is now known as tvoss [13:47] irc://irc.canonical.com:6697/#ubuntu-uds-client-2 [13:47] d'oh [13:47] :-$ === pete-woods1 is now known as pete-woods [13:56] pete-woods, :) === wolfslord is now known as thiagoandrade [15:25] Following the instructions in HACKING.md I get errors in the command mk-build-deps and it simply states 'dpkg call error' [15:26] How should I proceed to build? [15:28] Ok, managed it. There was an error in the command. [15:29] thiagoandrade: what was the error? [15:32] alan_g, I forgot a dash in the tool option [15:32] Just realized after. [15:32] thiagoandrade: ok. Thanks [16:12] bumping to g++4.7! [16:24] alan_g, do you think i should doc the android stuff in HACKING.md or on the wiki? [16:24] i'm leaning towards HACKING.md [16:25] kdub: Is there enough to be HACKING-android.md? [16:26] yeah, there is... i'll do that [16:26] kdub: but I favour the source tree. (We should be getting the make doc output up on a webserver.) [16:26] kdub, principle documentation should ship with the code [16:27] yeah, i was just about to say... would be nice if the HACKING.md files ended up on a webpage [16:46] 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] AlanBell, long term, yes to all [16:51] 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] the configuration dialog will probably be more minimal than the current one, but we expect to have some advanced settings tool. [17:02] thomi: we would need the output of make doc to appear on some public site for mir :) [17:02] thomi: so I thought you are the right person for it :) [17:03] mmrazik: good thing we now have a nice way to do that [17:03] mmrazik: will fil a bug & assign it to me so I don't forget [17:03] thomi: but we still need some special user on some server, etc, right? [17:03] thomi: cool [17:03] alan_g: ^^ [17:03] mmrazik: yeah - will talk to is [17:03] alf_: ^^ [17:04] all: do you have any ideas about where you'd like it? [17:04] alan_g: \o/ [17:04] perhaps somewhere on unity.ubuntu.com? [17:04] unity.ubuntu.com/mir/ ? [17:05] woot mir runs today \o/ [17:05] or rather: [17:05] unity.ubuntu.com/mir/api/ for the API docs [17:05] so, I have a green box with a scrolly bacteria or something in it [17:05] thomi: works for me [17:05] sweetbix [17:05] how do I do something more interesting with it? [17:07] 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] alf_: for autopilot, we just finished configuring it so the docs get uploaded at the end of the autolanding process [17:09] alf_: I assume something similar for mir would work well [17:09] AlanBell: what are you interested in? At the moment mir is a body waiting for a brain (the unity shell) [17:09] thomi: that would be great [17:10] 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] alan_g: dunno really, can I put a QML surface in it and poke about with phone apps? [17:12] alf_: right, that will determine if we want the /api/ suffix or not [17:12] alf_: I guess I can push them to .../api/ and we can always change it later [17:12] thomi: sure [17:13] or can I implement windows 7 on it http://xkcd.com/528/ [17:13] thomi: alf_ that's probably easiest. We'd need to pull content in to make it the main page. [17:16] ok, rt filed. [17:20] 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] alan_g: all those sections have a /api/ section as well [17:21] for example: [17:21] unity.ubuntu.com/autopilot/api/ [17:21] AlanBell, thats a space station, not scrolly bacteria :) [17:21] AlanBell: Sorry, trying to find someone that can advise on details [17:21] actually, that's a bad example, since we don't have a non-api section :) [17:21] alan_g: but you see what I mean, hopefully :) [17:21] kdub: ah, my scale was out slightly [17:22] AlanBell, phone demos on the desktop, a tricky to set up [17:22] not sure if anyone's done it yet [17:22] well, I am trying to do anything with it really [17:22] 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] AlanBell, i live mostly in the world of android headaches, not sure what precisely is possible on desktop these days... [17:24] alf_: yeah. We can always move things around if we need [17:24] racarr might be able to advise how to get those qml demos going [17:24] AlanBell: you need to get qmir from launchpad.net/qmir and build it (you need qt5) [17:24] alf_: thomi there's quite a bit of tailoring we can do to L&F of doxygen output [17:25] yeah [17:25] thomi: alf_ let's do the simplest thing (get what we have up) and iterate [17:26] agreed [17:26] alf_: oh, cool thanks [17:26] thanks alf_ [17:26] 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] AlanBell: note: no input yet [17:27] ok, so I can't make the eyes flash on ctrl+alt+del :( [17:29] no readme or makefile or anything in the qmir branch [17:31] AlanBell: unfortunately no, we are working on organizing the documentation as you may have noticed from the conversations here... [17:54] Met with Katie, nailing down focus concepts, "application focus" (for menu bar, launcher pips, etcs...) "window focus" and "stage focus" (input focus) [17:54] and "display focus" for shell components [17:55] very similar to how on the whiteboard in London but we wrote it down this time === netcurli_ is now known as netcurli === mmrazik_ is now known as mmrazik [18:58] 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] there won't be a 13.10. [19:00] 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] bryce, Right right - I meant looking forward before all of the RR talk. [19:02] bryce, but that answers my question ( i.e. accounting for multiple gpu / head / hotplug ) - thanks :) [19:34] 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] 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] bryce: thanks i will watch at the talk [19:39] 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] there's a long list of input issues which I gather folks hope Mir can give us better solutions [19:41] ;) [19:50] 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] Is there any other dependency I should install that is not covered in that document? [20:06] are you on raring thiagoandrade? [20:07] AlanBell, no [20:07] I'm on 12.04 [20:07] * AlanBell is on raring, it worked eventually [20:08] don't recall seeing that error message, but I had some problems which were my system's fault [20:10] is there going to be a new window manager to run in mir? [20:10] 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] to do the window decoration, title bar, borders etc [20:11] thiagoandrade: I dunno, you might be fine on 12.04 if you install the patched mesa from today [20:12] but raring is fine, I have been using it daily for months (even with raring-proposed accidentally enabled) and it is fine [20:17] AlanBell: As far as I understand things at this point, the unity shell in combination with MIR will do window management... [20:17] Somewhat similar to how GNOME shell integrates with mutter to handle window management. [20:17] Although probably more integrated. [20:38] TheMuso, btw Mir should not be all-caps. (MIR might get confused with Main Inclusion Request). [20:39] bryce: Sorry, its party a typo,a dn party a habbit. [20:39] gah typing == bad. [20:39] Its partly a typo and partly a habbit. [20:40] habit? ;-) [20:44] Yeah, dunno why, but it is. Probably from having to deal with main inclusion reports. :) [20:45] And writing the shorthand for that. [23:36] robertcarr, What can I do to help you with in process EGL work item?