| racarr_ | Buffer stream is supposedly done gonna let it sit for a day then do some self review/iteration though | 00:12 |
|---|---|---|
| racarr_ | don't want it to turn in to the 4500 line MR where everyone comes to hate me | 00:12 |
| racarr_ | :p | 00:12 |
| racarr_ | or rather It hink that may be what it is now | 00:12 |
| racarr_ | and want to turn it in to something else | 00:12 |
| RAOF | Pfft! | 00:13 |
| RAOF | :)- | 00:13 |
| racarr_ | deleting code is definitely the best way to spend last hour or so of work day | 00:52 |
| === chihchun_afk is now known as chihchun | ||
| duflu_ | OK, now bzr diff is lying to me | 03:01 |
| === duflu_ is now known as duflu | ||
| duflu | What the?! My whole fix got merged over without conflicts? | 03:03 |
| duflu | That's a new and scary bzr bug | 03:04 |
| * duflu longs for git | 03:12 | |
| mikodo | duflu, Thank you! https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580 | 03:33 |
| ubot5 | Launchpad bug 1400580 in Mir " Color Inverse on display. Toggle Negative Image" [Wishlist,Triaged] | 03:33 |
| duflu | mikodo: No problem | 03:34 |
| === chihchun is now known as chihchun_afk | ||
| duflu | alf__: Could you have another look at nice-log? | 06:43 |
| alf__ | duflu: FYI, client-api-platform-operation-* branches updated | 09:34 |
| alan_g | alf__: got a moment to review this? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026 | 09:36 |
| alf__ | alan_g: sure | 09:37 |
| alf__ | duflu: oops, just a moment | 09:37 |
| duflu | alf__: Thanks. Not sure if I'll have time to try and land them again today | 09:40 |
| duflu | But anyone can do it | 09:40 |
| alf__ | duflu: np, thanks | 09:41 |
| * alan_g looks to see who has... interesting: http://paste.ubuntu.com/9454116/ | 09:42 | |
| alf__ | aargh, merging back the trunk which contains the revert of the client-platform-* removes files from my branch! | 09:44 |
| alf__ | why bzr, why? | 09:45 |
| duflu | alf__: Yeah I meant to warn you of that. Need to resubmit under a different name | 09:46 |
| duflu | Because bzr is awesome | 09:46 |
| duflu | But it was my mistake not testing x-compile | 09:46 |
| duflu | alf__: I had the same thing happen (with less explanation) this morning. I had to download the diff from LP and patch it back in :S | 09:47 |
| alf__ | duflu: no worries, I should have checked x-compile to, but I forgot (I am used to CI checking it) | 09:49 |
| alf__ | s/to/too | 09:49 |
| duflu | alf__: I *thought* building all platforms covered the Android code on desktop | 09:49 |
| duflu | Must have been in #ifdef ANDROID | 09:50 |
| alan_g | duflu: it builds the all production code, but the tests only for the first platform | 09:51 |
| duflu | alan_g: Ah | 09:51 |
| duflu | alan_g: We *could* build tests for both | 09:51 |
| alan_g | duflu: there's stuff with different implementations that we'd need to split out | 09:52 |
| alan_g | But we *should* | 09:52 |
| * alan_g can't be motivated to log a bug | 09:52 | |
| alan_g | alf__: any opinion on mir_demo_server[_basic|_example|]? | 10:17 |
| alf__ | alan_g: +1 for "mir_demo_server" | 10:20 |
| alan_g | I'll roll that into the update then. :) | 10:21 |
| alan_g | alf__: pushed | 10:35 |
| greyback | alf__: hey, on a displayconfiguration change, is there any chance existing DisplayBuffers are all destroyed and re-created? | 10:50 |
| alf__ | greyback: they are | 10:53 |
| greyback | alf__: ok, explains things on my end | 10:54 |
| greyback | thanks | 10:54 |
| alf__ | greyback: Do you know which channel I should use to get the latest phone image? vivid-proposed? | 10:55 |
| greyback | alf__: yes, that's it | 10:55 |
| alf__ | greyback: ta | 10:55 |
| greyback | np | 10:55 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|a | ||
| === alan_g|a is now known as alan_g|lunch | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === alan_g|lunch is now known as alan_g | ||
| === ogra_` is now known as ogra_ | ||
| mlankhorst | racarr_: how's mirevent 2.0 coming along? | 15:37 |
| === dandrader is now known as dandrader|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === dandrader|lunch is now known as dandrader | ||
| kgunn | seb128: did you file a bug the other day on relative screen position ? | 17:15 |
| kgunn | i was just chatting with alf__ and it seems we already have this :) | 17:15 |
| * kgunn is also curious about racarr_'s answer re mirevent2.0....as is anpok | 17:16 | |
| alan_g | Have we defined any version macros that users can use to conditionally compile server code? | 17:43 |
| racarr_ | mlankhorst: The new accessors landed but we hav to port everything and make a release before we can rip out hte old event and start making more detailed changes | 17:49 |
| racarr_ | e.g. mir event-2.0 is there now but | 17:49 |
| racarr_ | equivalent to mir event 1.0 still basically | 17:49 |
| seb128 | kgunn, not yet | 17:50 |
| seb128 | kgunn, I had to call it a day yesterday and was not working today, going to do that tomorrow | 17:50 |
| kgunn | racarr_: so anpok should start to conform to the new mirevents structures for the libinput work ?....i mean since they're in there | 17:58 |
| kgunn | seb128: ack...so i think tomorrow your morning, just chat with alf__ | 17:59 |
| kgunn | before bugging | 17:59 |
| racarr_ | kgunn: Not yet, he still outputs the old mir event structures and clients see the new one (or the old one) | 18:00 |
| racarr_ | I think we talked about it yesterday and are on the same page | 18:00 |
| racarr_ | unless this is something else... | 18:00 |
| racarr_ | :) | 18:00 |
| kgunn | could be, just trying to help things along | 18:01 |
| === alan_g is now known as alan_g|EOD | ||
| racarr_ | no worries. I am wondering if I should speed up any bits to help | 18:01 |
| racarr_ | libinput | 18:01 |
| seb128 | kgunn__, k, thank you | 18:20 |
| anpok | re | 18:28 |
| anpok | racarr_: ah ok, wasnt sure about outputting the old one.. | 18:28 |
| anpok | thought the new ones were just around the corner | 18:28 |
| mlankhorst | racarr_: ok | 18:30 |
| racarr_ | anpok: Well...I dunno...like I said the new ones are there for clients | 18:31 |
| racarr_ | but even if something was mped to port every client now | 18:31 |
| racarr_ | it would be what, 2 weeks at least before we could drop the old code | 18:31 |
| racarr_ | and right now the old event is used over the wire | 18:31 |
| racarr_ | :/ | 18:31 |
| racarr_ | for accessing MirEvent though you should | 18:31 |
| anpok | hm for input .. we still have the mapping .. | 18:32 |
| racarr_ | use the new mir_input_event* | 18:32 |
| racarr_ | stuff | 18:32 |
| anpok | yeah | 18:32 |
| anpok | mapping to droidinput structures.. | 18:32 |
| racarr_ | mm | 18:32 |
| kdub | anpok, racarr_ any more thoughts on the namespace stuff from yesterday? | 19:17 |
| kdub | iirc, we were thinking about changing mir::input to mir::event because "input" is somewhat vague | 19:18 |
| racarr_ | aha thats not what I was thinking ;) | 19:22 |
| racarr_ | I was thinking that mir::input is fine as it is because its understood to mean input devices | 19:22 |
| racarr_ | and that if we put everything related to events | 19:22 |
| racarr_ | in the same namespace | 19:22 |
| racarr_ | we lose that meaning | 19:22 |
| racarr_ | so if you wantt o have stuff related to MirEvent, but don't want it in the mir:: namespace | 19:22 |
| racarr_ | maybe it belongs in a mir::events:: namespace | 19:22 |
| racarr_ | or something | 19:22 |
| racarr_ | but certainly for example, an input device prober, or the input dispatcher, etc | 19:23 |
| racarr_ | I think those make more sense in mir::input:: | 19:23 |
| kdub | okay, I see the distinction, although from the graphics side of the fence... all looks like input to me :) | 19:26 |
| racarr_ | kdub: You are right a generalization could be made I just think its more confusing than helpful | 19:27 |
| racarr_ | e.g. mir::output::logging, mir::output::graphics | 19:27 |
| racarr_ | wouldn't be helpful ;) | 19:27 |
| racarr_ | lol | 19:27 |
| kdub | right, but mir::hid or mir::events might be | 19:28 |
| kdub | anyways, so dropping the namespace stuff... I guess we're still looking for what to do with the 3 EventSink interfaces | 19:29 |
| racarr_ | kdub: I dunno...sorry ill think about it in a sec...furiously debugging | 19:37 |
| AlbertA | does anyone know why we don't have a mir_surface_spec_set_output_id? we have a set_fullscreen_on_output.... | 19:39 |
| kdub | AlbertA, just a fuzzy memory, but iirc, something having to do with helping more mesa bypass happen | 19:40 |
| AlbertA | ok...I'm just wondering so I can migrate the examples.... | 19:41 |
| AlbertA | to the new spec api | 19:41 |
| AlbertA | since eglapp uses the output id parameter to place a non-fullscreen surface | 19:41 |
| AlbertA | in a specific output id | 19:42 |
| AlbertA | if the user sets up that option | 19:42 |
| racarr_ | Interesting | 19:42 |
| racarr_ | I thought output_id was equivalent | 19:42 |
| racarr_ | to fullscreen on output | 19:42 |
| racarr_ | and didnt know the other behavior was allowed | 19:42 |
| AlbertA | so perhaps we just want to deprecate that behavior? | 19:43 |
| AlbertA | although reading the windowing spec | 19:43 |
| AlbertA | the system needs to support restoring the previous client context.... | 19:44 |
| AlbertA | which may include being in a certain monitor and non-fullscreen | 19:44 |
| AlbertA | but I guess that can just be done in the server side | 19:44 |
| racarr_ | I think thats opaque | 19:44 |
| racarr_ | to the client | 19:44 |
| racarr_ | yeah | 19:44 |
| racarr_ | ikf there is any client involvement | 19:44 |
| racarr_ | its through an opaque | 19:45 |
| racarr_ | cookie | 19:45 |
| racarr_ | im not sure apps are even allowed to use fullscreen_on_output | 19:45 |
| racarr_ | afaik the approved use case is: xmir | 19:45 |
| racarr_ | and nested | 19:45 |
| kdub | and eglspinner? | 19:46 |
| kdub | maybe what that means is that USC allows clients to do that (returns true), but U8 does not (returns false) | 19:48 |
| racarr_ | ah probably | 19:48 |
| AlbertA | ok, I think I have my answer :) change eglapp....:) | 19:49 |
| anpok | kdub: no further thoughts so far | 20:13 |
| === chihchun is now known as chihchun_afk | ||
| mibofra | kdub, nothing I've checked and I've the same problems/errors of the last time. But I think, also wayland on the framebuffer library works well xD . Is there an option to force mir to use only the framebuffer (as /dev/graphics/fb0)? | 20:40 |
| mibofra | *or the rendering method of the render_to_fb demo | 20:40 |
| kdub | "--disable-overlays true" (argv) or "MIR_SERVER_DISABLE_OVERLAYS=true" (env) forces the render_to_fb demo rendering method | 20:42 |
| mibofra | let's try (again | 20:42 |
| mibofra | ) | 20:42 |
| mibofra | MIR_SERVER_DISABLE_OVERLAYS=true , well, It's visible that it's an env specification xD | 20:43 |
| mibofra | kdub as usually segfault on egl demo, and nothing displayed on the screen for others | 20:49 |
| mibofra | just a thing, I launch the compositor in this way: | 20:49 |
| mibofra | unity-system-compositor --file '/run/mir_socket' --from-dm-fd 0 --to-dm-fd 1 --disable-overlays true | 20:49 |
| kdub | try mir_demo_server_shell | 20:50 |
| mibofra | the same result | 20:52 |
| kdub | any kernel or logcat error msgs? | 20:54 |
| mibofra | kdub, http://paste.ubuntu.com/9467210/ from dmesg, but I think is not really useful | 20:57 |
| kdub | nah, so thats okay | 20:57 |
| kdub | http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/android_new_device_bringup.md | 20:59 |
| kdub | has some more suggestions... one day it'll make it to unity.ubuntu.com/mir | 20:59 |
| mibofra | kdub, from logcat: http://paste.ubuntu.com/9467244/ | 21:01 |
| kdub | and try the mir_integration_tests | 21:01 |
| mibofra | ok | 21:02 |
| mibofra | well, kdub it doesn't accept the filters, anyway the integration test segfault after [ RUN ] StaleFrames.are_dropped_when_restarting_compositor and fail at http://paste.ubuntu.com/9467332/ | 21:07 |
| kdub | how does this one do?: mir_integration_tests --gtest-filter="TestClientIPCRender.test_accelerated_render_double" | 21:09 |
| mibofra | kdub, it returns the help of mir_integration_tests | 21:10 |
| kdub | oh, sorry, --gtest_filter | 21:11 |
| mibofra | kdub, http://paste.ubuntu.com/9467365/ | 21:12 |
| kdub | mibofra, so, the render_overlays one won't output anything for hwc 1.0, but the server should still work (and the render_to_fb works, so thats good) | 21:13 |
| mibofra | kdub, anyway on the android_new_device_bringup.md there is also --gtest-filter instead of --gtest_filter | 21:14 |
| kdub | right, should be updated | 21:14 |
| mibofra | kdub, http://paste.ubuntu.com/9467658/ , line 55 | 21:53 |
| mibofra | is normal that the compositor stops before the drawing? | 21:53 |
| kdub | mibofra, no, its strange | 21:56 |
| kdub | I guess if that integration test is working, and the render_to_fb works, the driver components are working... something else is going on | 21:56 |
| mibofra | kdub, does the compositor need some tty? | 21:58 |
| mibofra | like the tty1? | 21:58 |
| kdub | no, it doesnt | 21:58 |
| mibofra | ok | 21:58 |
| * kdub hasnt seen StaleFrames be the failing test for a new device before | 21:59 | |
| mibofra | kdub, I had an idea | 22:00 |
| mibofra | kdub, it uses /dev/ump as part of the driver (egl) no? | 22:01 |
| kdub | perhaps, that's abstracted to mir and different on each chipset | 22:02 |
| mibofra | I've fusered /dev/ump to see if there was something using it, and I've found something with lsof | 22:02 |
| mibofra | I've found Binder_1 , kdub | 22:02 |
| mibofra | maybe it interferences in a way? | 22:02 |
| kdub | not sure | 22:03 |
| mibofra | kdub, other process too are using ump | 22:05 |
| RAOF | AlbertA: Requests for output_id that _weren't_ fullscreen were denied. | 22:10 |
| mibofra | kdub, _render_to_fb access in another way, I think is not only problem of setting --disable-overlays true, because it doesn't solve the problem on the other mir servers (demo or not) | 22:11 |
| RAOF | AlbertA: mir_surface_spec didn't change that, it just meant that you couldn't make a request that we'd automatically deny :) | 22:11 |
| AlbertA | RAOF: ack | 22:15 |
| mibofra | hi AlbertA, hi RAOF | 22:16 |
| AlbertA | hi there | 22:17 |
| racarr_ | RAOF: Linux is about choice and MirSurfaceSpec is ruining it. | 22:23 |
| racarr_ | :p | 22:23 |
| racarr_ | Good morning | 22:23 |
| RAOF | Ok. Naming problem. | 23:31 |
| RAOF | I've got an interface, currently called Dispatchable, which has “get pollable fd” and dispatch() operations. | 23:32 |
| RAOF | I need to name an interface for something that has a create_dispatchable_for_me() operation. | 23:33 |
| AlbertA | RAOF: DispatchableFactory? :) | 23:41 |
| RAOF | Yeah, possible, but you only ever want to produce one Dispatchable from it. | 23:41 |
| RAOF | The interface is more create_a_dispatchable_that_will_dispatch_me() | 23:41 |
| RAOF | And it very rarely makes sense to have more than one of those. | 23:42 |
| racarr_ | DispatchableProgenitor | 23:52 |
| racarr_ | hmm | 23:52 |
| racarr_ | Sorry what is a dispatachable? | 23:52 |
| racarr_ | or rather what does dispatch() do | 23:52 |
| racarr_ | for whom | 23:53 |
| RAOF | dispatch() does whatever should be done when there's something ready. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!