| === chihchun_afk is now known as chihchun | ||
| alan_g | alf_: vt switching bug lp:1465585 | 10:08 |
|---|---|---|
| alf_ | alan_g: thanks | 10:08 |
| tjaalton | mesa doesn't build on wily due to mir abi changes | 10:57 |
| tjaalton | so egl-platform-mir.patch needs an update | 10:57 |
| alf_ | tjaalton: I will take a look | 10:59 |
| tjaalton | thanks | 10:59 |
| tjaalton | http://pastebin.com/RGP7Bt68 | 10:59 |
| tjaalton | is the error | 10:59 |
| tjaalton | if it's something simple I can apply it directly and upload a new mesa | 11:00 |
| tjaalton | since I have 10.5.7 merged and ready | 11:00 |
| tjaalton | btw, mir source package still refers to the old lp branch | 11:06 |
| tjaalton | in debian/control | 11:06 |
| === chihchun is now known as chihchun_afk | ||
| alf_ | tjaalton: This package dependency problem in mir. If you want a quick solution to unblock you until we fix it, you can add a build dependency on libmirclient-dev. | 11:20 |
| tjaalton | alf_: ah, ok I'll try that | 11:24 |
| tjaalton | alf_: yeah that fixed it, thanks | 11:29 |
| alf_ | tjaalton: yw | 11:29 |
| alf_ | tjaalton: Is there a branch holding the packaging of mesa? lp:ubuntu/mesa seems not to contain recent updates? | 11:38 |
| alf_ | tjaalton: ah, found it: http://git.debian.org/?p=pkg-xorg/lib/mesa.git | 11:39 |
| tjaalton | alf_: yeah that's it | 11:40 |
| tjaalton | just pushed the branch | 11:40 |
| === alan_g is now known as alan_g|lunch | ||
| === mzanetti is now known as mzanetti|run | ||
| alf_ | tjaalton: FYI, https://bugs.launchpad.net/mir/+bug/1465642, I will let you know when this change reaches wily, so you can remove the workaround | 12:10 |
| ubot5 | Launchpad bug 1465642 in Mir "mir-client-platform-mesa-dev package dependency is incorrect" [High,Triaged] | 12:10 |
| tjaalton | ok cool | 12:11 |
| === mzanetti|run is now known as mzanetti | ||
| === mibofra is now known as Guest38476 | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader_ is now known as dandrader | ||
| === pete-woods1 is now known as pete-woods | ||
| === Guest38476 is now known as mibofra | ||
| alan_g | alf_: was there any follow-up planned to your initial end-end test harness? I remember we discussed various options in Dallas... | 13:46 |
| alf_ | alan_g: I think the discussion was for the end-to-end latency tests (which I haven't made any progress on). | 13:48 |
| alan_g | alf_: yeah, that's what I was wondering about. We landed mir_privileged_tests didn't we? | 13:49 |
| alf_ | alan_g: Yes (and are enabled in CI). At the moment these only test that kernel input events reach clients, they don't perform any latency measurements/checks. | 13:52 |
| alan_g | alf_: OK. That's what I was wondering about. Thanks | 13:53 |
| alf_ | alan_g: When you get some time, could you please check that https://code.launchpad.net/~afrantzis/mir/fix-1465585-1465669-one-input-dispatcher-to-rule-them-all/+merge/262088 solves the VT issue for you. I was getting something but not sure if it is exactly what you bug was about. | 14:02 |
| alf_ | alan_g: "I was seeing something similar, but not sure..." | 14:03 |
| alan_g | alf_: ack. After I finish documenting the latest input bug I've found. | 14:05 |
| === chihchun_afk is now known as chihchun | ||
| alf_ | alan_g: Does purge-titlebars solve the same problem with GL you were referring to earlier today? | 14:09 |
| alan_g | alf_: yes | 14:09 |
| alf_ | alan_g: Great \o/ | 14:09 |
| alan_g | alf_: fixes 1465585 | 14:21 |
| alf_ | alan_g: thanks | 14:22 |
| alf_ | kdub: @allocate-and-release-buffers-protobuf, can the allocate_buffers() call allocate buffers independently of a buffer stream? | 14:24 |
| kdub | alf_, no | 14:24 |
| alf_ | kdub: ok, so 1. why is BufferStreamId optional and 2. why do we need to respecify buffer parameters, don't all buffers have the same parameters specified when creating the buffer stream? | 14:26 |
| kdub | its optional because optional fields were recommended somewhere on the protbuf site (bit hazy memory, but still abide by the advice) | 14:29 |
| kdub | I guess makes things easier to deprecate in the future | 14:29 |
| kdub | and for 2), I don't think we're having the constraint that all buffers have to be the same size | 14:30 |
| kdub | in the same stream | 14:30 |
| kdub | most the time they will... but I think for resize it might be helpful to have different sizes transiently | 14:31 |
| kdub | i have a sneaking suspicion that certain mm decoders might appreciate that too | 14:34 |
| alf_ | kdub: right, but I am not sure if we will need to explicitly allocate buffers of mixed sizes. We will get mixed sizes as we allocate buffers (of new size) and release buffers (of the old size). | 14:36 |
| kdub | alf_, I guess I'm imagining more of a client-cooperating resize | 14:42 |
| kdub | where they get a resize event informing it of its "ideal onscreen size" and it will allocate buffers (if it can) to fit that size, and start sending those | 14:42 |
| kdub | and release the old-sized buffers when the client is done with them | 14:43 |
| kdub | hence the side discussion about separating mg::Renderable::screen_position() from mg::Buffer::size() a bit more | 14:43 |
| kdub | side-discussion & card, I should say | 14:44 |
| alf_ | kdub: I don't get how the scenario you are resizing requires the client to _allocate_ buffers of mixed sizes (I agree that the buffer stream will end up having mixed sizes as the client allocates/releases) | 14:46 |
| kdub | well, if the client starts getting unrequested buffers as part of the server-initiated resize event, I guess it then has to free them | 14:47 |
| kdub | and, if the client is designating which of its many buffers to use, it can always just say 'use the badly-sized one' if it wants... the client has to cooperate with the resize, and letting it request buffers that it thinks are best seemed the way to go | 14:49 |
| alf_ | kdub: Perhaps I haven't made myself clear enough... I am not concerned about the client allocating custom sizes, I am doubting the usefulness of being able to allocate mixed sizes in a single call e.g. (100x100, 50x50, 10x10) vs (100x100,100x100,100x100) | 14:53 |
| alf_ | kdub: But the price we pay is small enough (and we are indeed a bit more versatile), so I guess I don't mind in the end | 14:53 |
| alf_ | kdub: primarily wanted to know if there was a scenario that absolutely needs this | 14:54 |
| alf_ | kdub: which I was missing | 14:54 |
| kdub | alf_, I started out with one buffer/call, but it seemed that some batching (esp for release) would just mean less ipc (in rev 2661 of the branch) | 14:54 |
| alf_ | kdub: I am OK with release, mostly concerned with allocate, but I am OK with that too :) | 14:55 |
| kdub | and right, I guess its just for versatility | 14:56 |
| kdub | I guess (and its stretching a bit) maybe a decoder might want a spare smaller p-frame hanging around, whereas it mostly allocates full-resolution buffers | 14:56 |
| kdub | anymore takers on: https://code.launchpad.net/~kdub/mir/multiple-bufferstream-api/+merge/261123 (otherwise will TA shortly) | 15:34 |
| alan_g | kdub: you have enough "Approve" by A* without me. ;) | 15:43 |
| kdub | :) the "A team" | 15:44 |
| === alan_g is now known as alan_g|EOD | ||
| === mibofra_ is now known as mibofra | ||
| AlbertA | @vogons: well looks like there are issues loading both libmirclient.so.8 and libmirclient.so.9 at the same time after fixing the protobuf issue... | 17:21 |
| AlbertA | no crashes, just can't get a connection.... | 17:21 |
| AlbertA | global var issues? | 17:22 |
| AlbertA | libmirclient.so.9 is loaded because the mesa client platform module links against it.... | 17:23 |
| AlbertA | but the ABI number of the modules themselves has not changed | 17:23 |
| kdub | groan | 17:27 |
| AlbertA | it seems the local scope from symbols.map is gone...hmmmm | 17:34 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| AlbertA | @vogons: so fixed the issue with the libmirclient symbols....it looks like using the protobuf xxx::default_instance().New() is enough to address the issue...so mir 0.13.3 is on | 19:45 |
| camako | AlbertA... great! | 19:48 |
| === mibofra is now known as Guest98396 | ||
| === Guest98396 is now known as mibofra | ||
| === chihchun is now known as chihchun_afk | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| kgunn | vogons anyone know about the race between mir and agetty ? | 22:49 |
| kgunn | i was wondering...if you lose the race, what's a way to undo the loss ? | 22:50 |
| kgunn | like can i just kill the agetty process ? | 22:51 |
| kgunn | or is there some other clean up or something that needs to happen ? | 22:51 |
| kgunn | ok, need to bail for a little... still post here, but email as well if i'm still off | 22:52 |
| AlbertA | kgunn: umm not quite sure...what's the issue? both starting at the same time and either agetty wins the vt or not? | 23:00 |
| AlbertA | kgunn: can it be in a different VT? | 23:00 |
| RAOF | Yay! I left this code in an uncompilable state, so there's an obvious entry point. | 23:45 |
| RAOF | Go me! | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!