robert_ancell | Was any Mir API reverted from vivid? I'm trying to work out how XMir compiled using mir_buffer_stream_release_sync but libmirclient-dev doesn't contain this (trunk does) | 04:39 |
---|---|---|
RAOF | I don't think mir_buffer_stream made it into vivid? | 04:43 |
RAOF | robert_ancell: Yeah, Maarten was developing against trunk, not vivid. | 04:44 |
robert_ancell | RAOF, but the PPA built somehow and it doesn't contain a newer version of Mir. So I guess he had a newer version of Mir at some point in there?! | 04:44 |
RAOF | robert_ancell: Maybe? That PPA doesn't have a dependency on one of the Mir landing PPAs, does it? | 04:45 |
robert_ancell | RAOF, oh, where would show that? | 04:45 |
RAOF | What's the PPA address? | 04:45 |
robert_ancell | https://launchpad.net/~mlankhorst/+archive/ubuntu/ppa | 04:46 |
robert_ancell | I can't see any dependency there | 04:46 |
RAOF | robert_ancell: Looks like the mir_buffer_stream calls are conditionally built. | 04:50 |
RAOF | robert_ancell: So the PPA would have built without cursor change support. | 04:50 |
robert_ancell | RAOF, but the condition only checks the existence of mir_toolkit/mir_buffer_stream.h, it doesn't know it doesn't have the API | 04:51 |
robert_ancell | I'm rebuilding it here (with debugging symbols) and it's failing to build | 04:51 |
RAOF | robert_ancell: I see it #ifdef based on MIR_TOOLKIT_MIR_BUFFER_STREAM_H_? | 04:52 |
robert_ancell | RAOF, yes. And that is defined in the vivid header | 04:53 |
RAOF | Really? | 04:53 |
robert_ancell | grep MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h | 04:53 |
robert_ancell | #ifndef MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ | 04:53 |
robert_ancell | #define MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ | 04:53 |
robert_ancell | #endif // MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ | 04:53 |
RAOF | You have a locally installed mir_buffer_stream.h | 04:54 |
robert_ancell | ? | 04:54 |
RAOF | /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h is *not* in the vivid libmirclient-dev | 04:54 |
robert_ancell | Oh. I have silo0 installed. It must have come in with that. | 04:56 |
robert_ancell | That explains things... | 04:56 |
duflu | Wow, bypass can hold buffers almost two frames. That should not be surprising as it is | 06:24 |
=== mibofra is now known as Guest60005 | ||
=== Guest60005 is now known as mibofra | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
anpok_ | alf_: why do you use a weak_ptr to the promise in ::start? | 14:30 |
alf_ | anpok_: I want to ensure that after we leave start() (i.e. the promise value has been set by the enqueued action), any exceptions will not try to set_exception() on it | 14:34 |
alf_ | anpok_: it's invalid to try to set the value/exception of a promise twice and there is no direct way to check if the promise is set | 14:35 |
anpok_ | ah now i see that | 14:35 |
alf_ | anpok_: so I resorted to this | 14:35 |
* racarr yawns | 14:37 | |
racarr | Good morning | 14:37 |
mibofra | oh hi racarr :D | 14:39 |
alan_g | anpok_: racarr - guys, can you think of anything changed in input for 0.13 that might explain AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping failing in the silo build? https://launchpadlibrarian.net/205655685/buildlog_ubuntu-vivid-armhf.mir_0.13.0%2B15.04.20150505.1-0ubuntu1_BUILDING.txt.gz | 14:50 |
racarr | alan_g: No. that test is actually relatively isolated iirc | 14:54 |
racarr | e.g. really depends just on a few classes | 14:55 |
racarr | my guess is its really just a race/slowness | 14:55 |
alan_g | racarr: The odd thing is that the failing line is EXPECT_GT(duration, 1ms); - which I wouldn't expect slowness to trigger | 14:56 |
alan_g | Or am I reading it wrong? | 14:57 |
racarr | alan_g: It looks like what it depends on | 15:01 |
racarr | alan_g: Is that the motion event, wont be reported when things are made dispatchable at | 15:01 |
racarr | l265 | 15:01 |
racarr | because its too new so it stays batched | 15:01 |
racarr | so the difference between start and is > 1 ms | 15:01 |
racarr | because we | 15:01 |
racarr | slept for some amount of tiome | 15:01 |
racarr | waiting for an event to become ready | 15:02 |
racarr | however if "auto start = high_resolution_clock::now()" | 15:02 |
racarr | well if we get there too late | 15:02 |
racarr | then the motion obviously wont be too new right | 15:02 |
racarr | and it has to do with the | 15:02 |
racarr | static time stuff in the input receiver | 15:02 |
alan_g | Yeah, the whole premise is dubious | 15:02 |
racarr | and is like 15-16ms or something | 15:02 |
racarr | I | 15:02 |
racarr | am a long standing proponent that this test doesn't make sense :p | 15:03 |
racarr | um | 15:03 |
racarr | woops standup | 15:03 |
alan_g | I'll join you on that | 15:03 |
alf_ | racarr: BTW, we should be using steady_clock not high_resolution_clock | 15:04 |
alan_g | that's the least of the problems | 15:05 |
racarr | camako: If you cant use non x input on non x graphics then maybe just them being in the same library is a good solution | 15:16 |
alf_ | alan_g: Well, a few years ago this led to a week of frustrating debugging because the device used in CI changed the clock during start-up. Not saying it's the same here, but there is no reason to risk going through this again :) | 15:17 |
=== dandrader is now known as dandrader|lunch | ||
=== marcusto_ is now known as marcustomlinson | ||
=== dandrader|lunch is now known as dandrader | ||
=== alan_g is now known as alan_g|EOD | ||
racarr | I made you guys some mps | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!