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