[00:04] Why hello, odd bug. [00:05] Why isn't disconnect() being responded to? [00:07] Oh, goodie. It's somehow a race? [00:11] AAAaaaah. [00:13] It's a race between mir_render_surface_release and mir_connection_release. [01:27] Hm. [01:27] Why do we ignore logical_width and logical_height for bufferstreams in mir_surface_spec_add_render_surface? [01:27] * duflu shrugs [01:29] Ah. [01:29] The reason why the tests don't *currently* deadlock in that race is because they race allocate_buffer instead. [01:39] RAOF: I think I'm overallocated for features this cycle. Do you want to take one of my major items off my hands? [01:39] duflu: Whatta ya got? [01:40] (fbdev + osmesa || SimpleDRM kernel work) [01:40] The first one is just a Mir driver [01:46] The second one is driving an already roughly-agreed-to patch through lkml. [01:49] Indeed, but it's been driving for a few years [01:49] Not sure how long to wait [01:49] Perhaps if we do nothing the feature will exist :) [01:50] Patch set v5 got submitted by a drm guy in September. [01:50] To me fbdev would be fun to learn driver development. And it would work on any kernel... assuming osmesa works [01:50] But that's just me [01:51] Why would fbdev involve learning driver development? [01:52] RAOF: Mir driver development [01:52] Ah, right. [01:53] I know the basics... I was building something similar back in the early 90s before I got distracted [01:56] RAOF: I just figured you know all the parts. If we were to build a fallback driver to solve all the fallback problems before 17.04 you would be able to do it [01:57] And working in any VM out of the box would be awesome [01:58] It's assigned to me, but before then I need to finish client-side vsync and probably now do GL-based display cloning [01:58] So there's a reasonable risk I won't have all three features done before 17.04 [01:59] Seems reasonable. [01:59] I'll see where SimpleDRM is at. [01:59] Because if it's done, that's the cheapest option :) [02:05] And, indeed, looks like simpledrm has landed. [02:11] Not in Linus' tree. Which one comes before that for DRM work? [02:12] In whatever tree all the patches to drm-devel are applied to. [02:12] I'm actually not sure what tree that is. [02:14] You always need to know who the second in command is, per component [02:14] The kernel docs say who [02:18] Yeah, it's drm-misc. I thought so. [02:18] Can't see it in there, though. [02:20] Which is odd, because I see unrelated patches that patch simpledrm. === chihchun is now known as chihchun_afk [03:36] Hey, cool! rr will now record mir_acceptance_tests! [03:43] And I thought Unix already took all the two letter names === chihchun_afk is now known as chihchun === andyrock_ is now known as andyrock === Trevinho_ is now known as Trevinho [06:04] RAOF: Is it intentional or incidental that streams use SurfaceIDs and SurfaceObservers? [06:04] Incidental, mostly. [06:04] Oh I see. We started with just surface and it morphed incrementally into streams [06:05] For the former, it might have made sense to have just a single “object ID” namespace. [06:05] For the latter, SurfaceObserver basically makes sense with Streams, too. :) [06:05] Indeed === JanC_ is now known as JanC === sil2100_ is now known as sil2100 === hikiko is now known as hikiko|ln === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === hikiko|ln is now known as hikiko === dandrader is now known as dandrader|afk === marcusto_ is now known as marcustomlinson === dandrader|afk is now known as dandrader === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [17:44] Greetings : ) Is this the right place to ask about mir_android_diagnostic testing and failures? [17:58] applemuncy_1: yep