| === duflu_ is now known as duflu | ||
| duflu | Back in 30ish | 06:54 |
|---|---|---|
| alan_g | alf_: I've got a workman turning up in the next few minutes - I might be a little late for greyback's meeting | 08:53 |
| alf_ | alan_g: ok | 08:53 |
| alan_g | greyback: : I've got a workman turning up in the next few minutes - I might be a little late for your meeting | 08:54 |
| greyback | alan_g: no worries | 08:55 |
| === alan_g is now known as alan_g|afk | ||
| === Cimi_ is now known as Cimi | ||
| === alan_g|afk is now known as alan_g | ||
| === Guest90581 is now known as w00t | ||
| xnox | alan_g: alf_: so emulator is mostly working now. There is functional adb and networking. So far it attempts to boot into "mir" mode. | 10:48 |
| xnox | I've made sure to compile all android container unstripped (so debug symbols are intact) | 10:48 |
| alf_ | xnox: I am missing some context here :) | 10:49 |
| xnox | attempting to start unity8 results in a segmentation fault, trying to run it under gdb only says that stack is corrupt =/ | 10:50 |
| xnox | alf_: so I want to ask for help bringing up mir / any graphical output on the emulator =) | 10:50 |
| alf_ | xnox: which emulator is that? | 10:51 |
| xnox | alf_: sometime back kgunn recommended you or alan_g as UK time people, who can help out with it. | 10:51 |
| alan_g | xnox: what emulator? | 10:51 |
| xnox | alf_: it's android-emulator packaged to run Ubuntu Touch. So it boots unflipped/read-only system image, with an android container. | 10:51 |
| xnox | alan_g: alf_: https://wiki.ubuntu.com/Touch/Emulator | 10:51 |
| xnox | also i've been posting about on ubuntu-touch. | 10:52 |
| xnox | it's a QEMU based ARM virtualised machine, running linux-goldfish kernel with android container and everything mostly the same as normal android device. | 10:52 |
| xnox | (apart from well, not displaying mir) | 10:52 |
| alan_g | xnox: so, what happens if you try running e.g. mir_demo_server_basic? | 10:54 |
| alf_ | xnox: you can try running Mir on its own to see what's going on | 10:54 |
| alf_ | alan_g: You beat me to it! :) | 10:54 |
| alan_g | alf_: is it a race? | 10:55 |
| alf_ | alan_g: No, but we had a photo-finish nonetheless ;) | 10:57 |
| xnox | root@ubuntu-phablet:/# mir_demo_server_basic | 10:58 |
| xnox | bash: mir_demo_server_basic: command not found | 10:58 |
| xnox | (this is running Ubuntu Touch rootfs, should be similar to mako/maguro tarballs et.al.) | 10:59 |
| ogra_ | its in a separate package | 10:59 |
| alan_g | xnox: can you install mir-demos? Or do you need to build it? | 11:02 |
| xnox | alan_g: i can, but it's very slow. I might repack a tarball and relaunch it. | 11:03 |
| * alan_g thinks Mir won't work unless it is installed | 11:04 | |
| xnox | same as before: | 11:17 |
| xnox | root@ubuntu-phablet:/# mir_demo_server_basic | 11:17 |
| xnox | __pthread_gettid -2 | 11:17 |
| xnox | Segmentation fault | 11:17 |
| xnox | which is similar to running unity8 et. al. | 11:17 |
| xnox | http://paste.ubuntu.com/6340712/ | 11:18 |
| xnox | alan_g: alf_: if you could figure out what's broke, i'd be happy to fix it both in android, ubuntu and emulator. But at the moment i'm not sure what's wrong, as pretty much everything else is working. | 11:25 |
| greyback | a BT like that always makes me suspect hybris | 11:26 |
| xnox | and i don't usually work on graphics at all. | 11:26 |
| alan_g | debug symbols might help with the BT | 11:26 |
| alan_g | what happens if you try run "mir_demo_server_basic --display-report log" | 11:27 |
| alan_g | That might give a clue as to how quickly it segfaults | 11:28 |
| alf_ | xnox: +1 debug symbols might help with the BT | 11:28 |
| xnox | alan_g: same output. | 11:40 |
| xnox | alan_g: so it's something fundamental =/ | 11:40 |
| alan_g | xnox: ack | 11:41 |
| xnox | alan_g: alf_: on android side in logcat i see that it's loading up EGL emulation, there is also GLES_android, GLESv1_CM and GLESv2 available. | 11:45 |
| alf_ | xnox: I wonder if running under valgrind could give you more clues | 11:47 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === greyback is now known as greyback|lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === greyback|lunch is now known as greyback | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader is now known as dandrader|lunch | ||
| === mpt_ is now known as mpt | ||
| === brainwash_ is now known as brainwash | ||
| === dandrader|lunch is now known as dandrader | ||
| rsalveti | kdub: ping | 16:29 |
| kdub | hello rsalveti | 16:29 |
| rsalveti | kdub: hey, so we were debugging the nexus 7 (tegra 3) issue yesterday, and we basically believe our code path might not be doing what the driver expects us to do | 16:32 |
| rsalveti | the crash happens in pthread_mutex_lock | 16:32 |
| kdub | rsalveti, 'our code path', meaning in hybris or mir? | 16:33 |
| rsalveti | and the lock is basically a pointer, unitialized | 16:33 |
| rsalveti | kdub: mir, by the way we're using the hwcomposer/gralloc | 16:33 |
| rsalveti | the first time it uses that pointer is already when trying the lock | 16:33 |
| rsalveti | so we believe we might be skipping a call or step that initializes that value internally | 16:34 |
| kdub | rsalveti, i don't know of something that surfaceflinger does that we're skipping | 16:35 |
| kdub | which function call into hybris has the problem? | 16:35 |
| rsalveti | kdub: the pthread_mutex_lock | 16:36 |
| rsalveti | kdub: the mutex pointer is not initialized, so just garbage | 16:36 |
| rsalveti | that's why when we try to access it, it crashes | 16:36 |
| rsalveti | I'm not sure yet that this is hybris specific at this point | 16:37 |
| kdub | right, but do we know the last function call mir makes? | 16:37 |
| rsalveti | do we have any sort of test cases/tools for hwcomposer/gralloc? | 16:37 |
| kdub | just the mir tests | 16:37 |
| === alan_g is now known as alan_g|afk | ||
| kdub | mir_demo_standalone_render_to_fb should just drive the display | 16:38 |
| rsalveti | kdub: right, let me see, the crash happens with mir_demo_server | 16:38 |
| kdub | but it will have the same problem as the server | 16:38 |
| rsalveti | kdub: right | 16:38 |
| rsalveti | kdub: let me try to get a better backtrace | 16:38 |
| rsalveti | kdub: but the issue, iirc, was that it was coming from gralloc | 16:38 |
| rsalveti | which is just a blob, making it harder to get the full trace | 16:39 |
| kdub | right | 16:39 |
| kdub | i mean, it could be some dumb thing like... | 16:39 |
| kdub | on nvidia you have to open {gralloc, fb, hwc} in some specific order | 16:40 |
| rsalveti | kdub: yeah | 16:40 |
| === alan_g|afk is now known as alan_g | ||
| brainwash | how do I switch to hardware cursor when running xmir? | 16:45 |
| === dandrader is now known as dandrader|bbl | ||
| kdub | i always like how the interface you couldn't quite get right at 6pm makes a lot more sense at 10am the next day | 17:34 |
| alan_g | kdub: that's after you've realised how to write the test. Right? | 17:35 |
| kdub | alan_g, yeah, you still have to decide what sort of things you want the test to test | 17:45 |
| alan_g | kdub: well if you don't know what "works" looks like it is hard to get the interface right | 17:46 |
| rsalveti | kdub: yeah, mir_demo_standalone_render_to_fb crashes the same way | 17:56 |
| rsalveti | kdub: do you have a n7 around? | 18:47 |
| rsalveti | kdub: I'm checking render_to_fb.cpp, but it seems the the buffer itself is null | 19:12 |
| rsalveti | which could be the reason for the mutex garbage content | 19:13 |
| kdub | yes, but when you say buffer, you mean, mir's buffer class? | 19:18 |
| === dandrader|bbl is now known as dandrader | ||
| rsalveti | kdub: crashing in src/server/graphics/android/hwc10_device.cpp -> hwc_device->set(hwc_device.get(), 1, &contents); | 19:56 |
| kdub | rsalveti, hmm | 20:07 |
| kdub | i have to tinker with that then | 20:07 |
| kdub | i'm actually working on improving that part of the code at the moment, maybe i'll find somehting | 20:07 |
| rsalveti | kdub: any ideas which we could try? | 20:10 |
| kdub | rsalveti, perhaps the list that's submitted there 'contents' isn't formed the way the driver expects it | 20:12 |
| kdub | hard to so how its malformed without tinkering with it though | 20:12 |
| rsalveti | kdub: so, when we set HWC_SKIP_LAYER at the hwcompositor layer, it doesn't crash | 21:09 |
| rsalveti | kdub: nothing in the screen, as expected, but the gl path and such is working as expected at least | 21:10 |
| kdub | rsalveti, thats good new news | 21:20 |
| rsalveti | kdub: so it might be something related with the hw layers | 21:21 |
| kdub | rsalveti, yes, it looks like it is | 21:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!