| === olli_ is now known as olli | ||
| === qengho is now known as CardinalFang | ||
| === CardinalFang is now known as qengho | ||
| 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:11 |
| duflu | alan_g: From memory I wanted to kill it. There's no realistic use case outside the examples | 09:14 |
| anpok_ | hmm you get the buffer | 09:15 |
| anpok_ | but you have no other context | 09:15 |
| 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:16 |
| 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:17 |
| duflu | I'm not sure that's relevant... if we don't already clear buffers in the server lib | 09:18 |
| 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:20 |
| alan_g | But if the only conceivable requirement is to clear it we don't need a customization point | 09:21 |
| anpok_ | yes | 09:21 |
| 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:27 |
| alf__ | anpok_: alan_g: ... (which I guess is the driving concern here) | 09:28 |
| seb128 | did Mir changed in a way that made the GTK backend stop working? does anyone know if that's a known issue? | 09:29 |
| 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:30 |
| 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:31 |
| alan_g | Or at least to tell us about it | 09:32 |
| seb128 | yeah | 09:32 |
| * 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:33 |
| 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:34 | |
| alf__ | seb128: A quick look indicates that we probably added some mir event that the code is not handling | 09:36 |
| seb128 | ok | 09:36 |
| 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:37 |
| alf__ | seb128: np | 09:38 |
| alan_g | +1 | 09:38 |
| * alan_g thinks a compile time warning would be better than a run time error. | 09:39 | |
| alan_g | (Not that C makes it easy.) | 09:40 |
| seb128 | alan_g, alf__: thanks | 09:43 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === alan_g is now known as alan_g|lunch | ||
| alf__ | anpok: Hi! In test_asio_main_loop why do we need "evaluate_clock_alarm" in AdvanceableClock ? | 12:38 |
| alf__ | anpok: Is it to guarantee that all time dependent actions for which the timeout has been reached will have been triggered? | 12:47 |
| === alan_g|lunch is now known as alan_g | ||
| === tvoss is now known as tvoss|food | ||
| alan_g | alf__: @"green background" that's been gone a while - but I didn't notice when it happened | 14:34 |
| anpok | alf__: thats to make the code that handles timers look for the current time again | 14:45 |
| 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:46 |
| anpok | alf__: thats the poor mans solution that does not involve duplicating asios timer functionality | 14:47 |
| === mhall119 is now known as mhall119|vacatio | ||
| 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 | 15:47 |
| kdub_ | alan_g, +1 from me, i don't mind taking things one step at a time | 16:54 |
| alan_g | kdub_: thanks (I think that discussion was off the point of the MP anyway) | 16:55 |
| === alan_g is now known as alan_g|EOD | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!