| robert_ancell | duflu, hey, up for some XMir volunteering? | 02:14 |
|---|---|---|
| duflu | robert_ancell: Yes. But in a hangout right now | 02:15 |
| robert_ancell | np | 02:15 |
| 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:04 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| robert_ancell | duflu, basically any ARM hardware is a useful dev platform to start tackling these issues. | 03:16 |
| duflu | Actually I do have a Bluetooth Apple Magic Trackpad. Just never succeeded in pairing it to a phone | 03:17 |
| 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:18 |
| robert_ancell | duflu, try it on wily | 03:20 |
| * duflu does both in parallel | 03:31 | |
| 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:32 |
| 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:33 |
| RAOF | Oh, ho. eglflash (and, apparently, *only* eglflash) dies with a segfault on exit. | 03:35 |
| RAOF | Intriguing. | 03:36 |
| duflu | That sounds familiar | 03:36 |
| duflu | Wonder why | 03:36 |
| 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:37 |
| duflu | Fun! rc-proposed is a mixture of Mir 0.14.1 and 0.13.3 | 03:38 |
| duflu | Because libmirclient8 | 03:38 |
| 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:51 |
| 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:52 |
| 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 | 03:58 |
| 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:04 |
| 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:05 |
| robert_ancell | ln -s /usr/bin/xkbcomp install/bin/ | 04:07 |
| robert_ancell | ln -s /usr/share/X11/xkb/ install/share/X11/xkb | 04:07 |
| robert_ancell | substitute where you install to and I think you have to delete the existing installed directory | 04:08 |
| duflu | robert_ancell: Always rootless right? | 04:14 |
| robert_ancell | duflu, no, never rootless | 04:14 |
| duflu | Oh... ok | 04:15 |
| robert_ancell | rootless has other issues | 04:15 |
| RAOF | Like crashing as soon as you start xeyes :) | 04:17 |
| robert_ancell | :( | 04:18 |
| robert_ancell | xeyes is our number 1 feature | 04:18 |
| robert_ancell | The killer app | 04:18 |
| duflu | Hmm, corrupt mouse cursor on desktop | 04:19 |
| duflu | Sometimes corrupt means invisible | 04:19 |
| 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:22 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| robert_ancell | RAOF, so what is the client side feature - Mir will support both methods where possible? | 04:54 |
| robert_ancell | client allocated I mean | 04:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 04:59 |
| 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:00 |
| robert_ancell | Can Mir deallocate a buffer the client allocated? | 05:01 |
| RAOF | No | 05:01 |
| RAOF | Well, ish. | 05:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| * RAOF is not particularly invested in server-side allocation | 05:06 | |
| robert_ancell | I'm particularly annoyed by server-side allocation... | 05:06 |
| 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 | 05:07 |
| === chihchun_afk is now known as chihchun | ||
| 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:41 |
| bschaefer | diff showed that was fine, now its showing the files as added/removed? | 06:42 |
| === chihchun is now known as chihchun_afk | ||
| 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:42 |
| 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:43 |
| bschaefer | RAOF, i wonder if the *.moved files were being re-generated | 06:44 |
| 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:45 |
| 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 |
| === guest42315 is now known as o | ||
| o | hi all | 06:46 |
| === o is now known as Guest30312 | ||
| 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:47 | |
| 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:48 |
| * 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:49 |
| * bschaefer goes away for the night | 06:50 | |
| RAOF | Urgh. Our example of creating decorations is all manner of wrong. | 06:51 |
| RAOF | Or, at least, awkward for me :) | 06:51 |
| 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:54 |
| RAOF | But generally? I don't think it's a mainstream thing. | 06:55 |
| 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:58 |
| RAOF | anpok_: C++ std::string ABI issues. | 06:59 |
| RAOF | ? | 06:59 |
| anpok_ | ahh i was using gcc 5 with a vivid cross environment | 07:00 |
| anpok_ | thx | 07:00 |
| RAOF | Ba baw! | 07:00 |
| anpok_ | aye and multistrap works with phone overlay \o/ | 07:02 |
| === chihchun_afk is now known as chihchun | ||
| duflu | anpok_: cross-compile-chroot.sh -d vivid fixes that | 07:05 |
| 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:06 |
| 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:24 |
| duflu | zzarr: This is probably the wrong channel. Try #ubuntu-desktop. Although that's probably not the best one either | 07:28 |
| zzarr | duflu, I know, but I thought as it's a mir related question I'd ask here | 07:37 |
| zzarr | is #ubuntu-devel a better place to ask? | 07:40 |
| duflu | I think so | 07:40 |
| zzarr | I'll try | 07:41 |
| zzarr | I realized I wrote the wrong name on the package, it sould be unity8-lxc | 07:44 |
| 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:50 |
| zzarr | okey, thanks | 07:58 |
| Guest30312 | zzarr, and you are right on time, usually they pop up on the channel at this hour | 07:59 |
| zzarr | nice, thanks to you too | 08:00 |
| Guest30312 | :P | 08:00 |
| === greyback|eod is now known as greyback | ||
| anpok_ | .. our cross compile ci run, does it run tools/setup-partial-armhf script or just the cross-compile-chroot script? | 09:15 |
| anpok_ | ah ok the latter | 09:16 |
| === 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 | ||
| anpok_ | alf, alan_g: where is the cross compile ci job defined? | 13:23 |
| anpok_ | is there a bzr repository with the script? | 13:23 |
| === dandrader|afk is now known as dandrader | ||
| 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) | 13:28 |
| === 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 | ||
| tedg | bregma: Is there any chance of getting a Mir snap that would work with the RaspPi2 touch screen? | 21:12 |
| bschaefer | tedg, mir doesnt work on raspi :( | 21:14 |
| bschaefer | not at lease the last time i tested it out | 21:14 |
| bschaefer | since raspi2 doesnt support/have /dev/dri and doesnt support software rendering and does use (something else? atm) | 21:15 |
| bregma | tedg, no | 21:22 |
| 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:23 |
| * bschaefer would enjoy that as well | 21:24 | |
| RAOF | bregma, tedg: You could also prod foundations/kernel to get the open-source rpi2 drivers enabled - http://dri.freedesktop.org/wiki/VC4/ :) | 23:23 |
| bschaefer | RAOF, thats the only issue? | 23:26 |
| bschaefer | o yeah that would make it work | 23:27 |
| RAOF | :) | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!