=== olli_ is now known as olli
=== qengho is now known as CardinalFang
=== CardinalFang is now known as qengho
[09:11] <alan_g> alf__: duflu anpok_ is BufferInitializer a feature we intend to support? https://code.launchpad.net/~alan-griffiths/mir/render-examples-using-a-simpler-server-setup/+merge/238469/comments/585656
[09:11] <alan_g> We don't - for example - have an acceptance test
[09:14] <duflu> alan_g: From memory I wanted to kill it. There's no realistic use case outside the examples
[09:15] <anpok_> hmm you get the buffer
[09:15] <anpok_> but you have no other context
[09:16] <alan_g> duflu: I suspected as much. There's no security concern requiring steps to initialize a buffer before handing it out?
[09:16] <duflu> alan_g: I think we could replace it more elegantly using software buffers where the examples use it
[09:17] <duflu> alan_g: If so then that might be a GBM/Mesa bug. Not sure if we have a requirement to clear new buffers
[09:17] <alan_g> "the examples" == render_surfaces?
[09:17] <duflu> alan_g: Yeah whatever it was. There may only be one
[09:17] <anpok_> hm i doubt mesa or drm driver will clear it
[09:18] <duflu> I'm not sure that's relevant... if we don't already clear buffers in the server lib
[09:20] <alf__> duflu: alan_g: anpok: Yeah, there is no guarantee that we get a cleared buffer
[09:20] <anpok_> but should we use that interface to implement clearing then?
[09:21] <alan_g> But if the only conceivable requirement is to clear it we don't need a customization point
[09:21] <anpok_> yes
[09:27] <alf__> alan_g: anpok_: BufferInitializer was mostly a convinience, we could probably implement the same functionality differently in render_surfaces, e.g., wrap the display and the buffer allocator, but I am not sure if that's much better in terms of hiding/exposing API.
[09:28] <alf__> anpok_: alan_g: ... (which I guess is the driving concern here)
[09:29] <seb128> did Mir changed in a way that made the GTK backend stop working? does anyone know if that's a known issue?
[09:30] <seb128> starting e.g gedit used to work and now hit "Gdk:ERROR:/build/buildd/gtk+3.0-3.12.2/./gdk/mir/gdkmireventsource.c:417:gdk_mir_event_source_queue_event: code should not be reached"
[09:30] <seb128> I guess that's more one for robert_ancell but he's not around anymore for today
[09:31] <alan_g> seb128: it isn't known to me anyway
[09:31] <seb128> was there any recent change in Mir that could lead to such issues?
[09:31] <seb128> we need some automated tests to make sure Mir updates don't make GTK stop working
[09:32] <alan_g> Or at least to tell us about it
[09:32] <seb128> yeah
[09:33]  * alan_g wonders where the gtk code is
[09:33] <seb128> alan_g, you don't want to know ;-)
[09:33] <seb128> alan_g, http://bazaar.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3/view/head:/debian/patches/mir-backend.patch
[09:34] <alf__> alan_g: seb128: Yeah, probably apt-get source is the best way to get it :)
[09:34] <seb128> alan_g, I think the vcs is https://git.gnome.org/browse/gtk+/log/?h=wip/mir
[09:34] <seb128> alf__, ^
[09:34]  * alan_g doesn't want to know
[09:36] <alf__> seb128: A quick look indicates that we probably added some mir event that the code is not handling
[09:36] <seb128> ok
[09:37] <seb128> I'm going to let robert_ancell know, thanks
[09:37] <alf__> seb128: btw, I think the event switch statement in question is too strict, it should ignore unexpected events (and perhaps log a warning) instead of aborting
[09:38] <alf__> seb128: np
[09:38] <alan_g> +1
[09:39]  * alan_g thinks a compile time warning would be better than a run time error.
[09:40] <alan_g> (Not that C makes it easy.)
[09:43] <seb128> alan_g, alf__: thanks
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== alan_g is now known as alan_g|lunch
[12:38] <alf__> anpok: Hi! In test_asio_main_loop why do we need "evaluate_clock_alarm" in AdvanceableClock ?
[12:47] <alf__> anpok: Is it to guarantee that all time dependent actions for which the timeout has been reached will have been triggered?
=== alan_g|lunch is now known as alan_g
=== tvoss is now known as tvoss|food
[14:34] <alan_g> alf__: @"green background" that's been gone a while - but I didn't notice when it happened
[14:45] <anpok> alf__: thats to make the code that handles timers look for the current time again
[14:46] <anpok> alf__: the code advances time and believes that if a new alarm is created the system will look for current time and calculate diffs..
[14:47] <anpok> alf__: thats the poor mans solution that does not involve duplicating asios timer functionality
=== mhall119 is now known as mhall119|vacatio
[15:47] <alan_g> camako: kdub_ anpok - anyone want to express an opinion? https://code.launchpad.net/~alan-griffiths/mir/basic_server-using-a-simpler-server-setup/+merge/238184
[16:54] <kdub_> alan_g, +1 from me, i don't mind taking things one step at a time
[16:55] <alan_g> kdub_: thanks (I think that discussion was off the point of the MP anyway)
=== alan_g is now known as alan_g|EOD