[02:14] <robert_ancell> duflu, hey, up for some XMir volunteering?
[02:15] <duflu> robert_ancell: Yes. But in a hangout right now
[02:15] <robert_ancell> np
[03:04] <duflu> robert_ancell: OK, now just need to finish the morning's bug triage and code review check-up
[03:04] <robert_ancell> duflu, sure
[03:08] <duflu> robert_ancell: OK, what's the best hardware setup (in the absence of a slimport cable and bluetooth mouse)?
[03:08] <duflu> I can use a mouse on arale (USB)
[03:08] <robert_ancell> I'm just sshing into my Nexus 4 and running XMir from one connection and the apps from another
[03:09] <robert_ancell> I haven't got past tackling output issues
[03:09] <duflu> robert_ancell: rc-proposed on mako then?
[03:09] <robert_ancell> duflu, I've just been using the stable image and dist-upgrading. Then building the git branch of XMir on the phone.
[03:09] <duflu> robert_ancell: Oh so you use wily?>
[03:10] <robert_ancell> No, it says vivid in /etc/os-release
[03:10] <robert_ancell> I've been dist-upgrading just to be newer than the OTA updates to rule out various Mir fixes.
[03:11] <duflu> robert_ancell: Sorry, forgot dist-upgrade never upgrades the dist :)
[03:11] <robert_ancell> I'm happy to hear other methods if there are easier ones.
[03:11] <robert_ancell> duflu, yeah, worst name eva
[03:12] <duflu> robert_ancell: You know wily works on mako?... in the devel-proposed channel. Just some bugs to contend with
[03:12] <duflu> And wily has the latest Mir the soonest
[03:12] <robert_ancell> duflu, do you think it's worth trying? We don't need wily specifically.
[03:13] <robert_ancell> And these might well not be Mir issues
[03:13] <duflu> robert_ancell: So long as your vivid ends up with Mir 0.15 it's not necessary
[03:14] <robert_ancell> Looks like I have Mir 0.14
[03:14] <duflu> robert_ancell: Before I downgrade mako for this, should I use arale instead? I can at least use a mouse on arale
[03:14] <duflu> robert_ancell: Yeah 0.14 is soon going to be two releases behind. I guess the overlay's not updated yet
[03:15] <robert_ancell> I have no idea what the state of arale is - but it could be useful to have a datapoint if the same issues exist there.
[03:16] <robert_ancell> duflu, basically any ARM hardware is a useful dev platform to start tackling these issues.
[03:17] <duflu> Actually I do have a Bluetooth Apple Magic Trackpad. Just never succeeded in pairing it to a phone
[03:18] <robert_ancell> duflu, you really don't need any input devices
[03:18] <duflu> Yeah I gathered that
[03:18] <duflu> Trying to sacrifice arale first. As I like to reserve mako for wily testing
[03:20] <robert_ancell> duflu, try it on wily
[03:31]  * duflu does both in parallel
[03:32] <RAOF> Sight.
[03:32] <RAOF> Sigh.
[03:32] <RAOF> What is the actual *failure* in https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6547/console ?
[03:32] <duflu> robert_ancell: "The git branch" of XMir?
[03:32] <robert_ancell> duflu, lp:~xmir-team/xorg-server/+git/xmir
[03:33] <duflu> RAOF: If everything crashes like that it's possible you've broken an ABI but forgot to bump it
[03:33] <RAOF> duflu: But nothing seems to have crashed? All the tests run to completion.
[03:33] <robert_ancell> I compile with --enable-glamor --disable-xwayland --disable-xorg --disable-xnest --disable-xephyr --disable-xvfb
[03:35] <RAOF> Oh, ho. eglflash (and, apparently, *only* eglflash) dies with a segfault on exit.
[03:36] <RAOF> Intriguing.
[03:36] <duflu> That sounds familiar
[03:36] <duflu> Wonder why
[03:37] <duflu> RAOF: Well extra datapoint: It doesn't happen to other branches right?
[03:37] <RAOF> Not consistently, at least ;)
[03:37] <RAOF> But I'll work under the assumption that it's hitting a real problem, at least for now.
[03:38] <duflu> Fun! rc-proposed is a mixture of Mir 0.14.1 and 0.13.3
[03:38] <duflu> Because libmirclient8
[03:51] <robert_ancell> duflu, how can Mir solve the texture format issues? As far as I can tell they are in the OpenGL layer.
[03:51] <duflu> robert_ancell: So zenity works on desktop I assume?
[03:51] <robert_ancell> duflu, yes
[03:51] <robert_ancell> zenity is just the "simplest X app I can run" case I'm working on.
[03:51] <robert_ancell> And then some hand written trivial GTK+ apps.
[03:52] <duflu> robert_ancell: It's just related work, not a complete solution. Mir 0.15 adds a new function to choose pixel formats automatically and correctly (which is a big problem for mako)
[03:52] <duflu> Mir 0.15 also adds more pixel formats and massively improved texture upload support
[03:52] <robert_ancell> duflu, right, the problems are in the Glamor layer - i.e. XMir is not picking the formats.
[03:58] <duflu> robert_ancell: Also it's almost obvious Glamor is doing things with extensions not present on phones. I know the alternatives that do work, but need a build environment first obviously
[04:04] <duflu> robert_ancell: What's the magic for running Xmir so as to avoid...
[04:04] <duflu> XKB: Failed to compile keymap
[04:04] <duflu> Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
[04:04] <duflu> I remember hitting that before
[04:05] <robert_ancell> duflu, hand on, my phone just resarted
[04:05] <duflu> I'm sanity checking on desktop first
[04:05] <robert_ancell> It's just couple of symlinks
[04:05] <duflu> While the phone installs things
[04:07] <robert_ancell> ln -s /usr/bin/xkbcomp install/bin/
[04:07] <robert_ancell> ln -s /usr/share/X11/xkb/ install/share/X11/xkb
[04:08] <robert_ancell> substitute where you install to and I think you have to delete the existing installed directory
[04:14] <duflu> robert_ancell: Always rootless right?
[04:14] <robert_ancell> duflu, no, never rootless
[04:15] <duflu> Oh... ok
[04:15] <robert_ancell> rootless has other issues
[04:17] <RAOF> Like crashing as soon as you start xeyes :)
[04:18] <robert_ancell> :(
[04:18] <robert_ancell> xeyes is our number 1 feature
[04:18] <robert_ancell> The killer app
[04:19] <duflu> Hmm, corrupt mouse cursor on desktop
[04:19] <duflu> Sometimes corrupt means invisible
[04:22] <duflu> robert_ancell: OK, I've made a start thanks. Need to run to the post office and grab lunch too
[04:22] <robert_ancell> duflu, ok, cool
[04:22] <robert_ancell> I'll be EOD by then but I'll catch up tomorrow
[04:42] <robert_ancell> duflu, fyi I just tried backporting all the glamor changes from master and it doesn't fix the crashers :(
[04:42] <RAOF> Oh, fun. It is a real issue, but odd.
[04:44] <robert_ancell> RAOF, hey, could you help me understand why we use DRI2 and not DRI3?
[04:44] <RAOF> robert_ancell: Intel driver had some problems with it at some point.
[04:44] <robert_ancell> RAOF, for Mir I mean.
[04:44] <RAOF> We don't use DRI at all for Mir?
[04:45] <robert_ancell> Last I heard it was due to buffer allocation.
[04:45] <RAOF> Oh, you mean for XMir?
[04:45] <robert_ancell> RAOF, so Glamor provides DRI3 by default, but we've disabled that and copied over the DRI2 code
[04:45] <robert_ancell> yeah
[04:45] <RAOF> Right, allocation issues.
[04:46] <RAOF> Specifically: in DRI3 the client allocates their buffer and tells the server about it. We've no support for that in Mir; clients use the buffers Mir sends them.
[04:46] <robert_ancell> RAOF, can DRI3BufferFromPixmap not be used to do server side allocation?
[04:46] <RAOF> That's not how DRI3 clients - specifically mesa - use it.
[04:46] <robert_ancell> or does that only return a buffer if the pixmap was created with DRI3PixmapFromBuffer
[04:47] <robert_ancell> RAOF, we can't stop Mesa direcly allocating buffers anyway can we?
[04:47] <RAOF> We can, and do; DRI2 uses server allocated buffers.
[04:47] <robert_ancell> i.e. a GTK+ app running inside Mir can happily grab buffers from the Intel driver
[04:48] <RAOF> Right, but the GTK+ app can't set that as the surface buffer.
[04:48] <RAOF> (This might actually change with the New Buffer Semantics™, in which case we'd just do DRI3 as-is)
[04:48] <robert_ancell> That would make life easy
[04:49] <RAOF> Yes, it would, wouldn't it.
[04:49] <robert_ancell> So I guess we need to wait to see the result of that before doing much.
[04:49] <robert_ancell> Because I figure DRI3 could do what we want, as long as Mesa knew it was in a "use DRI3BufferFromPixmap not DRI3PixmapFromBuffer case"
[04:49] <robert_ancell> But that would require proposing a DRI3 change
[04:50] <robert_ancell> And I think we'll have trouble convincing Xorg to take XMir with all the DRI2 code copied.
[04:50] <RAOF> I'd raise client-allocated buffers at whatever stakeholder meeting you can get to.
[04:50] <RAOF> Yeah, DRI2 is not the new hotness.
[04:51] <RAOF> XMir has *always* wanted client-allocated buffers; they'll make it much simpler because you're not fighting X's normal desire to allocate.
[04:52] <robert_ancell> OK, I guess I'll raise this with Will / Kevin that we're kind of blocked carrying XMir until we decide if we can do DRI3 / new buffer stuff.
[04:52] <RAOF> A bunch of the NBS stuff has landed, but client-allocated buffers is an additional change on top.
[04:53] <robert_ancell> I might also look at upstreaming XMir minus the DRI code and then we can solve that later.
[04:53] <RAOF> One that should be easy, because NBS will have cleared the path, but still something that needs to happen.
[04:53] <robert_ancell> RAOF, is there a bug for this feature?
[04:53] <RAOF> robert_ancell: No
[04:54] <robert_ancell> RAOF, so what is the client side feature - Mir will support both methods where possible?
[04:55] <robert_ancell> client allocated I mean
[04:56] <RAOF> robert_ancell: So, the NBS is that clients have a direct handle on their buffers; as it currently stands they still call into the server to allocate, but once they've received the handles they have the handles and can submit them in whatever order they want, etc.
[04:57] <RAOF> The obvious extension is to not call into the server, and instead have a mirclient function that takes an already-allocated buffer; a dma-buf + some metadata like size, stride, etc.
[04:57] <robert_ancell> RAOF, and that only works on the desktop drivers?
[04:58] <RAOF> You could probably get it to work on the android side as well, but I'm less familiar there.
[04:58] <robert_ancell> RAOF, I'm really struggling to work out what the original reason was for server side allocation
[04:59] <RAOF> There are a bunch of optimisations you can do with it.
[04:59] <robert_ancell> And they don't matter anymore?
[04:59] <robert_ancell> And the optimisations are better than a well behaved client?
[05:00] <RAOF> Well, *everything* is equivalent with a perfectly-behaved client.
[05:00] <robert_ancell> So we were just taking responsibility for the clients optimisations
[05:00] <robert_ancell> And now we will offer two methods - the easy one of using server side allocation and the harder one of doing the allocations yourself.
[05:01] <robert_ancell> Can Mir deallocate a buffer the client allocated?
[05:01] <RAOF> No
[05:01] <RAOF> Well, ish.
[05:02] <robert_ancell> Is that the major downside of letting the client do it? A bad client might starve the buffers?
[05:02] <RAOF> It requires less communication with the client to get good behaviour.
[05:03] <robert_ancell> RAOF, ok, thanks. I think I understand better.
[05:03] <RAOF> Any optimisation the server might want *can* be done by sending a message to the client instead and having the client do the equivalent thing.
[05:03] <robert_ancell> RAOF, as long as the client hasn't gone rogue and is no longer listening to messages from the server.
[05:04] <RAOF> Right. And if you're doing that then any *new* optimisation you might want to make may require a whole new set of clients.
[05:04] <RAOF> Because you might need to send a new message, etc.
[05:04] <robert_ancell> RAOF, but it would be wrapped up in libmirclient right?
[05:04] <RAOF> Not necessarily.
[05:04] <RAOF> It'd probably be wrapped up in libEGL, though.
[05:05] <RAOF> Slash XMir.
[05:05] <robert_ancell> Right, so it would be clients(n) where n is a small number and likely under the same development control as Mir.
[05:05] <RAOF> You'd get almost all of the way with EGL, GTK, Qt, SDL and XMir, yeah.
[05:06]  * RAOF is not particularly invested in server-side allocation
[05:06] <robert_ancell> I'm particularly annoyed by server-side allocation...
[05:07] <robert_ancell> RAOF, thanks again, heading off now.
[05:07] <RAOF> I'm not entirely sure that you'll be able to escape it on android, though.
[05:07] <RAOF> Raise it with kdub!
[05:07] <RAOF> robert_ancell: Have a fine evening!
[05:07] <robert_ancell> bye all
[06:41] <bschaefer> RAOF, do you see this crazyness? Or understand it?
[06:41] <bschaefer> https://code.launchpad.net/~mir-team/mir/attestable-timestamps-client/+merge/270470
[06:41] <bschaefer> somehow *.moved files got added to my MP (i dont remember adding it)
[06:41] <bschaefer> then i bzr rm the moved files only
[06:42] <bschaefer> diff showed that was fine, now its showing the files as added/removed?
[06:42] <RAOF> *.moved implies a merge conflict at one point.
[06:42]  * bschaefer grabs a fresh branch to check the damage
[06:42] <bschaefer> RAOF, right which i resolved
[06:42] <RAOF> Ooooh, yeah.
[06:42] <RAOF> I suspect you've run into bzr's tracking of renames.
[06:42] <bschaefer> usually when theres a *.moved file you just need to pick one
[06:43] <bschaefer> eww
[06:43]  * bschaefer guesses i need to edit something in /.bzr
[06:43] <RAOF> Specifically - each file gets an inode which is independent of the filename, so you *can* both remove and add a file at the same time :)
[06:43] <bschaefer> RAOF, haha.... hmm
[06:44] <bschaefer> RAOF, i wonder if the *.moved files were being re-generated
[06:45] <bschaefer> when i pushed the branch and said it was a child of the server branch...
[06:45] <RAOF> *Was* it a child of the server branch?
[06:46] <bschaefer> RAOF, well i merged the server branch into a fresh mir branch
[06:46] <bschaefer> commited that, then merged the old attestable branch
[06:46] <bschaefer> fixed conflicts
[06:46] <bschaefer> then pushed that branch as the split between the two
[06:46] <o> hi all
[06:47] <bschaefer> RAOF, how else would you normally split a branch? I suppose ... i should have just added the changes to the server branch
[06:47] <RAOF> bschaefer: Frankly? The normal way that I'd split a branch is to clone it into git, do a bunch of rebasing, and then push.
[06:47]  * bschaefer doesnt know git well enough
[06:48] <bschaefer> RAOF, i know bzr better :)
[06:48] <RAOF> Bzr does *not* make splitting branches a sensible operation.
[06:48] <bschaefer> which as it turns out isnt good enough
[06:48] <bschaefer> :(
[06:48] <bschaefer> RAOF, i was just imagining a nice split where the server changes would already be commited then i would commit the difference
[06:48] <bschaefer> into a new branch
[06:48] <RAOF> Well, it *can* be; if *all* the server changes occur before *all* the client changes then you can just branch from the point that it switches...
[06:48] <bschaefer> RAOF, i think ill just put the client code on hold
[06:48]  * duflu learns about git for launchpad and the world gets better
[06:48] <bschaefer> until server merges
[06:48] <bschaefer> then rebase vs trunk
[06:49]  * bschaefer starts learning git
[06:49] <RAOF> Yeah, that might help. Rebasing in bzr basically isn't supported.
[06:49] <RAOF> It's somewhat opposed, philosophically.
[06:49] <bschaefer> yeah, trunk is always kind to me, or rather a frash branch :)
[06:49] <bschaefer> RAOF, cool, ill just make a comment on the branch that it'll be fixed but you can still review the code...
[06:50]  * bschaefer goes away for the night
[06:51] <RAOF> Urgh. Our example of creating decorations is all manner of wrong.
[06:51] <RAOF> Or, at least, awkward for me :)
[06:54] <anpok_> RAOF: is Danger 5 really a thing in australia?
[06:54] <RAOF> anpok_: Define “a thing”
[06:54] <anpok_> popular?
[06:54] <RAOF> Moderately?
[06:54] <RAOF> Certainly among a certain demographic.
[06:55] <RAOF> But generally? I don't think it's a mainstream thing.
[06:58] <anpok_> humm what could cause the cross compile to fail with: src/protobuf/mir_protobuf_wire.pb.cc:174: undefined reference to `google::protobuf::io::StringOutputStream::StringOutputStream(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)'
[06:59] <RAOF> anpok_: C++ std::string ABI issues.
[06:59] <RAOF> ?
[07:00] <anpok_> ahh i was using gcc 5 with a vivid cross environment
[07:00] <anpok_> thx
[07:00] <RAOF> Ba baw!
[07:02] <anpok_> aye and multistrap works with phone overlay \o/
[07:05] <duflu> anpok_: cross-compile-chroot.sh -d vivid fixes that
[07:06] <anpok_> duflu: well not if you then go and selsect CC_VARIANT=-5 :)
[07:06] <anpok_> -s
[07:06] <duflu> Bad anpok_
[07:06] <duflu> anpok_: BTW it's changed names. You should pull from lp:mir
[07:24] <zzarr> hello! I installed ubuntu-lxc on a computer running Wily today, but it hangs on login, it seams to be a common problem, is there a solution?
[07:28] <duflu> zzarr: This is probably the wrong channel. Try #ubuntu-desktop. Although that's probably not the best one either
[07:37] <zzarr> duflu, I know, but I thought as it's a mir related question I'd ask here
[07:40] <zzarr> is #ubuntu-devel a better place to ask?
[07:40] <duflu> I think so
[07:41] <zzarr> I'll try
[07:44] <zzarr> I realized I wrote the wrong name on the package, it sould be unity8-lxc
[07:50] <duflu> zzarr: Ah ok, then try #ubuntu-unity
[07:50] <duflu> or #ubunt-touch
[07:50] <duflu> because that's where unity8 people live
[07:58] <zzarr> okey, thanks
[07:59] <Guest30312> zzarr, and you are right on time, usually they pop up on the channel at this hour
[08:00] <zzarr> nice, thanks to you too
[08:00] <Guest30312> :P
[09:15] <anpok_> .. our cross compile ci run, does it run tools/setup-partial-armhf script or just the cross-compile-chroot script?
[09:16] <anpok_> ah ok the latter
[13:23] <anpok_> alf, alan_g: where is the cross compile ci job defined?
[13:23] <anpok_> is there a bzr repository with the script?
[13:28] <alan_g> anpok_: IIRC You need to poke around the Jenkins job definitions to find it. (And since I can't get the VPN working I can't look at those currently)
[21:12] <tedg> bregma: Is there any chance of getting a Mir snap that would work with the RaspPi2 touch screen?
[21:14] <bschaefer> tedg, mir doesnt work on raspi :(
[21:14] <bschaefer> not at lease the last time i tested it out
[21:15] <bschaefer> since raspi2 doesnt support/have /dev/dri and doesnt support software rendering and does use (something else? atm)
[21:22] <bregma> tedg, no
[21:23] <bregma> tedg, it has to do wit hthe rendering path through Mesa, er sumpin'
[21:23] <bregma> there is a queued work item to get that working, prolly in the 0.17 release
[21:24]  * bschaefer would enjoy that as well
[23:23] <RAOF> bregma, tedg: You could also prod foundations/kernel to get the open-source rpi2 drivers enabled - http://dri.freedesktop.org/wiki/VC4/ :)
[23:26] <bschaefer> RAOF, thats the only issue?
[23:27] <bschaefer> o yeah that would make it work
[23:27] <RAOF> :)