| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| duflu | anpok_: I'm inspired now. Going to try attacking the cursor freezes with some real-time profiling | 08:09 |
|---|---|---|
| duflu | anpok_: Umm... the bug isn't happening for me any more (!?) | 08:15 |
| alan_g | bugs that bite and run away live to bite another day | 08: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 |
| duflu | anpok_: Sure yes in traces. But I can't "see" it any more | 10:02 |
| === hikiko|ln is now known as hikiko | ||
| zzarr | just a quick question does Mir work with any MESA driver? | 13:23 |
| 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:26 |
| anpok_ | this is relevant because we rely on the capability to import dmabuf fds | 13:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| zzarr | thanks, that's great | 13:34 |
| 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:06 |
| 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:09 |
| alan_g | Nobody had a usecase where the WM wanted to get an ID from a surface | 14:10 |
| 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:13 |
| greyback | which is neater, it associates a persistentId to the surface as soon as possible, and passes it along with the other WindowInfo | 14:14 |
| greyback | see "qtmir::NewWindowInfo" | 14:15 |
| alan_g | I'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 features | 14:18 | |
| greyback | :) | 14:18 |
| greyback | I don't have a strong opinion on it | 14:19 |
| greyback | I just made my implementation, and noticed the proposal might clean it up a little more | 14:20 |
| 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:22 |
| 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:24 |
| 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:25 |
| greyback | they might, and they might not. I cannot predict that | 14:26 |
| greyback | as you say, having a single downstream doesn't make it easy to identify features miral should support | 14:28 |
| alan_g | I just think runner.run_with(DbusMenus{}) would make exposing "persistent" IDs irrelevent. | 14:31 |
| 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:32 |
| 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:33 |
| alan_g | miral::DbusMenus only needs to support an abstraction over what you're wiring up | 14:34 |
| alan_g | And previous discussions have all said its the only "de-facto standard" around | 14:35 |
| === shuduo is now known as shuduo-afk | ||
| RAOF | FWIW, 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!