[00:25] <RAOF> Trevinho: I take it invalidate_for_new_frame isn't called by anything?
[00:26] <Trevinho> RAOF: it's called by gtkwindow as it's used as function overrider in gtkmirwindowimpl
[00:26] <RAOF> Ah, ok.
[00:27] <Trevinho> RAOF: so at the end in gdkwindow.c at line 3653
[00:27] <RAOF> Why does it bail early if not using GL? You still need to account for previous damage (unless you always do full-window repaints when not using GL?)
[00:28] <Trevinho> RAOF: not sure I undestood what you mean...
[00:29] <Trevinho> ah, the function...
[00:29] <RAOF> https://github.com/3v1n0/gtk/blob/wip/mir-gdkgl/gdk/mir/gdkmirglcontext.c#L63
[00:29] <Trevinho> well, when not using gl it shouldn't be called at all, in that case it uses a 2d surface
[00:30] <Trevinho> RAOF: basically this function works only when a gdkgl area is used, which happens only when using a gtkglarea, not for all the rest of the widgets
[00:32] <RAOF> Fair chop.
[07:43] <duflu> Wow, src/server/ is 317 files now. No wonder I'm still getting lost
[07:46] <mlankhorst> why so many?
[08:14] <duflu> mlankhorst: Mir does more than you think
[08:14] <duflu> Just not all that you want (yet)\
[09:25] <duflu> alan_g: Any idea why C++ says you can't get to namespace local things in the parameter list, but can in the function body?
[09:26] <alan_g> duflu: do you means something different to what I understand by "namespace local things"?
[09:27] <duflu> alan_g: I mean a function parameter list must use full namespace spec, and can't implicitly get to the namespace the function is in
[09:27] <duflu> I guess parameter list is different scope to the body
[09:27] <alan_g> I don't believe that is true.
[09:27] <alan_g> Give an example
[09:28] <duflu> alan_g:   mir::shell::Something::doit(shell::Type x)
[09:29] <alan_g> Like mir::logging::Logger::log(Severity, ...)?
[09:29] <alan_g> That works
[09:30] <duflu> alan_g: Maybe it's a different issue. No big deal.
[09:32] <mlankhorst> duflu: yeah, I would really like to have support for multiple keyboard/etc
[09:33] <duflu> mlankhorst: If that's your only complaint then we're doing well
[09:33] <duflu> mlankhorst: Find the egl examples?
[09:33] <duflu> We have a few
[09:33] <mlankhorst> well, no
[09:33] <mlankhorst> window management is lacking, makes rootless hard
[09:34] <duflu> mlankhorst: Working on that right this moment
[09:34] <duflu> mlankhorst: You know how to use mir_server_demo_shell?
[09:34] <mlankhorst> no, not at all
[09:35] <duflu> mlankhorst: Very primitive WM: http://unity.ubuntu.com/mir/demo_shell_controls.html
[09:35] <mlankhorst> don't even know the differences between all those mir servers
[09:36] <mlankhorst> oh and support for synaptics would b enice
[09:36] <anpok_> working on it
[09:36] <duflu> mlankhorst: I think anpok is working on libinput now
[09:37] <anpok_> and the underlying libevdev is causing some trouble with umockdev
[09:37] <mlankhorst> ah
[09:37] <mlankhorst> what about support for dumping keymappings so I can tell X about them?
[09:58] <duflu> alan_g: I didn't realise yesterday that "Shell" is a class already :)
[09:58] <duflu> alan_g: So I'm side-stepping that and making a "WindowManager" to avoid changing too much at once
[09:59] <alan_g> I don't know what your trying to solve. I thought I explained why there wasn't a problem yesterday
[09:59] <duflu> alan_g: I'm avoiding large changes suggested yesterday
[10:00] <duflu> These are less invasive
[10:00] <duflu> Not final, but smaller steps
[10:23] <mlankhorst> who knows more about the lifetime management of the buffers with mesa?
[10:26] <duflu> mlankhorst: A client is guaranteed to own any buffer the server gives it till the next swap
[10:26] <duflu> That's possibly all you need to know in the client
[10:27] <mlankhorst> duflu: yes, but what happens if I cache the fd's, should that work?
[10:28] <duflu> mlankhorst: Possibly not. The server might resize the surface once it gets it back. And I think that could mean the old one is gone
[10:28] <duflu> Resize means delete buffers when it's safe and replace them with new ones of the new size
[10:28] <mlankhorst> does it reset the buffer age in that case?
[10:29] <duflu> mlankhorst: Don't know. It _should_ I guess but unsure
[10:29] <mlankhorst> mm *checks how xorg-mir does it*
[10:31] <mlankhorst> ok it just does the whole dance over and over
[10:47] <mlankhorst> duflu: but is it really a good idea that the fastpath is gbm_bo_import, eglCreateImageKHR, glGenTextures, glEGLImageTargetTexture2DOES, glDeleteTextures, eglDestroyImageKHR, gbm_bo_destroy ?
[10:48] <duflu> mlankhorst: *shrug*
[10:55] <mlankhorst> bleh
[10:57] <mlankhorst> duflu: what about the drm fd, is that a new one only used by the device?
[10:58] <duflu> mlankhorst: I have lost context, sorry. Would have to dig through source to answer anything like that
[10:58] <mlankhorst> oh oops
[10:59] <mlankhorst> *checks if gbm closes the drm fd or not*
[11:08] <mlankhorst> even dup'ing seems to be affected, great
[11:24] <duflu> Woo, working on-the-fly WM policy
[11:24] <duflu> Just needs a few days to make it nice
[13:59]  * alan_g wonders if he's the only one to find the log messages now coming from the tests a PITA
[14:11] <kdub> alan_g, I do too... was thinking of logging a bug :)
[14:19] <kdub> https://bugs.launchpad.net/mir/+bug/1394221
[14:26] <alan_g> camako: the AnonymousShmFile tests should pass on kernel 3.13 shouldn't they? https://code.launchpad.net/~alan-griffiths/mir/migrate-more-acceptances-tests/+merge/242094/comments/596315
[14:45] <mlankhorst> ugh found my issue, I had to RTFM
[14:45] <mlankhorst> "If the EGL rendering context context is not current to any thread, eglDestroyContext destroys it immediately. Otherwise, context is destroyed when it becomes not current to any
[14:45] <mlankhorst>                     thread."
[14:47] <mlankhorst> x11perf works again now, and I no longer get those weird issues I was having..
[14:53] <mlankhorst> the basic functionality is now stable, on towards handling resizing events I guess. :P
[15:05] <camako> alan_g, yes they should
[15:06] <alan_g> camako: thanks
[15:21] <anpok_> mlankhorst: cool
[17:58] <attente_> hi, is there any progress on https://bugs.launchpad.net/mir/+bug/1391976? i can't seem to get unity8 running from trunk because of it