[00:05] <RAOF> racarr: ^^^ Looks like kgunn would like the meeting to be on this week :)
[00:06] <racarr> Oi
[00:23] <RAOF> racarr: Oh, by the way - do we have an input driver model?
[00:24] <RAOF> My vague understanding of our current input stack is that it expects to open an evdev device and go to town.
[00:26] <RAOF> I ask this for the reasonably transparent reason that I'll soon be wanting to fold a touchpad driver into the mix.
[00:33] <racarr> RAOF: Yes basically open an evdev device and go to town
[00:34] <racarr> actually though all that is constrained to EventHub which emits droidinput::RawEvents
[00:34] <racarr> and you could call that the driver
[00:34] <RAOF> So I get to implement an input driver API. Huzzah!
[00:34] <racarr> but its hardly a driver model
[00:34] <racarr> RAOF: Living the dream ;)
[02:36] <duflu_> Ping kgunn
[03:06] <RAOF> duflu: Maybe you can talk with him at the meeting this afternoon? :)
[03:06] <duflu> RAOF: That one that no one has come to for a month and I think we informally canceled?
[03:06] <RAOF> Yeah, that one.
[03:07] <RAOF> kgunn was on earlier mentioning that he was going to show up this time.
[03:08] <duflu> Awesome. If only anyone replied to my email about canceling it... or turned up
[06:02] <duflu> RAOF: Am I in the right hangout? I uninstalled my calendar plugin today so am guessing
[06:03] <RAOF> Gah. Why hasn't the email with the hangout link come in yet?
[06:04] <duflu> RAOF: No. I suspect kgunn canceled it after my email :)
[06:05] <RAOF> Still only static?
[06:06] <kgunn> RAOF: duflu i'm here...but meeting is in 1 hr i think
[06:06] <kgunn> we had daylight savings last weekend...bet that's the prob
[06:07] <duflu> kgunn: Oh. It's on your timezone?
[06:07] <duflu> kgunn: RAOF and I are in, and we don't expect anyone else
[06:07] <kgunn> hmmm....lemme check
[06:08] <kgunn> yeah...i'm showing 1 hr from now
[06:08] <kgunn> and alexandros is good about showing right ?
[06:09] <duflu> kgunn: We kind of agreed to cancel it after alf and I were the only attendees for several weeks :)
[06:09] <kgunn> yeah...
[06:09] <kgunn> we need to come up with a decent time
[06:10] <kgunn> i sort of feel like we should maybe have like 3 rotating spots or something
[06:10] <RAOF> Maybe.
[06:11] <duflu> kgunn: If you want to chat at all today, we're "all" in the hangout now :)
[06:11] <kgunn> ok
[06:12] <racarr> wait are wedoing it now?
[06:20] <tvoss_> good morning
[08:31] <mlankhorst> g'day
[08:39] <duflu> mlankhorst: hallo
[09:56] <mlankhorst> alf_: hey, did you ever end up merging the mesa / mir changes back? :P
[09:56] <alf_> mlankhorst: are you referring to the EGLImage changes?
[09:57] <mlankhorst> yeah
[09:57] <alf_> mlankhorst: yes, they are in RAOF's github repo
[09:57] <mlankhorst> ok what about the mir changes?
[09:59] <alf_> mlankhorst: I don't remember exactly what additional changes were needed on the Mir side, but nested mir works now with lp:mir (or at least it worked last I checked)
[10:00] <mlankhorst> ah k
[10:01]  * alan_g smells a missing test case
[10:07] <mlankhorst> hehehe, 'git merge ubuntu' on raof's branch then commenting out the mir patch in debian/patches/series works :P
[11:40] <mlankhorst> alf_: but what about my fixes ? I disabled vt switching in the nested case
[11:41] <alf_> mlankhorst: hmm, I am not sure... do you have a link to your changes/branch?
[11:44] <mlankhorst> http://paste.debian.net/64293/
[11:51] <alf_> mlankhorst: instead of passing a nullptr it would preferable to pass a NullObject, in this case a NullVirtualTerminal. There is an implementation of that in include/test/mir_test_doubles/null_virtual_terminal.h, so we just move that to src/server/graphics/gbm and use it (and also change the tests to use that too)
[11:53] <mlankhorst> :/
[11:53] <mlankhorst> hm lets see..
[12:16] <mlankhorst> alf_: http://paste.debian.net/64300/ -- enjoy?
[12:19] <alf_> mlankhorst: Looks good, thanks (only some nits). I will shepherd it into trunk if you want.
[12:19] <mlankhorst> please :)
[12:20] <alf_> mlankhorst: ok
[12:21] <mlankhorst> seems acceptance-tests.ServerShutdown/OnSignal and ServerShutdown.server_removes_endpoint_on_abort hang?
[12:23] <alf_> mlankhorst: Is it a consistently reproducible? I remember there was a bug about something similar, but I think it was resolved.
[12:25] <mlankhorst> sort of, it happens in my chroot
[12:33] <alf_> mlankhorst: hmm, I get a consistent failure (not a hang) in ServerShutdown/OnSignal.removes_endpoint_on_signal/2
[12:34] <alf_> mlankhorst: ...but only if I run the tests manually. If I use ctest everthing works.
[12:34] <mlankhorst> oh seems to be random here
[12:34] <mlankhorst> some other tests can fail too
[12:39] <mlankhorst> heh maybe my system is too fast :P
[12:40] <mlankhorst> C++ exception with description "Failed to find server" thrown in the test body.
[12:40] <mlankhorst> /home/mlankhorst/nfs/xorg/mir/tests/mir_test_framework/testing_process_manager.cpp:240: Failure
[12:40] <mlankhorst> Value of: server_process_was_started
[12:40] <mlankhorst>   Actual: false
[12:40] <mlankhorst> Expected: true
[12:41] <alf_> mlankhorst: btw, are you using the latest development-branch?
[12:45] <mlankhorst> not sure, last commit i have is from nov 3 :P
[12:45] <mlankhorst>     Restore:  mir (0.1.0+14.04.20131030-0ubuntu1) trusty; urgency=low
[12:45] <mlankhorst> hm nov5
[12:46] <alf_> mlankhorst: ok
[12:58] <alf_> mlankhorst: actually, the patch may not be needed after all... we create a different kind of platform when nested ("native platform") which doesn't use the VT at all
[12:58] <alf_> mlankhorst: did you actually have a problem with the current state of the code?
[13:16] <dandrader> greyback, ping
[13:19] <greyback> dandrader: pong
[13:20] <dandrader> greyback, working on the mir-with-qtscenegraph prototype?
[13:20] <greyback> dandrader: yep
[13:21] <dandrader> greyback, let me know when you're something I could use to start experimenting with the input part of it
[13:21] <dandrader> greyback, or if you need help with it
[13:21] <dandrader> s/you're/you've
[13:23] <mlankhorst> alf_: oh is that different? :P
[13:23] <mlankhorst> i think it used to be needed
[13:23] <mlankhorst> my bad then
[13:25] <greyback> dandrader: thanks, I'll remember that :) I've a good day or 2 of hacking to get the basics going, but then I'll ping you
[15:01] <Prf_Jakob> alf_: hey
[15:01] <alf_> alf_: hi!
[15:01] <alf_> Prf_Jakob: hi!
[15:02] <Prf_Jakob> I'm thinking a bit longer term here, but would you guys be okay with using egl to accessing buffers?
[15:02] <Prf_Jakob> I'm thinking of trowing together a extension for shadowfb type blitting to images.
[15:04] <Prf_Jakob> (disclaimer: I'm on the EGL WG at Khronos).
[15:04] <alf_> Prf_Jakob: Do you mean for the client to access buffers, or for the server to access buffers?
[15:06] <Prf_Jakob> It can be done in multiple ways, but one way would be that the server creates hardware image, you prime/dma-buf it over to the client (can be hidden in the toolkit) and then create a shadow on the client side which it uses for fast access.
[15:07] <Prf_Jakob> Alternativly you could prime over the shadow image.
[15:08] <Prf_Jakob> Both would require you to still load the hardware driver (in our case our mesa dri driver) in the client.
[15:15] <alf_> Prf_Jakob: I think it would be a useful extension that will cover some of the direct pixel access use cases, although there would still be apps/toolkits that for whatever reason don't want to do EGL/GL at all.
[15:15] <alf_> tvoss_: ^^ Was there a specific driving case for "software" buffers?
[15:16] <Prf_Jakob> alf_: yet they are okay with gbm :/
[15:16] <tvoss_> alf_, plymouth was the original one, yeah
[15:17] <alf_> Prf_Jakob: that's a good point
[15:18] <Prf_Jakob> I mean at that point you have already pulled in the dri driver and all the gl bits into the process VM anyways.
[15:19] <alf_> Prf_Jakob: Actually, a pure "software" client, doesn't load gbm. It currently only uses DRM to map dumb buffers.
[15:19] <Prf_Jakob> Ah
[15:20] <Prf_Jakob> Not to comfirtable putting that much of acceleration API in the kernel.
[15:20] <alf_> Prf_Jakob: :)
[15:22] <Prf_Jakob> Trying to eat the gpu cake and keeping the not using gpu API cake.
[18:38] <kgunn> goin' to work out
[23:13] <racarr> finally making some good progress on my persistent goal of
[23:13] <racarr> improving theinput acceptance testing framework...
[23:13] <racarr> hopefully should be able to make an MP with a net line of codeloss :)
[23:14] <RAOF> Huzzah!