| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mlankhorst | mali hw is weird :P | 04:46 |
|---|---|---|
| === alf|xmir-devel is now known as alf_ | ||
| === jono is now known as Guest64072 | ||
| alf_ | RAOF: My attempts to reuse the dri screen in platform Mir have been unsuccessful so far (see http://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment). I am probably missing some background to make this work, and I don't think it is productive to try blindly now. Hopefully we can tackle this next week. | 08:19 |
| alf_ | alan_g: FYI, ^^ | 08:19 |
| alf_ | RAOF: (reuse the gbm device's dri screen in platform mir) | 08:20 |
| alan_g | alf_: that's about resolving the gbm stack problems for nesting Mir? | 08:21 |
| alf_ | alan_g: yes | 08:21 |
| === alf_ is now known as alf|afk | ||
| alf|afk | nick alf_ | 10:20 |
| === alf|afk is now known as alf_ | ||
| alan_g | alf_: have you time/headspace to look at nested/android egl with me? | 10:34 |
| alf_ | alan_g: sure, although I am not currently set up to try it out on a device | 10:35 |
| alan_g | alf_: I'm set up - but I can't make sense of what I see. Grab lp:~alan-griffiths/mir/multiwin-hacks-for-nested/ | 10:36 |
| alf_ | alan_g: ok | 10:38 |
| alan_g | What I see is that multiwin works when talking to the host Mir session, but if talking to the nested one the screen remains blank | 10:38 |
| alan_g | I've tried various things, but the only thing that makes a difference is increasing the alpha on the windows. I.e. with alpha 0x50 the screen is blank, with 0xe0 it shows transparent windows | 10:40 |
| alan_g | With 0xff the windows are solid | 10:41 |
| alf_ | alan_g: where do you change the alpha? | 10:42 |
| alan_g | multiwin.c | 10:42 |
| alf_ | alan_g: is there a cutoff alpha value for visibility (e.g. the 0xe0 you mentioned?), or from 0x50 to 0xe0 the opacity is gradually increased? | 10:47 |
| alan_g | alf_: just doing a binary search... | 10:47 |
| alan_g | between 0xa0 (fail) and 0xb0 (pass) | 10:48 |
| alf_ | alan_g: btw, which pixel format does multiwin reports that it is using? | 10:50 |
| alan_g | 0xa0 fails and 0xa1 passes | 10:51 |
| alan_g | 1 - mir_pixel_format_abgr_8888 | 10:51 |
| alan_g | FWIW that's the same for talking to host and to nested | 10:52 |
| === hikiko is now known as hikiko|lunch | ||
| alf_ | alan_g: can you try 1. changing egl_attribs in nested_output.cpp to match the ones used in nested_display | 11:05 |
| alan_g | alf_: yes | 11:06 |
| * alan_g missed the change from using mgn::nested::attrbutes | 11:07 | |
| alan_g | alf_: that does it | 11:10 |
| alf_ | alan_g: \o/ | 11:10 |
| alan_g | thanks | 11:10 |
| alf_ | alan_g: yw | 11:11 |
| * alan_g knew it would seem obvious once someone pointed it out | 11:11 | |
| * alf_ wonders what strange format the android EGL impl. had selected to cause the alpha cutoff... perhaps something with EGL_ALPHA_VALUE = 1? | 11:15 | |
| alf_ | (1 bit of alpha) | 11:15 |
| alan_g | alf_: Wouldn't that just give blank or opaque | 11:17 |
| alf_ | alan_g: right, I forgot that we had a translucent state too | 11:20 |
| alan_g | alf_: hold a moment - it might not be working after all. | 11:25 |
| alf_ | alan_g: holding on... | 11:25 |
| alan_g | WTF I'm now running the same instrumented version that appeared to work...and it doesn't | 11:28 |
| alan_g | Not sure what happened when it appeared to work | 11:28 |
| alan_g | :( | 11:28 |
| alan_g | Hmm, there's now some intermittent working | 11:34 |
| === tkamppeter_ is now known as tkamppeter | ||
| alan_g | alf_: OK, the images through nested are a lot fainter than with the host. (Like the alpha is applied in the host render too?) | 11:38 |
| alf_ | alan_g: Is this condition stable, is that what you were seeing before thinking it didn't work? | 11:41 |
| alf_ | alan_g: also is the alpha rendered gradually (though fainter) in this case? | 11:42 |
| alan_g | alf_: am still experimenting - the change had an effect, but when I tidied the code I tried a lower alpha and couldn't see the image | 11:44 |
| alan_g | alf_: Sorry - have to deal with a crisis | 11:48 |
| === alan_g is now known as alan_g|afk | ||
| === mzanetti is now known as mzanetti|lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === dandrader|afk is now known as dandrader | ||
| === mzanetti|lunch is now known as mzanetti | ||
| alan_g | alf_: OK, now I'm looking more carefully, I've also noticed that the nested image from egltriangle is fainter than that from the host session. | 13:21 |
| alan_g | (It is harder to tell with plasm or fingerpaint) | 13:25 |
| alf_ | alan_g: perhaps changing the clear color in gl_renderer.cpp will give more visual clues (e.g. glClearColor(1.0f, 1.0f, 1.0f, 1.0f); before glClear()) | 13:26 |
| alf_ | alan_g: also I wonder... we are probably getting an argb surface from mir but are using an EGL config without alpha | 13:27 |
| alf_ | alan_g: two things to try: 1. force nested mir to create an opaque mir surface with mir_pixel_format_xbgr | 13:30 |
| alf_ | alan_g: (and separately) 2. ask for a config with ALPHA | 13:30 |
| alan_g | alf_: can we do that when the only supported format is mir_pixel_format_abgr_8888? | 13:31 |
| alan_g | What's the incantation for 2? "EGL_ALPHA_SIZE, 8,"? | 13:32 |
| alf_ | alan_g: yes | 13:32 |
| alan_g | changing the clear colour just changes the background - no obvious artefacts | 13:35 |
| alf_ | alan_g: @mir_pixel_format we can, it is supported according to the Android code. Actually the pixel formats we are checking in nested mir are the pixel formats of the display (e.g. of a scanout surface). We need to check the surface formats for now (unless we want to use bypass, which is another story). | 13:35 |
| alan_g | alf_: the pixel format seems to be an answer. | 13:47 |
| alf_ | alan_g: good to hear, let's see if (2) works too | 13:51 |
| alan_g | alf_: no - that doesn't work | 13:55 |
| alf_ | alan_g: is the background color also more faint? | 13:56 |
| alan_g | alf_: I reverted that change - but don't remember there being a difference. Am checking the pixel format logic - as forcing argb also seems to work. | 13:58 |
| alan_g | No that was a mistake. | 14:11 |
| alan_g | I'll check the background | 14:11 |
| alan_g | alf_: no change to the background colour. | 14:17 |
| dandrader | kgunn, I'm knee deep in the work of modifying android-input to support gesture accept/reject. I wonder if I should join mir daily standups so that people are aware of what I'm doing | 14:22 |
| kgunn | might not be a bad idea dandrader ....altho you'll have encourage racarr to join if you want him there (it's an 8am for him...he'll make it on demand :) | 14:23 |
| kgunn | dandrader: put you on the invite...its in 30 minues | 14:24 |
| kgunn | minutes even | 14:24 |
| dandrader | hmm, right. indeed the main point is in having racarr aware of it | 14:25 |
| dandrader | kgunn, ^ | 14:25 |
| alan_g | alf_: requesting egl config with alpha works. but only with glClearColor(_, _, _, 1.0f) | 14:29 |
| alan_g | So because I'd reverted the glClearColor() call it didn't | 14:30 |
| alan_g | alf_: so I have two fixes and too little knowledge to chose the best. | 14:32 |
| alan_g | 1. Add glClearColor(0.0f, 0.0f, 0.0f, 1.0f); and EGL_ALPHA_SIZE, 8, | 14:32 |
| alan_g | 2. use mir_pixel_format_xbgr_8888 regardless | 14:33 |
| alan_g | alf_: is there a 3? | 14:33 |
| alf_ | alan_g: nothing comes to mind... I think it makes sense for nested mir to draw to an opaque surface, since it is its "framebuffer" (host mir renders to an opaque buffer too). I don't think we currently have a use case for nested mir needing selective translucency. | 14:37 |
| alan_g | alf_: OK, does it make sense for the glClearColor(0.0f, 0.0f, 0.0f, 1.0f) to stay in GLRenderer::clear()? | 14:38 |
| alan_g | Or is there a better place in the nested code? | 14:39 |
| alf_ | alan_g: of course, ideally, we won't hardcode to xbgr_8888, but search the formats instead for a supported opaque format. | 14:41 |
| alf_ | alan_g: as long as our "framebuffer" surfaces are opaque, setting the clear color alpha to 1.0f doesn't make a difference | 14:42 |
| alan_g | alf_: I understand that, but do we have a suitable list of formats to search? | 14:51 |
| alf_ | alan_g: mir_connection_get_available_surface_formats | 14:52 |
| alan_g | alf_: I'll have a look there. | 14:53 |
| === sam113101 is now known as sam113101_afk | ||
| kgunn | kdub: mornin' you on ? | 15:27 |
| kdub | kgunn, yep | 15:28 |
| kdub | good morning | 15:28 |
| kgunn | kdub: hey so pending is all good (sort of)... | 15:28 |
| kgunn | flash, then apt-get dist-upgrade it....then rm surfaceflinger, mod env file, etc | 15:28 |
| kgunn | basically...our #1 is the little white flickers | 15:29 |
| kgunn | http://www.youtube.com/watch?v=HaPKxLh9_So | 15:29 |
| kgunn | kdub: ^ | 15:29 |
| kdub | kgunn, i see... | 15:30 |
| kdub | haven't seen that before | 15:30 |
| kdub | will look of course | 15:30 |
| kgunn | kdub: gerry says it doesn't exist on GN...and actually...i have always seen it on N4 | 15:30 |
| kdub | yeah, looks like something framebuffer related perhaps | 15:31 |
| kgunn | tvoss said it wasn't in this video https://plus.google.com/u/0/photos/117745549829232162250/albums/5922939740350969137/5922939748109840754?authkey=CMau8ZXwtKyjuwE | 15:31 |
| kgunn | but if you look real close....it was there | 15:32 |
| kgunn | its 2 weeks old...so yeah... | 15:32 |
| kgunn | i'm thinkin' some niggling android fb thing | 15:32 |
| kdub | kgunn, when we say flash these days... is that 'cdimage-touch' or 'ubuntu-system' | 15:34 |
| kdub | i don't really know the different :-[ | 15:34 |
| kgunn | cdimage-touch kdub | 15:35 |
| kdub | kgunn, ok, thanks | 15:35 |
| kgunn | kdub: at least i 've seen some struggles with systemimage....but if you want to try ....do this https://www.stgraber.org/2013/09/05/ubuntu-touch-system-images-now-default/ | 15:38 |
| kgunn | greyback: you've been doing cdimage as i have right ? | 15:38 |
| greyback | kgunn: I've been using it, yes | 15:39 |
| kgunn | greyback: do you have any idea what touch /home/phablet/.display-mir is ? | 15:39 |
| greyback | kgunn: yes, that's the switch used to decide whether to boot in SF mode, or Mir | 15:39 |
| greyback | if that file exists, it boots Mir, else.. | 15:40 |
| === sam113101_afk is now known as sam113101 | ||
| kgunn | greyback: is it shearly the file existing ? or does it need content? | 15:54 |
| kdub | good morning racarr | 15:55 |
| alan_g | alf_: Does this make sense? https://code.launchpad.net/~alan-griffiths/mir/multiwin-fix-for-nested/+merge/185535 | 15:56 |
| greyback | kgunn: just the file existing | 15:56 |
| davmor2 | kgunn: there is an email that says just touch the file and then sergiusens also said as much, the operation of the gfx is slower and jumpier with the file in place too | 15:57 |
| davmor2 | kgunn: you have to reboot after creating the file | 15:58 |
| kgunn | davmor2: hmmm | 15:58 |
| greyback | kgunn: yep, sorry reboot is needed after creating/deleting the file | 15:58 |
| kgunn | davmor2: the way i am running...mod'ing the environment file for the qpa to be ubuntumirclient & deleting surf flinger | 15:58 |
| kgunn | with good results | 15:58 |
| kgunn | wondering if using the .display-mir is not quite right | 15:59 |
| greyback | kgunn: none of that is necessary now, that "touch /home/phablet/.display-mir" command looks after all that for you | 15:59 |
| kgunn | greyback: yeah...just wondering, so many complaints with that... | 15:59 |
| kgunn | vs old way | 15:59 |
| greyback | kgunn: really? What problems are people having? | 16:00 |
| kgunn | davmor2: ^ can you share | 16:00 |
| davmor2 | greyback: gfx transitions are slow, opening contacts from the launcher has locked the screen repeatedly | 16:01 |
| greyback | davmor2: you using a Galaxy Nexus? | 16:01 |
| davmor2 | greyback: Yeap | 16:01 |
| racarr | Morning | 16:01 |
| greyback | davmor2: unfortunately the slow gfx is a Mig bug, being worked on I believe | 16:02 |
| greyback | davmor2: crashiness is probably my problem | 16:02 |
| greyback | davmor2: all you're doing is launching the contacts apps from the launcher, yes? | 16:02 |
| davmor2 | greyback: let me go through the steps once more to confirm and I'll throw a bug together for it | 16:03 |
| greyback | davmor2: appreciated, thank you. Please log against "unity-mir" | 16:03 |
| davmor2 | greyback: any logs that would be useful? | 16:04 |
| greyback | davmor2: the contents of $HOME/.cache/upstart/unity8.log would be great | 16:04 |
| davmor2 | greyback: no worries give me about 10 minutes | 16:04 |
| greyback | cheers | 16:04 |
| * alan_g decides it is time to prepare laptop and netbook for sprint | 16:05 | |
| kdub | oh yeah, i should do that too :) | 16:05 |
| kdub | my quarterly 'upgrade the laptop for the sprint!' | 16:05 |
| kgunn | davmor2: funny kdub was just asking me about my post on performance GN vs N4 | 16:06 |
| kgunn | davmor2: https://plus.google.com/116997345010659023379/posts/cWSUVkvpGax | 16:06 |
| kgunn | GN is a dog for oh so many reasons | 16:06 |
| davmor2 | kgunn: yeah but at the time it was the phone I could afford :) | 16:08 |
| davmor2 | greyback: I think I have it nailed now it's if you drag the launcher out while the app is still loading. I.e. while contacts is still light grey (before the contacts info/title loads) open the launcher again. It probably happened on the Surface flinger too but didn't present due to the addition speed | 16:12 |
| greyback | davmor2: good observation. I'll try to repo shortly (compiling) | 16:14 |
| racarr | ricmm: I am moving the screen blanking branch to lp:~robertcarr/mir/dpms-with-screen-blanking | 16:16 |
| racarr | contains the DPMS base too | 16:16 |
| ricmm | ok great | 16:18 |
| davmor2 | greyback: https://bugs.launchpad.net/unity-mir/+bug/1225077 | 16:27 |
| ubot5` | Launchpad bug 1225077 in unity-mir "Maguro: Opening launcher before an app is fully loaded crashes the gfx" [Undecided,New] | 16:27 |
| greyback | davmor2: thank you! | 16:27 |
| * greyback needs to reboot, bbiab | 16:30 | |
| racarr | kdub: I am just finishing off my unit tests for android screen blanking | 16:31 |
| racarr | want a test like....uh...well that just tests display::Configure | 16:31 |
| racarr | Display::configure oO | 16:31 |
| racarr | applies the PowerMode to the DisplayBuffers | 16:32 |
| racarr | fromt eh configuration | 16:32 |
| kdub | racarr, integration test? | 16:32 |
| racarr | Is there a test fixture that deals already with mocking the Display buffers? | 16:32 |
| kdub | there's one that actually drives the display :) | 16:32 |
| racarr | kdub: no I think its a unit test on android_display | 16:32 |
| racarr | that, uses a mock framebuffer window, and a stub display buffer factory that returns mock display buffers | 16:32 |
| kdub | kgunn, been playing with this for a while, haven't seen the flicker yet | 16:33 |
| racarr | I saw the flicker the last time I set up unity-mir (~2 days) | 16:33 |
| kdub | hmm, is it always white like I saw in the video? | 16:33 |
| racarr | no | 16:34 |
| racarr | ok well actually I have seen two things | 16:34 |
| kdub | oh, just saw a tear | 16:35 |
| racarr | 1 week or so ago I was seieng some "flickering" which actually semeed to be the app underneath the shell bubbling up a frame | 16:35 |
| racarr | and then, 2 days ago was seeing | 16:35 |
| racarr | tearing | 16:35 |
| racarr | but nothing I would call "flickering" I guess | 16:35 |
| racarr | just tearing | 16:35 |
| kdub | like a split screen vertical tear | 16:35 |
| racarr | oh | 16:35 |
| racarr | err | 16:35 |
| racarr | do you mean a horizontal tear from missign vsync | 16:35 |
| racarr | or an actual vertical tear | 16:36 |
| kgunn | kdub: open up some apps | 16:36 |
| kgunn | maybe ? | 16:36 |
| kdub | kgunn, just saw it | 16:36 |
| kdub | its pretty similar to things i've seen from hwc before... have to dig a bit | 16:36 |
| kdub | our demos should have a 'bank' of animations to select from on the command line | 16:37 |
| kdub | especially animations that are well-known to expose visual problems | 16:37 |
| kdub | like... scrolling :) | 16:37 |
| racarr | how about we make that my new job, writing animations in the demo clients | 16:38 |
| racarr | should take me like 2-3 months, real intense focus | 16:38 |
| racarr | ok thanks kgunn | 16:38 |
| kdub | hey, i thought of it! my job! | 16:38 |
| kdub | :) | 16:38 |
| kgunn | u guys | 16:39 |
| racarr | :p | 16:39 |
| alan_g | I think the boss wants to steal that task | 16:39 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | :) | 17:23 |
| mlankhorst | shake it | 17:56 |
| mlankhorst | we need the full compiz fusion set of plugins ;) | 17:56 |
| mlankhorst | wobbly windows you give some acceleration and watch it fly over the screen | 17:57 |
| * greyback eow | 18:11 | |
| === dandrader|lunch is now known as dandrader | ||
| racarr | Lunch! | 18:39 |
| * kdub lunch | 19:12 | |
| racarr | back | 19:30 |
| === dandrader is now known as dandrader|afk | ||
| * kdub back | 19:46 | |
| === dandrader|afk is now known as dandrader | ||
| kgunn | kdub any news? | 20:08 |
| kdub | no, keep hitting walls getting into a test/compile/test cycle | 20:09 |
| kdub | it looks like something hwc-related though to me | 20:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!