| 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:06 |
| 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:07 |
| 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:08 |
| duflu | bschaefer: Yes, that too. "hardware" and "software" are kind of vague words | 01:09 |
| bschaefer | duflu, just a little :) | 01:09 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| RAOF | Hm, maybe? | 01:22 |
| RAOF | I don't think that would be particularly helpful; everything but “software” is platform-specific. | 01:22 |
| duflu | RAOF: Yeah that's enough so long as the type of "hardware" is clarified by the currently loaded client driver-thing | 01:25 |
| RAOF | And that's what mir_surface_get_platform_type tells you. | 01:26 |
| 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:51 |
| racarr__ | oh sorry forgot | 01:56 |
| racarr__ | the meeting | 01:56 |
| 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:57 |
| RAOF | memeka: Have you tried it? That sounds like the major prerequisites :) | 01:58 |
| memeka | RAOF: not yet... planning to | 01:58 |
| 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? | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| memeka | kwin_gles and konsole should work, right? | 02:03 |
| 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:04 |
| duflu | Unfortunately EGL is not sufficiently featured to be a "platform" in itself | 02:05 |
| 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:06 |
| RAOF | duflu: I'll be doing that shortly, once the FrameDroppingPolicy | 02:07 |
| memeka | duflu: and where is the init stuff done? :D | 02:07 |
| 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:08 |
| 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:11 |
| memeka | duflu: thx for the link | 02:13 |
| memeka | duflu: hmm.. the exmaples there have a demo shell and window manager ... so I guess kwin_gles will not work... | 02:15 |
| 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:25 |
| 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:27 |
| memeka | RAOF: yes I forgot kwin is not mir compositor :P | 02:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| memeka | thanks for the answers... | 02:34 |
| RAOF | But there shouldn't be _significant_ work required to get, say Konsole to run under a Mir compositor. | 02:36 |
| duflu | Is there a nice software-blitting console app we should aim to port first? | 02:37 |
| RAOF | There's kmscon - http://www.freedesktop.org/wiki/Software/kmscon/ | 02:38 |
| RAOF | That actually gets us both software and GLES2-accelerated rendering. | 02:41 |
| duflu | RAOF: Sounds a little too tied to KMS/DRM | 02:43 |
| RAOF | Also supports wayland. | 02:44 |
| RAOF | Though a fork, perhaps. | 02:44 |
| RAOF | See also, http://www.freedesktop.org/wiki/Software/kmscon/wlterm/ | 02:45 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | And with that Qt Creator lock up, it's EOD for me! | 08:06 |
| duflu | Wow, throwing and catching exceptions is exceptionally slow. I can actually see the difference on screen :( | 10:12 |
| === 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 | ||
| asac | racarr__: hey, do you know if stgraber ended up being able to get something going with the lxc container thingy last week? | 14:44 |
| === chihchun is now known as chihchun_afk | ||
| racarr__ | asac: I never heard back | 16:14 |
| asac | kk | 16:21 |
| asac | thanks racarr__ | 16:21 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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:57 |
| 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:58 |
| 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 | 19:59 |
| 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:00 |
| 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:02 |
| AlbertA | kgunn: it looks like papi devel is behind trunk | 20:04 |
| AlbertA | kgunn: or am I reading that wrong | 20:04 |
| kgunn | AlbertA: well...it shouldn't be, but lemme check | 20:05 |
| 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:06 |
| 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:07 |
| kgunn | e.g. there is no u-s-c dev branch | 20:08 |
| kgunn | atm | 20:08 |
| AlbertA | kgunn: ok | 20:08 |
| 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:09 |
| 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:20 |
| AlbertA | kgunn: I see to keep a visible history? | 20:21 |
| 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:22 |
| kgunn | hmmm AlbertA how to undo what i did?...local bzr revert, then push ? | 20:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:39 |
| 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:40 |
| racarr__ | kgunn: EVerything has dev branches now? | 20:55 |
| 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:57 |
| racarr__ | yay | 20:59 |
| fginther | kgunn, the ci job is ready now | 21:42 |
| kgunn | fginther: thanks! | 21:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!