#ubuntu-mir 2014-02-10
<RAOF> bregma: https://bugs.launchpad.net/mir/+bug/1206780 and https://bugs.launchpad.net/mir/+bug/1216515 are probably part of your problem.
<ubot5> Launchpad bug 1206780 in Mir "[enhancement] Clients cannot change the hardware cursor" [Low,Triaged]
<ubot5> Launchpad bug 1216515 in Mir "[multimonitor] Mir's hardware cursor often becomes invisible on one monitor" [Medium,Triaged]
<anpok> alf_: the diff is about 7000 loc
<anpok> didnt we recently have an issue with unresolved symbol eglCreateImageKHR in unit tests?
<alf_> anpok: which diff?
<anpok> alf_: report namespace and hidding report implementations
<alf_> anpok: I vaguely remember that we used the symbol directly instead of getting it through eglGetProcAddress
<alf_> anpok: @7000 line diff, is there a way you can split it up? Do the 7000 lines include moves of files?
<anpok> moves of files, and splitting of files
<anpok> and lots of trivial renames
<anpok> lick NullFooReport null::FooReport ..
<anpok> like
<anpok> alf_: we still do that in tests/unit-tests/graphics/test_graphics_platform.cpp or I
<alf_> anpok: right, that's wrong... the extensions are already correctly set-up in mock_egl.cpp
<alf_> anpok: we can just remove the ON_CALLs from test_graphics_platform
<anpok> yes, curious why it did not fail before - or in all current mps
<alf_> anpok: possibly the specific egl functions where not even called in those tests
<Nothing_Much> How is a Radeon Xpress 200 on XMir or Mir whichever?
<Nothing_Much> Anyone?
<anpok> Nothing_Much: just try it. You will need the mesa based radeon driver instead of fglrx
<Nothing_Much> I just did, but I can't get XMir to work
<Nothing_Much> (I'm on an old Radeon Xpress 200)
<dandrader> https://bugs.launchpad.net/mir/+bug/1276162 says it's been released on Mir 0.1.5, But lp:mir and lp/ubuntu/mir has 0.1.4. Where is 0.1.5?
<ubot5> Error: Could not gather data from Launchpad for bug #1276162 (https://launchpad.net/bugs/1276162). The error has been logged
<xnox> ricmm: heya! i've tried to use mirout utility on grouper and it says that it couldn't connect to server.
<xnox> ricmm: how / under what environment should mirout be running?
<rsalveti> alf_: hey, were you able to split the backends into different packages already?
<rsalveti> just want to know if you already got it done somehow, so I can better plan the landing for it
<alf_> rsalveti: I am working on it, not ready yet. My plan is to provide package that use dpkg alternatives for the defaults, e.g., /usr/lib/../libmirplatformgraphics.so will point to either android or mesa shared object. You can also use a particular backend by explicitly setting environment variables.
<alf_> rsalveti: How does that sound?
<rsalveti> alf_: looks good
<rsalveti> let me know once you get a mr for it
<alf_> rsalveti: ok
<anpok> dandrader: there seems to be a tag but the branch has not been merged to lp:mir..
<anpok> reviwe is ongoing
<dandrader> anpok, ended up finding this branch https://code.launchpad.net/~mir-team/mir/trunk-0.1.5
<dandrader> so I suppose it will be put to trunk is smoke tests on it go well....
<dandrader> s/is/if
<kgunn> dandrader: eventually
<kgunn> process is log jammed
<kgunn> .............again
<kgunn> so yeah, i may even pull in additional changes on top of that mp...if time drags on
<kgunn> e.g. pull in newer dev-branch changes
<anpok> kdub: https://code.launchpad.net/~kdub/mir/hwc-layerlist-improvements/+merge/204789/comments/481336 -- sorry for taking so long..
<kdub> anpok, that line (59 in hwc layerlist) will just close the fd, all that's really changed on that line is the indentation
<anpok> yeah I expected more magic to happen there
<anpok> the other class does not need to close the fd?
<anpok> kdub: HwcFbDevice?
<kdub> that one relies on the fb device, so I don't see those drivers using t he fence,
<kdub> thanks anpok
#ubuntu-mir 2014-02-11
<kdub> thanks for the review duflu
<duflu> kdub: I don't claim to have tested it, but I support the idea :)
<RAOF> Oh, wow.
<RAOF> bzr merge -i --uncommitted works exactly like how I want it to work.
<mlankhorst> morning
<anpok_> alan_g: duflu alf_: which direction should i go now..
<anpok_> keep report::, but drop lttng:: and report::logging?
<duflu> anpok_: Ever forward... ?!
<duflu> Oh
<duflu> anpok_: I prefer the namespaces how they are today. And would prefer even more if we had fewer than that. So abstain
 * duflu -> dinner
<duflu> Good night
<alf_> duflu: bye!
<alan_g> Bye
<greyback> AlbertA: hey, quick comment on https://code.launchpad.net/~albaguirre/unity-mir/cross-compile-link-fix/+merge/205690
<anpok> alan_g: alf_: ... 200 lines less
<AlbertA> greyback: at least the mirserver library
<AlbertA> should be there
<AlbertA> as it's a direct dependency - it makes sure the api signatures haven't changed
<alan_g> anpok: It isn't the number of lines in the diff that matters. It is how easy it is to follow.
<AlbertA> greyback: Or not sure if you mean to use only the _LDFLAGS?
<greyback> AlbertA: yeah that was what I was asking. I was pouring over cmake manual to understand the difference
<greyback> AlbertA: _LIBRARIES seems to not set the -L path, which -LDFLAGS definitely does
<AlbertA> greyback: the LDFLAGS for those 3 packages at least just return -L path
<AlbertA> and the libraries flag sets -l<libname>
<greyback> AlbertA: http://www.cmake.org/cmake/help/v2.8.12/cmake.html <- searching for "_LDFLAGS" was what I was reading. I'm surprised now
<greyback> as it implies LDFLAGS contains all required linker flags (which I'd expect), whereas LIBRARIES contains list of lib names that need their pkgconfig scanned for linker flags
<greyback> do I mis-understand?
<anpok> greyback: the cmake pkg-config module creates a load of variables for each found library
<AlbertA> greyback: that's what I read too
<anpok> there is for example also PKG_NAME_LIBRARY_DIRS
<AlbertA> greyback: but it's essentially the output of pkg-config
<anpok> and that one could be used in link_directories() which is just symetric to include_directories()
<greyback> AlbertA: right
<greyback> So I guess I'm confused :)
 * greyback needs to dig a little more
<anpok> i.e. look inside CMakeCache.txt of your build dir..
<greyback> anpok: yeah I've been doing that, to check AlbertA's patch did what I expected, but now I'm unclear what's really happening
<greyback> mterry: comment on https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069
<mterry> greyback, noted.  I tested on android and it worked!  So apply_to must be doing something currently...
<greyback> mterry: nested in android? Or standalone?
<mterry> greyback, testing yourself is a little tricky.  You'd need to install several branches to see the difference, but will add to MP
<mterry> greyback, nested
<mterry> greyback, oh, you say that
<greyback> mterry: yeah, that I expect to be ok. Just standalone I found apply_to wasn't being called
<mterry> greyback, fair.  Though I don't happen to care about standalone case
<greyback> mterry: yep
<greyback> mterry: but I did for a while :)
<mterry> greyback, :)  hey, how is the scenegraph stuff going, btw?
<greyback> mterry: oh I've not been able to touch it for weeks now. Hope to resume it after MWC. racarr is doing some Mir adjustments to help integrate it however
<mterry> greyback, cool.  Poke me when it is more play-with-able.  I eventually plan to use it in the USC for interstitial animations between sessions
 * mterry heads out to buy a ladder
<greyback> mterry: really? Ok. /me thinks we'd better profile it carefully before nesting it like that
<AlbertA> greyback: you were right
<AlbertA> greyback: we only need LDFLAGS
<AlbertA> greyback: it does include everything like the docs say :)
<AlbertA> greyback: i.e. -L<path>;-l<libname>
<greyback> AlbertA: but I just tried compiling without LIBRARIES and it failed to link to mir!
<AlbertA> greyback: really? I tried here just using LDFLAGS it worked ok on both
<AlbertA> native and cross compiling
<greyback> let me try again, maybe I screwed something up
<greyback> AlbertA: you're correct, it works with just LDFLAGS
<AlbertA> I pushed a new revision
<AlbertA> to the branch
<greyback> AlbertA: and approved as it's exactly what I now have. Thank you!
<AlbertA> greyback: thanks!
<RAOF> anpok: It's not clear to me why logging:: should be under report::, as they're kinda two separate things. Not doing that move also reduces the namespace nesting somewhat.
#ubuntu-mir 2014-02-12
<anpok_> RAOF: logging::Logger and related went back to logging ... only report implementations are inside report now
<anpok_> RAOF: report exists only to have a place for report_factory and a place to know which report implementations exist.. so we could also not have report::lttng report::null.. but then we would end up having either one directory with 3 * 2 * n + n classes and three or one static libraries built and a shared library for lttng or three directories that do not add a namespace..
<anpok_> s/classes/files
<anpok_> n is 6 now
<alan_g> duflu: have you had time for more thoughts on https://code.launchpad.net/~alan-griffiths/mir/SwitchingBundle-controls-completion-of-client_acquire-without-blocking/+merge/205568?
<duflu> alan_g: On a hangout
<alan_g> np
<RAOF> anpok: I don't think I'd object to three directories that don't add a namespace :)
<anpok> RAOF: hm you only see the other namespaces in test cases when the null reports are used..
<anpok> i could get those cases away too
<anpok> i mean with something like .. NullReportFactory().create_what_needed() ..
<RAOF> Hm. That looks sensible at a first glance.
<duflu> alan_g: The answer is no BTW, I haven't thought about it at all. Consider that "Abstain" for now
<alan_g> duflu: OK. (It's just that I'd like as many good eyes as possible on that bit of code.)
<duflu> Yeah, agreed
<duflu> But instead, dinner!
<alan_g> Enjoy!
<alf_> alan_g: anpok: RAOF: at the moment our unit tests for the armhf native CI build run with valgrind, but we completely ignore valgrind errors... I wonder if there is a benefit in running them with valgrind at all at the moment. The only I can think of is the difference in timing that running under valgrind brings, and which may expose races (but then again the different timing may hide races too)
<RAOF> I thought valgrind was super-flaky on armhf?
<alan_g> So did I
<RAOF> As in: I didn't know the unit tests wouldn't SIGILL under valgrind on armhf :)
<alan_g> If valgrind can produce meaningful results we should use them
<alf_> alan_g: anpok: RAOF: They seem to run ok, apart from the thousands uninitialized value errors (running in Nexus 10, ERROR SUMMARY: 609348 errors from 532 contexts)
<RAOF> That sounds vaguely solvable with judicious overrides.
<RAOF> (As in: it's probably Android/libhybris stuff)
<RAOF> If no one feels like generating those overrides, though, I don't think we get any value out of running the tests in valgrind, except a 10x longer test time.
<alf_> RAOF: by overrides I guess you mean valgrind suppressions?
<RAOF> Yeah, that business.
<alf_> alan_g: anpok: RAOF: ok, so if no one objects I will 1. first try to create a suppression file if it's reasonable 2. if (1) fails turn off valgrind in mir-team-mir-development-branch-trusty-armhf-ci
<RAOF> Sounds good to me.
<alan_g> Sure
<anpok> ok
<mlankhorst> RAOF: ping? do you have an updated mir patch for mesa 10.1?
<mlankhorst> some parts no longer apply and other parts seem to have already been applied upstream in a slightly different form, so a rebase would be nic
<mlankhorst> nice*
<alf_> alan_g|lunch: anpok: great, our CI tests don't fail when there is a leak...
<anpok> hm because we would need extra flags to valgrind for that.. --leak-check=full?
<alf_> anpok: right
<alf_> alan_g|lunch: anpok: ok, the rabbit hole is too deep to deal with the suppressions right now, I will go for disabling valgrind for armhf in our CI
<alf_> alan_g|lunch: anpok: ... and at some poin we need to take a good look at what valgrind is actually doing in CI
<alan_g> alf_: ack
<mlankhorst> I pushed mesa 10.1 to https://launchpad.net/~canonical-x/+archive/x-staging/+packages -- i had to rebase the mir patch, so if you want to test if mir still works :-)
<alf_> rsalveti: ogra_: Hi! I need some advice for the separate -mesa, -android packages if you have some time
<mterry> Hello all!  I'm looking at USC and trying to do the following: determine when one of my sessions/surfaces has started writing actual content to its frame buffers.  i.e. when it has started to draw to the screen.  How would I go about doing that from a compositor perspective?
<ogra_> alf_, i saldy have to run out for a bit, is it ok to ping you back later ?
<mterry> ricmm, alan_g ^ ?
<alan_g> mterry: I'm not sure I understand the question. By "my sessions/surfaces" you mean a client process?
<ricmm> mterry: you mean you want to catch it *before* it first swaps?
<mterry> ricmm, no I don't need to intercept, just notice
<mterry> alan_g, yeah sure.  client process
<ricmm> no I mean, do you want to know while its rendering to the buffer but before swapping?
<ricmm> thats an odd need
<alf_> ogra_: sure, thanks
<mterry> ricmm, oh maybe I just need swapping
<mterry> ricmm, I just want to know when something is on screen for a given client
<alan_g> From the compositor the buffer swapper gets a client_acquire() call before the client gets passed the buffer. And a client_release() after it has drawn
<alan_g> mterry: what problem are you trying to solve?
<mterry> alan_g, with a split greeter, lightdm will launch both the greeter and user sessions at the same time.  I wanted to have the compositor wait to show either surface until the greeter is actually on screen (i.e. I don't want the user session showing on screen for a second if it wins the race)
<alan_g> I'm not convinced the compositor is the right place for that logic.
 * alan_g thinks...
<alan_g> Wouldn't it be better to just make the user session hidden?
<mterry> alan_g, but I want to unhide it when the greeter is drawn
<mterry> alan_g, (also is there a trivial way to mark it hidden?)
<anpok> session->hide()
<alan_g> session::hide()
<mterry> anpok, ooh, thanks.  Didn't notice that method
<mterry> OK, so that's helpful
<anpok> but you want both to be shown?
<anpok> (still confused?)
<mterry> anpok, yup, greeter is alpha-backed and will show session beneath it
<anpok> ah ok but you want to un-hide it as soon there are buffers to display?
<mterry> anpok, yes
<mterry> anpok, buffers to display by the greeter
<alan_g> I think this is better handled by detecting the swap_swap_buffers call in shell::Surface - not by hacking the compositor
<alan_g> until the greeter posts a buffer just hide() all sessions. When it has posted, then show() them
<alan_g> mterry: does that ^ make sense?
<mterry> alan_g, so install my own surface factory that returns a surface subclass that hooks into swap_swap_buffers?
<alan_g> mterry: yes. (If you try it in the compositor you'll never know whose buffer you're dealing with)
<mterry> alan_g, well.   I am in the compositor (I'm in unity-system-compositor).  Or do you mean the compositor class?
<alan_g> compositor component
<alan_g> s/component/namespace/
<mterry> alan_g, OK, cool.  Makes sense.  Though the compositor has access to session->name(), which will tell me which session it is
<alan_g> mterry: NB you'll be looking for a swap_buffers() call with a non-null buffer. (It will be null on the first call)
<mterry> alan_g, OK, thanks.  I will play with this today
<anpok> our tags seem to be wrong
<anpok> (or with a certain probablility I fail at using bzr tags)
<mlankhorst> RAOF: hm testing more.. 10.1 mir *client* fails, if I only upgrade mir server to 10.1 it works correctly..
<rsalveti> alf_: still in meetings, but can try to help
<rsalveti> alf_: what is the issue?
<alf_> rsalveti: Hi! I am trying to setup the dpkg alternatives for the various mir platform libraries (client and server) and was wondering if the preference was to go for symbolic link to the library directly, or to have a link to an ld.so.conf entry
<rsalveti> alf_: for me linking ld.so.conf is easier, I also use that for libhybris (to replace the mesa drivers)
<rsalveti> because then you end up having only one alternative
<rsalveti> ogra_: ^
<ogra_> alf_, have a look at the mesa gles/gl packages
<ogra_> they do exactly that iirc
<ogra_> (sorry, had to go into a meeting right after i returned)
<alf_> ogra_: I have, that's where I got the idea :) We have we have a client platform and a server platform in different packages, which naively leads to two alternatives. I wonder if there is a way to control both of them at the same time without conflict?
<ogra_> hmm, on a lib level that smells hairy
<ogra_> (unless your lib names differ indeed ... which i assume they dont)
<alf_> ogra_: what I have now is libmirclientplatform-mesa (usr/lib/*/mir/clientplatform/mesa/libmirclientplatform.so) and similarly for libmirclientplatform-android, libmirplatformgraphics-mesa/android
<ogra_> and you have setups where both are installed ?
<alf_> ogra_: the server and client platform alternatives can be controlled independently this way
<alf_> ogra_: both = both android and mesa?
<ogra_> yes
<alf_> ogra_: that's the goal if I understand correctly. If it's not then guess we could go for having *-mesa and *-android packages that replace/conflict each other (so no alternatives)
<ogra_> right, thats why i saked
<ogra_> *asked
<ogra_> well, i dont see any way apart from shipping one ld.so.conf with each package if the binaries are in separate packages ...
<ogra_> and have each of them set its alternative
<alf_> ogra_: rsalveti: that was my plan, if that sounds ok to you too
<alf_> ogra_: rsalveti: I will go ahead
<ogra_> yeah
<ogra_> DOIT !
<ogra_> :)
<rsalveti> +1
<RAOF> mlankhorst: I think I do have a rebase. Let me check.
 * mterry doesn't understand mg::Buffers
<RAOF> mterry: What about them?
<mterry> RAOF, I don't have time to debug this properly now, but tomorrow I might pick some brains in here.  I was trying to inspect them in USC to determine if the greeter had posted a frame yet
<mterry> RAOF, but to inspect actual data I had to go to the native buffer?  And that didn't seem to get me sensible results
<RAOF> You'll probably find it easier printf debugging (using the buffer ID that's exported in mir_client_library_debug.h) and matching up that way.
<RAOF> That's what I've done in the past.
#ubuntu-mir 2014-02-13
<RAOF> mlankhorst: Oh, I think I know why Mir clients are failing on new mesa; I ran into it before.
<mlankhorst> RAOF: go on
<mlankhorst> is this thep oint where the killer makes another move and you die before you can tell what the important information is? ;-)
<alan_g> alf: I'm looking at some of the valgrind errors we see in my SwitchingBundle proposal and have found some very misleading reporting. What do you make of this: http://pastebin.ubuntu.com/6924718/
<anpok> lacking support for c++11
<alan_g> Rats. valgrind can't detect std::atomic wrappers on types that don't need a lock. (Because the wrapper gets optimised away.)
<alan_g> That's a load of noise.
<alf> alan_g: :/
<anpok> there is also no _GLIBCXX_SYNCHRONISATION_WHATEVER .. in atomic
<alan_g> Yeah. tvoss suggested threadsanitizer - which isn't quite as wrong with the example
 * alan_g wanders off to talk to folks that know this stuff in detail
<alf> alan_g: anpok: I wonder if helgrind can understand hardware instructions with acquire/release semantics (e.g. probably used by atomic<> implementations)... probably not
<alan_g> alf: no. It is discussed on the valgrind lists - the opcodes are identical (for basic types anyway)
<mlankhorst> RAOF: yeah the refresh fixed things.. I'm curious though since it seems to remove a bunch of free-s. Why were those removed?
<mlankhorst> -+   free(dri2_surf->dri_buffers[__DRI_BUFFER_FRONT_LEFT]);
<mlankhorst> -+   free(dri2_surf->dri_buffers[__DRI_BUFFER_BACK_LEFT]);
<greyback> folks, I've a little C++ issue I need advice on: http://pastebin.ubuntu.com/6925097/
<greyback> I think I'm not fully understanding a reference to a pointer of an object and how to properly create one
<alan_g> greyback: C++ won't let you bind a non-const reference to a temporary
<alan_g> s/QScopedPointer<MockBuffer> buffer(new MockBuffer);/mir::graphics::Buffer* buffer{nullptr};/
<greyback> alan_g: interesting. Do I not need that MockBffer at all?
<alan_g> greyback: I doubt it: swap_buffers() is used to get a pointer to a buffer provided by the compositor and optionally return one
<alan_g> BTW swap_buffers got some drastic changes last week and that code is using the old version
<greyback> alan_g: ah really? Ok, well this is more an experiment than anything else.
<greyback> alan_g: thanks for the help, you've pointed me in the right direction
<alf> fginther: Hi! Do we need to do something to deploy the change for the pbuildjenkins scripts?
<alf> rsalveti: ogra_: How do you want to handle the package dependency of e.g. libmirclient to its platforms? libmirclient Depends: libmirclientplatform-mesa | libmirclientplatform-android ?
<ogra_> alf, right, and then se seed libmirclientplatform-android in touch and libmirclientplatform-mesa everywhere else
<fginther> alf, It's all deployed now, you should be good to go
<alf> fginther: excellent, thanks
<alf> ogra_: rsalveti: Also, do you want mesa and android to have the same priority (in terms of dpkg alternatives), or different priorites, possibly depending on platform?
<ogra_> alf, i assume they will never be installed together anyway
<ogra_> so they can have the same
<alf> ogra_: if a package with the same priority as an already existing one gets installed, does the alternative change to the new one or stick to the current one?
<ogra_> i thinkit gets changed
<alf> ogra_: hmm, let's see if I can find out for sure (to the sources!). The problem I am trying to avoid is someone using mir on the desktop, playing with packages, and installing the -android backend => broken system
<ogra_> use Conflicts/Breaks in the control file
<ogra_> then he needs to approve the removal ... (apt will ask Y/N )
<ogra_> thats at least one stop gap
<alf> ogra_: Then what is the point of having alternatives in the first place? We could just Conflict/Break from the start... I thought the (future) goal was to be able to install in parallel and have runtime selection?
<ogra_> but that would happen inside one package anyway, or not ?
<rsalveti> alf: ogra_: I'd put the android with a lower priority
<rsalveti> as our touch image is ro anyway
<ogra_> indeed
<rsalveti> then we're still good for the desktop
<ogra_> though my statement still stands, for the runtime selection we want both in one package
<alf> rsalveti: ogra_: would it make sense to have mesa < android on armhf, mesa > android otherwise?
<alf> rsalveti: ogra_: from the update-alternatives manpage: "If the group is in automatic mode, and the newly added alternatives' priority is higher than any other  installed  alternaâ tives for this group, the symlinks will be updated to point to the newly added alternatives
<ogra_> alf, right, well, do it like you described above
<rsalveti> alf: we don't want to assume anything for armhf
<rsalveti> as we now have the x86 emulator as well
<alf> rsalveti: ogra_: ok, I will make them equal, hopefully what the manpage says is accurate, so just installing the package won't mess up a system with an existing equal alternative
<rsalveti> right :-)
 * alf didn't know what he was missing by not using ccache when developing/rebuilding packages
<kgunn> mterry: didn't mean to abandon you....
<kgunn> mterry: so what you wanted to know was where in the mir code does a client know his buffer is about to be "used" for composition consumption
<kgunn> that right ?
<mterry> kgunn, yeah...  I want to know when a buffer with non-zero content is about to be used.  (i.e. not just transparent; I don't know if Mir optimizes such frames out anyway)
<mterry> kgunn, oh and this is from compositor side
<mterry> kgunn, I tried inspecting buffers but didn't know how to get actual pixel data
<kgunn> alf: or anpok ^ can you help out mterry...
<mterry> anpok and alan_g, you two were helping me yesterday with buffer stuff.  I have instrumented USC to insert itself into the surface/session creation process.  Now I have these buffers that the surface wants to swap
<mterry> But how do I inspect actual pixel data?  (I want to see if there's actual pixels to draw, it's not just all transparent -- does Mir optimize that away?)
<anpok> mir would not optimize that away
<anpok> also if you look at current system behavior you regularly see white or black buffers show up.. so we seem to display things before actual content shows up - I dont know exactly where that happens though
<mterry> anpok, hm.  But I have a mg::Buffer object.  I can't seem to do anything sensible with the native_buffer_handle, but how might I get the pixel data?
<alan_g> mterry: I don't think that's an intended use. Maybe alf can suggest a way?
<greyback> mterry: do you want to inspect the actual pixel data, or just be notified that a client has drawn its first frame?
<mterry> greyback, well you showed me you had something in the works for frame notification
<mterry> greyback, I suspect Qt is sending a dummy background before the Qml is fully loaded and drawn
<mterry> greyback, so I wanted to be able to inspect data to see if that is true and to detect the first non-empty frame
<greyback> mterry: when mir creates a Surface, it may be some time until the buffer is actually drawn to by the client. So I wanted to be notified after the client has drawn to the buffer, as then it is non-empty
<greyback> so I wasn't going to actually inspect the pixel data. I just wanted to know that the client swapped a buffer, which means it drew to it
<greyback> mterry: are you using the SurfaceManager in unity-mir by any chance?
<mterry> greyback, no, I'm currently looking to do this in USC
<greyback> mterry: ok
<mterry> greyback, so who does have access to the pixel data?  Seems hard to find in mir source  :)
<greyback> mterry: so what I think Mir needs to export is some kind of event which says "Session has a Buffer ready" to be composited/drawn on screen (i.e. one which the client has actually drawn to)
<mterry> That would help, yeah
<alan_g> mterry: the pixel data is platform dependent typically in a GL texture
<mterry> alan_g, hmmm OK
<alan_g> As far as Mir is concerned if a client has sent a buffer via swap_buffers()  there is data. So I'm not sure what else this event you're discussing would be.
<mterry> alan_g|tea, what about the idea of a client Mir session being able to indicate to the server that it is "ready" to be composited?  It seems not unreasonable that a compositor would want to keep some animation going or draw something to the screen while a client loads up
<alan_g> mterry: why doesn't it do that by posting a buffer?
<mterry> alan_g, yeah but when does it stop the buffer?
<alan_g> I don't understand
<mterry> alan_g, so here's the problem I'm working with
<mterry> alan_g, USC starts, and lightdm kicks off a greeter session and a user session around the same time.  There's a race there, but USC knows to keep the greeter on top when it does show up
<mterry> alan_g, but user session sometimes wins the race and appears for a second before the greeter
<alan_g> ack that's what we discussed yesterday
<mterry> alan_g, I'd like to be able to hide the user session when it appears (easy with Session::hide())
<alan_g> sure
<mterry> alan_g, but I need to know when to unhide it (i.e. when the greeter is "done")
<mterry> alan_g, and the greeter is posting frames before it is ready (presumably empty transparent frames)
<mterry> Qt is doing that I think for me
<mterry> alan_g, the situation would be very similar once USC gets boot animation support.  We need to know when to transition from the animation to the greeter when it is ready to be shown
<alan_g> So the answer to "why doesn't it do that by posting a buffer?" is that Qt posts buffers before it is ready?
<mterry> alan_g, well.  I mean, I could imagine a client like the unity8 shell not wanting to be "ready" before its scopes are loaded or whatever
<mterry> alan_g, "readyness" doesn't necessarily translate into frames being posted
<mterry> alan_g, but in this case, for the greeter, sure.  It's because Qt is posting before there is actual content to load
<mterry> alan_g, I think the Qt window is drawn and its waiting for the Qml stuff to load and draw etc
<mterry> at a guess, I haven't dived into it
<alan_g> I don't like the sound of inspecting buffers to guess when they have "real" content. Too much can go wrong
<mterry> alan_g, I get that.  What about some Mir signal that a client could post to its server?
<alan_g> It sounds like a weird client that posts buffers before it is ready.
<alan_g> Is this really a general problem or something restricted to greeter <-> USC?
<mterry> alan_g, I get that from a theoretical perspective.  But there are a lot of layers between a Qml file that knows "Component.onCompleted: isReady()" and Mir
<mterry> alan_g, those abstractions tend to mean that Qt/Qml throws data at Mir willy nilly
<mterry> alan_g, well, when an app launches...  We throw up a white screen right?   What if the shell wanted to show an animation while it loaded
<mterry> alan_g, it would need to know when to stop the animation.  When the app is "ready"
<anpok> for those cases the first frame is good sign of readyness
<alan_g> mterry: I've got a hangout - back in ~10min
<mterry> anpok, that's fair.  I suppose click apps are tiny enough
<anpok> i wonder whether other configuration changes will come up later
<anpok> configuration changes the shell might request from a client..
<mterry> anpok, alan_g: I'd be happy if Qt/Qml wouldn't post any frames until everything was loaded.  Is that a feasible change to make?  Ideally we could start "frozen" and unfreeze...  maybe Qt has internal support for doing that
<anpok> seems like worthwhile to look into qt for that
 * mterry isn't super familiar with Mir and Qt integration, but digs into it
<mterry> Maybe it's as easy as not doing show() until we're ready
<alan_g> mterry: I don't know much Qt but that sounds like a logical approach
<greyback> mterry: I'm not aware of any easy way to prevent Qt drawing until things are "ready"
<mterry> greyback, yeah I haven't been able to stop it yet.  Looks like QMirServerApplication even does it somewhere deep down?
<greyback> mterry: nope, it doesn't touch render loop. Render loop will spin once the QML scene is ready. But it won't render if the "window" is marked hidden. So maybe http://qt-project.org/doc/qt-5.0/qtgui/qwindow.html#hide might do it
<mterry> greyback, I tried removing all the QQuickView code from unity8, but it still is seemingly posting non-null buffers to swap_buffers
<greyback> mterry: thing is, Mir is doing the compositing. Is user session appears first, Mir shows it first. It just means Qt hasn't drawn its surface faster than the user session has
<mterry> greyback, maybe I don't understand how swap_buffers works, but it seems to be receiving valid buffers from the qml-less shell
<mterry> greyback, yeah that makes sense to me. I can have the compositor hide the user session until the greeter is ready
<greyback> mterry: as soon as a client asks Mir for a surface to render on, Mir will be aware of that surface and start compositing it - even though nothing has been drawn to that surface yet. So you see black
<mterry> greyback, I just need a way to know when the greeter is ready so I can unhide it
<mterry> greyback, or in the greeter's alpha case, transparency
<greyback> mterry: I don't know how to get Mir to create a Surface invisible by default. But maybe position it off-screen initially, or mark it fully transparent?
<mterry> greyback, well I've been using swap_buffers.  Did your approach you mentioned the other day to detect frames use a different mechanism?
<greyback> mterry: well that's step 2, no? That once the user session buffer has been drawn to you can then show it?
<mterry> greyback, there is a way to get it to allow transparency:  https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069
<greyback> mterry: indeed. I need to review that...
<mterry> greyback, I actually don't care so much about when the user session is ready.  I just want to know when the greeter is ready so I can show the user session (ready or not) behind it
<mterry> Eventually I'll probably be interested in that information too, to add a little "waiting for session" animation
<greyback> mterry: oh ok, I misread.In Qt, you can connect to this signal https://qt-project.org/doc/qt-5.1/qtquick/qquickwindow.html#frameSwapped
<greyback> mterry: else you need to get that info out of Mir somehow
<mterry> greyback, I'm saying that even without the shell creating any windows, Mir compositor is seeing swap_buffer calls with non-null buffers.  So I'm having a hard time determining when a frame is posted if that's not the right way.  You said you had something similar.  Does it rely on swap_buffers or something else in Mir?
<greyback> mterry: yep, I added something to ms::BasicSurface::swap_buffers so that I was notified when an actual buffer was swapped
<mterry> greyback, yeah I noticed you added a flag_for_render thing?
<mterry> Haven't dived into your branch yet, but looks like that's my next step
<mterry> But first, lunch
<greyback> mterry: yes that's it. That event was emitted when an actual client puffer was swapped
<greyback> worked nicely for my purposes
<mterry> greyback, that's something you added, right?  I don't see it in trunk
<greyback> mterry: yep
<mterry> greyback, oh, I see why flag_for_render isn't in trunk, it got removed...
<mterry> So I'm seeing swapped buffers from just mir::run_mir's use of DisplayServer...
 * mterry is wondering what could be posting buffers internally
 * anpok mumbles something unintelligible
<anpok> mterry: when the display is on the compositor threads will start drawing the first frame
<anpok> if you look in mir::compoistor::MultiThreadedCompositor::start I believe
<anpok> schedules a composition for each active output
<anpok> so with no surfaces you should get an initial glClear ... and swap buffers for
<mterry> anpok, huh without data from the client?
<anpok> I think this mainly about getting the display in the right state after turning it on again (or maybe the cause why we see old buffer contents - because we get the trigger before clients can send proper surface contents)
<anpok> havent played with that code yet.. so.. add a grain of guessing from my side
<mterry> anpok, huh.  OK, I'll need to find a way to tell these apart from client-driven swap_buffer calls.  Maybe only start listening for them after client is set up
<anpok> mterry: I wonder if that is proper behavior
<anpok> make waiting for the first round of new client buffers is better.. or just informing the shell and letting it decide what to do ..
<anpok> you could try without scheduling the first draw - just to be sure
<anpok> btw do you happen to know where the "Accept" decision is handled after an incoming call in unity8
<anpok> s/make waiting/maybe waiting/ o_O
<mterry> anpok, the accept notification is from telephony-service
<anpok> mterry: so they then launch the dialer app to take the call
<anpok> they==that service
<anpok> or searches for a running dialer app
<mterry> anpok, yeah
<mterry> anpok, launches it via upstart yeah, which either opens or focuses it
#ubuntu-mir 2015-02-09
<mlankhorst> greyback: so did you take a look yet why I get touch events instead of pointer events?
<greyback> mlankhorst: with mir alone, or with unity8?
<mlankhorst> unity8 only
<mlankhorst> nested mir works normally
<greyback> mlankhorst: ok, is because qtmir forwards on all input events as touch events - even if they started as mouse. Should be fixed by https://code.launchpad.net/~mir-team/qtmir/port-to-event-2.0/+merge/248067
<mlankhorst> oke
<mlankhorst> ah new version
<mlankhorst> greyback: are you sure it works? i apply it from r310 onward onto my qtmir snapshot from the 0.11 ppa and I still don't get touch events
<greyback> mlankhorst: I've tested it with Qt stuff, it appeared to work ok.
<mlankhorst> do you recompile anything else?
<greyback> nope
<mlankhorst> hm what version of mir do you use? trying from the port-to-event one I get /QtSensors    -o CMakeFiles/unityapplicationplugin.dir/mirsurfaceitem.cpp.o -c /home/mlankhorst/nfs/xorg/port-to-event-2.0/src/modules/Unity/Application/mirsurfaceitem.cpp
<mlankhorst> /home/mlankhorst/nfs/xorg/port-to-event-2.0/src/modules/Unity/Application/mirsurfaceitem.cpp: In member function Ã¢ÂÂbool qtmir::MirSurfaceItem::updateTexture()Ã¢ÂÂ:
<mlankhorst> /home/mlankhorst/nfs/xorg/port-to-event-2.0/src/modules/Unity/Application/mirsurfaceitem.cpp:396:21: error: Ã¢ÂÂclass mir::graphics::RenderableÃ¢ÂÂ has no member named Ã¢ÂÂbuffers_ready_for_compositorÃ¢ÂÂ
<mlankhorst>      if (renderable->buffers_ready_for_compositor() > 0) {
<greyback> mlankhorst: 0.11 was released, I'm working off that
<mlankhorst> hm oke
 * alan_g disappears to reboot
<mlankhorst> greyback: lp:~vanvugt/mir/fix-buffers_ready_for_compositor breaks it on 0.11
<greyback> mlankhorst: ah sorry, I thought PPA 12 had released. I'm working off mir 0.11 in that ppa
<greyback> so you need to merge all the qtmir branches listed there too, in order for anything to compile
<mlankhorst> which was sort of what I did..
<greyback> fix-buffers_ready_for_compositor does not go anywhere near the input code
<mlankhorst> except the other way around, grab your branch and stuff it on top of the qtmir there
<greyback> which should work
<greyback> mlankhorst: running your client with MIR_CLIENT_INPUT_RECEIVER_REPORT=log will at least show if you are getting mouse events or not
<greyback> http://unity.ubuntu.com/mir/component_reports.html out of date
<mlankhorst> oke
<mlankhorst> odd, don't see anything from that
<mlankhorst> do you need debug enabled or something?
<mlankhorst> greyback: can you try yourself with my xmir package? see if you get touch or mouse events..
<greyback> mlankhorst: I can. Where is your xmir package? And what x app should I run?
<mlankhorst> xev is fine
<mlankhorst> ppa:mlankhorst/ppa, I was only getting events when holding mouse buttons in my xev window
<kgunn_> alf_: since duflu is out of sync, would you mind keeping an eye out for assisting greyback in debugging ?
<kgunn_> alf_: long story short...seems there's a bug, but can't repro with demo server
<kgunn_> only happens with xmir
<alf_> kgunn_: sure
<alf_> greyback: ^^ let me know if you need something
<greyback> alf_: will do, am trying to repro currently
<greyback> mlankhorst: here's a sample of hte output I'm getting from xev: http://pastebin.ubuntu.com/10144336/
<greyback> mlankhorst: the first chunk is pure mouse motion
<greyback> the second chunk is me interacting with the touchscreen
<greyback> I'm unsure how to interpret those MotionNotify events
<greyback> what should a touch event look like to X?
<mlankhorst> greyback: do you only get events when the button's down?
<greyback> mlankhorst: no
<greyback> all motion events are being reported
<greyback> mlankhorst: there's something going weird with branches though. Trying to merge fix-buffers_ready_for_compositor into port-to-event-2.0 does nothing for me, and the build fails for that reason
<greyback> mlankhorst: try this branch, it works for me with mir 0.11: lp:~gerboland/qtmir/port-to-event-2.0-with-mir0.11
<racarr> Morning, lemme know if this xmir-event/2.0-qtmir thing I see in backscroll needs assistance :)
<mlankhorst> greyback: weird..
<racarr> confirmed that OSK bug is gone from silo
<greyback> yays
#ubuntu-mir 2015-02-10
<mlankhorst> bleh, greyback/'s branch doesn't work for me :/
<mlankhorst> greyback: I'm still getting compiling errors with your mir0.11 branch, what did you use as base?
<greyback> mlankhorst: mir 0.11 from the PPA
<greyback> silo12
<mlankhorst> I have that one too
<mlankhorst> 0.11.0+15.04.20150209.1-0ubuntu1
<greyback> what errors are you getting
<mlankhorst> did you even compile test it? I see tests failing to build :P
<mlankhorst>     surfaceItem->processTouchEvent(QEvent::TouchBegin,
<mlankhorst>         timestamp + 20, Qt::NoModifiertouchPoints, touchPoints[0].state());
<mlankhorst> should be
<mlankhorst>         timestamp + 20, Qt::NoModifier, touchPoints, touchPoints[0].state());
<greyback> I didn't enable building tests, it was just a proof of concept
<mlankhorst> oke
<greyback> give "-DNO_TESTS=true" to cmake
<mlankhorst> I probably had the wrong mir then, now it worksk (with that fix)
<mlankhorst> greyback: ah I was just doing a deb build
<mlankhorst> hm great, no session popping up at all..
<mlankhorst> seems if I use the qtmir from the ppa unity8 won't run
<greyback> lots of people have tested silo 12, and unity8 is working there
<mlankhorst> yeah silo 12 works, just not when I use your qtmir with silo 12
<greyback> let me see
<mlankhorst> black screen + infinite loop somewhere
<Mirv> I'm releasing Mir 0.11 but filed bug #1420175 as per archive admin comments
<ubot5> bug 1420175 in mir (Ubuntu) "Add conflicts/replaces for the obsolete packages" [Undecided,New] https://launchpad.net/bugs/1420175
<greyback> mlankhorst: so I pushed test fixes to the branch: lp:~gerboland/qtmir/port-to-event-2.0-with-mir0.11
<greyback> I built the package & installed it. unity8 works fine. I'm getting mouse hover events too
<mlankhorst> can you build the debs and install them?
<mlankhorst> it's the same but with -
<mlankhorst> -DQTMIR_USE_OPENGL
<greyback> mlankhorst: that's what I did. works ok here
<mlankhorst> weird
<alan_g> alf_: anpok_ no duflu? no hangout?
<mlankhorst> no matter what I try I don't get a u8 session
<mlankhorst> as soon as I use the one from the ppa again it works as intended
<anpok_> alan_g: sorry, notification did not work and I didnt notice how time passed by...
<alan_g> anpok_: got anything you want to discuss now? Or will it wait for standup?
<mlankhorst> meh I give up for now
<anpok_> hm no real topics
<mlankhorst> greyback: can I run unity8 in valgrind somehow?
<greyback> mlankhorst: sure, but I've not done it
<greyback> mlankhorst: are you getting errors anywhere? unity8.log should be very verbose
<mlankhorst> where's that one kept?
<greyback> ~/.cache/upstart
<mlankhorst> ahh
<mlankhorst> file:///usr/share/unity8/Shell.qml:21:1: plugin cannot be loaded for module "Unity.Application": Cannot load library /usr/lib/x86_64-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: (/usr/lib/x86_64-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: undefined symbol: _ZN19SurfaceConfigurator16staticMetaObjectE)
<mlankhorst> SurfaceConfigurator::staticMetaObject
<mlankhorst> needed qtmir-desktop too, why doesn't it have a proper depends on that?
<mlankhorst> yeah now it works
<mlankhorst> greyback: hmm still some silliness, autorepeat is handled wrongly..
<greyback> mlankhorst: I didn't go into such specifics. Please log bugs for the issues you find
<mlankhorst> ok
<mlankhorst> I get repeated KeyUp events instead of KeyRepeat events..
<greyback> if mir-demo-server doesn't give you that, then it's a qtmir issue
<mlankhorst> definitely a qtmir issue
<mlankhorst> only happens on your event 2.0 branch
<mlankhorst> greyback: do I have to file bugs against branches too?
<greyback> mlankhorst: would appreciate you mentioning in the bug which branch you're testing, but that's enough
<mlankhorst> oke
<mlankhorst> greyback: hm no support for mouse wheel either
<greyback> mlankhorst: was told that's not working in mir
<mlankhorst> oke
<mlankhorst> I'm getting some motion events from mir_demo_server at least when using my scrollwheel
<greyback> mlankhorst: talk to racarr, he knows more. But do log bug anyway
<mlankhorst> https://bugs.launchpad.net/qtmir/+bug/1420271 good enough?
<ubot5> Launchpad bug 1420271 in QtMir "Missing events in qtmir with the port-to-event-2.0 branch" [Undecided,New]
<racarr> mlankhorst: greyback: Mouse wheel is more related to an implementation detail of qtmir making it difficult to pass the information...e.g. too much gets lost through the translation to QEvent though I can't remember
<racarr> the exact details without looking
<greyback> racarr: ok
<racarr> it may have even just been modifiers lol I think there was something else though
<racarr> but anyway someone just needs a utility to pass through
<racarr> wrt to autorepeat events I can check that out
<racarr> :)
<alan_g> racarr: with your knowledge of the input changes this should be easy for you to check: https://code.launchpad.net/~alan-griffiths/mir/port-window-management-example-to-current-input-API/+merge/249180
<racarr> alan_g: :) Thanks. Will get to it right after I fix up this test...
<racarr> (I think I've decided on /proc/thread-self/fd/)
<racarr> Started reviewing the WM example framework yesterday too...it seemed appropriate but not done grokking all the policy members yet
<racarr> I liked the templating of the info classes...:D
<mlankhorst> alf_: at what point do you need the mesa 10.4.2-2ubuntu4 upload?
<alf_> mlankhorst: Without the fix the Mesa package won't build against mir-0.11, so it would be good to land this relatively soon.
<mlankhorst> will it still build against 0.10 with those changes?
<alf_> mlankhorst: no
<mlankhorst> can you get mesa through the landing ppa then? might be easier that way..
<mlankhorst> or at least tell me when mir hits proposed
<mlankhorst> for normal uploads
<alan_g> Well yes, the content of the Info classes is driven by the window management policy
<alf_> mlankhorst: mir 0.11 is already in the archive
<mlankhorst> oh how did it get past proposed?
<mlankhorst> hm right
<alf_> mlankhorst: it's only a build-dep for Mesa that got changed, no ABI/API breaks
<mlankhorst> yeah I guess it only checks installability, not buildability
<mlankhorst> I'll upload mesa
<alf_> mlankhorst: thanks
<mlankhorst> uploaded
<mlankhorst> alf_: https://launchpadlibrarian.net/197217165/buildlog_ubuntu-vivid-amd64.mesa_10.4.2-2ubuntu4_FAILEDTOBUILD.txt.gz
<mlankhorst> oddly enough local build succeeded, are you missing a dependency?
<DalekSec> Hrm, duflu is missing.
<DalekSec> Well, if anyone else is interested, http://sigma.unit193.net/lightdm/unity-system-compositor.log
 * racarr succumbs to the plague
<DalekSec> Hmm, yes.  That link could kill you.
<DalekSec> https://bugs.launchpad.net/mir/+bug/1212753
<ubot5> Launchpad bug 1212753 in mir (Ubuntu) "[i865] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [Medium,Fix released]
<kgunn> DalekSec: wait, you saying that bug didn't really get fixed ?
<DalekSec> kgunn: I would say that, yes.  I have the affected hardware, tested 0.11.0 that was uploaded today/yesterday, and it still crapped out with that log.
<DalekSec> Though I wasn't going to touch your bug report, had talked to duflu a little back about it.
<kgunn> DalekSec: thanks for being kind :)
<kgunn> DalekSec: can i ask what hw ?
<DalekSec> kgunn: He also said you guys couldn't obtain the hardware, so I figured I'd check and it'd be polite to report back.  Sure, what do you want to know exactly?  Some of the info is on the xubuntu mir wiki page, but 82845G/GL chip: 8086:2562.
<kgunn> DalekSec: yeah, that....was mainly curious about gpu
<kgunn> duflu will be on in a bit
<DalekSec> "Total crap" :P
<kgunn> ~1.5 hr
<DalekSec> http://paste.openstack.org/show/MNMILlfNtuhgOpJYJA3x/
<DalekSec> http://paste.openstack.org/show/ilFEYLp8qY75dkGm4Px5/ (or if you prefer lshw output)
<tmpRAOF> Hm, 845 :)
#ubuntu-mir 2015-02-11
<DalekSec> Anything else I can do?
<c74d3> What security issues in X's design does Mir fix? (And, are there any security issues in Mir's design?)
<tmpRAOF> The way that X clients can do whatever they want to each other, up to and including snoop all keyboard input.
<tmpRAOF> There aren't any security issues in Mir's design that we've identified :)
<c74d3> Thanks. In Mir, keyboard/mouse/etc. input will... only ever go to the focused window?
<duflu> c74d3: No... "focus" refers to things that don't have coordinates (key presses) everything else goes wherever you're pointing
<duflu> That said, we haven't implemented everything yet so you might see missing features
<c74d3> But a program can't know about a mouse-click unless it's the one whose window is being clicked on?
<duflu> c74d3: That or it owned the start of a gesture (clicked in window and dragged outside of). Also note we need and haven't yet implemented grabs
<duflu> Grabs allow a window to own the mouse
<c74d3> Okay, thanks.
 * tmpRAOF notes that âgrabsâ are probably the wrong term, as they're easily confused with X11's (multiple) grab concept(s).
<duflu> tmpRAOF: Perhaps
<c74d3> Oh, "grabs" as in "the program grabs the mouse", not "the mouse-pointer grabs something".
<duflu> c74d3: Yes
<c74d3> Can programs read other programs' output, e.g. for screen-captures (or, on the other side, stealing passwords etc.)?
<tmpRAOF> No
<tmpRAOF> *: in general.
 * duflu is reminded he doesn't know how screencast's security works (or should work)
<tmpRAOF> It's shell-mediated
<duflu> tmpRAOF: Oh, I hadn't seen that invite from Thomas ;)
<tmpRAOF> :(
<tmpRAOF> :)
<c74d3> "shell-mediated" -- The "shell" (which is like a window manager?) can approve or deny each screen-capture request, possibly after asking the user?
<duflu_> tmpRAOF: Did you lose internets last night too?
<tmpRAOF> duflu_: I don't think so?
<tmpRAOF> c74d3: Correct. The âshellâ could also be called the desktop-environment. Mir doesn't have the same display server/window manager split that X has.
<duflu_> This is a good thing. I found myself looking at Weston code last week for the first time and there are some horrible implications for what Wayland expects each compositor to re-implement
<c74d3> "desktop-environment", like KDE? With a file-management GUI, a system-settings GUI, etc.?
<duflu_> c74d3: Yes
<duflu_> That said, Mir should not discount Wayland. We've got a lot of selling/improving to do to support other shells
<c74d3> Mir requires a desktop environment?
<c74d3> Does a Mir shell need to include file-management etc. GUIs, or could it merely be equivalent to a X window manager?
<DalekSec> duflu_: Oh heya.
<tmpRAOF> c74d3: Mir is a library you use to build desktop environments, mostly.
<duflu> DalekSec: Hello...
<DalekSec> http://sigma.unit193.net/lightdm/unity-system-compositor.log was the log for 0.11.0 on the hardware affected (still) by bug 1212753.
<ubot5> bug 1212753 in mir (Ubuntu) "[i865] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [Medium,Fix released] https://launchpad.net/bugs/1212753
<tmpRAOF> c74d3: In roughly the same way that Wayland is an RPC mechanism + default protocol specification for a display-server-desktop-environment thingy.
<c74d3> tmpRAOF: hm, thanks.
<duflu> DalekSec: Thanks. I thought I was being a bit optimistic on that one. What chipset/GPU?
<DalekSec> http://paste.openstack.org/show/ilFEYLp8qY75dkGm4Px5/
<duflu> DalekSec: Hmm i845 is even older than that of the first reporter... :)
<duflu> DalekSec: In that case, can you please open a new bug?  https://bugs.launchpad.net/mir/+filebug
<DalekSec> Generally looks like the same error...
<duflu> DalekSec: Yes, but things get messy if we declare them fixed and reopen. I would reopen if someone with i865 also says "not fixed"
<duflu> Bugs are free. Please log them :)
<DalekSec> Bah...
<DalekSec> duflu: Just to be clear, this is xmir on Xubuntu/Xfce, not "native" mir.
<duflu> DalekSec: It's still Mir under XMir. The "native" part isn't really important there...
<DalekSec> Mhmm, just figured I'd note. :)
<duflu> DalekSec: Obviously in the long term we all want to use shells that are closer to the hardware... that's faster and less resource hungry
<DalekSec> Anything besides chip, release, mirver, and error log?
<tmpRAOF> unity-system-compositor is absolutely ânative Mirâ; we're writing a library that should support such things, not just Unity8's QML :)
<duflu> DalekSec: Nope, that's enough thanks
<DalekSec> lp 1420574
<ubot5> Launchpad bug 1420574 in Mir "[i845] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [Undecided,New] https://launchpad.net/bugs/1420574
<duflu> DalekSec: Ta muchly
<DalekSec> duflu: Sure.  I'll stick around too in case you need anything else. :)
<DalekSec> Cheers from the Xubuntu team!
<duflu> DalekSec: Oh, one important question: Can you run OpenGL (mesa) demos on this system using native X/Xfce? If so, what are the GL renderer strings reported?
<duflu> (glxinfo | grep OpenGL)
<DalekSec> I'm back into the installed system, 14.10, but yes it works: OpenGL renderer string: Mesa DRI Intel(R) 845G x86/MMX/SSE2
<duflu> DalekSec: Can you please run "glxinfo | grep OpenGL" and paste the output in the bug? The key thing is to prove that Mesa supports your system (and therefore Mir should too)
<DalekSec> Done.
<DalekSec> ...Just as long as I don't have to show FPS. >_>
<tmpRAOF> :P
<DalekSec> Anywho, I believe that's enough of that for now.  See you another day.
<duflu> DalekSec: Thanks. We're eager to make Mir work everywhere
<DalekSec> Bit surprised honestly, based on how dated this is.
<duflu> DalekSec: Well, it's not a Canonical priority but something I'd like to achieve on a weekend at least
<DalekSec> From 14.10, I take it "es2_info: es2_info.c:158: make_x_window: Assertion `num_configs > 0' failed." is a Very Bad Thingâ¢?
<duflu> DalekSec: Yeah that's a good explanation
<duflu> DalekSec: I think I could write a renderer that will work for you and Mir in OpenGL 1.x but Unity8 will never support it.
<DalekSec> I'm asking before posting as I'm not on 15.04, though don't believe that'd make a difference.
<DalekSec> duflu: Not to be rude, but I never plan to use unity8. :)
<duflu> DalekSec: Fair statement. You're not alone and we hope there are other shells
<DalekSec> Others might, but I can't see anyone on this old a card 1. Trying to use unity.  2. Keeping it for much longer.
<DalekSec> Anywho, I'll post.
<duflu> DalekSec: I like the challenge. The key point is whether introducing Mir alienates any/many existing Ubuntu users. Presently that's "yes"
<DalekSec> duflu: Hah!  Awesome. :)
<DalekSec> duflu: Oh, and xfwm4's compositor is off in all the 14.10 output. :3
<duflu> DalekSec: OK, I don't think that matters. First we need Mir to start, then XMir (or Unity8 or whatever) ...
<DalekSec> Yeah, glxinfo isn't different, just might be good to mention.
<tmpRAOF> duflu: unity-system-compositor as it currently stands doesn't really need GL at all; (at this point) we could entirely drop that requirement.
<duflu> tmpRAOF: Yeah fair point and I've been hoping to do so
<duflu> Just that a native DRM compositor right now would only support fullscreen
<tmpRAOF> Which is fine, because system compositor.
<tmpRAOF> In the current state of affairs we don't actually *composite* at any point.
<tmpRAOF> We just multiplex.
<duflu> tmpRAOF: I like to have such separations in code because it's a nice design sanity test for anyone making changes in future
<duflu> tmpRAOF: Well, proving server does composite (antialiasing and blending)
<duflu> "compose"?
<tmpRAOF> Yeah, absolutely. But DalekSec doesn't need proving server to run; they need unity-system-compositor to run :)
<duflu> I think the verb is "composite"
<duflu> tmpRAOF: Absolutely
<duflu> Although both look feasible
<duflu> Also, Gerry said he had done the change himself a while back. Not that many changes required to switch to full OpenGL
<duflu> The hard part is how to maintain it
<tmpRAOF> Oh, I thought you were thinking of switching to non-GL rather than just switching out GLES in favour of GL.
<duflu> tmpRAOF: Both eventually
<duflu> Support all the things
<tmpRAOF> Yay! Benchmarking different locking approaches in add-multiplexing-dispatchable leads to me discovering a bug!
<tmpRAOF> Also, cache invalidation :(
 * Mirv gets highlighted on "mirver"
<DalekSec> Hah, nice.
<duflu> Mirv: Sorry, shouldn't happen often
<duflu> Good morning BTW
<mlankhorst> alf_: ping..
<mlankhorst> ah nm I'll just remove the client_lib.h
<alf_> mlankhorst: pong
<mlankhorst> alf_: http://paste.debian.net/145453/ -- next time test you actually don't need libmirclient-dev please. :P
<alf_> mlankhorst: ah, right, sorry for that
<anpok> alf_: so far I only looked at one of the intermittently failing test cases.. but there the scenario is somehow related to lp:1401488
<anpok> the main thread gets terminated in g_main_context_iteration when before one or two source handles from previous runs got cleaned up inside the event reading thread during its first iteration
<anpok> i will try a different approach there..
<duflu> alf_: Found a fun regression: Clients consume double framerate if within 50-100 pixels of the shared screen edge (not even touching it)
<duflu> Now bisecting
<alf_> duflu: interesting
<duflu> Hmm, that could be the shadow extents. I think someone added that
<alf_> anpok: ENOCONTEXT
<anpok> :)
<anpok> alf_: i am creating a second glib main loop instance and this messes things up
<anpok> alf_: the signal handlers get unistalled due to the signal source cleanup happening in a later test run
<alan_g> anpok: alf_ - any thoughts on port-window-management-example-to-current-input-API or WindowManager-is-an-EventFilter? (If not I'll TA)
<anpok> alan_g: just looking at that ..
<alf_> alan_g: Haven't had time to look into them yet, but if you got sufficient feedback, feel free to TA.
<duflu> close(mayhem);
<mlankhorst> why does _mir_display_is_valid in the mesa patch use dlopen(NULL); to get a handle for dlsym, instead of dlsym(RTLD_DEFAULT) ?
<tsdgeos> AlbertA2: do you have a ppa/silo with the qtubuntu/port-to-mirclient and dependent branches?
<tsdgeos> i tried compiling them on my own and now i don't get unity8
<tsdgeos> probably a bit too early for him
<kgunn> tsdgeos: yeah, in a couple of hours.... i assume you mean this branch
<kgunn> https://code.launchpad.net/~mir-team/qtubuntu/use-mir-surface-types
<kgunn> yeah, not even up for review
<mlankhorst> greyback: hmm.. are applications expected to only create a single mir_surface?
<greyback> mlankhorst: qtmir doesn't support multiple surface apps yet
<greyback> I'm working on it
<mlankhorst> ahh
<mlankhorst> that explains it.. Xmir with -windowed shouldn't have a window created right away
<mlankhorst> huh?
<mlankhorst> why do I get mir_pointer_input_event_action_enter on mouse up, and mir_pointer_input_event_action_leave on mouse down?
<mlankhorst> oh I misunderstood..
<mlankhorst> it's hover_enter/leave :/
<mlankhorst> how is that a good name?
<tsdgeos> kgunn: AlbertA2: no i meant https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164
<AlbertA2> tsdgeos: kgunn: ok I'll address your feedback. I'll get started on a silo with papi/qtubuntu
<tsdgeos> AlbertA2: actually i got it running now, i messed up before so there's no immediate need for me to try it
<alan_g> arg8pah
<mterry> Heyo!  Does anyone here know anything about xmir crashing when chromium is launched in vivid?
<mlankhorst> still happens?
<mlankhorst> is that on desktop or arm?
<mlankhorst> mterry: You probably need to install more of the ubuntu-desktop to get it to work, not sure what exactly :/
<mterry> mlankhorst, desktop
<mlankhorst> mterry: it was working for me, do you have ubuntu-desktop installed?
<mterry> mlankhorst, filed bug 1420959, not sure how helpful
<ubot5> bug 1420959 in xorg-server (Ubuntu) "xmir crashes when launching chromium" [Undecided,New] https://launchpad.net/bugs/1420959
<mterry> mlankhorst, yes
<mlankhorst> oh.. that version
<mlankhorst> ln -svf Xmir /usr/bin/Xorg
<mterry> !
<mlankhorst> but there's no correct input support so you might need to use old xorg for now
<mterry> mlankhorst, I don't have /usr/bin/Xmir
<mterry> mlankhorst, I thought xmir didn't need manual intervention like that?
<mlankhorst> oh wait I thought you were using my ppa
<mlankhorst> there's 2 xmir's, one takes over Xorg, other one is standalone
<mlankhorst> brb
<mterry> mlankhorst, no not using your ppa, just vivid packages
<mterry> mlankhorst, I thought we had this more or less working (we have preview images and such, eh?).  So I figured it was just an everyday bug rather than a misconfigured xmir
<mterry> mlankhorst, but I'd love to have a workaround if you have suspicions on why the crash happens
<mlankhorst> mterry: unity mode is just a workaround :P
<mterry> mlankhorst, you mean unity7 in xmir is just a workaround?
<mlankhorst> I don't think it was ever particularly useful, just as stopgap until mir gets better
<mterry> mlankhorst, sure...  but I'd like it as a way to run unity-system-compositor while I test a mir-based lightdm greeter
<mlankhorst> ah :P
<mterry> mlankhorst, while also running my desktop
<mterry> mlankhorst, so for my use case, it'd be lovely
<mlankhorst> if you can enable hw cursors in unity-system-compositor..
<mterry> mlankhorst, I just don't like not being able to run chromium...
<mterry> mlankhorst, I have a cursor I can see
<mlankhorst> you could use Xmir-sa from my ppa
<mlankhorst> but it relies on mir to render a cursor
<mlankhorst> and it's limited by everything mir supports :P
<mterry> mlankhorst, what's the distinction for that package?
<mlankhorst> standalone
<mlankhorst> it's still part of xserver-xorg-xmir though
<mterry> mlankhorst, I guess I don't understand what standalone means in this context
<mlankhorst> it's not a module to Xorg, but a full Xserver
<mterry> mlankhorst, oh huh
<mterry> mlankhorst, is that the future, or an experiment?
<mlankhorst> latter, hopefully turning into the former when mir gains more features..
<mlankhorst> right now Xorg+mir works because it doesn't rely on anything from mir except as a means to swap the front buffer
<mterry> mlankhorst, well.  Do you think it might work well enough for my usecase?
<mlankhorst> perhaps
<mlankhorst> I don't draw sw cursors in Xmir-standalone right now
<mterry> mlankhorst, so I've installed dbg packages to try to get a better stacktrace for that bug / see what's happening.  But even with those installed, the backtrace in the logfile is bare-bones.  But it doesn't leave anything in /var/crash either.  How do I get a core dump from X?
<mterry> mlankhorst, hrm yeah.  I tried running a pure Mir session (unity8) and got no cursor
<mterry> mlankhorst, presumably if I had a touch screen, it would do something?
<mterry> Or maybe input is just busted in Mir right now on the desktop
<mterry> mlankhorst, OK, I've decided to just live with no chromium.  But I do want to test this hardware cursor.  In xmir,  I now see two cursors.  Do you know how to disable the sw one?
#ubuntu-mir 2015-02-12
<rsalveti> anyone from the mir team around still?
<rsalveti> kgunn: ^
<rsalveti> quite a lot of packaging changes landed with the new mir
<rsalveti> breaking the vivid touch build as we're depending on a package that got renamed
<rsalveti> just trying to understand the changes
<racarr> rsalveti: Hi
<racarr> rsalveti: I think im the only one around so ill give a best effort
<racarr> rsalveti: Wait RAOF is around and he made the changes
<racarr> RAOF: ^
<racarr> err
<rsalveti> he's not around
<rsalveti> it seems the backend can be dynamically loaded now
<racarr> rsalveti: He is hes just not in this channel I pinged him on mir
<rsalveti> https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982
<tmpRAOF> rsalveti: Sure.
<racarr> rsalveti: Yes but thats basically what is it so
<rsalveti> tmpRAOF: hey :-)
<racarr> yes so the soname version isnt required anymore
<tmpRAOF> racarr: You need to highlight tmpRAOF now, as freenode ate my RAOF registration :)
<racarr> and the libraries got renamed
<rsalveti> tmpRAOF: our vivid build is broken because it is still depending on the older packages
<racarr> is the summary of my understanding
<racarr> tmpRAOF: :)
<rsalveti> -		add_package install ubuntu-minimal mir-client-platform-android libmirplatform5driver-android ubuntu-touch
<rsalveti> +		add_package install ubuntu-minimal mir-client-platform-android mir-platform-graphics-android ubuntu-touch
<rsalveti> I changed this
<rsalveti> but we also had the update-alternatives for it
<rsalveti> and it seems it's not required anymore
<tmpRAOF> Correct.
<rsalveti> tmpRAOF: how is mir finding out the backend to load now?
<tmpRAOF> By loading them all and finding the one that works.
<tmpRAOF> The only reason not to have mir-graphics-drivers
<tmpRAOF> The only reason not to have mir-graphics-drivers-mesa on the touch images is you'll waste some disc space.
<rsalveti> tmpRAOF: right, that's something I'll check on the next build, in case we get that package installed for whatever reason
<rsalveti> tmpRAOF: but in case both are installed at the same time, how to select which one to use?
<rsalveti> not sure if mesa will indeed fail on touch
<tmpRAOF> It will.
<rsalveti> great, will remove the update-alternatives and trigger a new build then
<tmpRAOF> Unless it can *actually* work, in which case it's fine to use :)
<racarr> lol
<racarr> in which it turns out mesa worked on nexus devices this whole time
<rsalveti> :-)
<racarr> ;)
<rsalveti> well, it might work with software rendering
<rsalveti> not sure how is the current support though
<tmpRAOF> No, our mesa platform doesn't support software rendering.
<tmpRAOF> Also, you'd need a kms driver.
<racarr> Mm I think we are covered...because of the modesetting bit
<racarr> and then even if one did appear the platforms get "priorities"
<tmpRAOF> (And once we *do* support software rendering, the mesa platform will only load with software rendering if there's nothing better; android will be better in that case)
<racarr> and if an android driver is available (dont remember exactly how it works, but something like...can we load libhardware and open gralloc or whatever)
<rsalveti> right, awesome then
<racarr> then it gets priority "Best"
<tmpRAOF> rsalveti: So, the only package you should need is mir-graphics-drivers-android (conversely, mir-graphics-drivers-mesa for desktop).
<rsalveti> right, that's already in our seeds
<tmpRAOF> racarr: That's correct - android probes by trying to open gralloc.
<racarr> interestingly (not to this conversation, just to people interested generically in EGL implementations) mesa provides a DRI based implementation of gralloc
<racarr> for running android on intel free drivers
<racarr> kdub and I discovered it before hybris appeared as a driver solution and it took an hour or so of like...does this do what we need? Wait no this is
<racarr> the exact opposite...
<tmpRAOF> rsalveti: So, you should be able to drop mir-client-platform-android and keep just mir-graphics-drivers-android. We guarantee not to rename that one, and it'll always depend on a full set of packages required to get a fully functional Mir drivers on android.
<racarr> it took me an hour or so maybe kdub understood because he knew gralloc lol
<rsalveti> tmpRAOF: yeah, that's the change I did
<rsalveti> will trigger a new image in a few and let you konw
<tmpRAOF> Sweet.
<Trevinho> Mhmmh... I've just updated the gdk-GL mir backend to match upstream changes... and well, with then now after few seconds I run the test-gl I'm getting a kernel panic on MIR! :o
<Trevinho> gdk changes are basically:
<Trevinho> https://bugzilla.gnome.org/show_bug.cgi?id=741946 plus the relative changes to the mir backend...
<ubot5> Gnome bug 741946 in Widget: GtkGLArea "OpenGL context should allow for GL attribute selection" [Normal,Resolved: fixed]
<Trevinho> basically things have been moved to gl 3.2 APIs by default... But Not sure how I can help to fix this... I'd say it's mostly a driver issue....
<duflu_> Trevinho: What requires GL 3.2?
<Trevinho> duflu_: gdkgl
<duflu> That's unfortunate. We still have Ubuntu users limited to GL 1.x which I aim to support with Mir. It would be a pity if they just can't run GTK
<Trevinho> duflu: they can run gtk, but not gtk-gl apps
<duflu> Ah OK
<Trevinho> duflu: they supported legacy gl till few days ago, then they removed that as it was overcomplicating stuff for them
<duflu> Trevinho: P.S. Sleep
<Trevinho> duflu: so basically now in gtk you can create a gl context inside your app and make it interact with the rest
<duflu> Trevinho: I know. I've written toolkits with GLAreas :)
<Trevinho> duflu: I was about to go, then I got a friendly ping :)
<Trevinho> duflu: yeah, stuff like that... arrived just a little late...
<Trevinho> I mean, instead of putting such the efforts in clutter, maybe....
<tmpRAOF> Trevinho: Yeah, kernel panics are very much Not Our Faultâ¢
<Trevinho> yes, I was wondering that...
<Trevinho> I've not them in X, but I guess it's due to the fact it's using a different driver
<tmpRAOF> It's not really using a different driver. Unless you're using the nvidia binary drivers for X and nouveau for Mir (or fglrx/radeon)
<Trevinho> mh, no I'm using radeon currently... But I thought it was using an egl driver at mesa level, isn't it?
<tmpRAOF> Yeah; GTK doesn't use EGL on X as well?
<Trevinho> glx
<tmpRAOF> There certainly are differences in the uses, though. If you could capture the panic it might point to something we obviously do differently and possibly wrong.
<tmpRAOF> Huh. Fair enough.
<Trevinho> well, I currently I've no clue how to debug that kind of panic... ð¢
<Trevinho> probably I need to ping someone with hands at lower levels than me :)
 * Trevinho also can't build current mir without http://pastebin.ubuntu.com/10182012/
<tmpRAOF> Yeah, we've got some weirdness with our headers at the moment.
<Trevinho> maybe it works with pre-compiled headers, but I guess I've disabled them
<rsalveti> Get:335 http://ftpmaster.internal/ubuntu/ vivid/main mir-platform-graphics-mesa i386 0.11.0+15.04.20150209.1-0ubuntu1 [91.6 kB]
<rsalveti> Get:336 http://ftpmaster.internal/ubuntu/ vivid/main mir-platform-graphics-android i386 0.11.0+15.04.20150209.1-0ubuntu1 [82.4 kB]
<rsalveti> tmpRAOF: both were installed, will check the image in a few
<rsalveti> not sure why we're still getting the mesa package
<rsalveti> libmirserver29 depends on it
<rsalveti> as it's |, it seems it will always get the first
<rsalveti> even when my seeds is forcing the android one
<tmpRAOF> rsalveti: Garh, sorry.
<tmpRAOF> rsalveti: I fixed that for the client platform earlier, but at that point the server loading bit hadn't landed.
<rsalveti> right
<tmpRAOF> rsalveti: For what it's worth: https://code.launchpad.net/~mir-team/mir/server-doesnt-depend-on-drivers/+merge/249449
<rsalveti> tmpRAOF: great, thanks
<duflu> Trevinho: I just tried out building Mir on trusty. There are lots of hacks required. More than you suggest. How/where are you building mir?
<Saviq> hey guys, could someone please have a look at bug #1417773 and see if the attached traces suggest a Mir thread blocked somewhere?
<ubot5> bug 1417773 in unity8 (Ubuntu RTM) "Unity8 completely frozen (unable to unlock, receive calls, etc)" [Undecided,New] https://launchpad.net/bugs/1417773
 * duflu looks at the bug
<duflu> Saviq: Fun. Looks like some kind of deadlock in Mir's GlibMainLoop with Mir's framedropping logic
<Saviq> duflu, that sounds fun indeed
 * duflu shies away from owning problems he violently tried to stop from us having
<duflu> Also it's time to make dinner
<duflu> from us? us from.
<duflu> Saviq: I know we did try to decide both ends of that deadlock so that deadlocks can't happen. But sounds like we're not there yet
<duflu> Saviq: RTM running Mir 0.10? That sounds odd given https://launchpad.net/ubuntu-rtm/+source/mir
<duflu> Oh, also a stack from 0.11
<Saviq> duflu, my gdb output was from vivid indeed
<duflu> Saviq: Was the actual deadlock on vivid?
<Saviq> duflu, yes, my gdb output was from vivid 0.10 and 0.11 today
<tmpRAOF> I don't think that analysis is correct?
<tmpRAOF> It looks more like RPC failure?
<Saviq> duflu, might be I misattributed the lock incorrectly
<duflu> Saviq: OK, that needs clarification. Deadlocked on Mir 0.8 but retraced using Mir 0.10/11 symbols?
<tmpRAOF> (Note one of the threads has blocked in recvmsg)
<Saviq> duflu, no no
<Saviq> duflu, the original bug was from rtm
<Saviq> duflu, and rsalveti's trace should be from there
<Saviq> duflu, my deadlocks were both on vivid, and retraced then and there, while the device was deadlocked
<duflu> Saviq: rsalveti's looks quite different (dbus deadlock instead)
<duflu> Do we have two bugs in one?
<Saviq> duflu, very much possible
<Saviq> duflu, there was a bunch of random lockups reported
<duflu> Saviq: That's a huge can of worms. Time to make dinner
<Saviq> duflu, enjoy
<tmpRAOF> Saviq: Did you break and then continue in this backtrace?
<Saviq> tmpRAOF, I just attached gdb and got the trace there, didn't continue
<tmpRAOF> Saviq: So, the fact that it was blocked in recvmsg suggests that something in the RPC stack was being bogus, and the deadlock was U8 waiting for some RPC to finish.
<Saviq> tmpRAOF, if you have any pointers as to what else should I check (continue + break) the next time I see that, please comment on the bug
<tmpRAOF> Saviq: It might be helpful to work out what unity-system-compositor is doing when this happens.
<greyback_> AlbertA: hey, I've got QtCreator working reasonably well using this patch on top of your use-mir-surface-types: http://pastebin.ubuntu.com/10190374/
<greyback_> thought I should share the changes I've made, in case it helps
<AlbertA> greyback_: cool...I've changed the branch a bit too....
<AlbertA> :)
<greyback_> AlbertA: ack, will pull and see
<greyback_> AlbertA: moveResize deletes & re-creates the mir surface?! Cheeky ;)
<AlbertA> greyback_: works for menus lol
<racarr> in which we become what we once hated :(
<racarr> :p
<greyback_> :)
<AlbertA> racarr: that's why we are going to support client resize :) it's good for the mir team to feel the pain :)
<mlankhorst> yeah no other way :P
<mlankhorst> soon you'll find you want to support client hit testing for cursors too
<mlankhorst> and  then realize you want to give sub windows a cursor to make it feel more responsive
<adrian47> Hello is there anyone who can help with:  tiny.cc/i8lytx  (porting ubuntu touch)
#ubuntu-mir 2015-02-13
<duflu> mlankhorst: Can (or have you already?) document how to try the new rootless XMir?
<duflu> I forget everything I learned from the old xmir
<duflu> It was so long ago
<mlankhorst> that's fine, it's just a mir application :P
<mlankhorst> just add -windowed to it
<mlankhorst> but it doesn't work well yet
<mlankhorst> or was it -rootless
<duflu> mlankhorst: Weird. Why do I not see libxmir.so linking to GL-anything?
<duflu> It looks like the old version
<mlankhorst> duflu: /usr/bin/Xmir..
<duflu> mlankhorst: Not packaged yet then? :)
<mlankhorst> ppa:mlankhorst/ppa
<duflu> Ah
<mlankhorst> still crazy experimental at this point :P
<duflu> Kay
<mlankhorst> especially windowed mode, until I can control positioning there's not much point to windowed mode since menu's won't work right
<duflu> Hmm, I crashed USC. I should log/debug that
<mlankhorst> Xmir supports DRI2 (OpenGL) if mesa drivers are found, else it falls back to native EGL
<duflu> mlankhorst: Have you looked at Alberto's new API for that?
<mlankhorst> not yet
<duflu> mlankhorst: BTW I saw Trevinho running the rootless version. It had Composite loaded too. Should probably disable that
<duflu> Composite+compiz
<mlankhorst> oh that's not rootless
<mlankhorst> Xmir can run in a window too, and you can load compiz inside it
<duflu> OK
<mlankhorst> rootless mode gives each window its own mir window, but that doesn't work right yet
<duflu> mlankhorst: OK, looking forward to future Xmir
<duflu> mlankhorst: I just realised your menus problem isn't yet solveable (unless you have a mini-compositor in your XMir to avoid creating child surfaces :) ... https://bugs.launchpad.net/mir/+bug/1421572
<ubot5> Launchpad bug 1421572 in Mir "[enhancement] Missing a generic API for child surface placement" [High,Triaged]
<mlankhorst> duflu: yeah thought so, so I didn't bother yet
<alan_g> alf_: I've not tracked through the dependencies yet but was just looking at what happens when a shell wants to reconfigure the display. For reasons that are probably inadequate it first stops the compositor, then applies its changes and then restarts the compositor. But the compositor indirectly depends on the shell (i.e. there's a mutual dependency). Shouldn't the compositor simply be listening to display config changes an
<alan_g> d handle them for itself?
<alf_> alan_g: The idea was to serialize such reconfigurations in the main loop. Note that we need to stop the compositor because otherwise one of its threads may end up accessing display HW resources that we have reconfigured and cause problems/crashes.
<alan_g> alf_: Hmm. That's not what's happening of course. And the way it is - Display::configure(*conf) could notify listeners "change is happening"..."change is done"
<alan_g> And the compositor can stop & start accordingly
<alan_g> me::WindowManager (for example) doesn't use the main loop for config changes
 * alan_g doubts me::WindowManager is a good example of anything though
<alf_> alan_g: Ideally we would use the MediatingDisplayChanger (through a new interface suitable for the shell's needs)
<alan_g> I was just wondering about that (need to check the dependency graph though as depending on MediatingDisplayChanger which depends on Compositor doesn't avoid the loop I started with.
<alan_g> )
<alf_> alan_g: Yes, there are two orthogonal aspects here: the dependency loop which you want to break, and ensuring we go through the main loop
<alan_g> alf_: OK I've got enough to think about. Thanks. (I feel the design process starting)
<tsdgeos> racarr: did you see my last comment on https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 ?
<berz3rk> Hello
<berz3rk> can I use Virtualbox with the unity next iso?
<berz3rk> if not, can I use my gtx 860m notebook directly from boot (nouveau supports it)
<anpok> berz3rk: not yet.. but vmware and kvm work
<berz3rk> ok good
<berz3rk> i try vmware
<anpok> vbox has an out of source driver .. it needs a few bits
<berz3rk> alan_g: when I boot vmware, I dont get any graphical user interface
<berz3rk> anpok...
<berz3rk> failed to create login service or something like that in systemd, but now i just see a white mouse cursor ..
<greyback> berz3rk: these are the instructions I used once to test unity8 in VMWare: http://pastebin.ubuntu.com/10205619/
<kgunn> i confirm those instructions worked for me too...(however i'm on intel gfx)
<greyback> me too
<alf_> kgunn: I should add these instruction to our official documentation
<kgunn> alf_: yes, please...seems like a good idea
#ubuntu-mir 2016-02-15
<bregma> hey RAOF do you have magic core dev powers?  I'm trying to squeeze my libertine-scope package through the NEW queue for Xenial and it's been sitting there ignored for a week and could use a little push....
<RAOF> bregma: NEW processing isn't a core-dev power.
<RAOF> bregma: You're thinking of Archive Admin, which I'm not.
<duflu> Oh and an Xmir patch please :)
<bregma> it's all a black box to me
<duflu> Actually might need robert_ancell's help
<bregma> duflu, Xmir appears to have stopped working on Xenial, is that what you're talking about?
<duflu> bregma: No, but let me check that...
<RAOF> I can totally upload an XMir patch...
<duflu> bregma: It must just be your machine. Xmir has not changed since 27 November: https://launchpad.net/ubuntu/+source/xorg-server
<bregma> Xenial?
<duflu> Yep
<bregma> well, entirely possible it's my machine
<duflu> The last distro change was 27 Nov anyway
<duflu> Although I have been compiling and running the latest Xmir on the latest xenial and it works
<bregma> ...and Olli's machine, but in a totally different way...  there's a zillion places something could go wrong in the chain of events
<bregma> I know a new x.org went in in Xenial a while back, I'm just paranoid about changes not getting synched somewhere
<duflu> bregma: On that note, it's probably bad form to do a xorg update this late. I was only requesting it for kgunn's titlebar enhancement
<duflu> But in terms of risk, maybe not a great idea
<RAOF> We're still pre-feature freeze.
<RAOF> It's a perfectly sensible time to get new features in :)
<duflu> I know, but there's a huge maturity win in "It's unmodified since November" vs "it's unmodified for a couple of days"
<duflu> Confidence is a good thing to keep
<duflu> That said, this is xenial. And on desktop Xmir still defaults to less stable dri2 renderer
<duflu> Less correct, not less stable
<duflu> Speaking of maturity, despite our Unity8 issues Weston logins are more broken than Unity8 :)
<RAOF> Eh. Weston isn't really pretending to be a DE :)
<duflu> RAOF: No, but a VT with just a flashing cursor is worse than expected
<RAOF> Probably. No-one really cares for it in Ubuntu :)
<duflu> RAOF: True, but if you're going to the trouble of providing it as a login option in Ubuntu, it should do /something/ :)
<RAOF> It's actually more trouble to *not* provide it as a login option.
<RAOF> (Probably?)
<duflu> Possibly. Although my xenial system makes me suspicious that continuous daily updates have broken some things (like Unity8 is missing most apps, and those I do have exit immediately)
<duflu> I'm assuming a fresh install would be less broken
<zzarr> hello! this is a question that might not have an answer yet, but I find it interesting: how will Mir handle external GPU's? (in external cabinets like ASUS ROG XG2 and Razer Core)
<alan_g> zzarr: it isn't interesting (yet). Assuming there are userspace drivers I'd expect Mir to use them.
<zzarr> alan_g, okey, I thought more about, what if I use a GPU heavy application an it's running on an external GPU and I unplug the Thunderbolt 3 cable, will the application die or can it "jump" to the internal GPU? (or maybe it's suspended and resumes when I plugin the cable again)
<zzarr> I know it's a longways away, but I find it interesting
<anpok> just donate one of those to a team member :)
<anpok> at the moment we cannot because the kms platform figures that out during startup
<zzarr> hehe, okey
<zzarr> well there's another thing holding it back.... there are no cabinets for sale yet
<zzarr> so, I guess I should have asked, how would you like the application that just lost the GPU to behave?
<anpok> but later it might listen to udev.. from there on we have to deal with having several dri devies nodes for rendering/buffer allocation, and separate ones for outputs..
<zzarr> I would like it to resume on the internal GPU
<zzarr> okey
<zzarr> I'm still trying to port Ubuntu Touch/Mir to my chromebook (as long as I have a viable plan I'll proceed till success or failure)
<alan_g> In this hypothetical world of yours either the driver(s) migrates context across GPUs (implausible) or the application needs to rebuild it. Either way I don't think Mir has a big role.
<zzarr> okey, alan_g so the question was basically not related to Mir
<alan_g> Well, if you can come up with patches for Mir that would help we'll be happy to review them.
<zzarr> I just wonder, if I succeed porting, how will Mir handle more then 1 monitor?
<alan_g> Perfectly?
<zzarr> :-)
<zzarr> even if I use the Android (user space) driver or is that irrelevant
<alan_g> Mir currently handles multi-monitor based on abstractions implemented on both mesa-kms and android driver stacks. No reason your port would stop it working,
<zzarr> alan_g, that's exactly what I wanted to hear :-D
<RAOF> zzarr: In the best case, pulling the thunderbolt cable will result in applications seamlessly transferring to the integrated chip.
<RAOF> zzarr: In the common case, pulling the thunderbolt cable will result in applications crashing :)
<RAOF> In order to handle the loss of a GPU the application will need to either: (a) be using software rendering, or (b) create an EGL context with KHR_ROBUSTNESS support and handle the EGL_CONTEXT_LOST case by destroying its EGL state and rebuilding it on a different GPU.
#ubuntu-mir 2016-02-16
<duflu> robert_ancell: Sorry to trouble you but I'm not sure anyone else knows how and is also blessed to do so: Can we update the Xmir patch for xenial?
<duflu> RAOF: Did linking get faster recently? Did we switch to gold or did gcc just get fixed?
<RAOF> gcc may have been fixed?
<RAOF> We're on 5.3 now.
<robert_ancell> duflu, do you need it sponsored?
<duflu> Yeah 5.3 caused the slowdown actually
<duflu> robert_ancell: Maybe... I don't remember that process
<robert_ancell> duflu, or do you want me to generate a patch from the branch and upload that?
 * robert_ancell tries to remember about xmir
<duflu> robert_ancell: Yes please
<duflu> Fortunately xorg hasn't changed otherwise since November
<robert_ancell> duflu, is bregma aware of these changes?
<duflu> robert_ancell: Yes, it was work requested by him and kgunn
<robert_ancell> cool
<duflu> Otherwise I would not have touched it
<robert_ancell> :)
<duflu> robert_ancell: The two "Fix Committed": https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs?field.tag=xmir
<robert_ancell> duflu, do you fix configure.ac to check for a more recent version of Mir?
<robert_ancell> one of your commits suggests that is the case
<duflu> robert_ancell: Where is that comment?
<robert_ancell> duflu, https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=3f1e0ab7e5a8af5578cd10492c1f93e9bf97e252
<robert_ancell> it's a runtime dependency I guess, but probably worth checking on build
<duflu> robert_ancell: No, it's a runtime requirement. Also probably safe to assume any updated Ubuntu Touch system has Mir new enough
<duflu> Especially if it also has /future/ Xmir
<robert_ancell> duflu, yeah, but anyone building X would probably want to fail if they have an old version
<duflu> robert_ancell: It's not a build-time check. Xmir links to libmirclient.so.9 which may be from "any" Mir version
<robert_ancell> duflu, yes, but configure is not necessaraily just for checking API compatibility
<duflu> robert_ancell: It would have to be a runtime check (on Android only) that the Mir client library version is new enough. But that's actually less severe than the QtMir fix, which we can't detect from Xmir
<robert_ancell> duflu, my point is by putting in configure.ac you stop someone with Mir 0.15 installed from building, because they are almost certainly going to hit the issue when they run the X they built
 * duflu checks distro
<duflu> robert_ancell: Ubuntu 15.10 and later already ships with a new enough Mir. And the QtMir bug can't be detected (we don't even know where it got fixed)
<duflu> So I'm happy to skip any detection attempts
<robert_ancell> duflu, but this is a patch to xorg, which is not necessarily built on Ubuntu
<robert_ancell> ...
 * robert_ancell gives up
<duflu> robert_ancell: I see your point, but it would be a hack of probably no real-world value and would still not protect the user entirely if they are using an old Unity8
<RAOF> configure.ac is a nice place to document such a dependency.
<duflu> It's not a dependency. We could switch it to a compatibility mode at run time. But it's impossible to reliably detect if that is required
<duflu> I will personally worry about our phone images having the right bits. But non-Ubuntu users I'm happy to say: You need a Mir v0.16 or later for it to work properly.
<RAOF> (Which is what a mir-client >= 0.16 in configure.ac documents âº)
<duflu> RAOF: It can and should build with older Mir... libmirclient9 is the requirement. When did that happen?
<RAOF> But it won't work at runtime with mir-client < 0.16?
<RAOF> Which is why you document that in the configure.ac check!
<duflu> RAOF: It could if we detected it and switched to slow mode. But we can't also detect the broken QtMir
<RAOF> But we don't, so it doesn't.
<RAOF> Basically: it's harmless to bump that version requirement, and it's courteous to anyone trying to get it to work.
<duflu> RAOF: It's not a "bump". We don't check the Mir version at runtime yet do we? That's a code change
<duflu> Also not a reliable or useful one, probably
<RAOF> We have a check in configure.ac, yes? Because we link with libmirclient9.
<RAOF> *That* check is a simple bump.
<duflu> RAOF: That's a build time check. We still want it to be buildable with old Mir. Building on old Mir is not broken
<RAOF> It's useless to build against old Mir, though.
<RAOF> I mean, you can build it, but you'll run into this bug and it won't work.
<RAOF> So in order to use it you'll need to have a newer build of Mir.
<RAOF> So there's no benefit gained in letting people build something they won't be able to run.
<RAOF> But this isn't really interesting enough to argue about, either :)
<duflu> RAOF: It's a silly feature to check and then throttle. If someone is advanced enough to build their own Xmir and they're not using Ubuntu, we should just remind them we'll only support recent versions
<RAOF> Indeed!
<RAOF> Which is why we should bump the configure.ac check!
<duflu> RAOF: Also, this only applies to Android. And never desktop
<RAOF> I'm not arguing for runtime detection!
<duflu> Desktop users can use old Mir fine
<duflu> Only touch users can't
<duflu> Although the QtMir bug does affect desktop... we have no knowledge of exactly what version that got fixed in. Just "it seems to be fixed this year"
<duflu> Hmm, now I look at it again, the only relevant Mir bug was only on Android and only relevant to non-nested servers. That's what got fixed in 0.16.0
<robert_ancell> duflu, is anyone looking at updating xmir for the X 1.18 API (i.e. you)
<duflu> robert_ancell: No I wasn't yet. Still focusing on xenial (1.17)
<duflu> Sounds like branches will happen
<robert_ancell> tjaalton, was asking, but I haven't had time to have a look
<duflu> robert_ancell: Best not to mess with what we've got (which seems like the right branch for xenial) right now
<duflu> robert_ancell: Oh I see new Xmir in xenial proposed already. You rock.
<robert_ancell> duflu, it was for testing purposes and to be ready when fglrx updates to the new API we can shift over.
<robert_ancell> I guess 1.18 will land into 16.10
<robert_ancell> duflu, please test xmir from -proposed :)
<duflu> robert_ancell: OK, ta
<duflu> robert_ancell: I won't have an answer till at least your Wednesday though
<robert_ancell> duflu, for xmir?
<duflu> robert_ancell: Yeah I'm still ploughing through morning tasks and have two time consuming meetings today
<duflu> But should be able to do all the manual testing required before tomorrow
 * duflu wonders if his words are knocking robert_ancell over
<robert_ancell> hmm, any reason why I can't VT switch away from mir_demo_server anymore?
<robert_ancell> I had to reboot, was stuck on VT1
<duflu> robert_ancell: There is a known bug. Lemme find it
<duflu> robert_ancell: Non-root?
<robert_ancell> duflu, as root
<duflu> Oh, I found https://bugs.launchpad.net/mir/+bug/1286252
<ubot5`> Launchpad bug 1286252 in Mir "mir_demo_server* successfully start as non-root (without input support), meaning it can't be quit/switched away from" [Medium,Confirmed]
<robert_ancell> yeah, I've fallen for the non-root base before
<duflu> robert_ancell: Or generally it might mean you have no input platform :)
<robert_ancell> duflu, which package name
<duflu> robert_ancell: mir-platform-input-evdev5
<tjaalton> duflu: 1.18 is in ppa:canonical-x/x-staging
<tjaalton> i've ported xmir to it
<tjaalton> sent a CFT to ubuntu-devel some time ago
<tjaalton> plan was to move it to main before FF, but nvidia hybrids regress with the blob, unity-greeter crashes
<tjaalton> so we're looking into that first
<anpok_> hm i thought 1286252 has been fixed already, by accident
<anpok_> oh ok only partially
<anpok_> there is still a way to get stuck
<duflu> tjaalton: Thanks. So long as you have the Xmir changes from the past few days too (https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/)
<tjaalton> duflu: yeah I've now merged it in the branch, will upload to ppa later
<duflu> tjaalton: Cool, thanks. Ignore the email then
<tjaalton> this is what was needed to port it btw http://sprunge.us/JfHW
<duflu> tjaalton: No risk on the GL stuff because Touch uses software rendering for now. Only the keyboard changes I guess
<tjaalton> I should probably test that :)
<duflu> tjaalton: If you test it on desktop it will default to DRI2 (not what the phone uses), so add: -sw
<duflu> tjaalton: Do you have permission to create a git branch for your changes? https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/
<duflu> That's ~xmir-team I guess
<duflu> tjaalton: Today's package just vanished from proposed and only the old release is visible. Is that right? https://launchpad.net/ubuntu/+source/xorg-server
<duflu> Maybe it's just a transitional period. I vaguely recall that happens
<tjaalton> duflu: i might be able to create a branch, after joining the team at least
<duflu> Ah I see it was "Deleted 16 minutes ago by Ubuntu Archive Robot - moved to release"
<duflu> tjaalton: That's OK. Just we'll need to remember to do it and incorporate your changes before any new major Xmir work
<tjaalton> yeah
<duflu> And make that new branch the default one
<duflu> I forget how
<tjaalton> ok
<zzarr> okey RAOF, thanks, I  hope for the first option ("jumping" to internal, and back to external when the cable is pluged in again)
<RAOF> zzarr: Just bear in mind, essentially no application currently written will support that.
<zzarr> RAOF, I know, but if the Vulkan framework for a sample will be then that would be splendid :-)
<zzarr> I don't know if though
<duflu> Ooh progress. The new xmir is released in xenial before I've finished testing it :)
<zzarr> duflu, is that good or bad?
<duflu> Not sure yet
<duflu> Can't hurt. If anything is wrong we'll fix it quickly
<zzarr> well it happened in any way
<zzarr> awesome my internet is faster then I pay for I pay for 100/100 and get 120/115 :-)
<zzarr> my grammar is poor though (realized that when I read my line)
<zzarr> in any way I'm happy to see that so many are enthusiastic about Ubuntu :-) (I'm one of the enthustiast)
<zzarr> does anyone know the status of Miracast (Aethercast)?
<alan_g> greyback: I don't really know my way around the unity8 code, and this is something you might know: is there anything that relies on MIR setting $MIR_SERVER? ("anything" would be forking a client process that relies on that environment variable to find the server - which isn't something I expect/can find.)
<greyback> alan_g: MIR_SERVER env var? No, I've never even seen that env var before, let alone seeing code depending on it
<alan_g> greyback: the Mir client API can use it to find the server socket. (if the client code doesn't specify a socket)
<alan_g> But I *think* setting it in the server process is a legacy mess that isn't useful and is confusing.
<greyback> alan_g: ok. I've only seen MIR_SOCKET being used to specify that, and upstart is responsible for that
<alan_g> The legacy thinking was that Mir servers would set it and launch clients. But it hasn't turned out that way - U8 doesn't launch clients directly does it?
<greyback> alan_g: nope
<alan_g> Excellent!
 * alan_g is going to delete the mess
#ubuntu-mir 2016-02-17
<duflu> robert_ancell_: Thank you again. I should have made up my mind before I asked you the first time
<robert_ancell_> duflu, :)
<duflu> Interestingly it means that feature isn't blocked by the two bugs that we just fixed, but also one or two new bugs not yet reported
<duflu> I may have to redesign the frame scheduling in Xmir to better deal with it. And/or (hopefully not) finish implementing GLX swap control
<duflu> Weird one of the issues was noticeably lower smoothness in Unity8 vs Mir demo shells. That might be the QtMir issue already in my name
<duflu> RAOF: The latest gcc for xenial got linking of mir_unit_tests from 3 minutes back down to 15.9 seconds. Is gold still faster?
<duflu> or binutils... something fixed it
<duflu> Impressive given bin/mir_unit_tests.bin is 241MB
<duflu> Sigh. If we stripped symbols after building and use the unstripped DSOs for the tests, that could be 100 times smaller still
<duflu> Although symbol versions makes that very hard to do
<RAOF> ??
<RAOF> We *do* strip the symbols after building the packages. Why would we build two sets of DSOs, one stripped one not?
<duflu> RAOF: I mean build one with everything (so mir tests don't need to use object libraries) and then copy and strip the unwanted bits for release DSOs
<duflu> One set of DSOs built, but two variants of that build released.
<RAOF> But we don't *have* any superfluous symbols in the released DSOs?
<RAOF> Ah, no, I think I understand what you mean.
<RAOF> I don't see why we'd bother, but I think I see what you mean :)
<duflu> RAOF: In the least you get one shared copy of the test DSOs between mir*tests, instead of each getting its own
<duflu> Quicker build and less disk space
<duflu> Might be fun to try some day
<duflu> Again.. (I have tried similar in the past)
<anpok> alf_: could your workaround fix RAOFs enable-lto branch?
<duflu> Funny thing about mice being relative devices - you can have multiple plugged in and use any/all of them
<anpok> yay and use them to have multiple cursors on screen..
<alf_> anpok: I don't know, let me take a look
<anpok> i wanted to rebuild his branch as soon as yours lands.. it seems to not link pthread on armhf vivid
<alf_> anpok: looking at the error message you pasted, it's the same thing my MP fixes (just for mir_demo_server). Given that RAOF's branch doesn't use ld.gold, it's a good chance that the problem is in fact in g++/libstdc++-4.0
<alf_> anpok: -4.9
<anpok> duflu: on touchpad scrolling.. there is another thing blocking us.. we still do report ticks even on touchpads... which are scaled (/15.0f) touchpad gestures..
<anpok> if there is an integer conversion downstream.. we loose the accuracy
<duflu> anpok: Yet nautilus and Gnome apps have one-pixel accurate touch scrolling... some other way
<anpok> on top of mir too?
<duflu> anpok: I'm only talking about Unity7
<anpok> ok
<anpok> just curious if we need to offer both assumed ticks and the unscaled scroll moves too..
<duflu> anpok: Both are required yes. You never know which the app is able to use
<duflu> anpok: I did notice libinput synthesises a mouse wheel with two finger touches... Can now zoom with Super+two fingers :)
<duflu> Although it's super-sensitive
<Saviq> alf_, looks like jenkins defeated your python foo after all :/ https://code.launchpad.net/~gerboland/qtmir/fix-orientation-after-unplug/+merge/286065/comments/728945
<Saviq> I'm not sure what happened there
<Saviq> alf_, OTOH it might actually be the fault of the -ci job, it passed the wrong build number
<greyback> Saviq: it reports test fail
<alf_> Saviq: greyback: What's the problem with the output?
<Saviq> greyback, but that's the correct run https://unity8-jenkins.ubuntu.com/view/Launchpad/job/lp-qtmir-1-ci/77/
<Saviq> greyback, and that one's passed
<Saviq> alf_, PASSED, but all builds FAILED ;)
<greyback> I dunno, just sawing what I see in the failed log
<Saviq> alf_, someohow ${BUILD_URL} pointed at the previous run (again, rebuilds)
<alf_> Saviq: ...
<Saviq> greyback, yeah, I know why the builds failed, but notice it's the same run https://code.launchpad.net/~gerboland/qtmir/fix-orientation-after-unplug/+merge/286065/comments/728908
<Saviq> while it should be 77, which passed
<Saviq> alf_, it's dumb, see https://unity8-jenkins.ubuntu.com/view/Launchpad/job/lp-qtmir-1-ci/77/console
<Saviq> alf_, and then parameters for https://unity8-jenkins.ubuntu.com/job/lp-generic-2-update-mp/475/parameters/
<Saviq> Â¿?
<Saviq> rebuilds seem to confuse jenkins these days a lot
<alf_> Saviq: so when rebuilding ${BUILD_URL} contains the URL of the original build?
<Saviq> alf_, seems so
<Saviq> alf_, I'll have a few tries to see what's in env
<Mirv> anpok: any news on a Mir input info API to use from Qt Systems? you've reportedly mentioned it being in progress on Feb 4th
<zsombi> anpok: ping
<zsombi> Mirv: :D
<Mirv> :D
<zsombi> anpok: my ping is for teh same as Mirv's :D
<Mirv> anpok: we're just trying to figure out if we can get a Mir backend coding started for qtsystems
<pax55> anpok, ^^
<anpok> Mirv: still in progress.. the last two or three weeks other things were  more important
<Mirv> zsombi: ^
<Mirv> anpok: ok, thanks for the update
<anpok> kdub: yes i agree .. seems like a lot of stuff
<anpok> i was thinking about the resize handling.. which is probably the usual case for having different sized buffers in the presentation chain
<anpok> is the idea there to create the whole surface setup.. create a new chain.. submit buffer and then apply spec?
<anpok> hm or would resize only change the buffer size but not the the other parameters of presentation chain?
<anpok> s/would resizse only change/would resize only require a change of/
<kdub> anpok, the spec can be applied before the surface creation as well
<kdub> and which "resize"?
<kdub> a resize message, initiated by the shell/server would be a notification, and then in the case of MirPresentationChains, let the client-user figure it out, and in the case of MirBufferStreams, libmirclient will auto-manage the size transition
<anpok> hm the resize as in the client decides to follow a resize event and submit the next buffer in a different size
#ubuntu-mir 2016-02-18
<duflu> OK, I can connect a secondary client to USC but it never comes to the front. Do we have any hack or workaround for that?
<duflu> alf_: Have we implemented any key combo or other hack for session switching within USC?
 * duflu imagines funky carousel animations in the future
<alf_> duflu: No session switching, just some debug modes to set the active session name
<duflu> alf_: Switch at runtime?
<alf_> duflu: no, at program start time
<duflu> alf_: Fair enough. Thanks
<alf_> duflu: But it shouldn't be too hard to hack something for runtime. Instead of using a NullDMMessageHandler we could have a DebugDMMessageHandler listening to a socket or whatever
<duflu> alf_: I'm thinking more like a key combo as the demo servers have. Don't bring to front by default because that would be a security risk, but if the user asks for it
<duflu> alf_: We would first need to decide what modifier combo is reserved for USC use I guess
<duflu> It's curious how often I end the day bisecting bugs
<duflu> Almost done
<zzarr> hello duflu, just saying hello because it's  a nice thing to do ;-)
<duflu> zzarr: Hi
<duflu> zzarr: And bye... I'm logging off
<zzarr> okey, bye
<tjaalton> why are mir headers split like they are? I'm building vulkan loader but it can't find <mir_toolkit/client_types.h> because it's under mirclient
<tjaalton> so need to set CFLAGS, fine
<tjaalton> then it fails because apparently libmirclient-dev needs to depend on libmircommon-dev, and I need to add another -I/usr/include/mircommon
<tjaalton> sorry, the pkg dep is there
<tjaalton> but the question remains, why this pain for app packagers?-)
<tjaalton> or am I doing something wrong
<tjaalton> looks like the build will fail anyway, so I won't add mir support to libvulkan at this point
<mcphail> tjaalton: aren't you using pkg-config to set the cflags?
<alan_g> tjaalton: pkg-config is your friend
<alan_g> $ pkg-config --cflags mirclient
<alan_g> -pthread -I/usr/include/mirclient -I/usr/include/mircommon -I/usr/include/mircookie
<tjaalton> that would be swell, yes :P
<tjaalton> so it's just the build env that's broken
<tjaalton> and it's cmake, meh
 * alan_g thinks "magic" is great when it works. ;)
 * mcphail hugs pkg-config
<tjaalton> yeah, barking at the wrong tree again
<tjaalton> fyi, https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan will have an updated libvulkan soon, with working demos
<tjaalton> so since it was announced that xenial will have vulkan support in Mir, maybe someone could fix the loader first :)
<tjaalton> and send patches upstream too
 * alan_g assumes bregma has a plan
<tjaalton> indeed
 * alan_g discovers his mako doesn't boot today. :(
<jerryG> any1 online?
<anpok> yes
<jerryG> anpok: any way to disable mir cursor in mir_demo_server?
<anpok> there is yet no command line switch to do that
<jerryG> anpok: anyway to fix the cursor at a certain position.. or otherwise hide it?
<jerryG> anpk: or... can i make changes without using comaand line?
<anpok> you can hide it server.the_cursor()->hide()..
<anpok> you can write a client that disables the cursor
<anpok> i mean .. depends on whether you want to do that as a compositor or as a client on a specific surface..
<anpok> jerryG: whats your use case .. which API are you using.. then I can point you right to the example code..
<anpok> (most of which can be found in the acceptance-tests directory)
<jerryG> anpok: im using X11 client with snappy ubuntu mir server
<anpok> jerryG: then xmir should do that for you..  hmm
<anpok> jerryG: you could try running xmir with -nocursor..
<jerryG> anpok: thanks.  the problem is i have two cursors... one for mir and one for xmir
<jerryG> anpok: the xmir cursor is correct, however, the mir cursor is distracting
<anpok> strange .. i only get one cursor..
<anpok> jerryG: i will add an option for that.. we already quite a few examples related to cursor.. one more will not hurt..
<anpok> +have
<jerryG> anpok: ok thanks.  what file should i add the cursor-> hide command to on the server side?
#ubuntu-mir 2016-02-19
 * alan_g wonders why DeadlockLP1491566.* fails on ARM64
#ubuntu-mir 2017-02-13
<elopio> AlbertA: what is a good time for you on Friday?
<alan_g> camako: @miral-toolkit-dev any thoughts on using namespace mir::client instead of miral::toolkit?
<camako> alan_g, https://code.launchpad.net/~alan-griffiths/miral/miral-toolkit-dev/+merge/316827/comments/826727
<alan_g> camako: thanks
<camako> yw
<tjaalton> bregma: hi, sorry for the constant pings but not having xmir for 1.19 is blocking the potential migration to libglvnd ;)
#ubuntu-mir 2017-02-14
<duflu> RAOF: Could you please look at this again? https://code.launchpad.net/~vanvugt/mir/fix-hide-then-show/+merge/316089
<RAOF> Surle.
<duflu> RAOF: Ta muchly
<bregma> tjaalton, https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/?h=xmir-1.19 ... would you prefer a patch or a debdiff to make your life easier?
<tjaalton> bregma: git branch is perfect, many thanks ;)
<tjaalton> bregma: have you built it? looks like the branch is just rebased on top of upstream
<bregma> tjaalton, I built and tested previously against the debian package, I'm currently rebuilding against an update because the darn thing doesn't stand still
<bregma> you you have a branch for the Ubuntu 1.19 package kicking around anywhere?
<tjaalton> yeah hang on
<tjaalton> I kept it local until now
<tjaalton> pushed,  https://anonscm.debian.org/git/pkg-xorg/xserver/xorg-server.git, branch ubuntu
<tjaalton> or just debcheckout xorg-server
<bregma> perfect, thanks
<tjaalton> there's also the glamor fixup patch that's needed since 1.18.4 or so
<tjaalton> for xmir
 * bregma goes off to start a new build cycle
<tjaalton> looks like automake or something broke in zesty.. I can't build the damn thing anymore
<tjaalton> ah no
<tjaalton> hw/xmir/Makefile.am:53: error: AIGLX_DRI_LOADER does not appear in AM_CONDITIONAL
<bregma> hmm
<tjaalton> in middle of all the automake spam
<bregma> I'll poke at it
<tjaalton> cool
<tjaalton> I'm afk for a bit ->
<tjaalton> bregma: so that AIGLX_DRI_LOADER had to be dropped since upstream doesn't have that anymore, and then it failed to build later
<tjaalton> ../../../../../hw/xmir/xmir-thread-proxy.c:73:5: error: implicit declaration of function âAddGeneralSocketâ [-Werror=implicit-function-declaration]
<tjaalton> ../../../../../hw/xmir/xmir-thread-proxy.c:84:5: error: implicit declaration of function âRemoveGeneralSocketâ [-Werror=implicit-function-declaration]
<bregma> tjaalton, yeah, I have a fix for that but now I'm hitting deperaction warnings with Mir 0.26 (which just hit the archive) so it looks like I'll be busy for a little bit
<tjaalton> sure thing
#ubuntu-mir 2017-02-15
<RAOF1> I am sooooo terrible at writing shaders.
<duflu> Hmm, problem... zesty's libmiral requires Mir 0.26.0 and not 0.26.1
<duflu> So you need both installed
<duflu> robert_ancell, RAOF: Could we spin a rebuild of libmiral against the new Mir that's in proposed?
<duflu> We'll need to very soon
<robert_ancell> sounds like a job for RAOF or RAOF1
<duflu> RAOF, RAOF1, camako: https://bugs.launchpad.net/ubuntu/+source/miral/+bug/1664791
<ubot5> Ubuntu bug 1664791 in miral (Ubuntu) "miral needs rebuilding on zesty (it links to an old library libmirplatform.so.14)" [Undecided,New]
<RAOF> Hm. That goes through bilito?
 * duflu shrugs
<RAOF> I mean, I can trivially upload a no-change rebuild, but that's going to mess other things up.
<duflu> It seems like the kind of atomic ABI shift that silos are for
<duflu> RAOF: Don't we just need a new build of libmiral in proposed, and then promote both at once?
<RAOF> It won't migrate out of proposed until it's installable.
<RAOF> If this *wasn't* using bileto I'd know precisely what to do, and would already have done it :)
<duflu> At least it seems like miral is what's holding the old libmirplatform14
<duflu> I can't see anything else
<duflu> Hmm...
<RAOF> This is not an urgent problem at all, is it?
<duflu> RAOF: It will be. This will block the release of 0.26.1
<RAOF> Oh? Why?
<duflu> RAOF: Because zesty's miral depends on a package that only exists in 0.26.0
<duflu> Because we corrected an ABI break, mid-series :P
<RAOF> Why does that block the 0.26.1 release?
<duflu> RAOF: I think because this makes it impossible to build an ISO
<RAOF> That package will still exist in zesty?
<duflu> RAOF: No it won't
<RAOF> Yes it will.
<RAOF> Packages aren't removed from the archive until they have no reverse-dependencies.
<duflu> RAOF: OK, I won't argue with a positive outlook. But we need to rebuild soon
<RAOF> It won't be built from *source* in the archive, but it'll exist.
<RAOF> Yeah.
<duflu> We really need to get automated ABI checking back in action
<duflu> Since not having it and discovering breaks manually is one of the main things slowing down the release of 0.26.1
<duflu> Also not terribly accurate and reliable
<RAOF> If it were urgent I could just upload a no-change rebuild manually and fix whatever that breaks in bileto. But since it shouldn't block 0.26.1, we can probably wait for someone who knows how bileto releases go.
<RAOF> Grumble grumble stringly typed code.
<duflu> Stringly typed as in Perl? :)
<RAOF> No, more âI'm not experienced at writing shader code and having the compile step be at runtime on a different VT is quite annoyingâ.
<duflu> RAOF: I recommend developing via ssh. Then the window never goes away :)
<duflu> Although annoying that you really need ethernet to avoid lag when typing over wifi
<duflu> Or at least 802.11ac
<RAOF> Aaargh.
<RAOF> Now it's throwing no errors, just failing to copy anything.
<RAOF> Bah.
<RAOF> Bah!
<RAOF> There's *another* error eliminated that still doesn't result in rendering appearing :(
<duflu> RAOF: Speaking of graphics issues, I found that glmark2 fullscreen in Xmir is outputting incomplete geometry (the GPU hasn't filled in all the triangles)
<duflu> Which is interesting, and somewhat familiar
<duflu> I had similar bugs during the development of bypass
<RAOF> Well, we are blithely assuming that the GPU is going to synchronise for us.
<RAOF> We don't glFinish() before sending buffers ;)
<duflu> Fair point
<duflu> Or perhaps we're showing the backbuffer
<duflu> Which would explain other apps flickering black
<duflu> On that note, there's another bug I forgot to log...
<TheKit> does hardware OpenGL work in Xmir on Android?
<RAOF> No
<duflu> TheKit: No, but it will try. Mesa is used, with software rendering, and wrong colours (because Mesa and Android are not yet fully compatible)
<duflu> So OpenGL in Xmir on Android will indeed put pixels on screen, slowly and with red/blue swapped
#ubuntu-mir 2017-02-16
<RAOF> For those playing at home, lp:~raof/mir/mesa-hybrid-support should light up any and all outputs connected to any and all GPUs. Probably; it needs serious cleanup.
<duflu> RAOF: What's the expected behaviour if I put a graphics card in an intel desktop and try using both GPUs?
<RAOF> duflu: Assuming your bios doesn't disable the intel GPU, you should be able to light up outputs on both GPUs.
<duflu> Fancy
<RAOF> This was tested on my Intel/AMD/Nvidia desktop :)
<duflu> RAOF: Did you get tri-GPU going?
<RAOF> (Which has the Intel GPU disabled by the firmware)
<duflu> Oh
<RAOF> I should see if I can turn it on.
<RAOF> I don't have a third monitor though.
<RAOF> Hm. Could try a projector.
<RAOF> Hm. I actually don't need a third monitor...
<duflu> Conveniently I have two Nvidia cards on the desk, for lack of better storage choices
<RAOF> If I can convince the Intel to be the primary device, even though it's got no displays connected, then I'd be rendering on the Intel and displaying on the radeon and nvidia cards...
<alan_g> Saviq: @bug 1665123 is Unity8 running on the h/w or using a host USC(?) server?
<ubot5> bug 1665123 in Unity8 Session Snap "Mir graphics platform determined based on host system instead of snap" [High,Triaged] https://launchpad.net/bugs/1665123
<duflu> alan_g: Have you heard any news on 0.26.1 making it out of proposed any time soon? Today is feature freeze
<alan_g> duflu: MirAL 1.2 (a no-change rebuild failed) just passed QA. Have poked ci-eng.
<duflu> alan_g: Thanks. I shall soon EOD with confidence
<Saviq> alan_g, there is USC in there, yes
<Saviq> and that one's ran from /
<Saviq> not from the snap
<duflu> Saviq: Another thought on text rendering... if it's being rendered with float glyph offsets then we/Qt may need to ensure the glyph cache contents are at least double the resolution of the rendering (https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem)
<Saviq> duflu, I think what greyback wants to do is the first thing, we're not telling Qt to align properly atm
<duflu> Fair enough. More efficient and less work
<duflu> Good night
<alan_g> Saviq: then that mixing of servers is what breaks the snap.
<alan_g> /sigh this brave new snap world has a lot of traps for the architecture we adopted.
<Saviq> alan_g, aha, that sounds like something we've missed when designing this...
 * alan_g wishes once again that snaps had an overlay-like filesystem
<alan_g> Saviq: if we hacked a symlink in for the renamed platform .so it would (I predict) magically start working
<Saviq> alan_g, that would make them tied to the host system, which we don't want :)
<Saviq> I suppose the "nested" platform is the way to go...
<alan_g> No, in the snap link the new name to the old
<alan_g> That way the host driver can resolve the .so when loaded in the snap
<Saviq> well, sure, but we'd have to maintain a list of symlinks like that ;)
<Saviq> maybe that's what we need for now
<alan_g> Only until you rebuild the snap with 26.1
<Saviq> did that already
<Saviq> now we've the opposite problem until 0.26.1 migrates to zesty ;)
<Saviq> but this will happen every time we have a SONAME bump in the platform, so we really need to solve this proper
<alan_g> It works fine in a .deb world. (And RPM could be fine too.)
<alan_g> It's just we're doing stuff that snaps (and AFAICS flatpak) is designed against.
<alan_g> Saviq: miral 1.2 is publishing. Did we need anything else to unblock Mir 26.1 on zesty?
<alan_g> hikiko: if you've been using the miral::toolkit classes, then you should be aware they're moving to mir::client (in a new libmirclientcpp-dev package)
<alan_g> Landing in archive real soon now (I hope).
<Saviq> alan_g, no, that's all, thanks
<hikiko> thanks alan_g :)
<hikiko> alan_g, sorry had to reboot, I am running miral as a server (miral-shell) but I am using libmirclient-dev
<hikiko> will I have a problem?
<alan_g> nope
<hikiko> ok :) thanks a lot!
<dandrader> alan_g, have you just released a new miral?
<dandrader> alan_g, CI just failed with this: "fatal error: miral/toolkit/connection.h: No such file or directory"
<dandrader> alan_g, oh yeah, must be due to https://bileto.ubuntu.com/#/ticket/2476
<alan_g> dandrader: yes. New package libmirclientcpp-dev, new names mir/client/connection.h, new namespace mir::client.
<dandrader> alan_g, wan't miral supposed to ease the pain of constant api changes...
<alan_g> Nope. The pain of constant ABI changes.
<dandrader> alan_g, the funny thing is that I wouldn't have this problem is I were using mir directly for those bits
<alan_g> dandrader: sorry, I thought ou were in the loop about this change.
<alan_g> *you
<dandrader> alan_g, I did see the message the other day but was expecting a smoother transition. and not so soo :)
<dandrader> *soon
<dandrader> miral releases fast!
<alan_g> Ack. 1.2 got moved up because Mir cocked up binaries.
<alan_g> Se we needed a miral release to unblock Mir 26.1
<dandrader> alan_g, where's miral/toolkit/persistent_id.h now?
<bschaefer> ./client/mir_toolkit/mir_persistent_id.h
<bschaefer> o miral
<dandrader> alan_g, ok. bzr told me "RM  include/miral/toolkit/persistent_id.h => include/mir/client/window_id.h"
<dandrader> error: âfor_normal_surfaceâ is not a member of âmir::client::WindowSpecâ
<alan_g> s/surface/window/g
<dandrader> thanks
<dandrader> alan_g, with new mir and miral my internal mir client code stopped working
<alan_g> dandrader: odd. mine didn't
<dandrader> alan_g, the connection returned by mir::client::Connection{mir_connect_sync(...))
<dandrader> returns false here: mir_connection_is_valid(m_connection)
<dandrader> alan_g, has anything changed there. like the connection string format
<dandrader> ?
<alan_g> AFAIK
<alan_g> *not* AFAIK
<alan_g> dandrader: does mir_demo_server work with mir_demo_client...?
<dandrader> alan_g, no. http://pastebin.ubuntu.com/24007981/
<dandrader> alan_g, I'm missing something it seems
<alan_g> mir-graphics-drivers-desktop?
<dandrader> alan_g, I have that
<alan_g> updated?
<dandrader> ohhhhhhh. mir-client-platform-mesa5 is still 0.26.0 for some reason
 * alan_g thinks changing a .soname in the middle of a series doubled the problems
<dandrader> alan_g, now it works. thanks!
<alan_g> yw
<alan_g> bschaefer: if you have time and motivation it would be good for someone other than me to try out: https://code.launchpad.net/~alan-griffiths/miral/workspaces-example/+merge/316975
<bschaefer> alan_g, yeah i can test it out!
<alan_g> thanks!!
#ubuntu-mir 2017-02-17
<duflu> Some numbers to end the week on...
<duflu> https://docs.google.com/spreadsheets/d/1RbTVDbx04ohkF4-md3wAlgmxbSI1DttstnT6xdcXhZQ/pubchart?oid=1566479835&format=interactive
<greyback> duflu: thanks for taking on the subpixel bits for me
<greyback> and nice chart
<duflu> greyback: No problem. I needed some smaller tasks to end the week cleanly
<greyback> duflu: adding the set-subpixel feature was a good idea too
<greyback> I can see us exposing that in settings
<duflu> greyback: For some reason I was imagining a GUI for it a long time and forgot the API didn't exist
<duflu> Not sure if we've got output events wired up to that yet
<greyback> duflu: I'm not sure of the value of surface output event, aside from saying "hey, you're not on this screen"
<greyback> IMO the client can then read what it wants from the screen/display config
<duflu> greyback: It lets you abstract things about the outputs (like the most appropriate refresh rate or scale, which might not match any one real output)
<greyback> uhh, I meant, "hey, you're *now* on this screen"
<duflu> Anyway, gotta run
<greyback> duflu: if you say so. That sounds pretty special
<greyback> duflu: have a nice weekend!
<duflu> greyback: vsync now relies on it :)
<duflu> Bye
<aquarius_> alf_: are you the person I should talk to if I have repowerd questions? :)
<alf_> aquarius_: sure, what's up?
<aquarius_> alf_: basically, I'd like to temporarily prevent the screen on an ubuntu phone from being locked (either by timeout or by power-button press), but I'd also like to be notified somehow when the power button *is* pressed.
<aquarius_> I could just stop repowerd, but then it stops monitoring the power button, and so I can't listen for its d-bus signals. But I don't know how to tell repowerd to ignore power button presses and not lock the screen
<alf_> aquarius_: it's not possible to tell repowerd to ignore the power button. However, repowerd gets the original power button signals from the com.canonical.Unity.PowerButton service which is implemented by unity-system-compositor.
<alf_> aquarius_: so you could stop repowerd and listen on the PowerButton interface
<aquarius_> oh! repowerd doesn't actually monitor the button itself?
<aquarius_> that would explain why I can't find the code that does it then :)
<aquarius_> so I could, temporarily, stop repowerd and then listen for signals on com.canonical.unity.powerbutton
<aquarius_> and then later restart repowerd
<alf_> aquarius_: right, you will get Press and Release signals. Note, however, that you will not get a LongPress signal, since it's repowerd that emits that.
<aquarius_> that's fine
<aquarius_> excellent! thank you very much
<alf_> aquarius_: you are welcome
<elopio> good moning AlbertA! are you ready for today?
<AlbertA> elopio: sure what time again?
<AlbertA> ahh 11, ok
<elopio> AlbertA: yes, in two hours, thanks. I'll set up the hangout and make the announcements. Let me know if I can help you with something.
<alan_g> bschaefer: workspace-example is ready for breaking again
<bschaefer> alan_g, excellent!
<bschaefer> ooo fancy shortcut intro
<bschaefer> huh ... i need to figure out how to reproduce this our get some debugging messages... as going from workspace 1 ---> 2 and the window that *should* be on 2 isnt there
<bschaefer> but going from 3 ---> 2 and it shows up
<bschaefer> huh ... this is just really strange when it gets in this state
 * bschaefer attempts to reproduce
<alan_g> --window-management-trace is my favourite debugging tool
 * alan_g just needs to cut the excessive and unnecessary verbosity
<bschaefer> o yeah forgot about that
 * bschaefer adds that and sees if maybe some key is stuck down
 * alan_g should have found keys U7 doesn't eat
<bschaefer> huh miral doesnt seem to like it when i close it with ctrl+alt+del
<bschaefer> twice in a row its caused just a black screen that I couldnt recover from
<alan_g> ctrl+alt+BkSp?
<bschaefer> o yeah backspace
<bschaefer> [2017-02-17 07:26:26.824675] miral::Window Management: for_each_workspace_containing window=@Ã¦^BÃX^?
<bschaefer> that looks strange?
<bschaefer> [2017-02-17 07:26:27.062148] miral::Window Management: for_each_workspace_containing window=pÃ^BÃX^?
<alan_g> It does. Log it I'll fix the logging.
<bschaefer> alan_g, at some point, one window gets stuck on all workspaces
<bschaefer> but i wasnt sure if ctrl was stuck down (doesnt seem like it)
<alan_g> Odd
<alan_g> I've not seen that (yet)
<bschaefer> yeah ... i need a way to reproduce it, it seems to be meta + alt f1/f2 with two windows then taking a window from f1 and meta + ctrl onto f2
 * bschaefer will attempt to reproduce it a bit better
<attente> does mir have vulkan support?
<alan_g> bschaefer: you're commenting on a superseded version of the MP
<bschaefer> thought i clicked on the new one
<bschaefer> o a second time
<bschaefer> alan_g, found a way to reproduce
<bschaefer> alan_g, hopefully *thats* a correct way to reproduce
<bschaefer> hmm you dont need to hold the hot key down, but i seem to be able to reproduce it 100% of the time now
<bschaefer> annd dont need to do any alt + meta stuff in the beginning
 * bschaefer re-writes reproduction
<greyback> attente: not yet, camako was working on it but I think pulled onto other things
<bregma> attente, camako can correct me if I'm wrong, but Mir out of the box does not yet have WSL support for obtaining a Vulkan context when using Mir, it's currently EGL-only
<camako> attente, at some point it worked, but needed presentation chain API to be published... In the mean time, there has been a lot of Vulkan work in Mesa. Now that presentation chain support has been published in Mir, I need to refresh the Mesa patch for Vulkan.
<AlbertA> elopio: do you have a hangout link so I can setup?
<elopio> AlbertA: https://hangouts.google.com/call/hmcpgwejwff3znwobjy77snwzie
<elopio> and anybody else from the team who wants to join ^
<AlbertA> kgunn: ^ ?
 * alan_g wonders what it is
 * kgunn also wonders
<AlbertA> alan_g: it's an ubuntu-on-air session
<kgunn> AlbertA: i may hop on a ho with willcooke here in a second....but i'll at least join irc
<willcooke> kgunn, just getting near to wrapping here I think, won't be much longer
<elopio> thanks a lot AlbertA :)
<AlbertA> elopio: np
<alan_g> bschaefer: another iteration of workspaces-example ready for breaking
