/srv/irclogs.ubuntu.com/2016/09/07/#ubuntu-mir.txt

=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
dufluanpok_: I'm inspired now. Going to try attacking the cursor freezes with some real-time profiling08:09
dufluanpok_: Umm... the bug isn't happening for me any more (!?)08:15
alan_gbugs that bite and run away live to bite another day08:31
=== hikiko is now known as hikiko|ln
anpok_duflu: I do see pauses in traces .. combined with batching those pauses get larger..10:01
anpok_it seems as if the multiplexing dispatchable driving the input thread is not woken up..10:02
dufluanpok_: Sure yes in traces. But I can't "see" it any more10:02
=== hikiko|ln is now known as hikiko
zzarrjust a quick question does Mir work with any MESA driver?13:23
anpok_zzarr: there are two groups of mesa drivers13:26
anpok_those that are gallium based and the original mesa drivers13:26
anpok_from the second set .. I only have seen people use the intel mesa drivers..13:26
anpok_this is relevant because we rely on the capability to import dmabuf fds13:27
anpok_intel originally hat bugs in that area.. because mir was more or less the main user of that feature13:28
zzarrso it would not work with a MESA driver for an ARM based SoC?13:28
alan_gzzarr: 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 based13:28
zzarrokey13:29
anpok_so it should work.. with ubuntu patches for mesa.13:29
alan_gThere's a link in my latest "voices" post13:29
zzarrwill Mir support Gallium based MESA drivers in the future?13:29
zzarrohh, it could work now with patches?13:30
alan_gThe 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:30
anpok_no patches requires in the gallium drivers iirc .. we only have to add code to integrate with egl13:31
alan_ghttp://voices.canonical.com/alan.griffiths/ - look for "enabling Mir EGL"13:31
zzarrIf I understood correctly... Mir works with the Gallium based MESA driver if patched13:32
anpok_yes13:32
anpok_zzarr: based on your original question I extrapolated a more exotic hardware13:32
zzarrthanks, that's great13:34
greybackalan_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:06
greybackit might be handy for a window manager to use it to identify a surface to give it special behaviour14:09
alan_ggreyback: what is it needed for? The usecase that we knew about is covered by WindowManagerTools::info_for_window_id14:09
alan_gNobody had a usecase where the WM wanted to get an ID from a surface14:10
greybackalan_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-menus14:13
greybackthis is my implementation so far: lp:~gerboland/miral/qtmir-55514:13
greybackwhich is neater, it associates a persistentId to the surface as soon as possible, and passes it along with the other WindowInfo14:14
greybacksee "qtmir::NewWindowInfo"14:15
alan_gI'm reluctant to impose "every surface has an ID" because one user finds it convenient.14:17
* alan_g wishes for more downstreams that will fight each other over features14:18
greyback:)14:18
greybackI don't have a strong opinion on it14:19
greybackI just made my implementation, and noticed the proposal might clean it up a little more14:20
alan_gI 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:22
greybackalan_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 needed14:24
alan_ggreyback: do you think dbus menus should be directly supported in miral?14:25
greybackalan_g: nope14:25
alan_gWouldn't other shells also want them?14:25
greybackthey might, and they might not. I cannot predict that14:26
greybackas you say, having a single downstream doesn't make it easy to identify features miral should support14:28
alan_gI just think runner.run_with(DbusMenus{}) would make exposing "persistent" IDs irrelevent.14:31
kdubhmm, 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 api14:32
greybackalan_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 be14:33
greybackdednick would be the man to ask, but he's on holidays for 1.5 weeks14:33
alan_gFor the moment I think WindowManagerTools::id_for_window() is less intrusive14:33
greybackagreed14:33
alan_gmiral::DbusMenus only needs to support an abstraction over what you're wiring up14:34
alan_gAnd previous discussions have all said its the only "de-facto standard" around14:35
=== shuduo is now known as shuduo-afk
RAOFFWIW, I think PersistentSurfaceIDs are perfectly fine to use as our default cross-process-capable surface identifiers.23:18

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!