| === JanC is now known as Guest19389 | ||
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | Urgh. | 04:17 |
|---|---|---|
| RAOF | I wish we didn't so systematically destroy our stacktraces at every opportunity. | 04:18 |
| RAOF | Admittedly it doesn't help that this is over distributed 2 processes. | 04:33 |
| RAOF | ??? | 05:03 |
| RAOF | OK, so tearing down and rebuilding the compositor is an integral part of applying nested's display configuration? | 05:04 |
| duflu | Exceptions. Love them or hate them | 05:04 |
| RAOF | Oh, maybe no it isn't. | 05:06 |
| RAOF | And it's just that this test relies on a side-effect of restarting the compositor to work. | 05:07 |
| RAOF | Aces! | 05:07 |
| duflu | Umm, Trump is about to win | 05:14 |
| RAOF | Yeah, less aces. | 05:48 |
| duflu | RAOF: Could you look at my latency testcase fixes? For some reason that's failing a lot today. | 06:04 |
| RAOF | Sure. | 06:05 |
| anpok | RAOF: hmm | 06:42 |
| RAOF | anpok: Yo? | 06:42 |
| anpok | I am looking at a similar spot.. | 06:42 |
| anpok | the nested platform reconfiguring the display configuration rather late on startup.. | 06:43 |
| anpok | such that the surface of the nested compositor gets occluded for some time | 06:43 |
| anpok | during stop/start in mediating display changer.. | 06:44 |
| anpok | especially in our tests where stub graphics is used.. | 06:44 |
| anpok | so no input events can get through.. until the compositors have run another time and have redrawn the surfaces of the nested server | 06:45 |
| anpok | we should make that more atomic | 06:45 |
| anpok | or refine the occlusion logic.. | 06:46 |
| RAOF | Hm. | 06:49 |
| RAOF | The nested platform's surfaces *aren't* occluded on startup, though. | 06:50 |
| RAOF | They just don't have any content, so they're not focused? | 06:50 |
| duflu | I would like to think we don't need occlusion testing in future. In the arbitrary compositor case where anything can be translucent, duplicated on multiple desktops, or shrunked to previews, occlusion simply never happens often enough for it to be a useful thing to test for or base logic on | 07:02 |
| duflu | *shrunken* | 07:02 |
| RAOF | I disagree; occlusion remains a super common case. Almost all of my windows spend almost all of their time occluded. | 07:03 |
| RAOF | The times where windows are *not* occluded are the outliers. | 07:04 |
| duflu | I think both points are valid. But occlusion testing needs to either be perfect or not present at all. Because faulty occlusion testing is a problem obviously, and a complex one at times | 07:04 |
| === chihchun is now known as chihchun_afk | ||
| anpok | RAOF: hm the order is host server starts.. nested server starts.. client connects to nested and posts.. then nested server surface posts.. (is visible then) .. the reconfiguration happens (maybe it was started earlier) .. now nested surface is occluded [meanwhile the tests start to send input events] .. | 07:25 |
| anpok | now after the configuration is done compositor in the host server start drawing.. now the nested surface is visible again | 07:26 |
| anpok | the configuration change is not atomic to the rest of the system | 07:26 |
| === chihchun_afk is now known as chihchun | ||
| alan_g | greyback: I did it for you. 8^) You could vote: https://code.launchpad.net/~alan-griffiths/qtmir/WindowControllerInterface-isVisible/+merge/310184 | 09:27 |
| greyback | alan_g: thank you | 09:31 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === hikiko is now known as hikiko|ln | ||
| alan_g | alf_: try this: https://code.launchpad.net/~alan-griffiths/miral/improved-tiling-wm/+merge/310421 | 12:23 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| === JanC_ is now known as JanC | ||
| RAOF | We really need to stop writing acceptance tests that rely on real time. | 23:02 |
| bschaefer | +1 | 23:07 |
| bschaefer | RAOF, rather we need to agree upon that :) | 23:07 |
| RAOF | Well, no. | 23:07 |
| bschaefer | hmm well if someone doesnt agree with that, and still pushes real time tests | 23:08 |
| bschaefer | then we'll still have that issue? | 23:08 |
| RAOF | What we need to do is have someone stick a faketime wrapper around our existing tests and then reject any branch that adds real time tests. | 23:08 |
| bschaefer | that sounds better | 23:08 |
| anpok | RAOF: i am off already - what do you think about moving the location of the display buffer out of the graphcis platform - and thus being able to preserve the buffer when the display is reconfigured? | 23:13 |
| anpok | or actually moving that information out of the buffer might not be necessary.. | 23:13 |
| RAOF | anpok: Reconfiguring the display will, in general, require that the display buffer be invalidated. | 23:14 |
| anpok | at least it seems as if it should not be there. | 23:14 |
| anpok | RAOF: hm thats kind of fine.. but | 23:14 |
| RAOF | Now, a bunch of display configuration does *not* require the display to be reconfigured, true. | 23:14 |
| anpok | that currently mean that compositor threads are reconstructed | 23:14 |
| anpok | *means | 23:15 |
| anpok | which means that compositors come and go... | 23:15 |
| RAOF | But I think the graphics platform is really the only place where you can tell what sort of configuration changes invalidate the DBs. | 23:15 |
| anpok | and produce unnecessary notifications | 23:15 |
| RAOF | So, the branches that have landed (for android and kms) and are landing (for nested) reduce this quite a lot, and can be improved to invalidate the DBs even less often. | 23:17 |
| RAOF | But, in general, if you've got one thread per display buffer, a display configuration change may require compositor threads to be killed or started. | 23:17 |
| anpok | ok .. too tired. I am concerned that our reconfigurations are not processed as a single transaction in mir.. So from one perspective want to avoid the problematic cases.. and from the other perspective fix the way the configuration is applied | 23:17 |
| Pharaoh_Atem | hey, do you guys do any testing of your pkg-config files to make sure they are fully defined? | 23:18 |
| anpok | Pharaoh_Atem: probably not enough | 23:19 |
| RAOF | Hm. By ‘single transaction’ do you mean ‘Hey, shell, I'm going to be changing the configuration, so could you please do a composition pass to these new buffers before I do the switch’? | 23:19 |
| Pharaoh_Atem | anpok: I was asking because I was unable to build something to depend on mir because mir's own pc files don't declare what pkg-config modules they depend on | 23:20 |
| anpok | RAOF: not quite there are many internal bits.. that should wait until the switch is done | 23:20 |
| Pharaoh_Atem | so it didn't pull in things automatically | 23:20 |
| RAOF | Pharaoh_Atem: We *do* use those pkg-config files in all of the Mir downstreams, so we should notice any really glaring lacks. What was missing? | 23:21 |
| RAOF | (At least for releases; we don't necessarily notice when lp:mir is wrong) | 23:21 |
| Pharaoh_Atem | well, I'm using mir 0.24.1 | 23:21 |
| RAOF | And what was missing? | 23:23 |
| Pharaoh_Atem | one sec | 23:23 |
| anpok | RAOF: i found display reconf to be the main source of unexpected misbeheavior on startup | 23:24 |
| anpok | in our acceptance tests.. | 23:25 |
| RAOF | This does not surprise me terribly. | 23:25 |
| anpok | with that closing thought.. -> off | 23:25 |
| anpok | :) | 23:25 |
| bschaefer | anpok, byes! | 23:25 |
| RAOF | *Particularly* for nested. | 23:25 |
| RAOF | anpok: Sleep well! | 23:25 |
| anpok | RAOF: thats why there is now a preserve dbs in stub graphics MP | 23:25 |
| bschaefer | RAOF, ill have to poke you after this release about apply config :) | 23:25 |
| bschaefer | i suppose it'll just copy the old API? | 23:26 |
| anpok | that only helps in the trivial cases | 23:26 |
| bschaefer | eww cc1plus: error: invalid argument ‘/build/mir’ to -fdebug-prefix-map | 23:27 |
| RAOF | Race race race your build...! | 23:28 |
| bschaefer | haha... sadly this is for CI soo restart... | 23:28 |
| * Pharaoh_Atem is rebuilding the libinput->mir->mesa chain | 23:28 | |
| Pharaoh_Atem | RAOF: https://paste.fedoraproject.org/469496/47817680/ | 23:31 |
| Pharaoh_Atem | seems like xkbcommon wasn't defined as a Requires for mirclient | 23:32 |
| RAOF | Pharaoh_Atem: Quite true. | 23:33 |
| bschaefer | huh why dont we have that as a depends? | 23:33 |
| * bschaefer has made this assumption | 23:34 | |
| RAOF | We presumably missed that because all of our downstreams link it explicitly. | 23:34 |
| Pharaoh_Atem | that, and also you guys don't have dependency generation from pkg-config files | 23:34 |
| bschaefer | RAOF, yeah ive had to manually link with it | 23:34 |
| bschaefer | RAOF, hmm libmirclient-dev pulls in libmircommon-dev which should pull xkb? | 23:35 |
| bschaefer | (not sure about the pkg file) | 23:35 |
| Pharaoh_Atem | it does on Ubuntu, because those are manually specified | 23:35 |
| RAOF | Right; we're missing a Requires.private there. | 23:37 |
| Pharaoh_Atem | mmhmm | 23:37 |
| Pharaoh_Atem | I suspect there's more, but that was the first issue | 23:37 |
| RAOF | Quite plausibly. This is indeed not something we use. | 23:37 |
| RAOF | Fedora packaging autogenerates build-dependencies by scanning pkg-config? | 23:38 |
| Pharaoh_Atem | yes | 23:38 |
| Pharaoh_Atem | well, no | 23:38 |
| Pharaoh_Atem | that would be cool and awesome, but tricky | 23:38 |
| RAOF | But there's a tool that will populate your control files based on pkg-config that you'll need to edit? | 23:38 |
| Pharaoh_Atem | yep | 23:39 |
| Pharaoh_Atem | no | 23:39 |
| Pharaoh_Atem | it's an addendum | 23:39 |
| Pharaoh_Atem | generated at build time | 23:39 |
| Pharaoh_Atem | https://copr-be.cloud.fedoraproject.org/results/ngompa/Mir/fedora-24-x86_64/00472459-mir/build.log.gz | 23:39 |
| Pharaoh_Atem | at the end of the log, you see all the generated install-time dependencies | 23:40 |
| Pharaoh_Atem | My spec is nowhere near as defined: http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/Mir/mir.git/tree/mir.spec | 23:40 |
| RAOF | Ah. You generate the dependencies for foo-dev from the pkg-config files? | 23:40 |
| Pharaoh_Atem | yep | 23:41 |
| Pharaoh_Atem | deps are generated from scanning the files (binaries, libraries, dist/egg-info data, pc files, etc.) | 23:41 |
| Pharaoh_Atem | for example, instead of using libxkbcommon-devel, I could have used pkgconfig(xkbcommon) as my BuildRequires for that library devel package | 23:42 |
| RAOF | Well, I've added the xkbcommon to the relevant pkg-config file in trunk; you're right, though, it's moderately likely that this isn't the only missing link in pkg-config, as we basically don't use pkg-config that way. | 23:45 |
| Pharaoh_Atem | which is somewhat ironic, given that Debian was the creator and maintainer of modern pkg-config :/ | 23:46 |
| Pharaoh_Atem | not one of the Debian packaging systems supports parsing and exploiting pkg-config for these things | 23:47 |
| Pharaoh_Atem | (i.e. classic debhelper, cdbs, dh) | 23:47 |
| RAOF | Hm. Having a look through our #includes, I think this is actually the only one we miss. | 23:47 |
| RAOF | Yeah :) | 23:48 |
| bschaefer | well i can approve w/e its up :) | 23:48 |
| RAOF | ...it actually wouldn't be terribly hard to write a dh_pkgconfigdeps helper that extracted the relevant info and put it into ${depends:PkgConfig}... | 23:50 |
| Pharaoh_Atem | then you'd need ${Provides:PkgConfig} too | 23:50 |
| Pharaoh_Atem | you need a standard form of representation | 23:50 |
| Pharaoh_Atem | which thankfully, you guys can do now, since apt now supports version-release in virtual Provides | 23:50 |
| Pharaoh_Atem | err EVR | 23:50 |
| Pharaoh_Atem | see, I keep up with what you guys are doing on the other side of the fence ;) | 23:51 |
| RAOF | No, I don't think so. You'd just look up the -dev package providing the relevant pkg-config file. | 23:51 |
| Pharaoh_Atem | RAOF: that's way more expensive though | 23:51 |
| RAOF | Absolutely! But it's build-time expensive, which is cheap. | 23:51 |
| RAOF | :) | 23:51 |
| Pharaoh_Atem | >_> | 23:51 |
| * Pharaoh_Atem shrugs | 23:51 | |
| Pharaoh_Atem | I guess | 23:51 |
| Pharaoh_Atem | you already do this for library deps, to some extent | 23:52 |
| Pharaoh_Atem | so why not, eh? | 23:52 |
| RAOF | To a huge extent, yes. | 23:52 |
| Pharaoh_Atem | well, I say some extent, because a large segment of Debian packages opt to not do so | 23:52 |
| Pharaoh_Atem | and manually specify everything (which is insane!) | 23:52 |
| RAOF | bschaefer: https://code.launchpad.net/~raof/mir/missing-pkgconfig-requires/+merge/310497 | 23:53 |
| RAOF | Certainly for things which *aren't* shared libraries we don't have nearly the same sort of tracking. | 23:54 |
| bschaefer | nice | 23:54 |
| RAOF | But I can't think offhand of a single package I've touched which has manual dependencies on a shared library package. | 23:54 |
| RAOF | (Python and other things which aren't ELF DSOs, very much yes) | 23:54 |
| Pharaoh_Atem | I can't either, but then again, I try not to make Debian packages my reference for packaging very often | 23:55 |
| Pharaoh_Atem | too much stuff everywhere and difficult to parse most of the time | 23:55 |
| RAOF | Yeah, I feel fairly similar reading .spec files :) | 23:56 |
| Pharaoh_Atem | eh, spec files can be clean (and usually are most of the time) | 23:56 |
| Pharaoh_Atem | but some really old ones are nuts | 23:56 |
| RAOF | Likewise Debian packaging :) | 23:57 |
| RAOF | Although spread over multiple files. | 23:58 |
| Pharaoh_Atem | I immensely dislike touching libguestfs packaging | 23:58 |
| Pharaoh_Atem | CDBS is way too confusing | 23:58 |
| * Pharaoh_Atem has to do that from time to time at work | 23:58 | |
| RAOF | Yeah, also very much old. | 23:58 |
| RAOF | CDBS is from the dark ages before debhelper was sufficiently helpful. | 23:58 |
| Pharaoh_Atem | now my only problem with debian packaging is that the really modern stuff doesn't tell you what it's doing | 23:59 |
| Pharaoh_Atem | it's hard to figure out how it figures out things | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!