[08:09] <duflu> anpok_: I'm inspired now. Going to try attacking the cursor freezes with some real-time profiling
[08:15] <duflu> anpok_: Umm... the bug isn't happening for me any more (!?)
[08:31] <alan_g> bugs that bite and run away live to bite another day
[10:01] <anpok_> duflu: I do see pauses in traces .. combined with batching those pauses get larger..
[10:02] <anpok_> it seems as if the multiplexing dispatchable driving the input thread is not woken up..
[10:02] <duflu> anpok_: Sure yes in traces. But I can't "see" it any more
[13:23] <zzarr> just a quick question does Mir work with any MESA driver?
[13:26] <anpok_> zzarr: there are two groups of mesa drivers
[13:26] <anpok_> those that are gallium based and the original mesa drivers
[13:26] <anpok_> from the second set .. I only have seen people use the intel mesa drivers..
[13:27] <anpok_> this is relevant because we rely on the capability to import dmabuf fds
[13:28] <anpok_> intel originally hat bugs in that area.. because mir was more or less the main user of that feature
[13:28] <zzarr> so it would not work with a MESA driver for an ARM based SoC?
[13:28] <alan_g> zzarr: no. there's some Mir support patches needed. So you need the Ubuntu version or to pick up the patches another way.
[13:28] <anpok_> all mesa drivers for arm socs are gallium based
[13:29] <zzarr> okey
[13:29] <anpok_> so it should work.. with ubuntu patches for mesa.
[13:29] <alan_g> There's a link in my latest "voices" post
[13:29] <zzarr> will Mir support Gallium based MESA drivers in the future?
[13:30] <zzarr> ohh, it could work now with patches?
[13:30] <alan_g> The intention is to rework and upstream the patches. But we can't promise a timeline.
[13:30] <anpok_> zzarr: gallium based drivers work fine..
[13:31] <anpok_> no patches requires in the gallium drivers iirc .. we only have to add code to integrate with egl
[13:31] <alan_g> http://voices.canonical.com/alan.griffiths/ - look for "enabling Mir EGL"
[13:32] <zzarr> If I understood correctly... Mir works with the Gallium based MESA driver if patched
[13:32] <anpok_> yes
[13:32] <anpok_> zzarr: based on your original question I extrapolated a more exotic hardware
[13:34] <zzarr> thanks, that's great
[14:06] <greyback> alan_g: hey, I'm in a situation where for every miral::Window, I need to associate a PersistentId from StubPersistentSurfaceStore - do you think the persistentId makes sense to add to miral::WindowInfo?
[14:09] <greyback> it might be handy for a window manager to use it to identify a surface to give it special behaviour
[14:09] <alan_g> greyback: what is it needed for? The usecase that we knew about is covered by WindowManagerTools::info_for_window_id
[14:10] <alan_g> Nobody had a usecase where the WM wanted to get an ID from a surface
[14:13] <greyback> alan_g: use-case is dbus-menus, and is more shell-specific. https://code.launchpad.net/~unity-team/qtmir/persistent_surface_id/+merge/303580 is giving each surface a persistentId, that it uses as unique identifier to find its dbus-menus
[14:13] <greyback> this is my implementation so far: lp:~gerboland/miral/qtmir-555
[14:14] <greyback> which is neater, it associates a persistentId to the surface as soon as possible, and passes it along with the other WindowInfo
[14:15] <greyback> see "qtmir::NewWindowInfo"
[14:17] <alan_g> I'm reluctant to impose "every surface has an ID" because one user finds it convenient.
[14:18]  * alan_g wishes for more downstreams that will fight each other over features
[14:18] <greyback> :)
[14:19] <greyback> I don't have a strong opinion on it
[14:20] <greyback> I just made my implementation, and noticed the proposal might clean it up a little more
[14:22] <alan_g> I still wonder if this is a problem persistent IDs are meant to solve. I mean, no-one has created a *persistent* store of them, and this seems like an unintended usage.
[14:24] <greyback> alan_g: I agree it is incorrect usage if the classes was indeed persistent, but it's not, in which case it is doing what is needed
[14:25] <alan_g> greyback: do you think dbus menus should be directly supported in miral?
[14:25] <greyback> alan_g: nope
[14:25] <alan_g> Wouldn't other shells also want them?
[14:26] <greyback> they might, and they might not. I cannot predict that
[14:28] <greyback> as you say, having a single downstream doesn't make it easy to identify features miral should support
[14:31] <alan_g> I just think runner.run_with(DbusMenus{}) would make exposing "persistent" IDs irrelevent.
[14:32] <kdub> hmm, we could fix http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/include/common/mir_toolkit/mir_native_buffer.h#L51 with the mir_buffer.h api
[14:33] <greyback> alan_g: dbus menus are the only reason 'persistent'IDs are being used. But I am not familar enough with dbus menus to know what features they provide, so I don't know how complex that task would be
[14:33] <greyback> dednick would be the man to ask, but he's on holidays for 1.5 weeks
[14:33] <alan_g> For the moment I think WindowManagerTools::id_for_window() is less intrusive
[14:33] <greyback> agreed
[14:34] <alan_g> miral::DbusMenus only needs to support an abstraction over what you're wiring up
[14:35] <alan_g> And previous discussions have all said its the only "de-facto standard" around
[23:18] <RAOF> FWIW, I think PersistentSurfaceIDs are perfectly fine to use as our default cross-process-capable surface identifiers.