[02:03] RAOF: 'make test' is now very terse. Is that what the fans want? [02:04] “make test” has been very terse where it matters for *ages* [02:04] The fans want make ptest, anyway. [02:05] RAOF: Like 20 lines terse? [02:05] duflu: Indeed, like 20 lines terse. [02:05] You only get interesting output on CI because we pass ARGS=-V to make test. [02:05] Meh, it was never a useful level of zoom anyway [02:06] * RAOF would prefer to have parallel tests *always* run, because that means parallel failures will largely be caught in CI, but that's apparently difficult. [02:07] duflu: Anyway, would MirReference rather than MirSurfaceId satisfy your nomenclature concerns? [02:07] RAOF: Sure, but don't ask mako to. It might asplode [02:07] Libtypo?? [02:08] RAOF: "MirReference" was a worse name. "Signature" or "Fingerprint" would be OK. I prefer "Signature" [02:08] RAOF: libtypo was called "gltext" during its development. Then at the last minute I found such a thing already existed and would be quite confusing so renamed [02:09] And characters are a precious resource, so “typography” was rejected? :P [02:09] RAOF: Yes, we are programmers, humans and Australians. All three prefer shorter names [02:10] I dislike both Signature and Fingerprint. Neither of those tell me that I can use it to refer to a specific object. [02:10] Both Signature and Fingerprint sound like verification mechanisms rather than reference mechanisms. [02:10] RAOF: "Reference" is too overloaded in programming circles. Best to not re-overload that word [02:11] I... disagree. [02:11] I think that the common use of Reference exactly describes what a MirReference is. [02:12] RAOF: In the English sense yes. But in the programming sense existing meanings of "Reference" take precedence [02:12] And there are already too many [02:12] I think that this *is* the programming meaning of Reference. [02:13] [02:13] RAOF: Well I don't want this to become yet another case of "please rename" resulting in a worse outcome than where we started so stay on MirSurfaceId till a better word is conceived I guess [02:14] To this list of nouns === chihchun_afk is now known as chihchun [10:01] Hmm it's becoming a little too easy to crash the drm kernel module in vivid [10:02] But since it's 6pm that tells me to give up for now [10:03] oh yes [10:03] 4.1 is not much better [10:03] alf_: Fun fact: I just noticed buffers_sent_to_compositor can contain a buffer multiple times even in a single compositor environment. So if the client misses a frame deadline, that amplifies and makes it even less likely we'll return to the client in time [10:04] This might be an entirely new bug [10:07] just had an interesting i915 kernel message and after that just one core left .. or 1/8 of the processing power [10:27] anpok: Are you using a custom kernel with vivid (4.x)? [10:27] anpok: I see vivid has 3.19.x by default [10:28] yes [10:28] hm cannot remember what made me switch to 4.0 [10:29] but with 4.0 i915 crashes as soon as we do the vt switch [10:29] 4.1 fixes that [10:31] maybe i have to go backwards to solve those troubles [10:31] alf_: i am using the kernel from the mainline kernel ppa [10:32] anpok: ok [12:47] anpok: After calling input_manager->start() and input_dispatcher->start() is there a guarantee that the input subsystem is 100% up and running? [12:48] anpok: or are there asynchronous operations taking place [13:28] alf_: nope [13:28] start does not wait unti the thread is started [13:29] so the first thing that happens after start() completes is a device scan.. [13:30] anpok: is it feasible to change the code to provide that guarantee? [13:31] hm yes you basically could have a promise.set_value right after the legacy_dispatchable->dispatch.. [13:31] within ::starT() [13:31] which is the first device scan [13:32] alf_: but I am not sure how long that take.. is there a problem? [13:36] anpok: The problem is that there is no way to tell when the server has *really* started. It's mostly a problem for tests (e.g. the end-to-end input tests I am looking into) at the moment, but even for production it would be nice to guarantee that when the socket appears the server is 100% up and running. [13:38] hm but instead of blocking we could do something different.. [13:38] send some .. trigger back to main_loop.. [13:39] so that the compositors and input may start in parallel.. [14:00] anpok: At the moment, the compositor starts first and blocks until its threads are up and running. We could return an std::future<> from both compositor->start() and input*->start() and allow them to start up in parallel if needed. [14:01] right [14:39] alf_: hmm will you make an mp for that? [14:40] i just realized that I will run into that in the next fixture I wanted to update [14:41] anpok: I was planning to start working on these tasks... do you have any concerns? [14:41] no I am kind of cleanin up the test fixtures .. cleaning out fake_event_hub.. [14:44] alf_: no concerns, just wasnt sure if you would do it.. or expect someone to do it :) [15:11] kdub: "the document" refers to a proposal about the power-management architecture (powerd etc) [15:11] ah, yes thanks === mhall119 is now known as mhall119|afk === Guest50796 is now known as mibofra === mhall119|afk is now known as mhall119