[01:06] <bschaefer> duflu, hey, figure out that software rendering issue in SDL. Turns out if you set mir_buffer_hardware instead of mir_buffer_software you get a failed to mmap a buffer
[01:06] <bschaefer> i think it started to happen when shm was introduced
[01:06] <duflu> bschaefer: Ah yes, sounds like the right error then :)
[01:06] <bschaefer> duflu, :)
[01:07] <bschaefer> you can get the same error if you change multiwin as well
[01:07] <duflu> I keep thinking we should augment some exception messages like that to describe the most likely cause/mistake
[01:07] <bschaefer> could be helpful, but the area it fails at, im not sure if it knows much about the buffer type
[01:08] <bschaefer> as it happens in: client/mesa/client_buffer.cpp:60:
[01:08] <RAOF> We should make mir_surface_get_graphics_region return an error when called with a hardware buffer.
[01:08] <bschaefer> but there could be a better way to detect, if the surface is set to hardware
[01:08] <bschaefer> and you ask for the region, it should possibly have an error there
[01:08] <bschaefer> yeah
[01:09] <duflu> bschaefer: Yes, that too. "hardware" and "software" are kind of vague words
[01:09] <bschaefer> duflu, just a little :)
[01:11] <duflu> bschaefer: More confusingly "hardware" does not always imply GL. For example, our X drivers render (accelerated) using "hardware" buffers but not GL
[01:11] <duflu> But that's the only exception
[01:13] <bschaefer> duflu, thats interesting, I didn't know that... im not sure how SDL would handle that?
[01:13] <bschaefer> as SDL either uses OpenGL/ES1/ES2/Software
[01:14] <duflu> bschaefer: Yeah that's normal. Only X is weird.
[01:14] <bschaefer> duflu, haha
[01:14] <RAOF> As far as almost all clients are concerned, “hardware” == “Can use OpenGL*”
[01:14] <RAOF> Theoretically you could have something like the cairo-drm backend, though, and that would use hardware buffers without going through GL.
[01:14] <duflu> RAOF: Can we ever use OpenGL on shm buffers? surely...
[01:14] <bschaefer> cool, yeah i hand't taken that into consideration, and defaulted to "hardware buffer"
[01:15] <RAOF> duflu: Yes, we can, if we want to.
[01:15] <RAOF> duflu: Although that'll need some libEGL support.
[01:15] <duflu> RAOF: Your sound's still broken. I give up on the hangout
[01:15] <RAOF> Eh.
[01:15] <RAOF> I didn't think anyone was saying anything?
[01:16] <duflu> RAOF: I think we need that for software rendering anyway
[01:16] <RAOF> Oh, yes.
[01:16] <RAOF> Well, if we want to allow software-rendered GL clients.
[01:16] <duflu> It would also be generally cool to have a fallback buffer sharing mode that works on *everything*
[01:17] <RAOF> Buffer sharing the easy part; the hard part is getting anything on the display :)
[01:17]  * duflu thinks the opposite
[01:17] <RAOF> Howso?
[01:18] <duflu> We should work together
[01:18] <duflu> RAOF: I just know more framebuffer stuff than buffer sharing
[01:18] <RAOF> We've already got a buffer sharing mechanism that works everywhere - shm.
[01:19] <duflu> When it's fixed to work everywhere?
[01:19] <RAOF> It works everywhere now (although doesn't get you GL)
[01:19] <RAOF> (And will never get you hardware-accelerated GL)
[01:19] <duflu> I think we're missing a flag in our buffer messages to tell the client explicitly which to use?
[01:20] <RAOF> Yes; I we assume that the client remembers what it asked for.
[01:20] <duflu> Fortunately we have a flags field in those messages :)
[01:20] <duflu> Although an enum to support N buffer sharing mechanisms might be better
[01:22] <RAOF> Hm, maybe?
[01:22] <RAOF> I don't think that would be particularly helpful; everything but “software” is platform-specific.
[01:25] <duflu> RAOF: Yeah that's enough so long as the type of "hardware" is clarified by the currently loaded client driver-thing
[01:26] <RAOF> And that's what mir_surface_get_platform_type tells you.
[01:51] <memeka> hi all
[01:51] <memeka> I have libhybris installed on an ARM device, test_hwcomposer works ... what else is needed to get mir running?
[01:56] <racarr__> oh sorry forgot
[01:56] <racarr__> the meeting
[01:57] <duflu> racarr__: Yeah twas just RAOF and myself. Nothing happened
[01:57] <racarr__> :)
[01:57] <racarr__> "It was just me and RAOF! NOthing happened I Swear"
[01:57] <racarr__> like a sitcom plot
[01:57] <racarr__> lol
[01:57] <duflu> Nobody in here but us chickens
[01:58] <RAOF> memeka: Have you tried it? That sounds like the major prerequisites :)
[01:58] <memeka> RAOF: not yet... planning to
[01:59] <memeka> just wanted to know what to expect
[01:59] <memeka> XMir probably will not work?
[01:59] <RAOF> XMir will definitely not work.
[01:59] <duflu> memeka: No XMir, but you should be able to compile/run the native Mir demos
[01:59] <memeka> except the demos, is there anything that would run?
[02:00] <RAOF> SDL2 stuff should.
[02:00] <duflu> memeka: You need toolkits to answer that question. So yes, SDL2 and Qt-based apps
[02:00] <duflu> But you have to have the right packages and voodoo
[02:00] <RAOF> memeka: Well, XMir won't work unless your ARM device happens to already have a kms driver, X support, mesa support, and you want to add a little patch to its DDX. :)
[02:01] <memeka> RAOF: so that's a no :)
[02:01] <RAOF> Correct :)
[02:01] <memeka> demos require libgles2-mesa .... can I bypass mesa and use the egl from hybris?
[02:01] <RAOF> They will use the egl from hybris.
[02:02] <memeka> k, so setting the env variables should do it then
[02:02] <RAOF> I think if you've got hybris installed it will already be providing your libGLES2.so.2; we use the alternatives system to delegate stuff like that.
[02:03] <memeka> kwin_gles and konsole should work, right?
[02:04] <duflu> memeka: Native EGL/GLES stuff needs explicit porting to Mir. Just the initialization stuff
[02:04] <duflu> Because you need to create a Mir connection and surface for EGL to run in, and GLES runs in that.
[02:04] <memeka> duflu: i see
[02:05] <duflu> Unfortunately EGL is not sufficiently featured to be a "platform" in itself
[02:06] <memeka> duflu: so that's why the egl tests fail :)
[02:06] <duflu> RAOF: So it seems 1hz needs much porting
[02:06] <memeka> only hwcomposer test actually runs
[02:06] <RAOF> duflu: Yes indeed.
[02:06] <duflu> Plus all the other proposals :P
[02:07] <RAOF> duflu: I'll be doing that shortly, once the FrameDroppingPolicy
[02:07] <memeka> duflu: and where is the init stuff done? :D
[02:08] <duflu> mememka: A good example is in the Mir source. This sets up enough of Mir for an EGL app to use it: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/eglapp.c
[02:11] <memeka> right, so this is when you want to start an EGL app
[02:11] <memeka> this does not mean that kwin_gles needs to be patched as well, does it?
[02:13] <memeka> duflu: thx for the link
[02:15] <memeka> duflu: hmm.. the exmaples there have a demo shell and window manager ... so I guess kwin_gles will not work...
[02:25] <duflu> memeka: It's not a real shell or window manager. They're just class names. You can still run anything on top of that.
[02:25] <RAOF> memeka: Correct. kwin is fundamentally an X11 window manager. Making it work with Mir will require you to turn it into a Mir compositor.
[02:27] <memeka> my impression was that you need android /system + libybris + mir and it should work out-of-the-box with e.g. unity 8
[02:29] <memeka> RAOF: yes I forgot kwin is not mir compositor :P
[02:30] <memeka> so for unity8 + apps like konsole, there shouldn't be anything to code
[02:30] <memeka> while for EGL apps you just need to make them Mir clients
[02:30] <RAOF> As long as konsole doesn't use any X11-only calls.
[02:31] <RAOF> Apparently lots of KDE apps _do_ use X11-only calls (and are now adding Wayland detection, so they'll make X11-only or Wayland-only calls depending on environment variables. Woot!)
[02:32] <RAOF> This seems to me to be a sub-optimal solution over, say, adding support in Qt to abstract these interfaces, but who am I to judge? :)
[02:32] <memeka> I see...
[02:34] <memeka> thanks for the answers...
[02:36] <RAOF> But there shouldn't be _significant_ work required to get, say Konsole to run under a Mir compositor.
[02:37] <duflu> Is there a nice software-blitting console app we should aim to port first?
[02:38] <RAOF> There's kmscon - http://www.freedesktop.org/wiki/Software/kmscon/
[02:41] <RAOF> That actually gets us both software and GLES2-accelerated rendering.
[02:43] <duflu> RAOF: Sounds a little too tied to KMS/DRM
[02:44] <RAOF> Also supports wayland.
[02:44] <RAOF> Though a fork, perhaps.
[02:45] <RAOF> See also, http://www.freedesktop.org/wiki/Software/kmscon/wlterm/
[08:06] <RAOF> And with that Qt Creator lock up, it's EOD for me!
[10:12] <duflu> Wow, throwing and catching exceptions is exceptionally slow. I can actually see the difference on screen :(
[14:44] <asac> racarr__: hey, do you know if stgraber ended up being able to get something going with the lxc container thingy last week?
[16:14] <racarr__> asac: I never heard back
[16:21] <asac> kk
[16:21] <asac> thanks racarr__
[19:57] <AlbertA> kgunn: so I have a branch for compatibility changes to 0.2.0 for unity-mir , do I push this devel now I suppose? what is the workflow now?
[19:58] <AlbertA> kgunn: compat to next revision of mir
[19:58] <kgunn> AlbertA: yes...that would make sense, and _should_ end up giving you a binary in staging
[19:59] <AlbertA> kgunn: how does that work? Just pushing the branch gives you a binary? or after it's merged?
[19:59] <kgunn> the recipes used for unity-mir & papi now use their respecitive devel branches for daily builds
[19:59] <kgunn> https://launchpad.net/~mir-team/+archive/staging
[20:00] <kgunn> you can see here now, papi is failing too...
[20:00] <kgunn> https://launchpad.net/~mir-team/+archive/staging/+build/5971411
[20:00] <kgunn> i assume for the same change ?
[20:02] <AlbertA> ah I see, so basically a compat branch with the debian ver bump should be enough and the next daily build will just pick it up
[20:02] <AlbertA> so it builds against mir devel ?
[20:04] <AlbertA> kgunn: it looks like papi devel is behind trunk
[20:04] <AlbertA> kgunn: or am I reading that wrong
[20:05] <kgunn> AlbertA: well...it shouldn't be, but lemme check
[20:06] <kgunn> yeah...
[20:06] <kgunn> you're right
[20:06] <kgunn> but i guess its just because we've not really tried to commuicate the change in way of working
[20:07] <kgunn> (ci just got going on thurs last week...)
[20:07] <kgunn> AlbertA: also...we need to do this on u-s-c too
[20:08] <kgunn> e.g. there is no u-s-c dev branch
[20:08] <kgunn> atm
[20:08] <AlbertA> kgunn: ok
[20:09] <AlbertA> kgunn: so until that's in place, you can't really build agains mir devel then I suppose
[20:09] <kgunn> right... AlbertA, i'll put one up and see if i can get francis to enable ci on it
[20:20] <kgunn> AlbertA: so for papi-devel, i just merged trunk...but was that really the right way to do it ?
[20:20] <kgunn> i feel its wrong somehow...
[20:20] <AlbertA> kgunn: for this one time yes, to sync them up
[20:20] <kgunn> yeah...
[20:20] <kgunn> i suppose in the future
[20:20] <AlbertA> kgunn: then after this devel should be merged to main
[20:20] <kgunn> the right way would be indy MP's per change just retargeted
[20:20] <AlbertA> kgunn: for the rest of the MP's coming in
[20:21] <AlbertA> kgunn: I see to keep a visible history?
[20:22] <kgunn> exactly
[20:22] <kgunn> AlbertA: ...but not sure how to achieve it ?
[20:22] <AlbertA> you can merge individual revisions from the other branch
[20:23] <kgunn> hmmm AlbertA how to undo what i did?...local bzr revert, then push ?
[20:24] <AlbertA> kgunn: but hold on...I think bazaar does keep history just ...doesn't display it
[20:24] <AlbertA> kgunn: so maybe you don't really want that? it may complain about criss-cross merging
[20:24] <AlbertA> kgunn: in the future when merging from devel to main
[20:25] <kgunn> this would be simpler is trunk were....ah never mind
[20:25] <AlbertA> kgunn: maybe just copy the commit messages to the merge commit?
[20:25] <kgunn> AlbertA: actually...its ok, from the perspective that trunk (release) reflects the right history
[20:26] <kgunn> its only devel which will have a "merged from trunk" item
[20:26] <kgunn> which is totally sensible i think
[20:26] <AlbertA> kgunn: yeah
[20:26] <kgunn> ok..feels slightly less wrong
[20:39] <kgunn> fginther: hey, hope you're well, could you help us out by setting up ci to run ~mir-team/unity-system-compositor/development-branch
[20:39] <kgunn> just like it does for u-s-c's trunk ?
[20:40] <fginther> kgunn, I can actually get to that right now
[20:40] <kgunn> fginther: once that's done, we'll be totally switched onto dev branches
[20:40] <kgunn> cool
[20:55] <racarr__> kgunn: EVerything has dev branches now?
[20:57] <racarr__> that are intended to always build against mir devel
[20:57] <racarr__> ?
[20:57] <kgunn> yes...in the process of writing a mail :)
[20:59] <racarr__> yay
[21:42] <fginther> kgunn, the ci job is ready now
[21:42] <kgunn> fginther: thanks!