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