[02:03] <duflu> RAOF: 'make test' is now very terse. Is that what the fans want?
[02:04] <RAOF> “make test” has been very terse where it matters for *ages*
[02:04] <RAOF> The fans want make ptest, anyway.
[02:05] <duflu> RAOF: Like 20 lines terse?
[02:05] <RAOF> duflu: Indeed, like 20 lines terse.
[02:05] <RAOF> You only get interesting output on CI because we pass ARGS=-V to make test.
[02:05] <duflu> 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] <RAOF> duflu: Anyway, would MirReference rather than MirSurfaceId satisfy your nomenclature concerns?
[02:07] <duflu> RAOF: Sure, but don't ask mako to. It might asplode
[02:07] <RAOF> Libtypo??
[02:08] <duflu> RAOF: "MirReference" was a worse name. "Signature" or "Fingerprint" would be OK. I prefer "Signature"
[02:08] <duflu> 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] <RAOF> And characters are a precious resource, so “typography” was rejected? :P
[02:09] <duflu> RAOF: Yes, we are programmers, humans and Australians. All three prefer shorter names
[02:10] <RAOF> I dislike both Signature and Fingerprint. Neither of those tell me that I can use it to refer to a specific object.
[02:10] <RAOF> Both Signature and Fingerprint sound like verification mechanisms rather than reference mechanisms.
[02:10] <duflu> RAOF: "Reference" is too overloaded in programming circles. Best to not re-overload that word
[02:11] <RAOF> I... disagree.
[02:11] <RAOF> I think that the common use of Reference exactly describes what a MirReference is.
[02:12] <duflu> RAOF: In the English sense yes. But in the programming sense existing meanings of "Reference" take precedence
[02:12] <duflu> And there are already too many
[02:12] <RAOF> I think that this *is* the programming meaning of Reference.

[02:13] <duflu> 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] <duflu> To this list of nouns
[10:01] <duflu> Hmm it's becoming a little too easy to crash the drm kernel module in vivid
[10:02] <duflu> But since it's 6pm that tells me to give up for now
[10:03] <anpok> oh yes
[10:03] <anpok> 4.1 is not much better
[10:03] <duflu> 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] <duflu> This might be an entirely new bug
[10:07] <anpok> just had an interesting i915 kernel message and after that just one core left .. or 1/8 of the processing power
[10:27] <alf_> anpok: Are you using a custom kernel with vivid (4.x)?
[10:27] <alf_> anpok: I see vivid has 3.19.x by default
[10:28] <anpok> yes
[10:28] <anpok> hm cannot remember what made me switch to 4.0
[10:29] <anpok> but with 4.0 i915 crashes as soon as we do the vt switch
[10:29] <anpok> 4.1 fixes that
[10:31] <anpok> maybe i have to go backwards to solve those troubles
[10:31] <anpok> alf_: i am using the kernel from the mainline kernel ppa
[10:32] <alf_> anpok: ok
[12:47] <alf_> 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] <alf_> anpok: or are there asynchronous operations taking place
[13:28] <anpok> alf_: nope
[13:28] <anpok> start does not wait unti the thread is started
[13:29] <anpok> so the first thing that happens after start() completes is a device scan..
[13:30] <alf_> anpok: is it feasible to change the code to provide that guarantee?
[13:31] <anpok> hm yes you basically could have a promise.set_value right after the legacy_dispatchable->dispatch..
[13:31] <anpok> within ::starT()
[13:31] <anpok> which is the first device scan
[13:32] <anpok> alf_: but I am not sure how long that take.. is there a problem?
[13:36] <alf_> 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] <anpok> hm but instead of blocking we could do something different..
[13:38] <anpok> send some .. trigger back to main_loop..
[13:39] <anpok> so that the compositors and input may start in parallel..
[14:00] <alf_> 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] <anpok> right
[14:39] <anpok> alf_: hmm will you make an mp for that?
[14:40] <anpok> i just realized that I will run into that in the next fixture I wanted to update
[14:41] <alf_> anpok: I was planning to start working on these tasks... do you have any concerns?
[14:41] <anpok> no I am kind of cleanin up the test fixtures .. cleaning out fake_event_hub..
[14:44] <anpok> alf_: no concerns, just wasnt sure if you would do it.. or expect someone to do it :)
[15:11] <alf_> kdub: "the document" refers to a proposal about the power-management architecture (powerd etc)
[15:11] <kdub> ah, yes thanks