#ubuntu-mir 2013-03-05
<luc37> will Mir be available on *BSDs? ;)
<duflu> luc37: I think that will be a direct function of Mir's success on Linux first. But there's no reason why not... eventually :)
<luc37> haha! I think Mir sounds too wonderful to be real
<luc37> or everyone hates the x server, i guess ;)
<luc37> duflu: well, if it's a simpler solution than wayland, let's hope the best for Mir
<tvoss> Good morning :)
<llstarks> why go mir instead of iss or opsek?
<llstarks> canonical is living the past
<llstarks> lololololololol according to slashdot et all
<llstarks> *al
<zAo^2_> Which license is used for Mir?
<RAOF> GPL3 for the core; LGPL3 for the client libraries.
<zAo^2_> Thanks RAOF
<AlanBell> morning all
<AlanBell> why doesn't libgl1-mesa-dri in the ppa contain libgallium.so.0?
<tvoss> RAOF, can you help AlanBell?
<tjaalton> likely because it's based on an older packaging
<tjaalton> we have 9.1 on a staging ppa with the shared libgallium build sorted out, iirc
<tjaalton> yup
<tjaalton> that's canonical-x/x-staging ;)
<tjaalton> without the mir bits
<zAo^2_> Can someone explain to me how Canonical make the schedule for Mir?
<tvoss> zAo^2_, happy to explain. What are you interested in especially?
<zAo^2_> tvoss: well, how can such a small team complete such a huge project within a year?
<tvoss> zAo^2_, first, the team is small in terms of numbers right now. That might change in the future. Second, number of developers is not always a good measure for efficiency
<zAo^2_> tvoss: True, but still; it's a major task don't you think?
<tvoss> zAo^2_, sure, I do fully agree, but we are confident about our timelines
<zAo^2_> tvoss: I really hope you make it. X needs to be put to rest. When can we expect the first alpha that can run (any sort of) desktop apps?
<tvoss> zAo^2_, thank you :) in between May 2013 and October 2013, we are focusing on the Ubuntu touch use-case right now, aiming for full convergence by April 2014
<AlanBell> tjaalton: ok, so it doesn't work without that it seems
<AlanBell> hmm, I had it complaining about the lack of libgallium.so.0 earlier, now it just segfaults
<Cheery> I read about https://wiki.ubuntu.com/MirSpec today.
<Cheery> and this might interest anyone working with Mir: https://devtalk.nvidia.com/default/topic/529486/general-graphics-programming/direct-rendering-access-on-linux/
<Cheery> I don't know.. but it feels to me that nvidia pretty much ignores anything that's related to opening a display context through any other way than glx.
<Cheery> I just wonder how you're going to do it.
<RAOF> Via the magic of EGL :)
<RAOF> More seriously, as mentioned on the MirSpec page, we're in discussion with nvidia.
<Cheery> if you're smart, I guess you'll try to come up with an API that would work also for wayland and whatever anyone else is doing.
<Cheery> anyway I'd hope I'll get some announcement once you get results.
<RAOF> If all goes well, yeah.
<AlanBell> anyone got it working on Raring?
<RAOF> I'm using it right now; xmir-on-mir-on-ati.
<AlanBell> ok, the client just segfaults for me
<RAOF> But I'm not sure if I'm using the same stuff as has landed in the public PPA :)
<AlanBell> I am using mir from trunk
<zyga> alf_: hey :)
<alf_> zyga: Hi!
<AlanBell> mesa from https://launchpad.net/~mir-team/+archive/staging/+packages?field.name_filter=&field.status_filter=published&field.series_filter=raring
<zyga> alf_: good work, to all of the team :)
<alf_> zyga: thanks
<Cheery> can I try out Mir on my desktop already?
<vibhav> Is it possible to have libx11\libxcb wrappers for Mir?
<vibhav> We could probably support more software/drivers then.
<tjaalton> you have xmir for that
<vibhav> tjaalton: ah, thanks
<AlanBell> Cheery: if you are on raring you can add the PPA to get the patched mesa packages and download and build the source from trunk
<AlanBell> it segfaults for me, but I would be interested in someone else's results from doing this
<AlanBell> I am astonished that there are no screenshots or videos to say how wonderful it is
<tvoss> AlanBell, working on that :)
<vibhav> I should start contributing to this project now
<jjardon> Hi, is the code for the GTK+ backend available somewhere?
<tvoss> jjardon, nope, not yet
<tvoss> AlanBell, ping
<AlanBell> hi tvoss
<chenxiaolong> Hi Mir developers!
<chenxiaolong> Does anyone know when the XMir code will be released? lp:~rocket-scientists/xserver/xmir
<RAOF> chenxiaolong: Ah. I haven't pushed that publicly yet? Whoops
<RAOF> chenxiaolong: You should be able to get just the source, but not the branch, from the PPA though?
<chenxiaolong> RAOF: I'm not seeing the source in the PPA yet
<chenxiaolong> You're talking about ppa:mir-team/staging, right?
<llstarks> RAOF, are we taking bets on whether mesa-devel accepts your proposal?
<RAOF> I don't really expect significant pushback on that.
<RAOF> It's self-contained, there are already 3 other platforms.
<llstarks> cool
<llstarks> RAOF, does mir work with edgers?
<RAOF> No; you need some mesa patches.
<llstarks> okay i'll downgrade
#ubuntu-mir 2013-03-06
<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?
<bryce> thiagoandrade, yes.  Or if you're not sure who to talk to, ask robert or thomas for guidance.
<llstarks> why mir? why not smithers?
<RAOF> Why not Zoidberg?
<duflu> "Zoidberg ate my windows" sounds plausible
<tvoss> good morning :)
<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
<llstarks> or weston
<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 :)
<llstarks> RAOF, can you rephrase that? i interpreted that as "mir is where weston was 6 months ago"
<llstarks> i'm probably just too tired to think straight
<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".
<tvoss> RAOF, admittedly focusing on the desktop form-factor, right?
<RAOF> tvoss: Indeed.
<RAOF> And it's not much help *weston* being able to do something, because weston isn't actually intended to be used.
<RAOF> It's more a testbed.
<tvoss> RAOF, yup
<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
<testi> Is Mir capable of reliable bypass offscreen on fullscreen? (also in order to reduce delays)?
<testi> in my last tests compiz is not reliable in that, while kwin does a good job
<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
<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?
<testi> tvoss: and by a strongly-propaged default any toolkit will be compiled with both mir and wayland support?
<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
<tvoss> testi, I'm not sure about the exact mechanism for GTK3, but I think it should support that
<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.
<testi> except for X11 I'd accept an external wrapper-server and protocol translation
<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
<tvoss> testi, any specific game-engine you have in mind?
<testi> tvoss: Unigine, ioquake3, warsow, xonotic, any wined3d game, any wine opengl game, Source Engine, Doom3
<tvoss> testi, that's a comprehensive list :) I hope I could answer your question?
<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
<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.
<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?
<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?
<tvoss> llstarks, sure. Again, most of the applications will rely on a toolkit and we will work towards enabling them for Mir
<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
<testi> tvoss: I know, but input events are
<tvoss> testi, sure, those would need to be translated
<testi> tvoss: translated into Mir?
<tvoss> testi, from Mir into Wayland, to be picky here, but yes
<testi> tvoss: of course
<testi> tvoss: but why? It doesn't need to talk "Mir" if it ends up in a wayland client.
<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
<testi> tvoss: but then it's not mapped from protocol to protocol, but from the core directly to wayland?
<tvoss> testi, yup
<testi> tvoss: Well okay - if these are the goals, I'm fine - I'm a bit a latency/performance fanatic
<tvoss> testi, fair enough, we all are :) we are working to put quite extensive benchmarking in place, too
<tvoss> testi, for the ubuntu touch demos, we used highspeed cameras twice to check on our actual frame rate and responsiveness to input
<testi> :-)
<xnox> Can I run raring unity on mir on amd64?
<xnox> If so, where and how? =)
<alan_g> xnox: soon (I'm not sure of exact status - some packages were missing)
<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).
<alan_g> xnox: And instructions
<alan_g> alf_: snap
<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.
 * xnox is running current ubuntu session like that, we are planning on merging and landing upstart1.7 soon.
<tvoss|food> xnox, you might want to talk to robert_ancell, too
<tvoss|food> xnox, he is offline, currently
<xnox> tvoss|food: is he usually in this channel?
 * xnox ponders about pointing to "juju deploy znc" ;-)
<tvoss|food> xnox, yup
<pete-woods1> irc://irc.canonical.com:6697/#ubuntu-uds-client-2
<pete-woods1> d'oh
<pete-woods1> :-$
<tvoss> pete-woods, :)
<thiagoandrade> Following the instructions in HACKING.md I get errors in the command mk-build-deps and it simply states 'dpkg call error'
<thiagoandrade> How should I proceed to build?
<thiagoandrade> Ok, managed it. There was an error in the command.
<alan_g> thiagoandrade: what was the error?
<thiagoandrade> alan_g, I forgot a dash in the tool option
<thiagoandrade> Just realized after.
<alan_g> thiagoandrade: ok. Thanks
<kdub> bumping to g++4.7!
<kdub> alan_g, do you think i should doc the android stuff in HACKING.md or on the wiki?
<kdub> i'm leaning towards HACKING.md
<alan_g> kdub: Is there enough to be  HACKING-android.md?
<kdub> yeah, there is... i'll do that
<alan_g> kdub: but I favour the source tree. (We should be getting the make doc output up on a webserver.)
<bryce> kdub, principle documentation should ship with the code
<kdub> yeah, i was just about to say... would be nice if the HACKING.md files ended up on a webpage
<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?
<bryce> AlanBell, long term, yes to all
<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
<bryce> the configuration dialog will probably be more minimal than the current one, but we expect to have some advanced settings tool.
<mmrazik> thomi: we would need the output of make doc to appear on some public site for mir :)
<mmrazik> thomi: so I thought you are the right person for it :)
<thomi> mmrazik: good thing we now have a nice way to do that
<thomi> mmrazik: will fil a bug & assign it to me so I don't forget
<mmrazik> thomi: but we still need some special user on some server, etc, right?
<mmrazik> thomi: cool
<mmrazik> alan_g: ^^
<thomi> mmrazik: yeah - will talk to is
<alan_g> alf_: ^^
<thomi> all: do you have any ideas about where you'd like it?
<alf_> alan_g: \o/
<thomi> perhaps somewhere on unity.ubuntu.com?
<thomi> unity.ubuntu.com/mir/ ?
<AlanBell> woot mir runs today \o/
<thomi> or rather:
<thomi> unity.ubuntu.com/mir/api/ for the API docs
<AlanBell> so, I have a green box with a scrolly bacteria or something in it
<alan_g> thomi: works for me
<thomi> sweetbix
<AlanBell> how do I do something more interesting with it?
<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
<thomi> alf_: for autopilot, we just finished configuring it so the docs get uploaded at the end of the autolanding  process
<thomi> alf_: I assume something similar for mir would work well
<alan_g> AlanBell: what are you interested in? At the moment mir is a body waiting for a brain (the unity shell)
<alan_g> thomi: that would be great
<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.
<AlanBell> alan_g: dunno really, can I put a QML surface in it and poke about with phone apps?
<thomi> alf_: right, that will determine if we want the /api/ suffix or not
<thomi> alf_: I guess I can push them to .../api/ and we can always change it later
<alf_> thomi: sure
<AlanBell> or can I implement windows 7 on it http://xkcd.com/528/
<alan_g> thomi: alf_ that's probably easiest. We'd need to pull content in to make it the main page.
<thomi> ok, rt filed.
<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.
<thomi> alan_g: all those sections have a /api/ section as well
<thomi> for example:
<thomi> unity.ubuntu.com/autopilot/api/
<kdub> AlanBell, thats a space station, not scrolly bacteria :)
<alan_g> AlanBell: Sorry, trying to find someone that can advise on details
<thomi> actually, that's a bad example, since we don't have a non-api section :)
<thomi> alan_g: but you see what I mean, hopefully :)
<AlanBell> kdub: ah, my scale was out slightly
<kdub> AlanBell, phone demos on the desktop, a tricky to set up
<kdub> not sure if anyone's done it yet
<AlanBell> well, I am trying to do anything with it really
<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)
<kdub> AlanBell, i live mostly in the world of android headaches, not sure what precisely is possible on desktop these days...
<thomi> alf_: yeah. We can always move things around if we need
<kdub> racarr might be able to advise how to get those qml demos going
<alf_> AlanBell: you need to get qmir from launchpad.net/qmir and build it (you need qt5)
<alan_g> alf_: thomi there's quite a bit of tailoring we can do to L&F of doxygen output
<thomi> yeah
<alan_g> thomi: alf_ let's do the simplest thing (get what we have up) and iterate
<thomi> agreed
<AlanBell> alf_: oh, cool thanks
<kdub> thanks alf_
<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
<alf_> AlanBell: note: no input yet
<AlanBell> ok, so I can't make the eyes flash on ctrl+alt+del :(
<AlanBell> no readme or makefile or anything in the qmir branch
<alf_> AlanBell: unfortunately no, we are working on organizing the documentation as you may have noticed from the conversations here...
<racarr> Met with Katie, nailing down focus concepts, "application focus" (for menu bar, launcher pips, etcs...) "window focus" and "stage focus" (input focus)
<racarr> and "display focus" for shell components
<racarr> very similar to how on the whiteboard in London but we wrote it down this time
<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 ) -
<bryce> there won't be a 13.10.
<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
<FunnyLookinHat> bryce, Right right - I meant looking forward before all of the RR talk.
<FunnyLookinHat> bryce, but that answers my question ( i.e. accounting for multiple gpu / head / hotplug ) - thanks :)
<UbuPhillup> Question: will I be able to run Virtualbox full screen in Mir? Will the input handling stop the HUD stealing my alt key?
<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).
<UbuPhillup> bryce: thanks i will watch at the talk
<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.
<bryce> there's a long list of input issues which I gather folks hope Mir can give us better solutions
<UbuPhillup> ;)
<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!"
<thiagoandrade> Is there any other dependency I should install that is not covered in that document?
<AlanBell> are you on raring thiagoandrade?
<thiagoandrade> AlanBell, no
<thiagoandrade> I'm on 12.04
 * AlanBell is on raring, it worked eventually
<AlanBell> don't recall seeing that error message, but I had some problems which were my system's fault
<AlanBell> is there going to be a new window manager to run in mir?
<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.
<AlanBell> to do the window decoration, title bar, borders etc
<AlanBell> thiagoandrade: I dunno, you might be fine on 12.04 if you install the patched mesa from today
<AlanBell> but raring is fine, I have been using it daily for months (even with raring-proposed accidentally enabled) and it is fine
<TheMuso> AlanBell: As far as I understand things at this point, the unity shell in combination with MIR will do window management...
<TheMuso> Somewhat similar to how GNOME shell integrates with mutter to handle window management.
<TheMuso> Although probably more integrated.
<bryce> TheMuso, btw Mir should not be all-caps.  (MIR might get confused with Main Inclusion Request).
<TheMuso> bryce: Sorry, its party a typo,a dn party a habbit.
<TheMuso> gah typing == bad.
<TheMuso> Its partly a typo and partly a habbit.
<bryce> habit?  ;-)
<TheMuso> Yeah, dunno why, but it is. Probably from having to deal with main inclusion reports. :)
<TheMuso> And writing the shorthand for that.
<thiagoandrade> robertcarr, What can I do to help you with in process EGL work item?
#ubuntu-mir 2013-03-07
<RAOF> alf_: I'm in the process of wandering through graphics/gbm and wiring up buffer passing using dma-buf rather than flink. Just a heads-up.
<RAOF> Hm. That was disturbingly quick, which suggests we don't test the buffers all that much :)
<llstarks> RAOF, i've been trying to find a real world example of dma-buf use. how are you using it?
<RAOF> llstarks: Passing prime fds rather than flinked gem buffer names.
<llstarks> radeon?
<RAOF> Radeon, Intel, and Nouveau all do it.
<llstarks> i know
<llstarks> waiting for maarten's fencing work and for nvidia to use the new shims
<RAOF> Somehow I've managed to trigger a g++ 4.7 ICE.
<llstarks> you broke c
<tvoss> llstarks, RAOF is well-known for that :)
<RAOF> I love the smell of C++11 in the morning
<tvoss> RAOF, ;)
<alf_> RAOF: ok, looking forward to that
<RAOF> Hah. Looks like g++ 4.6 gives a useful error rather than ICEing.
<RAOF> For those playing at home - you can ICE g++4.7 by having one of your Google Mock objects missing a pure virtual function.
<RAOF> alf_: You can check out lp:~raof/mir/use-dma-buf; I *think* that's pretty much the server-side done.
<RAOF> And with that, dinner.
<alf_> RAOF: sure, checking
<llstarks> it's cool seeing dma-buf userspace code
<RAOF> llstarks: There's some in xf86-video-{intel,radeon,nouveau,modesetting} :)
<alf_> RAOF: Looks good and runs well overall. With some slight cleanup it will be ready to go \o/
<alf_> RAOF: plus answering the GEM_CLOSE/close(fd) questions
<RAOF> alf_: Oh, you've tested it with actual clients? :)
<alf_> RAOF: just the unaccelerated one, that doesn't use mesa
<RAOF> I guess I could have done that; software-rendering should work, right? I haven't updated the mesa bits.
<alf_> RAOF: and render_surfaces which is server side only
<zAo^> Will GTK2 become Mir compliant?
<zAo^> Or only QT5.1 & GTK3?
<min2> hello
<llstarks> i don't think of ddx drivers as userspace unless it's in the context of ums. for the past few months it's like dma-buf is present in every component it needs to be, but nothing calls it. i have to go out of my way to set up nouveau prime on my laptop just to see it in action. or am i missing something?
<llstarks> can i run gnome-shell on mir?
<RAOF> llstarks: Yes*
<RAOF> llstarks: Where the * denotes - âin a nested X serverâ. Otherwise, the question is like âcan I run gnome-shell on westonâ, which is like âcan I run gnome-shell on Unityâ âº
<llstarks> so only unity runs natively in mir atm?
<RAOF> llstarks: I think you're misunderstanding what Mir is.
<AlanBell> which is a fault of the documentation to an extent
<RAOF> True!
<AlanBell> the spec is a somewhat challenging read to most people
<RAOF> Mir is not a display server in the sense of X; it's more like a library for building display-server-compositor-shells, like wayland.
<RAOF> It's somewhat hard for us to write a good summary of what Mir is, because it's obvious after you've spent several months designing it ;)
<llstarks> that's just a problem of communication, which seems central to the case for mir at this point
<RAOF> As far as I'm aware there *is* a build of the Ubuntu-touch Unity that's linked against Mir, though. That's the closest to "unity running on mir" that makes sense.
<AlanBell> llstarks: so far, the source enables you to get a scrolling picture of the mir space station in a green box
<llstarks> i saw that
<llstarks> very sexy
<AlanBell> it stops on ctrl+c but as I understand it you can't capture other keys yet
<AlanBell> actually I am not sure if mir stops then kills the client or the other way round
<RAOF> Well, and also X-on-mir, but apparently I haven't pushed that anywhere usefully public yet.
<AlanBell> I think clients tell mir what to put on the screen, and mir talks OpenGL to the GPU
<AlanBell> mir kind of manages requests from multiple clients, it shares out the GPU access kind of like a hypervisor does with a CPU
<llstarks> usefully public should be what you and tvoss are cooking with nvidia. you guys are about to kill 2 birds (optimus and mir enablement) with one stone and i must commend that.
<llstarks> counting on nvidia to fix their x stack would never work
<RAOF> AlanBell: Mir hands out a buffer, the client does what it wants with it (which will generally involve rendering to it with some variant of GL), the client says âI'm done with this frameâ, and then Mir takes the buffer and displays it.
<AlanBell> RAOF: a 2d buffer?
<AlanBell> oh, rendered to the buffer with GL
<RAOF> AlanBell: A GPU buffer, although clients can request a buffer that's CPU-accessible.
<RAOF> It is, not *entirely* surprisingly, quite a lot like wayland in that respect.
<racarr> Finally close to getting rid of the last frontend/shell unit test coupling to shell::ApplicationSession and ms::Surface/ProxySurface (except of course the application session unit test ;))
<racarr> have lost so much time over the last week to having to change 10 tests everytime I mess with the application session or surface interface
<wolfslord> How should I install the custom Mesa in order for Mir to work?
<AlanBell> wolfslord: I installed mesa from the PPA and build mir from source on Raring
<AlanBell> oh, Mir is now in the PPA with lightdm and xorg-server with xmir
<wolfslord> I'm using raring now under VirtualBox and tried to install the ppa but it gives errors when I do 'apt-get update'
<AlanBell> but the PPA version of xorg is based on the prior version in raring so that might not install
<AlanBell> 2:1.13.2-0ubuntu2+xmir1 is in the ppa but 2:1.13.2-0ubuntu3 is in the main repos
<wolfslord> Also how should I install mesa. I see from the ppa that there are a lot of packages. Is there a meta one or something?
<AlanBell> I am kinda doubtful that it will support the virtualbox 3d stack?
<AlanBell> wolfslord: add the ppa with sudo apt-add-repository ppa:mir-team/staging
<AlanBell> then sudo apt-get install mir will probably bring in the rest
<RAOF> Note that xorg-server failed to build, because mesa was buggy at the point it tried to build.
 * AlanBell installs 166MB of assorted stuffs
<AlanBell> rolling releases = 100MB/day \o/
<AlanBell> !mir
<ubot5> Mir is the next-generation display server currently under development by Canonical and Ubuntu. It's slated for inclusion in Ubuntu 14.04. For more information on it, see https://wiki.ubuntu.com/MirSpec . For code, see https://launchpad.net/mir
<AlanBell> ^^ does that look accurate?
<racarr> Anyone have time to review: https://code.launchpad.net/~robertcarr/mir/reduce-coupling-in-application-mediator-tests/+merge/152304 would be nice to land it this afternoon so I can submit another branch based on top of it that people can review in the morning without using pipes
<racarr> guessing the next branch will be more contrversial than this one ;)
<RAOF> Heh.
<kdub> with blobs, there's always something fun to figure out
<robert_ancell> AlanBell, that looks good. Thanks
<AlanBell> it was main inclusion request, but that wasn't used much so we changed it
#ubuntu-mir 2013-03-08
<wolfslord> racarr, How can I help you with the work item "In process EGL"?
<racarr> wolfslord: Hi!
<racarr> Hmm it's hard to explain right now. it's close to done actually but blocked on figuring out some weird issues in jenkins environment for prepare-for-inprocess-egl-branch
<racarr> the idea is about, allowing to create an EGLContext from a seperate thread bound to a mir surface in process
<racarr> and render like a client, but in process
<racarr> this of course, for the shell
<racarr> I don't know how to split it up in to seperate tasks right now. The idea is the prepare-for-inproces-egl branch changes the (Mir)EGLNativeDisplay type from MirConnection to this "NativeDisplay" structure which has several callbacks (surface_advance_buffer, surface_get_parameters), etc.
<racarr> then in prepare-for-inprocess-egl the client library, is modified to create this native display structure with functions pointing to client library based impementations
<racarr> so the next step (once the issue with landing prepare-for-inproces-egl is unblocked, so this can proceed somewhat without it)
<racarr> is to implement a server side version of MirMesaEGLNativeDisplay, with callbacks that work in terms of the in process server interfaces
<racarr> There is already one around in the branch mentioned here though https://bugs.launchpad.net/mir/+bug/1122388 (demo-shell-with-egl-abstraction)
<ubot5> Error: launchpad bug 1122388 not found
<racarr> err. bug setting failure :/
<racarr> anyway, it's absically done just a matter of landing the code in the right order and figuring out this
<racarr> jenkins failure
<racarr> so I can't think of a sub task or anything to give you :(
<wolfslord> So which ubuntu version exactly is recommended to dev MiR?
<RAOF> wolfslord: Raring
<wolfslord> RAOF, Thank you. I had a problem with my system and I'm going to reinstall so that's why I asked :)
<bochecha_> hi, I'm developing a new IBus input method engine for Hong Kong people, and with the recent Mir announcement I'm wondering if I should bother spending time to make it work well on Ubuntu
<bochecha_> what particularly confuses me is this statement in the MirSpec page:
<bochecha_> We have looked at multiple candidate input stacks and have chosen the one included in Android for its efficiency, clear design and flexibility.
<bochecha_> "input stack" is a bit vague, so just do be clear: does it mean that Ubuntu is moving away from IBus?
<bochecha_> (not that there is anything inherently wrong with it, but I'd just like to know how to prioritize the platforms I will be working on)
<tvoss> bochecha_, we are looking into the different input method (protocols) and IBus is on our list. But we would be happy to work together with you and identify your requirements. In general though: making your new engine work on Ubuntu would be great
<bochecha_> tvoss: well, my requirements are simple: a running IBus daemon :)
<bochecha_> if Ubuntu moves away from IBus, then my engine just won't run, and I will have one less platform to care about (yay, less work! :P)
<tvoss> bochecha_, @ibus daemon: that's easy enough :) for your question on the input stack: we are not moving away from iBus, the input stack refers to the low-level event process from evdev
<bochecha_> oh, I see
<Leyland> Hello, I have some questions. Is anyone working on a 'mir client over X' library for development of mir clients with out leaving the comfort of an X desktop? Are there things that would make such a library impossible? Are there any major changes expected for the mir client interface, is it a good time for toolkit integration? If I am not here please respond anyway, I will look at the logs later, thanks!
<Pajn> One thing I wonder about Mir is if it's going to recreate all work done by Wayland or if it only will support a subset of Waylands features?
<Pajn> This is because of the wery narrow time frame that have been set
<Pajn> Wayland have been developed for far longer and whit Canonicals daily QA it should take even longer
<Pajn> Is there any margins in the time frame for unexpected happenings?
<Leyland> I would love to see a more comprehensive comparison of wayland and mir, rather then the knee jerk reactions I've been reading lately, but oh well. May the X server replacement that garners the most hardware support win!
<alan_g> Leyland, I don't know of anyone working on a 'mir client over X' - it would be interesting, but probably just achieve the "worst of both worlds".
<alan_g> Wayland and mir are very different things - A Wayland (the protocol) implementation using mir (the library) could happen.
#ubuntu-mir 2013-03-10
<zebaszp> hi everyone, I need some big help: I've been trying to improve my read on all things Mir and Wayland, but for the love of me I just don't understand what's going on...so I'm asking both parties their opinions
<zebaszp> I need a full, honest to goodness explanation on what Wayland means to Unity and Mir, from feature differences, to community support and everything else
<zebaszp> ...anyone?
<zebaszp> popey, perhaps? hello?
<zebaszp> hello? anyone there?
<zebaszp> AlanBell, maybe?
<zebaszp> is anyone actually here? come on!
<zebaszp> come on, guys! there must be someone here!
<paulo-castro> I have the same questions zebaszp
<paulo-castro> I am worried with the fragmentation. When dealing with a so important software as a display server, fragmentation must be avoided.
<zebaszp> indeed, paulo-castro, which begs the question "why Mir?"
<zebaszp> I read the wiki, and I talked to the guys at #wayland, but I don't feel any closer to the answer
<zebaszp> which brings me here
<paulo-castro> zebaszp: When reading a Muktware arcticle it seamed to be about software control. Looks like canonicle want to control the display server to make the implementation of needed features easier
<paulo-castro> Looks like good answer to me, but I want to hear more opinions obout the subject.
<zebaszp> so far, the logic from the guys at #wayland was Mir is not a replacement for Wayland, but for SurfaceFlinger
<zebaszp> which still doesn't quite fit
<paulo-castro> Maybe a strategy to converge both
<zebaszp> but why not use Wayland for that?
<zebaszp> that's what it boils down to right now for me
<paulo-castro> Seems much like upstart vs. systemd to me
<paulo-castro> Maybe the features are missing and implementing something new in Wayland (upstream) is too slow
<zebaszp> as far as the guys at #wayland are concerned, Mir doesn't include anything new, and Canonical made no attempt to contact them
<paulo-castro> Yes....this leads to the same fragmentation problem...
<zebaszp> ...we're just going around in circles...
<zebaszp> I want someone who knows to reply! popey! come here!
<paulo-castro> Why they don't work togheter? Systemd vs. upstart. Libre vs. OpenOffice. Mate vs. Cinnamon. It's a shame IMHO
<paulo-castro> together*
<zebaszp> LibreOffice made sense, so OpenOffice should really merge into Libre; MATE and Cinnamon are radically different; and Upstart predates systemd, but was made obsolete by it
<paulo-castro> Why MATE and Cinn are different? They don't look so different from users pov
<zebaszp> MATE is Gnome2 running in GTK3, but Cinnamon works on Gnome Shell
<paulo-castro> But, as a UI, they aren't so different. I mean, besides tech aspects.
<paulo-castro> The work very similarly from design's perspective
<zebaszp> yeah, I guess, but for that matter, can't you replicate the same design in XFCE or LXDE?
<zebaszp> anyone willing to answer my questions now?
<zebaszp> no one?
<zebaszp> wow, I can't believe no one replied in almost 2 hours...
<zebaszp> (no offence, paulo-castro)
<RAOF> Shock! Developers not in #ubuntu-mir at 15:00 on a Sunday afternoon. âº
<popey> or 4AM on a Sunday morning
<tvoss> good morning :)
#ubuntu-mir 2014-03-03
<RAOF> âª You're one microscopic cog in his catastrophic plan / designed and directed by his red right hand â«
<mlankhorst> hey
<RAOF> Ho!
<RAOF> What can I do you for?+
<makara> Hi. What's the story with adoption of Mir?
<makara> will it be available in Ubuntu 14.04 desktop
<RAOF> Depends on what you mean by âavailableâ, really :)
<RAOF> There's a unity8-desktop-session package available in trusty-proposed; I don't know if that's migrated yet, after beta freeze.
<RAOF> And the Mir libraries are available, of course.
<alan_g> alf_: are you happy with response on https://code.launchpad.net/~alan-griffiths/mir/add-some-intelligence-to-scheduling-compositing/+merge/208633?
<kgunn> mterry: so we're talking about ripping out setting of MIR_SERVER_STANDALONE  currently in usc...within mir, this looks like it doesn't do squat (and is likely buggy)
<kgunn> seems like an artifact....curious if you had an opinion
<mterry> kgunn, no it is now an artifact I believe
<kgunn> mterry: ok...its going bye bye
<mterry> kgunn, as long as Mir keeps defaulting to nested when MIR_SOCKET is defined, we should be fine
<kgunn> alan_g: ^ can you confirm the approach ?
<alan_g> kgunn: I don't intend to change that.
<evstevemd> any documetation on how to support mir to new toolkit (wxWidgets)
<evstevemd> any documetation on how to support mir to new toolkit (wxWidgets)
<Captain_Crow> does mir prevent apps from stealing the keyboard?
<kdub> shells choice
#ubuntu-mir 2014-03-04
<mterry> Hrm.  Does trusty's Mir ftbfs for anyone else?
 * mterry wonders how close new Mir is to landing
<duflu> mterry: Like https://bugs.launchpad.net/bugs/1285955 ?
<ubot5> Ubuntu bug 1285955 in mir (Ubuntu) "Ubuntu trusty update "glm 0.9.5.1-1" broke Mir builds" [Critical,Triaged]
<mterry> duflu, looks like it, yeah
 * mterry resigns himself to building mir/devel
<mterry> I suppose I could steal that one patch
<duflu> mterry: It's a simple patch to backport
<mterry> duflu, thanks for the link
<mterry> duflu, yeah, but I might as well test against latest anyway.  It's been a while since Mir dropped
<duflu> mterry: Yeah 0.1.6 grew a bit larger than other releases
<duflu> On the plus side, that means lots of fixes
 * mterry loves fixes!  :)
<duflu> mterry: BTW I've made changes to the rendering interfaces in 0.1.7 and more to come. So I would not recommend building /effects/ of any sort on what we have just yet
<duflu> Because what we have won't exist that way for long
<mterry> hmm, OK.  I'm just trying to track down weird nested mode behavior with split mode
<duflu> The good news is, changes in that area are now landing(!)
<duflu> mterry: Anything we know about? https://bugs.launchpad.net/mir/+bugs?field.tag=nested
<mterry> duflu, no, don't think so.   I'm not even sure it's a Mir bug yet, but it's a good place to start debugging for one of my issues
<mterry> duflu, these only show up when using split mode.  So may be a bug in my integration
<duflu> mterry: Does split mean sidestage?
<mterry> duflu, no sorry.  I mean split greeter
<mterry> duflu, so like an actual separate greeter process
<RAOF> Welcome to: It Works Fine On My System, XVII
<RAOF> duflu: So, apparently bzr lp-sumbit doesn't particularly care to respect the submit branch I try to set :)
<duflu> Hurrah
<didrocks> RAOF: you have to set a target branch
<didrocks> in your branch config
<didrocks> (I know, it's stupid, but that's a launchpad "feature")
<didrocks> I had to workaround that for daily release, so really conscious about the problem :)
<RAOF> What?
<didrocks> RAOF: what branch do you want to target against?
<RAOF> The docs for bzr lp-propose strongly imply that âbzr lp-propose lp:mir/develâ will try to be submitted to lp:mir/devel. On the basis that it's called SUBMIT_BRANCH :)
<didrocks> yeah, but then launchpad is trying to be smarter
<didrocks> and think "oh, but this SUBMIT_BRANCH has this parent branch"
<didrocks> so I'll target thatâ¦
<didrocks> RAOF: try running: bzr config -d lp:mir/devel public_branch=~mir-team/mir/development-branch
<didrocks> then resubmit
<RAOF> We'll see next time I want to submit something; I've already retargetted.
<RAOF> Hm. google::protobuf declares itself to be not threadsafe for non-const methods. Why do we explicitly release all our locks before calling protobuf methods?
<duflu> RAOF: Good question. I think otherwise it led to deadlocks. But that doesn't make it right
<duflu> RAOF: Do we really have multiple threads using the protobuf objects though?
<RAOF> If we have a multithreaded client, certainly.
<duflu> RAOF: Ah
<RAOF> Such as, say, having two separate nested outputs...
<duflu> Critical blocking CI: https://bugs.launchpad.net/mir/+bug/1287600
<ubot5> Ubuntu bug 1287600 in Mir "./cross-compile-chroot.sh: line 83: popd: build-android-arm: invalid argument popd: usage: popd [-n] [+N | -N]" [Critical,In progress]
<duflu> Anyone?
<RAOF> duflu: SUre.
<duflu> RAOF: Ta
<alan_g> duflu: @"something should be mentioned in debian/changelog" - I don't see anything in the changelog for the changes that broke USC (mostly -r1420)
<duflu> alan_g: I just mean if it's not a standard part of the 0.1.6 release (r1433) then it needs a separate mention
<alan_g> duflu: got it
<duflu> alan_g: At the top-level of the bullet points so it's not under the 0.1.6 release stuff
<alan_g> Although IIUC kgunn was busy pulling more stuff into 0.1.6 yesterday
<alan_g> so it might be moot
<duflu> alan_g: I reverted that. Because it included mostly my own work which I intentionally omitted from 0.1.6 wanting it to mature some more
<alan_g> alf_: does "frame" mean "buffer filled with fresh pixels we want displayed" to you?
<alf_> alan_g: frame => "buffer filled with pixels". Whether it's "fresh" or we want it displayed is another story.
<alf_> alan_g: i.e. these are not implied by the term 'frame' without any other context
<alan_g> alf_: thanks. Then "usable_frames()" would be reasonable for buffers we can compose?
<alf_> alan_g: pending_frames?
<alan_g> I don't like "pending" as it can include a frame that has been composited (either on this display compositor or one one for another output)
<alan_g> "frames()"?
<alan_g> completed_frames()?
<alf_> alan_g: I don't agree with Daniel about using the terms 'frames'. This is a *Buffer*Stream, and I find using 'frames' confusing in this context. BufferStream::completed_buffers()? ready_buffers?
<alan_g> alf_: the reason I went for composable_buffers() was that it also supplies client buffers and I wanted to avoid any possible confusion
<alan_g> filled_buffers()
<anpok_> I havent used our demos on android some time now, any ideas why clients cannot connect to demo shell
<alan_g> anpok_: they can
<anpok_> "Can't get connection"
<alan_g> Are you running as the same user?
<anpok_> yes
<anpok_> tried with and without supplying the path to server and client. socket file is created properly
<alan_g> It works on my kit
<anpok_> hm i just stopped unity8 and lightdm
<anpok_> ok will try with devel
<anpok_> system error thrown by asio when it tries to connect to the socket .. cannot examine the system error category but error val is 2
<anpok_> and that would be address in use o_O
<anpok_> or no such file or directory
<anpok_> oh ok that was all me
 * alan_g assumes it works on anpok_'s kit too
<alan_g> alf_: "buffers_ready_for_compositor_aka_frames()"?
<alf_> alan_g: :)
<anpok_> sounds reasonable
<anpok_> hm is it intended that all motion events go to the topmost or focused surface even when those motion events did not originate from the screen region of the surface?
<alan_g> anpok_: I think that is probably a policy decision - check the design guidelines
<anpok_> ah ok that is the behavior of demo shell
<anpok_> using focused application -> default_surface, which also explains why multi win behaves that way
<alan_g> alf_: happy with the latest comment? https://code.launchpad.net/~alan-griffiths/mir/add-some-intelligence-to-scheduling-compositing/+merge/208633
<anpok_> wet_buffers() ?
<anpok_> that would have the freshly paint pixels.. and the term buffers
 * ogra_ hands anpok_ a mop
<anpok_> nah not needed, they are not leaking
<kgunn> alan_g: so i saw duflu reverted our promotion branch, so re-cherry picked...
<kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1440
<kgunn> and
<kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1438
<kgunn> just fyi
<kgunn> i'm supposing it was the renderable for rendering stuff he didn't want in yet
<alan_g> kgunn: I am content to let you and duflu reach a consensus
<alan_g> Anyway, your choices look sensible.
<anpok_> do we have a usage scenarios behind set_inpput_rectangles?
<anpok_> what is supposed to happen if somebody creates a surface. resizes it. then sets input_rectangles.. should the input_rectangles be resized too?
<kdub> anpok_, is https://code.launchpad.net/~andreas-pokorny/mir/cursor-position-on-rotated-output/+merge/209076 ready to go?
<anpok_> yes
<kdub> cool
<anpok_> alan_g: alf_: racarr_: kdub: I plan to propse something that would scale the input rectangles on resize, and apply the other transformations to the input rectangles (rotation and positioning) when querried through contains..?
<anpok_> kdub: the other two things .. hot spot setting and managing rotated buffers will be done later.. hmm but should be straight forward..
<alan_g> anpok_: would it be easier to merge the input rectangles into the surface hierarchy and not have to keep updating copies of the data?
<anpok_> hm you mean reworking inputwindowinfo/handle?
<alan_g> anpok_: we've far too many implementation classes representing the way surfaces interact with parts of the system. It sounds like you're struggling with keeping the input one in step with the others
 * alan_g is guessing as he's not looked closely
<anpok_> true, but the problem is now internal in basic_surface::input_rectangle not being updated
<anpok_> actually revisiting the other bug.. I wonder which portion of the android object went out of date... since the main query method goes for surface::contains anyhow
<anpok_> so maybe I will soon provide a cleaner fix for the other bug too, which ripps out more of the InputInfo
 * alan_g is mildly irritated that a bug he fixed days ago on a one branch hosed his system when testing on another branch
<alan_g> alf_: do you have time to re-review before EOD? https://code.launchpad.net/~alan-griffiths/mir/nested-sessions-dont-post-buffers-until-something-happens/+merge/209107
<racarr_> ok now that im not worried about accidentally saying chromium I live here again
<racarr_> hi everyone :p
<bschaefer> racarr_, the chromium work looks awesome! :)
<racarr_> bschaefer: Thanks :)
<mterry> mf::Shell::open_session() is turning on the display for me  :-/
<kdub> maybe its triggering a callback for a new surface
<mterry> kdub, new surfaces turn on the display
<mterry> ?
<kdub> mterry, not sure why that would happen
<kdub> mterry, have any ideas about this in unity-system-compositor.log, "Unable to set active session, unknown client name session-0"
<mterry> kdub, that is known (harmless for now) race, fixed by a branch of mine....
<mterry> https://code.launchpad.net/~mterry/unity-system-compositor/greeter-depth/+merge/207549
<kdub> mterry, ok
<kdub> mterry, another question, who is in charge of turning on the display today?
<kdub> unity8, or usc
<mterry> kdub, a bunch of people  :)  Normal flow is powerd asks USC to turn it on
<mterry> kdub, unity8 shouldn't be involved anymore
<kdub> and thats all landed?
<mterry> kdub, yeah
<kdub> and this branch did that? https://code.launchpad.net/~mterry/unity-mir/drop-dbusscreen/+merge/202236
<kdub> i'm trying to test some mir changes with the whole stack, having a hard time getting all the ducks in a row
<mterry> kdub, no, that just removed some old unused code (unused because USC is claiming the bus unity-mir wanted, so it never got it)
<mterry> kdub, the branch that made the switch was just enabling nested mode by default
<mterry> kdub, USC has had a copy of that dbus_screen code for a while, it just wasn't used until it got turned on by default
<kdub> mterry, okay, thanks
<mterry> Huh.  SessionMediator::next_buffer turns on the display
<mterry> I'm not sure I like that
#ubuntu-mir 2014-03-05
<RAOF> duflu_: How would you feel about a script that just sets up the appropriate environment for you (ie: that you'd run on the device)?
<RAOF> duflu_: That has the slight drawback of needing to be run in a special directory because ctest, though.
<duflu_> RAOF: Working on one myself, which will make the whole issue moot and unblock my review of that
<RAOF> duflu: Cool. Shouldn't be hard, except for the annoying bit where $CWD/../../bin/udev_recordings needs to resolve.
<RAOF> robert_ancell: Good afternoon my good man!
<robert_ancell> RAOF, sup
<RAOF> robert_ancell: You know, the same. Reviews, SRU processing, chasing stupid threading bugs...
<robert_ancell> exciting stuff :)
<RAOF> Yo fine self?
<robert_ancell> yep
<duflu> Heh, we might need to find people to do Mir code reviews full time :)
<RAOF> Ah, memtest. Time to make lunch!
<duflu> memtest86? MemCheck?
<duflu> Applies to both really
<duflu> AlbertA: Awesome that you found the Nexus4 GLSL bug. Did you know of that limitation or just discover it?
<AlbertA> duflu: I got annoyed by it :)
<AlbertA> duflu: as I was doing some changes in screencasting
<AlbertA> duflu: I like to use the eglplasma example + egltriangle on top
<duflu> AlbertA: Even more impressive you diagnosed the bug in the hardware shader. Something like that could go years without people figuring it out
<AlbertA> duflu: :)
<duflu> AlbertA: Only Mako right?
<AlbertA> duflu: nexus 7 too, I didn't test nexus 10...let me see
<duflu> Odd
<AlbertA> well nexus 7 2013, which is still qualcomm
<duflu> That makes sense. Qcom-only bug
<duflu> The next challenge is to reduce the number of trig functions. 20 years ago I could write more efficient and prettier plasma than that. But I forget...
<AlbertA> duflu: I'm seeing the slowdown in n10 as well...weird
<duflu> AlbertA: Doing manual testing now...
<AlbertA> duflu: and gone with the fix proposed
<AlbertA> duflu: though it makes some sense as you start giving away precision as you move to bigger and bigger float numbers
<duflu> AlbertA: Yeah, but I don't think they're "big" for floats
<AlbertA> duflu: It just happens sooner than I think it should
<duflu> AlbertA: I think it was probably only happening in the thousands. That's just a GPU bug
<AlbertA> duflu: in mako at least, it was happening
<AlbertA> duflu: after about 32.0f
<AlbertA> duflu: which seemed to soon for me
<duflu> Yep, seems to be running fine now
<duflu> If the function is implemented in hardware, I don't suppose there's much value in reporting it to Qualcomm
<duflu> Although it would help if they stopped producing new chips with the bug
<AlbertA> duflu: well but it's happening with Mali too though
<AlbertA> duflu: n10
 * duflu wonders if fmod is an O(N) operation
<duflu> It shouldn't be
<AlbertA> duflu: it may be that mediump in opengl es is not 32-bit
<duflu> Less?
<AlbertA> duflu: probably
<AlbertA> duflu: that's the only thing that makes sense
<AlbertA> duflu: I'll take a look at the spec later
<duflu> Yeah mediump looks low. It could run out of bits after a few thousand
<AlbertA> duflu: quick google searches suggest it's 10-bit
<AlbertA> duflu: that would kinda explain why it's starts happening around angle of 32.0f
<duflu> 32 is only 6 bits...?!
<AlbertA> duflu: but it's floating point
<AlbertA> duflu: make more sense to assign more precision down the normalized range
<duflu> Yeah, so once you get that high you could start losing decimal places at the other end
<tvoss> o/
<alan_g> duflu: do you want to have you an opinion on https://code.launchpad.net/~alan-griffiths/mir/nested-sessions-dont-post-buffers-until-something-happens/+merge/209107?
<duflu> alan_g: I don't have an opinion on it as yet. And am logging off momentarily
<mterry> Hello!  I'd love to talk to someone about mf::SessionMediator::next_buffer turning on the screen, when someone gets a chance.  I'd very much like it to not happen
<mterry> alan_g, you've been looking at buffer stuff  :)  ^
<mterry> speaking of, I should test your branch
<alan_g> mterry: turning on the screen every time any client posts a buffer? Sounds expensive.
<mterry> Code says:
<mterry>     // We ensure the client has not powered down the outputs, so that
<mterry>     // swap_buffer will not block indefinitely, leaving the client
<mterry>     // in a position where it can not turn back on the
<mterry>     // outputs.
<mterry> alan_g, ^
<alan_g> mterry: please do. (kgunn just top approved it)
<alan_g> Ah. That sounds like a different issue. I'm trying to recall the details...
<alan_g> As I recall it being explained to me we (somewhere) serialize processing of client messages, which meant we didn't listen for a new power on message while processing next buffer. I don't remember it being addressed (but I'm fallible)
<alan_g> But as I've stopped next_buffer blocking this may no longer be an issue.
<alan_g> mterry: ^ do you have an easy way to reproduce?
<mterry> Whoops, got disconnected
<mterry> Last saw "Ah. That sounds like a different issue. I'm trying to recall the details..."
<alan_g> <alan_g> As I recall it being explained to me we (somewhere) serialize processing of client messages, which meant we didn't listen for a new power on message while processing next buffer. I don't remember it being addressed (but I'm fallible)
<alan_g> <alan_g> But as I've stopped next_buffer blocking this may no longer be an issue.
<alan_g> <alan_g> mterry: ^ do you have an easy way to reproduce?
<mterry> alan_g, yeah sort of.  If you install branches for split mode, when the display turns off, the greeter session starts and turns the backlight back on.  Reliably
<mterry> alan_g, you want me to try to reproduce with your branch and commenting out the ensure_display_powered line?
<mterry> Well, commenting out the line for sure will make the bug go away
<mterry> But test something else maybe that indicates we can safely delete that line?
<alan_g> mterry: The original problem that this was a workaround for was that a client with a blocked call to swap_buffers() couldn't request the screen turning on. (But I can't remember who explained it to me or how to reproduce - let me dig a bit...)
<alan_g> ...can't find it. alf_ ^^ can you remember the scenario that caused us to turn on the display whenever a buffer is posted?
<alf_> alan_g: not in detail, I remember it was racarr that first explained it
<alan_g> mterry: I suggest you try the effect of removing the offending code and, if you don't see anything obvious check with racarr.
<alan_g> alf_: thanks
<mterry> racarr_, poke when you're around, will try again later
<mterry> alan_g, thanks
<alan_g> yw
<racarr_> mterry: pong
<racarr_> mterry: That code exits because of xmir
<racarr_> but in general its sort of required the problem is
<racarr_> as it stands we only process one message at a time from a client
<racarr_> in order
<racarr_> one message per client per time that is
<racarr_> we may be processing multiple messages in parallel
<racarr_> ok so the problem is if the client calls
<racarr_> Turn off display
<racarr_> then calls swap buffers
<racarr_> the client will block for foreer
<racarr_> adn cant do anything about it
<mterry> racarr_, well my use case is this:
<mterry> racarr_, assume split greeter.  Then you lock user session.  Screen turns off, greeter session starts up in order to be ready for use when screen is turned on again
<mterry> racarr_, the way Mir is written now, the screen will turn back on by itself because greeter session opened
<racarr_> I thought it was only if
<racarr_> the greeter is the one that requeste
<racarr_> turnign of the screen
<mterry> racarr_, hmm?  didn't follow
<racarr_> mterry: I mean, the way the logic was intended to be
<racarr_> is a client swapping buffers only turns the screen on
<racarr_> if it was that client which turned it off
<mterry> racarr_, I don't *think* that's how it works today?
<mterry> racarr_, do clients even put screen-on holds into Mir?  I thought everything was proxied through powerd, which then asks USC to turn on/off.  So USC (the compositor) doesn't even have that info
<racarr_> mterry: XMir
<racarr_> will turn it off
<racarr_> um
<mterry> racarr_, I guess I don't know enough about XMir
<racarr_> ill look in to it or you :)
<racarr_> sounds like its broken today
<mterry> racarr_, thanks!  if you need me to test something or need more info about the code path I'm hitting, let me know
<racarr_> mterry: Maybe. Thanks! The first thing I will do
<racarr_> is write an acceptance test client_swapping_buffers_only_enables_display_if_said_client_reuested_display_off
<racarr_> or something lol
<racarr_> and maybe the behavior is just broken
<racarr_> and its just a bug
<mterry> racarr_, OK, sure.  I believe in this case USC is turning screen off.  So that might make sense
<racarr_> mm
<racarr_> excellent
<racarr_> ok. me -> coffee -> emacs
<racarr_> I hate this threading but im dealing with right now so I will look at it
<racarr_> now!
<mterry> :)
<kdub> racarr_, in SessionMediator?
<racarr_> kdub: Err. if you mean my last sentence there was a missing word
<racarr_> I hate this threading issue I am dealing with now (not in session mediator)
<kdub> ah, okay
<racarr_> this is a little in session mediator
<racarr_> in that it calls DisplayChanger::ensure_display_powered or whatever
<racarr_> but I guess the logic is there
<racarr_> mterry: Err. so I lost track during my detour to chromium world is the greeter a nested mir atm?
<mterry> racarr_, yes
<mterry> racarr_, basically just another unity8 session
<racarr_> mterry: Ok. Great.
<racarr_> I think the nested code is configuring the display
<racarr_> and thus getting the client in to the list of clients who are configuring the display
<racarr_> and messing up this code
<racarr_> but....uh
<racarr_> well, it still doesnt entirely make sense
<racarr_> but I have a plausible code path to investigate
<racarr_> mterry: How many monitors are you testing with
<mterry> racarr_, mako
<mterry> so 1
<racarr_> haha ok
 * mterry keeps getting unity8 crashes with latest mir
<mterry> Either I miscompiled something or I'm missing a merge
<mterry> kgunn, is there a branch I need for unity8 for Mir 0.1.6?
<kgunn> not for unity8
<kdub> unity-mir maybe
<kgunn> mterry: but for unity-mir
<mterry> kgunn, I have the one that lets it compile
<mterry> kgunn, but is there a subtler change I need?
<kgunn> mterry: to be specific do you mean mir-devel or 0.1.6
<kgunn> there are differences from the tag to the tip
<mterry> kgunn, I was building from scratch lp:mir/devel
<kgunn> ah...tip
<mterry> should have specified
<mterry> kgunn, is there ongoing drama in tip?
<kgunn> mterry: well...so configure_output got removed....
<mterry> kgunn, yeah, I've made those changes.  Maybe poorly, but it seemed simple enough
<kgunn> mterry: oh...in usc ?
<mterry> kgunn, and unity-mir I think
<kgunn> mterry: well unity-mir you should include your drop dbus screen brnach
<kgunn> which takes care that way...
<mterry> did that, but it also has some other change, maybe which was in 0.1.6 anyway
<kgunn> and then for u-s-c you can grab
<mterry> anyway.  Sounds like nothing crazy...  But maybe I should go back down to 0.1.6 for safety's sake
 * mterry just doesn't like re-compiling things again
<kgunn> https://code.launchpad.net/~kgunn72/unity-system-compositor/usc-mir-0.1.6/+merge/208821
<kgunn> mterry: ^ that one should make tip happy
<kgunn> there were some config option changes that were needed along with it...cherry picked beyond 0.1.6
<mterry> kgunn, I was using lp:~mir-team/unity-system-compositor/staged-next-rev
<kgunn> mterry: ah...yeah...that's for the ppa i'm trying to get rolling...
<kgunn> i might not have updated it yet
<kgunn> with the https://code.launchpad.net/~kgunn72/unity-system-compositor/usc-mir-0.1.6/+merge/208821
<kgunn> latest changes
<mterry> kgunn, this is a crash in unity8 not usc that I'm seeing though
<mterry> so probably in unity-mr
<mterry> or platform-api or some such
<kgunn> mterry: oh, so you've built ok ?
<mterry> kgunn, yeah
<mterry> kgunn, unity8 just keeps crashing
<kgunn> sorry dude...i thot you were having build issues
<kgunn> mterry: crashing when ? on startup?....or specific action ?
<mterry> on startup
<kgunn> mterry: hope i won't see the same thing when i attempt to land
<mterry> kgunn, well presumably those branches are already tested together?
<kgunn> mterry: which unity-mir are you using ?
<mterry> Figured it was something unique to me and/or my split branches
<kgunn> mterry: well...those branches i shared in the other channel are building together now...but not done building yet, so...untested atm
<mterry> kgunn, I'm using unity-mir with dropdbus and manual changes for configure_output change (there is one other place where it is called in unity-mir)
<mterry> *unity-mir tip that is
<kgunn> mterry: ah...ok...and actually not exactly what i am testing....we took on some of the mir server cfg changes...but not the removal of configure_output
<mterry> kgunn, alright.  For better help to you folks and my own sanity, I'll downgrade to 0.1.6 and the branches in the landing silo
<kgunn> lol
 * mterry recompiles a bunch more
<kgunn> mterry: yeah maybe...what are you after exactly ?
<mterry> kgunn, testing some alan_g changes to Mir that I want
<mterry> haven't landed yet
 * kdub had to do the same thing as mterry this week
<mterry> kdub, did you test tip or 0.1.6?
<kgunn> mmm....yeah... mterry so you'll have to do 0.1.6 tag revision from mir-devel...then merge on top the alang changes
<kdub> i tried tip yesterday,  i had a problem
<mterry> kdub, perfect
<mterry> kdub, well you know  :)
<kdub> it might have been crashing, or not starting
<kdub> so today, i'll try the stuff going in the silo
 * kgunn is now worried
<racarr_> ok wait I think this bug is easy lol
<racarr_> it has nothing to do with the swap buffers powere enabling logic
<racarr_> but rather, just the nested display configuration
<racarr_> USC turns off the display, greeter starts
<racarr_> NestedDisplay makes mir_connection
<racarr_> applies default display coniguration policy
<racarr_> which turns the screen back on
<racarr_> USC says ok
<racarr_> screen is back on lol
<racarr_> so either the nested display in the case of the greeter shouldnt mess with the display configuration policy
<racarr_> or USC should deny
<racarr_> configuration requests from
<racarr_> everyone except...xmir and other special things that exist later
<racarr_> probably both of those
<mterry> racarr_, hah, sorry if I put you on the wrong track
<racarr_> mterry: No!
<racarr_> plus we got a free acceptance test out of it
<racarr_> actually im not sure how the word free
<racarr_> applies here
<racarr_> but anyway
<racarr_> :p
<mterry> :)
<racarr_> mterry: OK you will be around for another few hours yeah?
<mterry> racarr_, yeah
<mterry> racarr_, you say " the nested display in the case of the greeter shouldnt mess with the display configuration policy"
<mterry> racarr_, why just the greeter?
<racarr_> well nested in the case of the
<racarr_> user session compositor
<racarr_> does want to apply the session display configuration
<racarr_> or whatever
<AlbertA> racarr_: we just discussed this today
<racarr_> oh?
<mterry> racarr_, how are those two sessions really any different as far as the USC is concerned?  Shouldn't USC just apply display config and nested should stay out of it?   But I don't know much about display confis
<AlbertA> racarr_: the display state will be ripped out of powerd
<racarr_> Great :D
<AlbertA> racarr_: and the sessions will now be in control of initiating display state changes
<racarr_> this is just a simpler issue though.
<racarr_> here its ust the greeter is requesting something it doesnt want
<racarr_> or maybe USC is allowing something it shouldnt
<racarr_> mterry: Not as far as USC is concerned
<racarr_> but as far as what they want
<racarr_> the unity8 nested session, does have some sort of
<racarr_> display configuration policy right
<mterry> k
<racarr_> I mean right now its the same as the USC display configuration whcih is just
<racarr_> turn all the displays to native mode
<racarr_> but hypothetically its like
<racarr_> you start up this user session and this users
<racarr_> configuration applys
<racarr_> etc
<AlbertA> racarr_: well in android devices is all driven by powerd
<AlbertA> racarr_: not sure in desktop
<racarr_> AlbertA: This is the dpms mode which is seperate from the
<racarr_> early suspend logic
<racarr_> and also not really DPMS on android :p
<racarr_> MirPowerMode
<racarr_> mterry: You see what I mean? So the thing is just
<racarr_> the greeter isnt interested in this, so we need to make it possible to change that
<racarr_> default behavior
<racarr_> the greeter just wants to take the display configuration from USC
<mterry> racarr_, fair enough
<racarr_> mterry: Anyway im going to mull it over lunch...I think the greeter just needs to not use the DefaultDisplayConfiguration
<racarr_> Policy
<racarr_> but also perhaps
<racarr_> USC should be
<racarr_> denying this request
<mterry> racarr_, sounds like you know what's up.  Enjoy lunch!  Don't mull too much, unless it's cider
<racarr_> :D Back soon
<racarr_> mterry: Ok where does greeter live these days?
<racarr_> is it using Unity-Mir?
<mterry> racarr_, well....  in unity8 source.  But it's not split out yet.  I still have a separate branch for that
<mterry> racarr_, yes
<mterry> racarr_, basically just a copy of unity8, running different Qml
<racarr_> so there is no seperate binary?
<racarr_> mterry:
<mterry> racarr_, there is in my branch, but not in trunk
<racarr_> ok
<racarr_> bug is easiest to fix in that context so it that enough?
<racarr_> is*
<racarr_> mterry: ^
<mterry> racarr_, in which context?
<racarr_> mterry: I mean if we fix it in your branch with
<racarr_> the seperate binary
<racarr_> is that fine?
<mterry> racarr_, oh yeah!
<mterry> racarr_, I only care about my stuff  ;)
<mterry> racarr_, branch is lp:~mterry/unity8/split
<mterry> racarr_, if you want to propose a change I can make it
<racarr_> mterry: ok
<racarr_> thanks :D
<racarr_> mterry: It looks like its still the same binary? i.e. the same main.cpp is loading
<racarr_> Greeter.qml vs Shell.qml
<mterry> racarr_, yeah.  But there is a #define for greeter compile if you need to #if on it
<mterry> let me see...
<racarr_> I see #if !UNITY8_SHELL
<mterry> racarr_, the poorly named UNITY8_SHELL
<racarr_> :D
<racarr_> ok should have something for you soon
<mterry> kgunn, did you ever test your 0.1.6 PPA?
<kgunn> mterry: struggle bus
<kgunn> trying to sort out an arm unit test failure
<mterry> kgunn, I'm getting unity8 crashes still with the 0.1.6 branches.  I didn't grab every single branch in the silo, so maybe I just missed something
<kdub> mterry, kgunn my build has unity8 crashing with the 0.1.6 stuff too
<mterry> :(
<kdub> but interestingly, unity8 alone works okay
#ubuntu-mir 2014-03-06
<kgunn> kdub: are you tip ? or at the rev of the 0.1.6 tag ?
<kdub> the tag
<kdub> USC should have which branches? i see a few likely candidates
<kdub> here's what I see http://pastebin.ubuntu.com/7041505/
<racarr_> https://code.launchpad.net/~robertcarr/unity-mir/update-to-not-use-configure-output/+merge/209565
<racarr_> more build fixing
<racarr_> https://code.launchpad.net/~robertcarr/unity-mir/usleep-include/+merge/209564
<racarr_> not sure why this only appears on my system...
<racarr_> which branch fixes the
<racarr_> frontend detail link errors
<racarr_> or is this new
<kdub> racarr_, that one is new to me
<kdub> racarr_, with usleep, AlbertA has https://code.launchpad.net/~albaguirre/unity-mir/remove-usleep-call
<racarr_> kdub: Ah. thanks
<RAOF> racarr_: Have you made any progress on multihead inprocess eglL
<RAOF> L
<RAOF> ?
<racarr_> RAOF: Nooo
<racarr_> you need a nested qualifier too :p
<racarr_> but still no
<RAOF> racarr_: True.
<RAOF> Ok. I'll do more diving today then.
<racarr_> RAOF: Thanks
<duflu> racarr_: That was a purdy video of Chromium you made... and with the fix landed this week it no longer needs to be maximized ;)\
<racarr_> duflu: Credit to olli :D
<racarr_> I made a really ugly video
<racarr_> referred to as the blair witch project of web browser demos actually
<racarr_> it kind of caught on in the film festival scene but
<racarr_> :p
<duflu> Hah. Yeah it's probably a job requirement that olli can do videos with flair
<RAOF> Woot! That's why everything's getting wedged!
<RAOF> racarr_: So you know how src/server/frontend/surface.cpp::swap_buffers_blocking assumes that the callback to swap_buffers() will always get called? There's absolutely no guarantee of that.
<RAOF> racarr_: Although it might be a little bit to late for you, I guess ;)
<kgunn> RAOF: wouldn't the only time that happens is if the gpu crashes ?
<kgunn> or locks up
<RAOF> Apparently not.
<RAOF> Specifically: with the non-blocking client_acquire thingy, if there isn't a free buffer then client_acquire returns without calling the callback.
<RAOF> Now, compositor_release *should* call the callback once its been called, but does not appear to be doing so.
<kgunn> also...blocking on swapbuffer swaps doesn't sound good in general (e.g. just wasting time for a buffer to be free...not good use of time)
<RAOF> The other option is to have a buffer-available signal?
<RAOF> If you set swap interval 0 then we don't block(ish), and always return a buffer.
<RAOF> Blocking SwapBuffers until you've got a back buffer seems like a reasonable (and reasonably standard) thing to do?
<duflu> kgunn: Blocking in general is bad. But for swapbuffers, that's what throttles client rendering to the same rate as the compositor consumes frames
<duflu> So in places, very important to block
<kgunn> duflu: are you saying you actually block clients renders (_even_ when they have a free buffer) ...if the compositor is "busy" and doesn't have a free buffer (e.g. double buffered system its easier to do)
<kgunn> that would seem to preclude clients from making a decision to just render if they want to...
<kgunn> seems cheeky
<duflu> kgunn: Clients never have such a thing as a "free" buffer (that's bug 1253868). But they do always have a buffer to render to when not blocking inside SwapBuffers. SwapBuffers for the client will only block for one frame (16ms). Unless the screen is asleep, in which case we block everyone to avoid wasting power.
<ubot5> bug 1253868 in Mir "[enhancement] Mir protocol design prevents clients from ever being more than double-buffered" [High,Triaged] https://launchpad.net/bugs/1253868
<duflu> No, that's not right. Clients' SwapBuffers will return ASAP, on a maximum period of the maximum monitor refresh rate
<duflu> Unless they have explicitly disabled blocking with eglSwapInterval(0), but that's a bad idea usually
<kgunn> right...ok...video mode panels would likely be 16ms...but command modes don't have a vsynch...its realy an in determinant frequency
<RAOF> Yay! Hypothesis!
<duflu> kgunn: Yeah, indeterminant. But holistically your commands need to complete within that frame time, one way or another, to keep up 60Hz (or whatever)
<kgunn> usually faster if possible...
<duflu> Well the good news is that since Mir 0.1.5 we have maximized the rendering time available
<duflu> On desktop anyway. I'm not as familiar with Android
<RAOF> Nested creates 1 surface per output, even if the underlying system is cloned (which is pointless, but not super wrong). These surfaces get placed one above the other, meaning that one is completely obscured, meaning that its swaps never complete, and then everything falls in a heap.
<RAOF> But! Lunch time.
 * duflu assumes other people understand whatever bug that is
<RAOF> duflu: https://bugs.launchpad.net/mir/+bug/1287282
<ubot5> Ubuntu bug 1287282 in Mir "Nested server may hang with multimonitor and internal clients (Mesa)." [Undecided,New]
<duflu> That sounds unpleasant
<RAOF> Yeah. You should really replace the âmayâ with âwill definitelyâ. And the âmesaâ with âbut we don't have dual-head support on android, so can't expose this bug thereâ :)
<duflu> RAOF: Please do
<duflu> RAOF: On another note... I almost forgot. We can now implement xrandr rotation against XMir
<duflu> For fun. Not because anyone *needs* it
<RAOF> Woot!
<RAOF> Anyway, really lunch time.
<duflu> Hmm, apparently I had been running Mir on multiple monitors for weeks without knowing (half are off). And didn't notice any slowdown
<duflu> Is it a good idea to automatically use monitors that are off from the beginning?
<RAOF> duflu: We can't tell that they're off.
<duflu> Oh. That would do it
<RAOF> Except with DisplayPort and *some* HDMI.
<racarr_> RAOF: Oh...good catch :D I forgot
<racarr_> we had implemented the obscuring logic...
<racarr_> I should have figured out thats what it was when
<racarr_> moving the top nested window
<racarr_> unblocked them lol
<racarr_> I also should have remembered to mention that to you
<RAOF> I should have tried it sooner :)
<racarr_> :D
<racarr_> ITERATEEEEE
<RAOF> So, shall I fix that FIXME in nested_output.cpp? :)
<duflu> Whee, bisection without the ability to build old revisions
<RAOF> Oh, why not?
<duflu> RAOF: The glm package update from trusty, remember?
<RAOF> Oh, right. Buh!
<duflu> Fortunately the offending use case is pretty uncommon right now
<racarr_> RAOF: Would be excellent or if you are busy I can do it in the morning
<racarr_> I am now, not busy! (I am sure that statement will be corrected when kgunn wakes up :p)
<kgunn> racarr_: i have so much planned for you
<kgunn> mmwwwhahhahahah
<racarr_> go to sleep or you arent going to grow up to be tall.
<kgunn> too late for that
<racarr_> :p
<kgunn> probably causses gray hair too
<kgunn> i so heart this landing process
<duflu> http://memegenerator.net/instance/46502261
<racarr_> What happened? It seems like everything is in a jumble
<racarr_> and im missing the root cause of the chaos
<racarr_> duflu: Lol I see So you do window management
<racarr_> is the new team meme
<duflu> This is really annoying. SwitchingBundle reports multi-monitor frame sync working perfectly. But my eyes disagree
<duflu> Maybe the parallelized page flipped has somehow found a way to go a double speed?
<RAOF> Bah! Any ideas what the hell is going wrong on the CI hardware? https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/206659 passes the (memcheck) tests on my desktop *and* my Nexus 4, but fails without any useful info on the build boxes.
<racarr_> ok sorry australia friends but the more you say the less sleepy I feel :p and thats the wrong direction
<racarr_> goood night!
<duflu> racarr_: Night
<duflu> RAOF: I was wondering... do we need to give CI new instructions as to how to successfully run the tests on armhf?
<duflu> Cos I assume the old method will fail now (since that branch)
<RAOF> duflu: No, the old method works fine.
<duflu> The failures look udev/syscall specific. So possibly actually related to the code changes
<RAOF> What failures are you looking at?
<duflu> RAOF: A couple of them https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/206659
<RAOF> Which log result?
<duflu> This is a fun one:
<duflu> [----------] 2 tests from UdevWrapperDeathTest
<duflu> [ RUN      ] UdevWrapperDeathTest.DereferencingEndReturnsInvalidObject
<duflu> ==10840==
<duflu> ==10840== Process terminating with default action of signal 11 (SIGSEGV)
<duflu> ==10840==  Bad permissions for mapped region at address 0x1884DB8
<duflu> ==10840==    at 0x1884DB8: ???
<duflu> ==10840==
<RAOF> That's entirely expected.
<RAOF> The test is checking that SIGSEGV is raised, so valgrind picking that up is pretty normal :)
<duflu> Well it can't pass with it either, can it?
<duflu> Oh, those are passing!?
<racarr_> I was trying to write an acceptance test today
<racarr_> that, a client will block on swap buffers.
<RAOF> duflu: Yup, those are passing.
<racarr_> and swap buffers will not turn the display back on
<duflu> RAOF: A memcheck failure doesn't always mean the test failed. It can just mean non-zero errors reported by valgrind (which there are)
<racarr_> if its another client thats requested turning the display off
<racarr_> but its hard to write these tests, i.e. check that like
<racarr_> swap buffers blocks. when do you time out?
<RAOF> A second, maybe 2.
<racarr_> But, if 1, we add some symbolic kind of names to threads, i.e. a thread registers itself I am a compositor thread, etc.
<duflu> RAOF: Sanity check with some trivial proposals and see if they can land?
<racarr_> and then use a custom mutex implementaion with a simple...graph traversal kind of thing
<racarr_> you can write tests like...
<racarr_> EXPECT_THAT(RPCThreadFor(session, BlocksOn(CompositorThread))
<racarr_> and then just quit the test
<racarr_> </idea>
<duflu> racarr_: If this is you sleeping, may I suggest finding new ways to wind-down evenings? :)
<racarr_> lol
<racarr_> i just wanted to put it somewhere because I knew I would forget
<duflu> racarr_: And archived for you: http://irclogs.ubuntu.com/2014/03/06/%23ubuntu-mir.html
<RAOF> racarr_: Enjoy https://code.launchpad.net/~raof/mir/nested-one-surface-per-crtc/+merge/209615
<duflu> alan_g: Any chance you could look into https://bugs.launchpad.net/bugs/1288570 some time?
<ubot5> Ubuntu bug 1288570 in Mir "[regression] Multi-monitor frame sync no longer works (not synchronized)" [Medium,Triaged]
<alan_g> duflu: sure - although you mentioned something about just using a different approach in comments?
<duflu> alan_g: That was really only relevant when I thought I caused it. I'm not sure how much that rewrite idea would help now
<alan_g> ok
<duflu> alan_g: In fact, it's not just rendering faster, but looks like it's alternating forwards/backwards in time so juddering
<duflu> Not sure
<anpok_> http://paste.ubuntu.com/7043201/ I will make an MP out of that - but I still get a fancy off by one error for a rectangle (2x6) placed at (10,10) and rotated by 90 degrees. but only in x direction
<anpok_> i expected the rectangle to go from 8 to 13, but it starts at 9..
<alan_g> duflu: it is a big shame we don't have an acceptance test covering it.
 * alan_g wishes for a software backend once again
<duflu> alan_g: Yeah I went back and looked at the tests I wrote for that. They seemed OK
<duflu> Of course, you can't write tests for *everything* you haven't thought of yet
<duflu> However we broke it, I didn't foresee as possible
<alan_g> duflu: don't let it spoil your evening
<duflu> alan_g: It won't. I was happy to just complete the bisection
<kgunn> alf_: so greyback is ahead of me and tested silo a bit...any reason mir on android might be looking for mesa & trying to open vts ? (...thinking of the recent backend loading changes)
<alf_> kgunn: Is this during the build in the silo, or when using the built packages on a phone? Do we have any logs?
<greyback> alf_: using build packages from the silo. I just flashed my tablet & installed the silo's ppa and updated
<greyback> ah not again, think latest adbd broken on manta
<greyback> Setting up libmirclientplatform-mesa:armhf (0.1.6+14.04.20140306-0ubuntu1) ...
<greyback> update-alternatives: using /usr/lib/arm-linux-gnueabihf/mir/clientplatform/mesa/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_mirclientplatform.conf (arm-linux-gnueabihf_mirclientplatform_conf) in auto mode
<ogra> greyback, working on that (well, trying to, my manta misbehaves)
<greyback> ogra: Great, thanks. It started working again after reboot. But I was struggling with it this morning, had to reflash
<ogra> oh ? i wonder why it started working ... theoretically it shouldnt :P
<greyback> lol
<kgunn> i'm trying on a N4
<greyback> ogra: any logs useful for you, while it is magically working?
<kgunn> alf_: what should i look for as this thing attempts to boot...log ? or output ?
<ogra> no, i'm just surprised it started to work
<alf_> greyback: kgunn: hmm, we shouldn't be installing the mesa packages on phone/tablet. Probably something in our package upgrade dependencies/replaces. In any case, just remove the -mesa packages (and install the -android packages if not already there) and everything should work.
<alf_> greyback: kgunn: I don't think this is a problem with images, since the proper packages should be seeded for them.
<greyback> alf_: confirmed that works
<kgunn> i just got the vt err on unity8 manual attempt
<greyback> kgunn: sudo apt-get install libmirclientplatform-android libmirserverplatform-android && sudo apt-get purge libmirclientplatform-mesa:armhf libmirplatformgraphics-mesa:armhf
<greyback> that should help
<alf_> greyback: kgunn: I think the problem is that both libmirclientplatform-mesa libmirclientplatform-android replace libmirclientplatform, but I am not sure if there is a way around that
<alf_> greyback: kgunn: anyway, this should only be a problem when upgrading in a system that already has libmirclientplatform. Future images won't have it, so problem solved :)
<kgunn> lol
<kgunn> nice try
<greyback> alf_: how is mesa/android decided by Mir? At runtime?
<alf_> greyback: dpkg-alternatives set a system-wide default, but you can also override the exact library to use with environment variables
<davmor2> greyback: magic
<greyback> alf_: I just don't want someone to accidentally install -android packages on their desktop and break it.
<greyback> ogra: sanity restored: rebooted manta again, no adb
<ogra> heh
<ogra> greyback, feel free to roll back manually  http://launchpadlibrarian.net/168424245/android-tools_4.2.2%2Bgit20130218-3ubuntu19_4.2.2%2Bgit20130218-3ubuntu20.diff.gz
<alf_> greyback: nor do I, so I made sure that can't happen :) The -mesa and -android packages have the same alternatives priority, so any existing packages (e.g. mesa) are not overriden by newly installed ones. You need to change the alterntives by hand
<ogra> (but you will get the annoying disconnects)
<greyback> ogra: you're fixing the disconnects, wonderful! You'll single handedly lower my blood pressure and extend my life span with that fix
<kgunn> one nit for anyone reading scrollback its "sudo apt-get install libmirclientplatform-android libmirplatformgraphics-android && sudo apt-get purge libmirclientplatform-mesa:armhf libmirplatformgraphics-mesa:armhf"
<ogra> well it doesnt seemt o work on manta ...
<ogra> trying to find a proper fix ... but since i use my manta only once a month the battery went completely dead
<greyback> ogra: well if you need tester, let me know
<ogra> will do
<greyback> kgunn: with that change, things seem to work. Any idea how the crash is reproduced?
<kgunn> greyback: mterry & kdub were saying it was on startup
<kgunn> what's strange is kdub could launch unity8 manually...
<kgunn> and it would work
<kgunn> greyback: one note...they were building tip mir dev...and not sure about the other components....
<kgunn> meaning...its not precisely whats in silo3
<greyback> kgunn: which means I don't care...yet
<greyback> let's see if silo3 has that issue
<kgunn> greyback: right if silo 3 works...
<kgunn> alf_: greyback ...however, i just removed the mir mesa packages & installed the android ones....and rebooted, stuck at google splash screen
<kgunn> manual attempt resulted in: Failed to load platform plugin "ubuntumirserver"
<greyback> kgunn: is qtubuntu-android:armhf installed?
<kgunn> just trying that now
<kgunn> ooo....broken packages
<didrocks> kgunn: broken, like broken? (or broken as you didn't upgrade everything needed?)
<kgunn> didrocks: just to make sure...i added the ppa(slio3) did a apt-get update, followed by a dist-upgrade
<didrocks> yeah, that should be right
<kgunn> https://pastebin.canonical.com/106009/
<didrocks> did you change the packaging more than usual?
<didrocks> hum
<kgunn> nope...only thing i did was the removal of "mesa" and install of "android" discussed for the 2 pkgs above
<didrocks> kgunn: ok, I can extract the packaging diff as a first look (cheating and sshing on citrain machine)
<didrocks> just to see if there is any crazyness in packaging changes first ;)
<kgunn> didrocks: if its important to know...i started with a channel devel-proposed image like 30 min ago
<didrocks> yeah, sounds perfect
<kgunn> didrocks: hey thanks...
<didrocks> let me reflash cleanly my phone at the same time
<kgunn> didrocks: yeah...weird greyback says its ok with manta (i'm on mako)..but greyback did you have an "older image" ?
<didrocks> yeah, the device shouldn't come into play for deps issues
<didrocks> apart from a "non cleaned image"
<greyback> kgunn: ooh wow I did, from Feb20: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
<kgunn> ok guys...i gotta step away for monring duties...bbian
<kgunn> bbiab
<kgunn> greyback: you lazy bastard :)
<kgunn> jk...lol
<greyback> I've excuses, but anyway...
<didrocks> -               android-headers (>=4.2.2) [armhf],
<didrocks> +               android-headers (>=4.2.2) [i386 amd64 armhf],
<didrocks> that's a little bit weird, but not the issue per say
<didrocks> hum
<didrocks> +         libmirplatformgraphics-mesa (= ${binary:Version}) |
<didrocks> +           libmirplatformgraphics-android (= ${binary:Version}),
<didrocks> greyback: do you know about that? ^
<didrocks> kgunn: description of the binary packages aren't good btw (shouldn't be NEWed that way)
<kgunn> alf_: might know about that didrocks
<greyback> didrocks: I do now
<greyback> but alf_ is the author
<alf_> didrocks: ?
<didrocks> alf_: the short description needs to be different between packages
<didrocks> alf_: both reference the same
<didrocks> (also, not really sure the per-arch will please everyone ;))
<didrocks> so, from what I understand, on dist-upgrade, we need to install the -android mir and client packages, right?
<alf_> didrocks: either the -mesa or -android packages, depending on which platform we are on (and x86 no longer means mesa, nor armhf means android necessarily)
<didrocks> alf_: right, the thing is that we don't build even -mesa on all platform
<alf_> didrocks: e.g. on the x86 phone emulator we would need android
<alf_> didrocks: which platforms are these?
<didrocks> alf_: powerpc and ppcel64
<alf_> didrocks: we aren't building any mir package on these platforms AFAICT
<didrocks> alf_: yeah, I mean, it's something that will need to be looked at some point (especially as being in main intend more or less that)
 * didrocks wonders why he can't download from the ppa on the phone :/
<didrocks> oh I know
<didrocks> alf_: however, we still need to have different short descriptions between binary packages (which was the start of the discussion)
<alf_> didrocks: ok, I will take care of that
<didrocks> I'll be happy to not block on this for NEWing if there are new packages, if there is a MP for that :)
<didrocks> thanks
<didrocks> ok, so, let me try to apt-get install + dist-upgrade
<didrocks> alf_: so, with that change, I guess we need to seed libmir*android on Touch?
<alf_> didrocks: Right. If you just upgrade in an older image you will get the mesa packages, which is wrong (greyback had that problem), but I am not aware of a way around this transition glitch.
<didrocks> yep
<didrocks> that should be noted in the silo line (kgunn)
<didrocks> ok, so  libmirplatformgraphics-android : Depends: libmirplatform (= 0.1.6+14.04.20140306-0ubuntu1) but 0.1.5+14.04.20140212-0ubuntu1 is to be installed
<didrocks> interesting, let's see why apt-get doesn't want to upgrade it
<didrocks> I guess we just need them to be listed explicitely as libmirserver15 will be removed
<didrocks> The following packages will be REMOVED:
<didrocks>   libmirserver15
<didrocks> The following NEW packages will be installed:
<didrocks>   libmirclientplatform-android libmirplatformgraphics-android libmirserver16
<didrocks> The following packages will be upgraded:
<didrocks>   libmirclient7 libmirplatform libmirprotobuf0
<didrocks>   libubuntu-application-api-mirserver1 libunity-mir1 mir-test-tools
<didrocks>   unity-system-compositor
<didrocks> alf_: I'm missing no package here, right? ^
<alf_> didrocks: looks good
 * didrocks reboot the phone
<didrocks> kgunn: ok, all good here. As the transition is more complex than usual (new packages that you need to set explictely) and some packages need to be removed, you need to help apt. "sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform" should do it
<didrocks> kgunn: can you please add something along the line "need to seed libmirplatformgraphics-android and libmirclientplatform-android" in the comment of your landing request please? (and set that to red)
<alf_> kgunn: didrocks: https://code.launchpad.net/~afrantzis/mir/packaging-fixes/+merge/209676 , do you want an MP for urgent inclusion into lp:mir too ?
<didrocks> kgunn: alf_: if you don't have any other reason to rebuild Mir for other fixes, don't worry about it as long as it's merged in next release
<didrocks> alf_: but you will get bonus point if you can fix tabs vs spaces :p
<didrocks> which are in debian/control, rules, the new postinst scripts as well IIRC
<alf_> didrocks: I can only see spaces (except the make rules that need tab indentation)
<didrocks> alf_: let me grab you some of the stuff I'm seeing (space and misalignement)
<didrocks> alf_: oh, maybe you did that on purpose?
<didrocks> +         libmirplatformgraphics-mesa (= ${binary:Version}) |
<didrocks> +           libmirplatformgraphics-android (= ${binary:Version}),
<didrocks> (same on client)
<didrocks> and yeah, in rules:
<didrocks> +         -DMIR_RUN_ACCEPTANCE_TESTS=OFF -DMIR_RUN_INTEGRATION_TESTS=OFF \
<didrocks> +          -DMIR_PLATFORM=android\;mesa
<alf_> didrocks: @control, yeah that's on purpose, @rules, we don't have that text in debian/rules, at least not in mir/devel
<didrocks> alf_: it's in the one which was generated on trunk, starting to get anxious if you have such diff there
<didrocks> alf_: do you mind checking once that's landed? maybe you do have trunk/devel diff with changes only in trunk
<alf_> didrocks: it's going to be taken care of by https://code.launchpad.net/~mir-team/mir/trunk-0.1.6/+merge/208717 , I think that kgunn is testing this branch in the silo before merging into trunk, so we can fix the big issues before landing
<didrocks> alf_: yeah, the diff I showed you is the result of that branch
<alf_> didrocks: ok, thanks for pointing it out
<kgunn> alf_: didrocks ...the rules file needs to suppress the android integ tests b/c the silos != our "ci" builders....meaning, anything requiring access to arm gl drivers fails on silo but passes on dev branch "ci"
<kgunn> i say "ci" in quotes since i was corrected that its all CI...but you know what i mean :)
<kgunn> alf_: and thanks...
<kgunn> alf_: i'll just make those updates manually
<kgunn> to the branch for lp:~mir-team/mir/trunk-0.1.6
<alf_> kgunn: ok, in that case perhaps also fix the indentation noted by didrocks in debian/rules (-DMIR_RUN_ACCEPTANCE_TESTS=OFF -DMIR_RUN_INTEGRATION_TESTS=OFF \)
<alf_> kgunn: actually the next line (-DMIR_PLATFORM=android\;mesa)
<kgunn> alf_: what's wrong with it ?
<rsalveti> didrocks: you also need to change the seeds with latest mir
<rsalveti> guess you're just landing that together with the mir silo
<alf_> kgunn: nothing functionally, just one space more indented than it should be
<didrocks> rsalveti: yeah, I pinged kgunn to add a note for that
<rsalveti> cool
<didrocks> rsalveti: not sure we can land that together, the packages are NEW to the archive
<rsalveti> oh, that's true
<didrocks> rsalveti: something I've speced for the airline and we'll need to change our tooling, but for now, let's do it in a 2 steps process
<didrocks> (and not kick an image in between :p)
<kgunn> didrocks: i should rebuild ? or ?.....i just updated the branch for mir0.1.6 that would be merged post landing...
<rsalveti> didrocks: sure :-)
<didrocks> kgunn: what branches? only the typo ones?
<alf_> kgunn: actually it's a matter of tabs vs spaces (but not a big deal, we can fix it later)
<didrocks> yeah, don't rebuild just for that
<didrocks> get that in the next batch
<kgunn> didrocks: yeah, the description: in control & spacing for rules
<kgunn> ok
<kgunn> off to test then....
<didrocks> kgunn: don't bother to put into the current one :)
<didrocks> as long as it's not lost, it's fine :)
<kgunn> didrocks: curious...what was the deal with broken packages ? was that me ?
<kgunn> its working now
<didrocks> kgunn: did you see my apt-get install line?
<kgunn> ...well qtubuntu-android installed...
<kgunn> didrocks: you had no trouble ?
<didrocks> 14:24:16 didrocks | kgunn: ok, all good here. As the transition is more complex than usual (new packages that you need to set explictely) and some packages need to be removed, you need to help
<didrocks>                   | apt. "sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform" should do it
<didrocks> kgunn:  ^
<kgunn> kdub: mterry...so if either of you try silo 3 just be aware don't sudo dist-upgrade the ppa...you have to specifically sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform
<mterry> kgunn, yeah I meant to ask
<kgunn> in order to avoid loading platform obj's for mesa....
<mterry> kgunn, I can't have the mesa variants I suppose?
<mterry> kgunn, that's what was causing my crashes we're guessing?
<kgunn> otherwise mir will think its mesa and try to open vt's and stuff
<kgunn> mterry: it would depend on how you loaded it
<mterry> kgunn, normal everyday booting into unity8
<kgunn> ...if you by chance installed mesa platform packages for mir then yes
<mterry> kgunn, I bet I did dpkg -i ../libmir*.deb
<mterry> without realizing we got new mesa things
<kgunn> yeah...that'd do it
<mterry> kgunn, stop making it a pain to dpkg a new mir!
<mterry> :)
 * alan_g goes looking for yet another monitor to add to his laptop
<kdub> i must have missed some email somewhere, but when we say silo... where is that?
<ogra> where the train parks :)
<greyback> kdub: https://launchpad.net/~ci-train-ppa-service/+archive/landing-003/ is the one I was referring to
<kdub> thanks greyback
<ogra> greyback, fyi, adbd should behave a lot better with my recent upload ... (i'm not completely done yet on the mtp side though)
<greyback> ogra: cool, thanks
<mterry> kgunn, so theoretically removing those two -mesa packages would fix the unity8 problems?  didn't seem to work for me
<kgunn> mterry: well...did you purge ?
<kgunn> btw...in the end, i had to reflash & reinstall....the simple uninstall/install only android didn't work for me
<kgunn> only greyback claimed success
<kgunn> andhe was on an ancient image
<kgunn> ancient == 2 week old
<mterry> kgunn, ok, will do the cycle
<kgunn> mterry: sorry...sucks i know
<mterry> kgunn, if this is indeed necessary (instead of some weird other problem), seems like bad packaging...?
<kgunn> alf_ changed packaging names....and according to didrocks if you dist-upgrade you get the mesa, but if you do the specific install like so
<kgunn> sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform
<kgunn> then it all just works
<kgunn> and according to didrocks...that'll be fixed when it lands for real
<rsalveti> kgunn: yes, that should indeed work
<rsalveti> kgunn: are you having issues with it?
<rsalveti> I can give it a try
<kgunn> i just reflashed and it worked
<rsalveti> awesome
<rsalveti> kgunn: any other issue blocking that silo?
<rsalveti> just to know if we'll be able to land that today still
<kgunn> rsalveti: i found a gnarly manual test that revealed a problem with OSK....note AP test for OSK passed 100%
<rsalveti> oh, ok
<racarr_> mterry: Want to test a branch for your screen turning on issue?
<mterry> racarr_, sure...  Can I apply it to 0.1.5 easily enough?
<racarr_> mterry: Yes unity-mir only
<racarr_> mterry: lp:~robertcarr/unity-mir/greeter-configuration-for-mterry
<racarr_> then in your unity8 branch, where main.cpp calls
<racarr_> runQMirServerWithClient
<racarr_> call runQMirServerWithGreeterClient
<racarr_> if you are um...
<racarr_> the greeter
<mterry> racarr_, huh, k
<mterry> racarr_, your branch makes me feel so special  :)
<racarr_> mterry: Oh no, thats an abbreviation for Mir Thread Enhancing RAII Refactoring (from) Yesterday.
<mterry> racarr_, lol'
<rsalveti> alf_: how to run glmark2 with mir? also, can we update the package available in ubuntu to also bring support for mir by default?
<rsalveti> it seems the package is really old
<rsalveti> alf_: I can sponsor the upload if you need any help
<mterry> racarr_, I must have screwed something up, unity8 is crashing
<racarr_> mterry: Well. You mayt have not screwed anything up ;)
<racarr_> can you get a basic backtrace + stdoutstderr etc if there is anything interesting
<racarr_> and if its not obvious I will try and reproduce it locally
<mterry> racarr_, I'm more inclined to think it's me right now, will try again.  But I didn't see anything interesting in stdout/stderr
<racarr_> ok
<racarr_> API/ABI issues are all over right now so
<racarr_> one thing to check lol
<mterry> racarr_, yar
<mterry> racarr_, if I fail again, note that you can have split greeters too with lp:~mterry/unity8/split and lp:~mterry/unity-system-compositor/greeter-depth
<racarr_> mterry: Im just trying to avoid setting it all up by hoping it will all work lol
<racarr_> if you dont get anywhere pretty quick lemme know and ill build it all
<mterry> racarr_, that's fair.  Don't do anything until I reconfirm my crash
 * mterry is rebuilding unity-mir, I might have accidentally built your branch with bad ABI
<racarr_> storrry of our lives
<racarr_> I had this idea the other night that everything could be quote continuously integrated
<racarr_> but I was probably just too drunk thats crazy talk
<racarr_> :p
<mterry> racarr_, ok.  Fixed crash by recompiling
<mterry> racarr_, but now I don't see a change in behavior
<racarr_> mterry: That is a crying shame
<racarr_> mterry: Oh wait is this mir 0.1.5
<mterry> racarr_, yes
<racarr_> mterry: Ok sorry I got
<racarr_> that whole part about not neeidng mir changes
<racarr_> I made that up
<racarr_> you need some revision from alan that does async swapping on the server side annnd
<racarr_> mterry: and https://code.launchpad.net/~robertcarr/mir/remove-ensure-display-powered/+merge/209734
<racarr_> so unless this is blocking anything I think the answer is try again next thursday because right now its
<racarr_> not possible to build those combination of things against unity mir :p
<mterry> racarr_, I just want lp:mir/devel and all extant branches to land in trusty right now
<racarr_> ok well hopefully things will land then we will revisit htis next week
<mterry> hmm
<mterry> Maybe I need to try to rebuild Mir world again
<racarr_> unity-mir wont build against
<racarr_> mir never than 0.15
<racarr_> newer
<mterry> racarr_, there aren't branches for it?
<racarr_> uh there seem to be branches for
<racarr_> 0.1.6
<racarr_> but not for devel
<racarr_> 0.1.6 + my branch
<racarr_> might get you what you need
<kdub> and... lp:mir/devel has broken api with 0.1.6
<racarr_> right
<racarr_> devel + unity mir is no go
 * mterry gets grumpy
<racarr_> mterry: XD me too
<racarr_> which is why I forgot that you needed mir changes too
<racarr_> because I couldnt get unity-mir to build to make the changes then was like
<racarr_> oh I can just use 0.1.5
<racarr_> then forgot that we actually need to run them too
<racarr_> 21:27 < kgunn> racarr: for unity-mir against dev branch tip it'd be
<racarr_> 21:28 < kgunn> basically every mp "ready to land" here https://code.launchpad.net/unity-mir/+activereviews
<racarr_> 21:28 < kgunn> in specific order its
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~albaguirre/unity-mir/cross-compile-link-fix/+merge/205690
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~albaguirre/unity-mir/add-cross-compile-scripts/+merge/206058
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1240400/+merge/207302
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1281075/+merge/207375
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~mterry/unity-mir/drop-dbusscreen/+merge/202236
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~mzanetti/unity-mir/expose-appimage-sourceSize/+merge/207626
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision/+merge/208645
<racarr_> 21:29 < kgunn> https://code.launchpad.net/~kgunn72/unity-mir/um-mir-0.1.6/+merge/208819
<racarr_> this wont work against dev branch tip lol
 * kdub gets grumpy too
<racarr_> but should against 0.1.6
<racarr_> ...lol yeah
<racarr_> Why did unity-mir ABI updates start landing
<racarr_> out of sync with
<racarr_> mir changes
<kgunn> racarr_: what do you mean ?
<kgunn> because we have a dev-branch for mir
<kgunn> but things w/o a dev branch cannot merge stuff that doesn't get to archive
<kgunn> make sense ?
<racarr_> maybe we should have a dev branch
<racarr_> for unity-mir too
<kgunn> agreed
<racarr_> that is always in sync with mir/devel
<racarr_> I was thinking about this last night
<kgunn> cause afaik you're missing one MP
<racarr_> and then again with glmark 2
<racarr_> today
 * kdub likes that idea
<racarr_> and we should have a list of projects that depend on mirclient/mirserver ABI
<racarr_> and they should all always have a branch that builds against devel
<racarr_> and if you submit a mir branch or example
<racarr_> that breaks unity-mir build
<racarr_> you have to point the mir CI at a branch that
<racarr_> fixes unity-mir build
<kgunn> racarr_: i don't disagree...but its the mir teams responsibility to make that happen
<kgunn> if we break abi we should either work with someone or do the job ourself
<racarr_> right what I am saying is it needs
<racarr_> to be part of continuous integration reviews
<racarr_> because we cant keep track of it
<racarr_> and we need the dev branch so
<racarr_> we can always make the ABI change/update right after one another
<racarr_> rather than end up with a list of buffered ABI changes like now
<racarr_> because now there are unbuildable combinations of branches
<racarr_> The thing is
<racarr_> we can never land the changes exactly concurrently obviously because
<racarr_> unity-mir CI will depend on the new version of mir being published
<racarr_> if we had no dev branch, and didnt have the problem of CI getting choked up around difficult...times
<racarr_> then its no problem, mir ABI breaks land and are published, unity-mir immediately follows, everything moves out of proposed
<racarr_> Err...I kind of lost track of my conclusion there lol
<racarr_> trying to head back to: We need a dev branch for unity-mir too
<kgunn> racarr_: if you want...there are 3 branches here
<kgunn> called stage
<kgunn> d
<kgunn> in the names
<kgunn> for each platform-api, usc, unity-mir
<kgunn> they should all build together for tip....
<kgunn> as i already merged all the various MP's in
<kgunn> and i got all but unity-mir to build for tip
<racarr_> kgunn: Excellent :D
<racarr_> so what Ia m saying, is 1. Those branches should always exist
<racarr_> 2. if a mir commit causes those branches to fail to build
<racarr_> the commit description or something has to include a link to branches that fix it
<kdub> or, better yet, debian/changelog
<kgunn> sure...and i don't think its that hard to figure out when abi is broken for server
<kgunn> its not magic
<kgunn> i mean to me, before even landing a break...every individual on the team should have a matching MP
<racarr_> Well, rather than trying
<kgunn> on the relevant projects
<racarr_> to detect ABI breaks
<racarr_> lets just literally
<racarr_> build the dependent projects
<kgunn> sure
<racarr_> with the fixing branch merged in you cant
<racarr_> merge the fixing branch at first but we can have some sort of
<racarr_> special syntax jenkins bot understands like
<kgunn> racarr_: there are some nuancess....
<kgunn> like, stupid ppa builders...do not today permit running of our android integration tests
<racarr_> <fixes unity-mir-build> lp:~santaclaus/unity-mir/update-abi
<kgunn> they always fail
<racarr_> Even without testing
<kgunn> so literally the mir staged branch is mir-dev w/ android integraion tests disabeld
<racarr_> it still buys us a lot
<racarr_> we can make it impossible to land a mir commit without
<racarr_> having an open proposal to fix
<racarr_> all dependent projects which are broken
<racarr_> at least in terms of
<racarr_> building
<kgunn> so we could simply add that to the jenkins job today could we not ?
<kdub> kgunn, maybe i can work on getting those tests disabled if no hardware is detected
<racarr_> kgunn: I think almost.
<kgunn> kdub: that would mean we could use lp:mir/devel so yeah that'd be awesome
<racarr_> We will have to play with the jenkins bot to get it to
<racarr_> 1. Understand some list we place somewhere of
<racarr_> dependent projects
<kdub> kgunn, I'll see what can be done
<racarr_> I mean I guess its a new job
<racarr_> that 1. understands the list of dependent projects. 2. understands this special syntax for specifying branches that fix ABI breaks
<racarr_> 3. Builds everything
<racarr_> so, probably not today
<racarr_> but in the scope of a few days espescially if someone knows what they are doing with jenkins
<kgunn> racarr_: acutally what you are describing is a dedicated build silo from the "ci train" process that didrocks/asac own
<racarr_> more than me lol
<kgunn> and i've been asking for this...
<racarr_> You lost me
<racarr_> build silo = ?? ci train = ??
<kgunn> racarr_: basically ci train silo is what i take all the mp's dump them into ...and then it builds matching packages across all the projects
<racarr_> ok yes something like that
<kgunn> racarr_: output from a build silo https://launchpad.net/~ci-train-ppa-service/+archive/landing-003
<racarr_> except integrated in to Mir devel
<racarr_> continuous integration
<kgunn> but its more flexible than recipes
<racarr_> which requires the mir dependent branches to have devel branches too
<kgunn> but not as good as our ci on mir-devel
<racarr_> and this little syntax to tell jenkins which branches to use
<racarr_> but produces the same result
<racarr_> I just want to find a way to get it part of our
<racarr_> mir devel CI
<racarr_> once we have a job like this as part of Mir CI too
<racarr_> we can start adding integration tests
<racarr_> like you cant land on mir devel if it breaks a Qt window from opening
<racarr_> or we can run autopilot tests on the produced set, etc
<racarr_> tbh this whole CI bit I am talking about is
<racarr_> really step 2.
<racarr_> just step 1 maintaining a staged/devel branch for unity-mir, platform API, etc.
<racarr_> I think could help us a lot
<racarr_> because right now when someone from the shell team needs a mir change you often cant make it against mir devel (so you lose other recent changes)
<racarr_> or you have to wait a long time on test turn around
<racarr_> kgunn: Sorry haha hope it doesnt seem I am ranting at you
<racarr_> I am just brainstorming
<racarr_> kgunn: If you want I can take some time to try and
<racarr_> rig something up
<racarr_> I am kind of waiting on Alan to finish studyibg things to move forward on QML compositor stuff
<racarr_> so mustly just picking up odd bits and ends atm
<kgunn> yes...please
<kgunn> it would help immensely
<kgunn> feel free to harnes the staging ppa with the branches...if you want
#ubuntu-mir 2014-03-07
<racarr_> kgunn: Ok will at least write up some sort of study on it by tomorrow
<racarr_> RAOF: Ping?
<racarr_>  / anyone else who has thought about client cursor APIss
<racarr_> I think it might be time
<racarr_> xmir doesnt want the cursor
<racarr_> nested unity8 does
<racarr_> rather than add another hack to USC XMir should request to turn off the cursor I think
<greyback> kgunn: just tried reproducing bug 1289058 now, but I can't even get the signon UI to appear
<ubot5> bug 1289058 in unity-mir "[regression] OSK focus issues" [Critical,Triaged] https://launchpad.net/bugs/1289058
<RAOF> racarr_: Pong.
<RAOF> racarr_: I think that both XMir and Unity8 want usc to handle the cursor at some points, and to handle the cursor themselves at other points.
<RAOF> (Although U8 will likely want to handle the cursor more often than XMir)
<RAOF> racarr_: I've suggested to greyback that U8 just turn off the cursor and handle it themselves, to unblock things.
<racarr_> RAOF: MM its not to hard to unblock things...I was just thinking maybe its a nice excuse to add client cursor API
<racarr_> and figured if anyone had an opinion on how that should look it would probably be you
<RAOF> Ah, if you've got time to do a client cursor API then that'd be aces.
<racarr_> I mean its pretty simple right, MirCursor *c = mir_upload_cursor_sync(connection, pixels); mir_surface_set_cursor(surface, pointerid(?), cursor)
<racarr_> well we dont hae multiple cursors right now so ignore that lol
<racarr_> just surface, cursor
<racarr_> and there is not much more to it
<racarr_> I think?
<RAOF> Roughly?
<RAOF> The other option is to only expose symbolic pointer names in the API.
<RAOF> Which I think would be better?
<duflu> racarr_: Don't forget the hotspot x/y parameters with each image :)
<RAOF> Right :)
<duflu> https://bugs.launchpad.net/mir/+bug/1206780
<ubot5> Ubuntu bug 1206780 in Mir "[enhancement] Clients cannot change the hardware cursor" [Low,Triaged]
<duflu> https://bugs.launchpad.net/mir/+bug/1189775
<ubot5> Ubuntu bug 1189775 in Mir "Mir cursor has no hotspot setting, assumes (0, 0)" [Medium,Triaged]
<RAOF> racarr_: So, I think the API should probably look something like... mir_cursor_set_cursor(MirSurface* surface, char const* cursor_name); mir_cursor_load_theme(char const* theme_name);
<RAOF> racarr_: Hm, or something similar.
<RAOF> racarr_: Actually, maybe a first go could be MirCursor c = mir_upload_cursor(connection, buffer_containing_xcursor_data); mir_surface_set_cursor(surface, cursor);
<RAOF> racarr_: And copy http://cgit.freedesktop.org/wayland/wayland/tree/cursor/xcursor.c again :)
<racarr_> RAOF: duflu: Aha sorry my IRC client hung
<racarr_> symbolic names mebbe...Im not sure
<racarr_> I feel like some clients will reasonably want to upload custom cursors
<racarr_> GIMP, etc
<racarr_> im not sure
<racarr_> so maybe thats better done at the toolkit level
<racarr_> maybe we should support both
<racarr_> I dunno
<RAOF> racarr_: Yeah.
<RAOF> racarr_: Did you get all my comments?
<RAOF> Particularly: racarr_: Actually, maybe a first go could be MirCursor c = mir_upload_cursor(connection, buffer_containing_xcursor_data); mir_surface_set_cursor(surface, cursor);
<RAOF> ... racarr_: And copy http://cgit.freedesktop.org/wayland/wayland/tree/cursor/xcursor.c again :)
<racarr_> RAOF: Yes I did
<racarr_> yeah I think that is going to be
<racarr_> the first go
<RAOF> The next cut being MirCursorTheme t = mir_cursor_theme_from_$X(connection, <filename, symbolic theme name, buffer>); MirCursor c = mir_cursor_from_theme(t, char const* symbolic_name);
<alf__> rsalveti: @glmark2, sure, I will prepare a package update branch and contact you for further guidance
<kgunn> anpok: so i saw AlbertA's post in the bug...so do we think there's a combination of MP's that will allow mir0.1.6 to get promoted ? (...while we may have to hold back some of our bug fix?)
<kgunn> greyback:  based on https://bugs.launchpad.net/mir/+bug/1289058/comments/8
<ubot5> Ubuntu bug 1289058 in unity-mir "[regression] OSK focus issues" [Critical,Triaged]
<kgunn> sounds like we need a update to the namespace patch seperate from the fix for 1240400.
<greyback> kgunn: I'm rebuilding as I type. Sadly the PPA disappeared
<kgunn> greyback: actually https://drive.google.com/a/canonical.com/?tab=wo#folders/0B4GvOYxwuvpFdm5DbXNYUzFDdG8
<kgunn> i saved it off
<greyback> oh yay
<kgunn> sorry..i should have mailed that last night..but i was getting weird
<kgunn> greyback: i don't want to suck you into this...so if you just want to redo your branch...anpok or i can test
<kgunn> we might even get a silo back up soon
<kgunn> ooo...maybe soon is optimistic, we're in line behind the qt landing :P
<greyback> yeah I noticed that
<kgunn> reboot
<anpok> kgunn: i tried to reproduce the issue without mir 1.6 this morning .. and could not
<kgunn> anpok: thanks...when you tested 0.1.6, what did you test it with in terms of the unity-mir configuration ?? (or usc for that matter?)
<kgunn> ...and when you say mir0.1.6 do you mean lp:~mir-team/mir/trunk-0.1.6 ?
<kgunn> ...avoiding the confusion that maybe you tested mir-devel tip :)
<anpok> no not yet with 0.1.6
<anpok> i couldnt imagine that it could relate to mir changes so I thought to reproduce it with my current setup..
<anpok> my wifi was flaky ..
<anpok> kgunn: do you already have a reduced branch that only resolves the MirSurface colision in unity-mir?
<greyback> anpok: almost done
 * greyback loves when a C++ error message contains more lines than his scrollback buffer
<greyback> anpok: lp:~gerboland/unity-mir/namespace-to-prevent-collision2
<kgunn> dandrader: "maybe" is the answer to your ques from the other channel
<kgunn> i think greyback's branch ^^ might do the trick
<dandrader> kgunn, ok, let me know if I should jump on it
<greyback> kgunn: that's not fixing the bug, but it means we could land the few branches needed to unblock mir0.1.6 anyway
<kgunn> greyback: @"not fixing bug"...which bug :) ?
<kgunn> the osk one ?
<greyback> kgunn: https://bugs.launchpad.net/mir/+bug/1289058 yeah
<ubot5> Ubuntu bug 1289058 in unity-mir "[regression] OSK focus issues" [Critical,Triaged]
<kgunn> greyback: oh i see...trying to reduce the outstanding MP's down to just the lp:~kgunn72/unity-mir/um-mir-0.1.6
<kgunn> +1
<greyback> kgunn: right. Thought it best to shrink the landing queue to unblock mir
<kgunn> dandrader: yeah...so if you would take a look today at 1289058 that'd be great...
<kgunn> greyback: quick one...so you've basically now tests AlbertA's post and proved it wrong ?
<kgunn> meaning...removing the bug fix for 1240400 didn't help
<greyback> kgunn: http://studio.sketchpad.cc/f2Lr8RTY8z is list I'm proposing for landing. I'm just building now to check everything is ok.
<kgunn> greyback: +1....i actually had the same list/idea last night....but it got late...and now we gotta wait :)
<kgunn> anpok: greyback dandrader...i gotta step out for some banking...bbiab
 * greyback also has to step out a bit, back in 10
<anpok> greyback: ok
<rsalveti> alf__: thanks
<anpok> is it really done that way that osk forwards all input of the side or main stage application?
<anpok> i mean motion input at the upper half of the surface
<anpok> have to go and get some stuff.. will be back later
<greyback> anpok: yeah
<greyback> it is a full screen surface, to support all the orientations necessary. Therefore its surface has transparent parts, and shell tries to position an InputArea over the opaque bits, so that the OSK surface gets those touch events
<AlbertA> greyback: it looks like the namespace changes actually are the culprit
<AlbertA> greyback: I used your new branch
<anpok_> o_O
<AlbertA> greyback: if I just change the name of MirSurface instead, then focus issue is gone
<kgunn> dandrader: ^ focus issue = osk issue on 0.1.6
<kgunn> AlbertA: so you've done the clean-image-test, verified you're packages installed, and everything ?
<AlbertA> kgunn: I'm manually installing (i.e. pushing with adb to /usr/lib)
<kgunn> AlbertA: got it...but once you see it, then a dpkg -a to double check (...at least i think its -a)
<greyback> anyone have a few minutes to review https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision2/+merge/209930 ?
<greyback> AlbertA: odd. What have I screwed up...
<dandrader> greyback, I can do it
<greyback> okay, I'm just rebuilding to see
<dandrader> greyback, btw unity-mir is clashing with what mir symbols specifically?
<greyback> dandrader: "MirSurface"
<dandrader> kgunn, so the mir branch to use for this bug is lp:~mir-team/mir/trunk-0.1.6 , right?
<kgunn> dandrader: correct
<kgunn> so...wanna join
<kgunn> https://plus.google.com/hangouts/_/calendar/a2V2aW4uZ3VubkBjYW5vbmljYWwuY29t.2k4udqa2ovs931siq3b5fprgkc
<anpok> dandrader: alf__ AlbertA: hmm had connection issues again..
<anpok> Q_DECLARE_METATYPE seems to need some additional love..
<dandrader> kgunn, so we have a unity-mir branch that renames MirSurface (instead of putting it in a namespace) and it solves bug 1289058 ?
<ubot5> bug 1289058 in unity-mir "[regression] OSK focus issues" [Critical,Triaged] https://launchpad.net/bugs/1289058
<anpok> dandrader: i think AlbertA does not have published one yet..
<greyback> dandrader: that'll work I suppose. Why namespaces breaking it still mystifies me tho
<anpok> https://bugreports.qt-project.org/browse/QTBUG-15459
<anpok> greyback: ^
<greyback> anpok: yep, I knew about that
<greyback> but usually a nice loud error message accompanies that
<kgunn> greyback: so dandrader says "we just shouldn't go there"
<kgunn> :)
<kgunn> i'm gonna leave that bug open tho....maybe it should go against Qt ?
<greyback> kgunn: the fastest solution is that yes. Looks like a bug I can beat my head against for a day or two, something subtle with Qt/qml and namespaces
<AlbertA> greyback: kgunn: I think we found the issue
<AlbertA> greyback: kgunn: it is indeed the Q_PROPERTY in inputarea.h
<AlbertA> Q_PROPERTY(MirSurface* surface READ surface WRITE setSurface NOTIFY surfaceChanged)
<AlbertA> change to
<AlbertA> Q_PROPERTY(unitymir::MirSurface* surface READ surface WRITE setSurface NOTIFY surfaceChanged)
<greyback> ah feck
<greyback> AlbertA: that's if
<greyback> it
<AlbertA> greyback: we need to do that for all Q_PROPERTY items
<AlbertA> greyback: kgunn: yep confirmed on the n4
<AlbertA> kgunn: greyback: so what do you want to do?
<kgunn> AlbertA: wow...so if that confirms it, sounds like we should just poperly use the Q_PROPERTY
<kgunn> ....unless, did dandrader|lunch say there was some other knock-on bug ?
<greyback> AlbertA: I'm updating the namespace branches now
<greyback> AlbertA: I reapproved your https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1240400/+merge/207302 since it was not to blame
<greyback> anpok ^^
<AlbertA> kgunn: well in this particular case
<AlbertA> kgunn: there was no qt error
<AlbertA> kgunn: because I suppose MirSurface * got resolved to Mir's version
<kgunn> AlbertA: greyback anpok dandrader|lunch ...thanks all nice work, and so, the MP list should remain as it is...i'll just assume gerry's update will be on the original
<kgunn> https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision/+merge/208645
<greyback> kgunn: yep
<greyback> ok fix pushed
<dandrader> kgunn, using fully qualified names in all qt macros might solve all woes indeed. It's just that I've been bitten by such issues before thus I would rather avoid this namespace vigilance if possible
<dandrader> AlbertA, kgunn and that includes all signal-slot connections and parameters as well, if I'm not mistaken
<AlbertA> dandrader: just for my own curiosity, what sort of issues have you encountered? To they manifest as crashes? weird behavior? something else?
<dandrader> AlbertA, a connection between a signal and a slot may fail, for instance (mismatching parameters due to namespace confusion). and that failure, depending on how you do that connection in C++, will fail silently at runtime
<dandrader> AlbertA, but it was a while ago, so I don't recall details.
<greyback> dandrader: well C++11 does give us nicer compile time signal/slot connections, which can help - it does parameter matching if I'm not mistaken
<dandrader> greyback, yes
<greyback> adding more symbols to the global namespace will inevitably cause collisions. namespaces necessary evil. They're tricksy with Qt annoyingly
<anpok> hmm ok now the nexus 4 shows a black screen with a grey sign, red letters: Download Mode Do not unplug the device until the process is complete..
<kdub> eh, its lying
<kdub> probably just a wrong key combo when it was booting
<anpok> k restarting
 * greyback eow, but will be back online in a few
<anpok> swapping the usb cable did the trick..
#ubuntu-mir 2015-03-02
<Saviq> hey guys, running unity8 AP tests I'm getting:
<Saviq> [1425305407.478378] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in setSwapInterval): /build/buildd/mir-0.12.0+15.04.20150228/src/client/buffer_stream.cpp(283): Throw in function virtual void mir::client::BufferStream::request_and_wait_for_configure(MirSurfaceAttrib, int)
<Saviq> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEEE
<Saviq> std::exception::what: Attempt to set swap interval on screencast is invalid
<Saviq> ideas?
<greyback__> you're not the first to report that
<greyback__> https://bugs.launchpad.net/mir/+bug/1425307
<ubot5> Launchpad bug 1425307 in mir (Ubuntu) "[regression] Exception when running phablet-screenshot (mako/vivid 110) [std::exception::what: Attempt to set swap interval on screencast is invalid]" [Medium,Triaged]
<Saviq> ok seems non-fatal indeed
<Saviq> anpok, hey, can you please resolve conflicts in https://code.launchpad.net/~andreas-pokorny/mir/override-orientation-for-input-region-and-cursor/+merge/248897
<anpok> Saviq: resolving that will not help
<anpok> Saviq: at least for the purpose of silo-0
<Saviq> anpok, uhm :/
<anpok> the other conflicts in mg::Display are more problematic
<anpok> so i was moved to silo-9 and started a new branch
<anpok> https://code.launchpad.net/~andreas-pokorny/mir/reworked-external-output-centering-integration-branch/+merge/251357
<anpok> ^ this contains all of it
<anpok> and works fine for n4, but needs another trick for n7
<Saviq> thank
#ubuntu-mir 2015-03-04
<alan_g> alf_: anpok - any opinions pending on this? https://code.launchpad.net/~kdub/mir/report-vsync/+merge/251532
<anpok> taking a look
<duflu> alan_g: I'm still concerned about the accuracy. The report function is called some unbounded time after vsync. But in the case of constant rendering, it will usually be fairly close
<duflu> We have the same trade-off in our perf reports already
<duflu> And that's enough.
<alan_g> On the BBC: http://m.bbc.co.uk/news/technology-31723029
<ameurux> hello
<kenvandine> i hear there a way to make mir logging more verbose, any pointers?
<anpok> kenvandine: http://unity.ubuntu.com/mir/component_reports.html
<kenvandine> anpok, thx
<anpok> kenvandine: two are missing shared-library-prober-report and compositor-report (fixing that)
<tmpRAOF> Hm. That reminds me. Should turn shared
<tmpRAOF> Hm. That reminds me. Should turn shared-library-prober-report into some unconditional logging.
<anpok> hm hm
<anpok> but meanwhile it gets documented
<tmpRAOF> Absolutely.
#ubuntu-mir 2015-03-05
<alan_g> alf_: anpok_ are we content to support these interfaces? https://code.launchpad.net/~alan-griffiths/mir/integrate-generic-shell/+merge/251581
<kenvandine> what causes the prompt session state to change to mir_prompt_session_state_suspended
<kenvandine> ignore that last question :)
<kenvandine> i'm working on trust session for content-hub, and I'm close... I have a valid prompt session and i'm sure i have a valid file descriptor for MIR_SOCKET
<kenvandine> but my helper is throwing this:
<kenvandine> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<mir::socket_error> >'
<kenvandine>   what():  Failed to read message from server: Socket operation on non-socket
<kgunn> camako: racarr AlbertA ^ anyone got any hints for kenvandine
<camako> kgunn, below his question he says to ignore it (figured it out?)
<kgunn> camako: true, just wondering if someone knew why the helper might be angry
<dandrader> kdub,  does mir provide the display DPI?
<kenvandine> camako, i had another question after that
<kenvandine> on my service side i have a prompt session that is in the state starting
<kenvandine> and my helper finds the file descriptor (and is valid)
<kenvandine> but i get that error
<kenvandine> although now i seemed to have broken the service side... let me fix that again and ask again later :)
 * dandrader wonders it differs from ro.sf.lcd_density]
<kdub> dandrader, it does not yet
<kdub> although its mostly plumbed out... let me put something on the mir backlog
<dandrader> kdub, ok, so the best way is to fetch the ro.sf.lcd_density android property, right?
<dandrader> at least for now
<dandrader> racarr_, racarr, ping
<racarr_> dandrader: Pong
 * kdub considers tinkering with std::regex for the lttng parsing
<racarr> or rather pong
<dandrader> racarr, https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164/comments/625592
<racarr> dandrader: Yeah good call
<racarr> I guess it works because papi still pulls in mirclient
<racarr> hmm
<racarr> 0.11 I guedss
<racarr> oh
<racarr> maybe 0.10
<racarr> I dunno
<racarr> dandrader: Fixed. Thanks
<dandrader> ack
<kdub> dandrader, put the dpi task on the mir backlog: https://trello.com/c/mzxOXlfW
<dandrader> kdub, where will you get that information from? can it differ from ro.sf.lcd_density?
<kdub> that bubbles out to me through the driver
<kdub> from the kernel, through the hwc library
<kdub> and, I guess it shouldnt differ, but havent done a survey of devices
<AlbertA> kenvandine: it sounds like the connection has not yet been established....could be race somewhere...
#ubuntu-mir 2015-03-06
<duflu> kdub: Still around?
<duflu> That's fun. Apparently I wrote almost half the Ubuntu spinner code and didn't even know it
<alan_g> That's being productive. ;)
<duflu> Yeah, welcome to open source
<alan_g> duflu: have you any thoughts on this one? https://code.launchpad.net/~alan-griffiths/mir/integrate-generic-shell/+merge/251581
<duflu> alan_g: Nope. I haven't looked at any of your shell work
<duflu> And am about to run out of week
<alan_g> np Have a fun weekend
<kenvandine> i tried enabling some reporting in mir, to debug my trust session issues
<kenvandine> but now the shell isn't starting
<kenvandine> MIR_SERVER_SESSION_MEDIATOR_REPORT=1
<kenvandine> MIR_SERVER_SCENE_REPORT=1
<kenvandine> any ideas?
<alan_g> MIR_SERVER_SESSION_MEDIATOR_REPORT=log MIR_SERVER_SCENE_REPORT=log
<kenvandine> oh
<kenvandine> alan_g, thanks!
<alan_g> yw
<alan_g> I guess you don't see the error message. ;)
<kenvandine> alan_g, to debug trust sessions is MIR_SERVER_SESSION_MEDIATOR_REPORT the most important one?
<kenvandine> not sure where to look for the error :)
<alan_g> What's the symptom?
<kenvandine> my client is getting rejected
<alan_g> Are you connecting to the trusted socket or the regular one?
<kenvandine> with MIR_SOCKET set to the file descriptor
<kenvandine> not sure what the regular one is
<alan_g> That's OK, I misunderstood
<alan_g> You could also see what msg-processor-report and rpc-report have to say
<alan_g> but session mediator is a starting point
<kenvandine> wow that's verbose
 * alan_g wonders if the only reason handle_surface_created() exists is to raise() a surface that hasn't yet posted a buffer.
#ubuntu-mir 2016-03-09
<tjaalton> mesa 11.2.0-rc3 available on ppa:canonical-x/x-staging
 * popey pounces on bschaefer 
<bschaefer> hello!
<popey> bschaefer: been playing with ScummVM again :)
<bschaefer> nice!
<popey> http://people.canonical.com/~alan/screenshots/device-2016-03-09-174048.png
<bschaefer> so at lease its working :)
<bschaefer> *still*
<popey> it launches, game launches, and runs, audio etc
<popey> but it seems to fail to get the right resolution in landscape
<bschaefer> right thats.. still an issue
<bschaefer> im not sure who  controls that (i think i might have to do something in sdl2?)
<bschaefer> popey, i talk directly to mir with sdl2
<bschaefer> soo i got no fancy unity8 help
<popey> :(
<popey> http://people.canonical.com/~alan/screenshots/device-2016-03-09-135627.png is what currently happens which I think is... http://imgur.com/bvwVD2j
<bschaefer> there was an idea to always stary games in landscape if possible...
<popey> it's like the app gets told 540x960 even in landscape
<bschaefer> popey, hmm
<bschaefer> strange, im not super sure, as unity8 *should* still attempt a rotate
<bschaefer> since we are still a surface in unity8
<popey> it does "rotate", just keeps the fixed 540x960 res
<popey> same for other apps like dosbox
<bschaefer> right, im guessing i just dont handle that
<popey> so it's quite common
<popey> right
<bschaefer> (i think thought a resize event?)
<popey> i dont see any resizing happen
<bschaefer> i mean
<bschaefer> i should be getting a resize event in sdl2
<bschaefer> but i just dont do anything with it :)
<bschaefer> which ... could be an easy fix
<bschaefer> popey, IIRC the issue was SDL2 didnt have an easy way to resize their surface
<bschaefer> soo i had to remake it or something ... then forgot about it
<greyback_> popey: in the desktop file, could you add "X-Ubuntu-Supported-Orientations=Landscape" and re-launch the app
<greyback_> just in case that persuades it to use the correct resolution
#ubuntu-mir 2016-03-11
<alan_g> anpok: I'm seeing a local failure (on xenial) in LibInputDeviceOnMouse.reads_pointer_settings_from_libinput today - any suggestions?
<anpok> alan_g: hm I can remember having that in xenial too .. I solved that with make clean .. and cleaning ccache?.. not sure..
<alan_g> anpok: I solved it. make clean didn't help, rm -rf * && cmake .. did
<anpok> means it loads something old.. somehow..
<alan_g> Dunno. Probably not refreshing something in CMakeCache.txt
<alan_g> camako: in case it is something trivial (for you), could you glance at this: https://bugs.launchpad.net/mir/+bug/1556210
<ubot5> Launchpad bug 1556210 in Mir "Mir-on-X11 doesn't exit (until it gets an event)" [Undecided,New]
#ubuntu-mir 2016-03-13
<talmage_> I'm looking for help making ubuntu touch work on my WeTab.
<talmage_> I have ubuntu8-desktop-session-mir installed.
<talmage_> I have mir-graphics-drivers-desktop installed.
<talmage_> I can start the regular ubuntu desktop.  It's often finger friendly.
<talmage_> When I start the touch desktop, I'm prompted to log in again.  There is no on screen keyboard.
<talmage_> How do I enable the keyboard so that I can log in?
<talmage_> I plugged in a USB keyboard so that I could log in.
<talmage_> Now I have a window that says "Scopes".  It keeps closing and re-opening.
<talmage_> Any clues for me?
#ubuntu-mir 2017-03-06
<alan_g> anpok: in our test framework, can you recommended a way for an acceptance test to synthesise pointer events?
<alan_g> For DnD I just want to "move" the cursor over a couple of surfaces
<bschaefer> alan_g, i think ive done some in test_confined_pointer.cpp though ... could look a bit better
<alan_g> bschaefer: thanks, that's a good place to start
<bschaefer> np!
#ubuntu-mir 2017-03-08
<hikiko> hey
<hikiko> duflu, are you around?
<duflu> hikiko: Yes
<hikiko> hello :)
<hikiko> do you know anything about miral?
<hikiko> I run it and it crashes with this error:
<hikiko> http://pastebin.com/wzCNkedA
<hikiko> and I am almost sure, I didn't install some mir or miral dependency
<duflu> hikiko: Don't know. Try alan_g (who starts in 5 minutes?)
<hikiko> ok :) thanks!
<hikiko> lol here he is!
<hikiko> hi alan_g
<hikiko> I have questions for you!!
<hikiko> good morning :)
<hikiko> mmm duflu do you use any ppa for mir?
<duflu> hikiko: No. Just zesty, or compile lp:mir. But I only use Unity8 with the official zesty packages
<hikiko> I can't compile mir for some reason either... I get some compile errors
<hikiko> can I show you?
<duflu> hikiko: That's interesting. Yes please show the error
<hikiko> might be just my configuration :p 1 sec
<hikiko> duflu, linker* errors
<hikiko> https://paste.ubuntu.com/24136976/
<hikiko> I am pretty sure I didn't install something properly
<hikiko> I am building that inside a chroot
<hikiko> so I might miss some package
<hikiko> I have installed mir common, platform, client, server, mesa-x12 etc
<alan_g> hikiko: are you following https://unity.ubuntu.com/mir/0.26/building_source_for_pc.html?
<hikiko> alan_g, yes
<hikiko> also miral-shell gives me a segfault because some cpp is missing give me a sec
<hikiko> [10:54:00] <hikiko> I run it and it crashes with this error:
<hikiko> [10:54:20] <hikiko> http://pastebin.com/wzCNkedA
<hikiko> alan_g, I am sure there's something on my system missing because I could run miral
<hikiko> but I can't figure out what
<alan_g> hikiko: I don't see how those instructions would try to lonk with //usr/lib/x86_64-linux-gnu/libmirclient.so.9
<alan_g> *kink
<alan_g> **link
<hikiko> alan_g, I don't know either
<hikiko> I just copy pasted all the commands
<hikiko> oh I don't know if it's relevant
<hikiko> I am using also this ppa:
<alan_g> hikiko: "./miral-shell/decoration_provider.cpp:196" is trying to load a font
<hikiko> cemil-azizoglu-ubuntu-mesa-rs-zesty.list
<hikiko> I am apt-file searching it
<hikiko> ttf-ubuntu-font-family: /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf
<hikiko> alan_g, it seems that the font is there
<duflu> hikiko: It appears you have an old version of the libmirclient package installed (0.25) but a new libmirclient (0.26). Try updating to ensure they are all version 0.26.1
<duflu> hikiko: It appears you have an old version of the libmirclient package installed (0.25) but a new libmircommon (0.26). Try updating to ensure they are all version 0.26.1
<duflu> hikiko: zesty right?
<hikiko> duflu, yes
<hikiko> but apt-get update/dist-upgrade
<hikiko> doesn't propose anything for mir
<duflu> Hmm
<duflu> hikiko: dpkg -l | grep libmir
<hikiko> duflu, http://pastebin.com/UWBS4hHx
<hikiko> it seems that everything is 0.26 :s
<duflu> Oh, maybe I should not expect the symbol versions to change. Hang on
 * alan_g wonders why loading the font failed at L196, not L96 (which gives a clear message)
<hikiko> alan_g, do you want a backtrace>
<hikiko> ?
<duflu> hikiko: That PPA won't cause the problem either. I guess you have either leftovers from some old PPA or custom environment finding libmircommon in a strange place
<alan_g> hikiko: does "$ miral-app -kiosk" run?
<duflu> I really wish we didn't have launcher commands
<duflu> But now count at least four
<hikiko> alan_g, it gives the same error
<hikiko> but then:
<hikiko> waiting for /run/user/1000/mir_socket
<hikiko> waiting for /run/user/1000/mir_socket
<hikiko> oh
<hikiko> sec
<hikiko> maybe it's the chroot
 * alan_g wonders how it can give an error from code that isn't running
<alan_g> or even in the executable
<hikiko> [2017-03-08 09:23:40.909694] mirserver: Using software cursor
<hikiko> ERROR: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
<hikiko> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >
<hikiko> std::exception::what: bind: No such file or directory
<hikiko> Segmentation fault
<hikiko> waiting for /run/user/1000/mir_socket
<hikiko> waiting for /run/user/1000/mir_socket
<hikiko> then it prints the message forever
<alan_g> If the server crashes /run/user/1000/mir_socket will take a long time to appear
<alan_g> Just kill it with ^C
<hikiko> yep, I killed it already
<alan_g> Do you have anything Mir in /usr/local/lib?
<hikiko> let me check
<hikiko> no
<hikiko> just python
<alan_g> $ ldd `which miral-shell`
<duflu> Morning alf_ ... Perhaps interesting reading: https://lists.freedesktop.org/archives/mesa-dev/2014-July/063977.html
<hikiko> alan_g, http://pastebin.com/zAVKL89W
<duflu> (which I only found when searching for the new function he added in the header but failed to implement)
<alan_g> That all looks sane
<hikiko> then why it segfaults?
<alan_g> Not obvious.
<alf_> duflu: thanks
<alan_g> It's annoying to debug too - (mir-on-X grabs input). Can you ssh from a different machine?
<hikiko> alan_g, it's a chroot I guess if I open it from another terminal it's fine
<hikiko> it doesnt grub input btw if you roll the window :)
<alan_g> hikiko: for differential diagnosis - do Mir & MirAL work outside the chroot?
<hikiko> mmm miral-shell seems to work
<hikiko> I don't know about mir I don't want to install its dependencies on desktop
<alan_g> Sure
<hikiko> so, it's probably what I suspect
<hikiko> something missing from chroot
<alan_g> Yeah
<hikiko> that is installed on desktop
<alan_g> A stacktrace from miral-kiosk might give a clue
<alan_g> There's clearly also a problem with the font
<duflu> It may not be relevant now, but when I first did font support I found I could not use the Ubuntu font because it was missing in Core
<hikiko> interesting: miral-kiosk without params can run (it shows a red screen that fades out) when I mount /run/user/1000
<hikiko> but miral-shell cant
<hikiko> alan_g, the font is just a warning
<hikiko> I think the real error is that:
<hikiko> (anonymous namespace)::Printer::printhelp (
<hikiko>     this=0x55555583a080 <(anonymous namespace)::render_pattern(MirGraphicsRegion*, unsigned char const*)::printer>, region=...)
<hikiko>     at ./miral-shell/decoration_provider.cpp:196
<hikiko> 196     ./miral-shell/decoration_provider.cpp: No such file or directory.
<hikiko> $ apt-file search decoration_provider.cpp returns nothing
<hikiko> that's why I was wondering if my mir version is outdated and I need a ppa
<alan_g> hikiko: ./miral-shell/decoration_provider.cpp:196 is trying to use the font. Are you sure it exists with sane access permissions in the chroot?
<duflu> If you're using Core/snappy then it's possible the Ubuntu font doesn't exist still. That's why I used LiberationSans-Bold.ttf. Confusingly Ubuntu Core did contain RedHat's font
<duflu> hikiko: Are you running full desktop zesty?
<duflu> Might have a similar problem with Ubuntu Server
<alan_g> OK, if miral-kiosk runs then the only problem seems to be the font
<alan_g> Are there any fonts in the chroot?
<hikiko> I reinstalled the font
<hikiko> and worked :)
<hikiko> now I have to find out why mir doesn't build, I guess something similar :p
<hikiko> alan_g, yes
<hikiko> there were
<duflu> hikiko: What ISO did you install from?
<duflu> If any
<hikiko> duflu, no iso I used debootstrap
<hikiko> on zesty
<alan_g> You can choose the font with --shell-titlebar-font
<duflu> I guess a more elegant fallback than crashing is required for missing fonts
<hikiko> yeah :)
<hikiko> anyway, thanks duflu alan_g :)
<alan_g> duflu: it's odd - it exits with an error if opening the font fails. This is something new.
<duflu> Oh
<duflu> Anyone found PosixRWMutex unit tests hang/fail?
<duflu> I'm only seeing it today
<alan_g> Hmm. I was wrong...
<alan_g> WARNING: failed to load titlebar font: "rubbish"
<alan_g> Segmentation fault (core dumped)
<duflu> That's not this one is it? https://errors.ubuntu.com/problem/c4a91485a9e7bf2774806d21e8c6c71f8ef79f08
<alan_g> hikiko: do you see a "WARNING: failed to load titlebar font" message before the segfault?
<hikiko> yes alan_g
 * alan_g goes to log a bug
<hikiko> but as I said, after re-installing ubuntu fonts I don't see the segfault, it works great
<alan_g> Sure, but it shouldn't segfault if the font isn't there.
<alan_g> duflu: I can't tell what that is
<alan_g> greyback: HTH https://bugs.launchpad.net/miral/+bug/1670741/comments/1
<ubot5> Ubuntu bug 1670741 in MirAL "Have a MIRAL_WINDOW_MANAGEMENT_TRACE env var" [Undecided,Invalid]
<greyback> alan_g: oh so that already works? Great
<alan_g> You just had the spellign wrong
<greyback> *nod* understood
 * alan_g can't type this morning
<greyback> alan_g: https://bugs.launchpad.net/miral/+bug/1670876 <- ack, I couldn't see any real miral code that would impact it, but logged it against miral as miral-shell has the same bug
<ubot5> Ubuntu bug 1670876 in Mir "Setting cursor causes window's input_region to be reset" [Undecided,New]
<alan_g> Sure, it's either the new APIs or misuse of the new APIs
<attente> is gtk supposed to be receiving a resize event when the window appears? or should gtk be querying this manually?
<alan_g> attente: the resize events are mostly useless as they are not synced with the size of the buffer. The buffer has a size which is accurate.
<attente> alan_g: but the resize events are still useful for checking when the buffer size changes, no?
<alan_g> attente: well, if the size doesn't match the buffer, then there is a possibility that you'll get a buffer of a different size after a few swaps. (Unless there's another resize first)
<alan_g> Not sure how useful that is though.
<attente> alan_g: ok, so the buffer size is authoritative basically...
<attente> alan_g: thanks
<attente> this is a bit annoying that we have to keep track of the size and synthesize the gdk event when it changes, but should be manageable
<alan_g> kdub: ^^ anything to add for NBS?
<greyback> attente: I can say from the Qt side, we totally ignore the mir resize event. It arrives at an arbitrary time. It would be far more useful if it arrived, and then you were guaranteed the next buffer you swap has that size.
<greyback> we go by the buffer size instead
<greyback> which is not ideal
<attente> greyback: ok, thanks for the info. in the end i don't see it being too much of a problem
 * alan_g thinks we should never have provided resize events. Then people wouldn't try to use them.
 * attente shrugs
<greyback> I see value in resize events, but only if they arrive at the right time
<attente> if this is the concern, why not deprecate them?
<kdub> oh, resize events make sense now
<kdub> they're a notification that the shell has redesignated the size, and the client is in control of the physical size of the buffers
<kdub> and lets the client figure out how its subscene should get resized
<attente> kdub: what if the client decides to set the buffer size to something different from the resize event's size?
<greyback> kdub: what if client creates buffers of sizes that the shell didn't decide on?
<greyback> heh, same question, different epxression
<attente> :)
<greyback> only real buffer management qtubuntu is doing is via egl swap buffers
<kdub> a different physical buffer size isn't a problem, the client arranges its scene via mir_window_spec_set_streams
<kdub> and the difference is accommodated by the renderer, usually scaling, but guess a renderer could also do clamping or whatever if it wanted
<kdub> greyback, the new system, when the resize event comes along, its only an indication that the shell has resized the on-screen size
<attente> but that kind of invalidates the approach we were talking about earlier where we would check the buffer size to reliably determine the window size
<kdub> and the client calls mir_render_surface_set_physical_size() (soon to be mir_surface_set_physical_size()), and at that point, then the next buffer out of eglSwapBuffers will be the right size
<greyback> so it is up to shell to confine any client buffers that "mis-behave"
<kdub> well, the shell is already painting at the size it wants
<attente> i'm really just looking for a reliable way to know the size we should render at to get no scaling
<greyback> sure. But as I understood it, clients got a buffer of size whose size the shell decided ultimately
<kdub> in the new system, the clients are in charge of buffers
<attente> this is what i thought too, greyback
<attente> based on what alan_g was saying
<kdub> so, in the case where there are no sub-surfaces (one surface to one bufferstream)
<greyback> kdub: ok, new system behaves differently, that's ok. I just wanted to be consider the diffference from the shell's PoV
<attente> kdub: so does that mean this bug should theoretically fix itself once the new system is in place? https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1670390
<ubot5> Ubuntu bug 1670390 in unity8 (Ubuntu) "Desktop applications don't get properly resized when launched in staged mode" [High,In progress]
<attente> (speaking from a gtk perspective)
<greyback> attente: that's unity8 only, right?
<attente> greyback: i'm not sure. but i haven't seen this bug in miral-shell
<greyback> attente: if not in miral-shell, then probably unity8's fault
<kdub> re the bug, not sure without thinking harder
<attente> greyback: i'm just confused about how to reliably get the window size
<greyback> attente: I'd go with buffer size for now
<kdub> attente, which window size? :)
<attente> kdub: the mir window size :)
<greyback> attente: there is a general problem with unity8 and window resizing, which I think is mainly qtmir's fault (for which I've ideas)
<attente> kdub: like, should i be expecting it to come from a resize event? or do i have to query it?
<kdub> sure, the size of the window that the shell designates is comes from the resize callback
<kdub> right, resize event, no querying
<attente> kdub: ok, then there's definitely an issue with unity8 not sending the proper resize event when the window appears
<attente> or in stage mode for that matter
<kdub> attente, iirc, there's no resize event sent at startup
<greyback> attente: here is how we're doing it in Qt: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/view/head:/src/ubuntumirclient/qmirclientwindow.cpp#L641
<attente> kdub: what's the right thing to do here? query on window creation? or should u8 send a resize event?
<greyback> attente: look for "handleGeometryChange" <- that is how we notify Qt of the window size change
<attente> greyback: is it worth doing this if the new system is supposed to send resize events reliably at some point?
<greyback> attente: I can't answer that, sorry. I can only tell you what works for us now
<attente> greyback: fair enough, thanks for the pointers. i think i'll eventually just copy what you've already done
<kdub> i think mir_window_get_parameters at startup to get the initial size the shell said, and after that the callback or you can requery via that function
<greyback> yep, we do that in qtubuntu, works ok
<kdub> right, in the old system, server/shell controlled both window size and physical size, in the new system, the server controls window size, and the client controls/owns the physical buffers (and their sizes)
<greyback> gotcha
<greyback> kdub: will old system hang around? Or eventually deprecated?
<greyback> kdub: and roughly on the topic, what about pixel format. If every buffer can have different pixel format, why would Window have that property (ref: https://bugs.launchpad.net/mir/+bug/1666533/comments/9)
<ubot5> Ubuntu bug 1666533 in MirAL "Shell wants api to listen for window pixel_format changes" [Medium,Incomplete]
<kdub> greyback, the old system really only exists in the client api that's being deprecated (internally, things are already plumbed with client-controlled physical sizes)
<kdub> greyback, windows no longer have pixel format
<kdub> hmm, might be a missed deprecation there
<kdub> i guess it says 'to be deprecated soon' in the comments
<greyback> ok
<greyback> kdub: from unity8's perspective, something that we be really useful is a notification that a client swapped a buffer with the new size & pixel format, as soon as the client swapped it
<greyback> s/we/would/
<greyback> welll
<greyback> actually, ignore hat
<kdub> sure :)
<greyback> I need to test an idea first. But if that idea fails, I'll be back to you
<kdub> looking at qmirclientwindow.cpp, mir_buffer_stream_get_egl_native_window is going away soon
<greyback> kdub: I presume it will get a replacement of similar functionality?
<kdub> greyback, right, so in the mir-1.0 world, you just plug a MirSurface (formerly MirRenderSurface) into eglCreateWindowSurface
<kdub> the MirSurface->MirWindow and MirRenderSurface->MirSurface rename in 1.0 makes for confusion when talking about it :)
<kdub> basically, we've gone from being a server that supports 2 different EGL systems, to being one that has a mir egl platform
<greyback> yep, the transition made all my old terminology confused
<kdub> yeah, we also need a grand mir-server-internal rename for it :/
#ubuntu-mir 2017-03-09
<duflu> mpt: (sorry, I haven't seen or found design docs in a long time) is there any surface type that never gets keyboard focus?
<duflu> I mean I need one that can be on top but not get keyboard focus to support X apps
<mpt> duflu, yes, the âglossâ and âtipâ types are unfocusable, and an app/toolkit should be able to specify whether a particular âfreestyleâ window is unfocusable. <https://goo.gl/VWvXTA>
<duflu> mpt: Excellent, thanks
<RAOF> duflu: The thought occurs that you could also do this with arranging streams inside the window...
<duflu> RAOF: Perhaps, but I can do the same with XComposite. Both have the downside of only working correctly if the child overrideRedirect is within the parent
<duflu> Assuming we fix our MirWindow clipping
<RAOF> It's an open question whether that's âfixâ or not :)
<duflu> RAOF: You mean we should support streams outside their window?
<RAOF> Correct.
<duflu> Maybe
<duflu> *shruf*
<RAOF> Yeah.
<duflu> *shrug*
<duflu> At least not give each stream a titlebar
<RAOF> Last time I checked each stream didn't get a titlebar :)
<duflu> Well that's good.
<RAOF> It's a perfectly sensible thing to do (it gets you nice things, like client-side shadows working correctly). It's also a perfectly sensible thing to want to prohibit.
<duflu> I'm randomly reminded I would like to implement MIR_CLIENT_PERF_REPORT=in_titlebar
<duflu> Client-side shadows are a bug, not a feature
<duflu> The compositor can't join them and do proper 3D arrangement
<RAOF> This is true.
<duflu> I strive to fix that
<duflu> That said, dumb shadows as part of your decoration are beautifully simple and efficient
<anpok_> similar to other types of client side bling bling..
<anpok_> like .. ambilight..
<anpok_> if you ever want to watch movies not fullscreen..
<duflu> Don't know. I need to EOD at some point
#ubuntu-mir 2017-03-10
<duflu> RAOF: I spent most of the past week with a radeon card and then nouveau... but strangely both prevented lightdm from starting. Is that expected? Mir was happy to run in a VT still
<RAOF> duflu: That is unexpected.
<duflu> Hmm, like some state from intel was remembered
<duflu> Oh I wonder...
<RAOF> My desktop has a radeon card *and* a nouveau card, and lightdm is perfectly happy to drive X across both.
<RAOF> If you've got an xorg.conf or such snippet, that would be a problem.
<duflu> I don't have a xorg.conf
<duflu> Thought of that
<duflu> RAOF: Could it be the intel card was still active and having a monitor only on the discrete card was unexpected?
<duflu> I will check some day...
<RAOF> Unlikely. X will bring up any and all GPUs.
<RAOF> Xorg.0.log is, as always, the price of admission to the debug train :)
<duflu> Anyway; win! Mir is doing better than X for card support and in some cases touchpad support
<duflu> If only we could stop using ubershaders in U8 then Atoms would run nicely too
<duflu> Thanks for the quick fix RAOF
<duflu> (capnp)
<duflu> Why is USC's compositor thread my top disk writer?!
<duflu> That's the opposite of what I want
<duflu> Oh, reporting
